S
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