Hello All, Now that I've had some time to think, I'd like to follow up on the ideas I put forward about "Pipes" connecting PuffinPLC "Nodes". Remember, the purpose of these Pipes is to make commissioning and on-site debugging easier, even if you're using hardware and software from different sources. First of all, I'd like to define the following terms, whether or not they've been defined before: PuffinPLC Node (PPLC): - This isn't necessarily the LinuxPLC, but LinuxPLC is an implementation of a PuffinPLC. A PPLC has the following characteristics: it contains data (points) that are of length 0 to 32 bits, and it interfaces with local modules that "own" these points. Module: - These are objects that have access to, and own the "points" in the PPLC. They may perform any other task, such as I/O, logic, etc. In this case, I would like to define two modules with special attributes: "Link Modules", and "Vendor Config Modules". Link Modules: - I'm defining this as any module that offers the *possibility* of connecting with *another* PPLC. This would be determined by the module itself when it registered with the PuffinPLC Node - letting it know that it is a Link Module. This could include modules that interface with a network, or even ones that connect two PPLC's on the same local machine. Vendor Config Modules: - Each PPLC will allow at most *one* of its modules to be registered as a Vendor Config Module. This module, as the name suggests, is vendor (or system) specific, but it's basically a way of saying "this module manages vendor specific remote configuration." Some of this configuration might be uploading new firmware to the device, changing PPLC parameters, or whatever the specific implementation requires. It's just a module that's registered to perform a service. ----- Now that the definitions are out of the way, I'd like to introduce the idea of a Pipe. The Pipe is just a virtual connection between two PuffinPLC's, with specific attributes that make the control system integrator's life much easier. First, an example scheme: On one Node: Originating Module | V PuffinPLC A <-> Link Module <-> Physical media On another Node: Physical media <-> Link Module <-> PuffinPLC B Assume that a Pipe connects PPLC A, and PPLC B. This Pipe has the following properties: 1. The pipe is originated by *any* module on PPLC A. I am assuming this would be some kind of configuration software tool, but it could be any module. 2. Over the pipe, the originating module can request any of the points on PPLC B. Access rights may not permit this, but that is beyond the scope of this RFC. Note that this functionality is implemented by PPLC B - i.e. it responds to the request. 3. The pipe is directional. A module on PPLC B can't use the pipe to request points on PPLC A, for instance. 4. The connection is tested regularly to ensure that communication has not been disrupted. If the communication check fails, the originating module is informed, and the Pipe ceases to exist. It is the originating module's responsibility to attempt a reconnection at this point. 5. The originating module can request a list of all "Link" modules attached to PPLC B. The originating module can use any of these Link modules to establish a Pipe to another PPLC, say PPLC C. Note that this is an *extension* of the A->B pipe, that we can call the A->B->C pipe. None of the modules on B are allowed use the B->C pipe (they have to originate their own). 6. If a Vendor Config Module exists on B, then the originating module may send and receive unstructured (Vendor defined) data over the pipe. This assumes that the originating module is a Vendor supplied configuration manager for PPLC B, and therefore it understands and speaks the particular Vendor defined data format for this implementation. ---- No matter what, this gives you the ability to access point data from anywhere on the network, for monitoring purposes. It also allows you to check the integrity of the communications links in the system (i.e. can one node "see" another?). As far as implementing this RFC, my goal is to keep the overhead to a minimum, and weight the bulk of the work towards the originating end of the pipe. This means that you could plug very simple PPLC compliant nodes onto your network (a "smart" photoeye, for example) that could easily respond to the basic idea of a Pipe. It would supply no Link modules (therefore not needing to implement the overhead), and perhaps not even a Vendor Config Module, but it would allow you to access the data point(s) on that node, and verify the network integrity. Well, this is an RFC, so fire away! Scott _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Scott Whitlock wrote: > > Hello All, > > Now that I've had some time to think, I'd like to > follow up on the ideas I put forward about "Pipes" > connecting PuffinPLC "Nodes". Yes... I too have finally found some time to think! But not much, I am still undecided how best to structure some of the functionality... > (...) > First of all, I'd like to define the following terms, > whether or not they've been defined before: > > PuffinPLC Node (PPLC): > - This isn't necessarily the LinuxPLC, but LinuxPLC > is an implementation of a PuffinPLC. Yes, I like the above. > Module: > - These are objects that have access to, and own the > "points" in the PPLC. They may perform any other > task, such as I/O, logic, etc. In this case, I would > like to define two modules with special attributes: > "Link Modules", and "Vendor Config Modules". > > (HUGE snip...) I don't like modules with special attributes. I would prefer to keep them as generic as possible. But yes, I understand your motives, so I might go along to a certain extent. I would do without the "Vendor Config Modules" (but not their functionality, please read on...), and separate the "Link Modules" into two entities: a "Node Manager Module", and a "Gateway". Note that the gateway is _not_ a module! Node Manager Module (nmm) ------------------------- This would be a 'special' module that would allow external control of the PuffinPLC node. Things that could be controlled could be, for example: - determine the state of plc points - force the state of plc points - start/suspend/stop the whole plc node - start/suspend/stop a module - download/upload global plc configuration data - download/upload module specific configuration data This module would accept remote comands from several sources (TCP/IP, fieldbus network, RS232 port, etc...). It will therefore have a rather complex internal structure. We will need to augment the current puffinplc library to support some of the above functionality. This module would always run asynchronously from the rest of the modules, so maybe we should not view it as a module afterall. It would nevertheless have to accept simultaneous commands from the various sources (TCP/IP, RS232, etc...), and make sure they make sense and don't interact in funny ways. This will probably lead us to some very nasty situations. We should probably try and re-structure this module some other way?!?!? Maybe as multiple modules, one for each transport protocol?!?!?!? I still have to think this through...! This module would also have access to the configuration memory, where every module should store their global and configuration data (Note: this is not yet implemented and the puffinplc library does not yet support it). This way it could download a block of opaque data to store in the configuration memory area used by a certain module. It does not have to understand what the config data means. It only needs to know the name of the module the configuration data is for, and the offset within the configuration memory of that module to which the nmm shopuld store the opaque config data. This means that Scott's "Vendor Config Modules" are not required! What we really need is a communication protocol that would allow us to issue such commands remotely, hopefully the same for every transport protocol. The Gateway ----------- The gateway would be a process, independent from any PuffinPLC node, that would function as a gateway between several transport protocols for the above mentioned PuffinPLC Command Protocol. It may be run on any machine, even on machines already running a PuffinPLC node. This gateway would need to be able to dynamically find any PuffinPLC that resides on the networks to which it is connected, etc... This would allow the Scott's pipes to work. Scott, I think this would provide the functionality you desire, but is more in keeping with the PuffinPLC architecture. What do you say? Jiri, I'm sure you can find many holes in what I have described. Could you please point to them! Cheers, Mario. -- ---------------------------------------------------------------------------- Mario J. R. de Sousa [email protected] ---------------------------------------------------------------------------- The box said it requires Windows 95 or better, so I installed Linux _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc