Hi All, I must admit that I'm not much of a lurker, because I haven't been lurking all that long. Please excuse any of my comments that seem silly/redundant/etc.. Apparently what you're trying to do with the LinuxPLC/PuffinPLC project is to make the basis for a free PLC, that anyone can use, and anyone can add to. True open source, and I'm very excited. Now, let me give you a few background details about myself - I took engineering in university, and have since been working in the Control Systems Integration field. My experience includes: OSes: Windows, QNX 4.x, QNX Neutrino, QNX RTP, and Linux. Throw in a real time OS course in there too. Controllers: Modicon Compact 984, AB SLC500, PLC5, and ControlLogix 5000. Also, Steeplechase VLC. FieldBus technologies: DeviceNet, ControlNet. ----------- Now, I'm eager to participate in this project, but my first reaction is that there is a lack of direction or vision. If I may make a comparison, when Linus Torvalds started Linux, he had a very clear goal in mind: "Make a UNIX for the PC". I think that someone needs to state a similar one-liner, and make it the motto of your project. Several suggestions come to mind... "Make a PLC for Linux", for instance. However, that doesn't quite capture what I think it is you're trying to do here. Your real motive, perhaps, is to "Create an open PLC architecture". That way, you're not tying yourself to any particular OS, or hardware. Some of you are probably wrinkling your foreheads right now, so let me try to explain with an analogy. Most of you are probably familiar with the concept of object oriented programming, and many of you have expressed interest in applying these concepts to PLCs. Now, in an OO environment, if you want to create something big, you don't need to start writing classes - all you really need to do is design a really good set if interfaces to those classes. The implementation can't be written until the interface is defined. Back to PuffinPLC... Rather than actually saying that your PLC is a group of processes running on a Linux box (which, by the way, is an *excellent* beginning), try saying that the "PLC Node" is really just a collection of "points" (instances of various data types) with built-in controls to limit access to those points. A "module" (good word) is an "executive" that accesses the points in a PLC Node (read and write). Note that you've already begun this with your idea of a central memory manager that co-ordinates communications amongst various modules. I would suggest one other addition... to borrow from the world of Unix, consider a *virtual* entity called a "Pipe". A Pipe moves a set of points from one PLC Node to another (think producer/consumer). A pipe might consist of a module that connects a PLC Node to a fieldbus, and another module at the other end that connects the fieldbus to another PLC Node. Another simpler situation might be a module that connects two PLC Nodes that reside on the same computer. The importance of a pipe is not that it moves data, but rather that it provides built-in handshaking between the two PLC Nodes. Now, as an integrator, I could design my system as a group of PLC Nodes, and I can put them wherever I want... two on this processor, one over here... I can use the Pipes as the synchronous binding of the system, and any two nodes can talk to each other to share the data (status, I/O, etc.) they need. Here's the important part for me though... Plug'n'Play. I want to be able to plug a new processor into my system, with preloaded Nodes and modules on it, and then I want to be able to dynamically create a virtual Pipe from wherever I'm currently logged on, to that new PLC Node, through any number of intermediate Nodes, so that I can do an online test and configuration of that new hardware. Basically, every PLC Node also needs to act as a *bridge* between any two of its communication links (modules). ...and then I want the interface scalable enough that it can be implemented (in basic form) on something as small as a microcontroller. I want to be able to plug a microcontroller PLC Node into my parallel port, and then create a pipe to that microcontroller through every intermediate node on the network, and through the parallel port driver module, so that I can access the internal coils of the PLC Node in that microcontroller. Can we do this?!?!? Please.... I want to help! _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Hello Scott Whitlock, welcome! > Apparently what you're trying to do with the LinuxPLC/PuffinPLC project > is to make the basis for a free PLC, that anyone can use, and anyone can > add to. Yes. > Now, I'm eager to participate in this project, but my first reaction is > that there is a lack of direction or vision. ... > Several suggestions come to mind... "Make a PLC for Linux", for instance. > However, that doesn't quite capture what I think it is you're trying to > do here. Your real motive, perhaps, is to "Create an open PLC > architecture". That way, you're not tying yourself to any particular OS, > or hardware. I think it's somewhere between those two - in the abstract we want to create an open PLC architecture, but in the concrete we are making a PLC for Linux. Mostly, these two aims are compatible; where they conflict, pragmatism favours the latter (though a rethinking may be indicated). > Back to PuffinPLC... Rather than actually saying that your PLC is a > group of processes running on a Linux box (which, by the way, is an > *excellent* beginning), try saying that the "PLC Node" is really just a > collection of "points" (instances of various data types) with built-in > controls to limit access to those points. Good word, `node'. I think it's been adopted... > A "module" (good word) is an "executive" that accesses the points in a > PLC Node (read and write). Yup. > Note that you've already begun this with your idea of a central memory > manager that co-ordinates communications amongst various modules. Yup - that's what a node is in PuffinPLC. Actually, currently a node consists of a collection of IPC resources and a shared library. There's no process associated with it, the manager just sets it up or takes it down. > I would suggest one other addition... to borrow from the world of Unix, > consider a *virtual* entity called a "Pipe". A Pipe moves a set of > points from one PLC Node to another (think producer/consumer). A pipe > might consist of a module that connects a PLC Node to a fieldbus, and > another module at the other end that connects the fieldbus to another PLC > Node. Useful abstraction, and a nice short word for it. > Another simpler situation might be a module that connects two PLC Nodes > that reside on the same computer. That'll be a pain to write, because the library's not that reentrant But it'll be a useful module to have. > The importance of a pipe is not that it moves data, but rather that it > provides built-in handshaking between the two PLC Nodes. I'm not sure what sort of handshaking you envision, apart from the data transfer being atomic, and the protocol required to make the data exchange happen at all. Anything else? > I want to be able to dynamically create a virtual Pipe from wherever I'm > currently logged on, to that new PLC Node, through any number of > intermediate Nodes, so that I can do an online test and configuration of > that new hardware. Why? You can simply telnet or X to the machine you want to test/configure and skip the intermediate steps. Unlike certain other systems, Unix already *has* remote administration; we don't need to re-implement it. > Basically, every PLC Node also needs to act as a *bridge* between any two > of its communication links (modules). In some ways, it can't help but do that. That's its primary function - to act as the bridge between all its modules (pipes, io, logic, whatever). On the other hand, every node in the chain will add latency. The integrator will need to be careful with those, and design the topology appropriately. Jiri -- Jiri Baum <[email protected]> Q: Why did the chicken cross the Moebius Strip? A: To get to the other... um... er... --r.h.f.r _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Hi Scott, Welcome! I'm sorry, but I have read your message twice and I can't really understand what it is you are trying to achieve with the 'pipe' entity. You can certainly connect two PLC nodes with a network. Just use two communications modules, one in each node, talking to each other. Of course, you still have to configure the data they will be exchanging. I understand you want something more than this, but I don't quite understand what it is. What is it that you want the pipe to achieve automatically? Do you want complete access to the remote node? Let me just add something that has been at the back of my mind for some time (and you can certainly find comments relating to it in the gmm code). I was considering the possibility of allowing modules to run on one CPU but access the global memory on a remote CPU. They would in essence be part of a PLCnode that was running on a remote CPU. This would be done with a --PLCremote option when launching the remote module, instead of a --PLClocal (the current default) or --PLCisolate options.This would be handled entirely within the gmm library, and it would be invisible to the module, besides the larger delays when calling plc_update(). Since then I coded the synchronisation library, and I have not yet considered how we could implement the remote option for this library. Jiri persuaded me not to code this as it would make more sense to have two PLCnodes running with two modules communicating between them, but now it seems you are asking for something similar? Maybe I am mis-undertsanding you? Currently we have many ideas, but very few people to code them. Do you want to help out with writing code? If so, please email me directly with what kind of code you prefer writing, and I'm sure we'll find something for you to do. 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

 

Mario de Sousa (in response to Scott Whitlock): > I'm sorry, but I have read your message twice and I can't really > understand what it is you are trying to achieve with the 'pipe' entity. > You can certainly connect two PLC nodes with a network. Just use two > communications modules, one in each node, talking to each other. Of > course, you still have to configure the data they will be exchanging. If I understood Scott correctly, that's exactly what a pipe should do... It's just a word for the abstract concept, just like we already have ``logic'' modules and ``io'' modules. In some ways pipe modules will necessarily overlap with io modules; for instance, a fieldbus module can be used as either a pipe or as io. But that doesn't make the concept any less useful. In particular, where the other end of a pipe is another PuffinPLC, there are certain assumptions we can make about it. > I understand you want something more than this, but I don't quite > understand what it is. What is it that you want the pipe to achieve > automatically? Do you want complete access to the remote node? If we know the node is there, and it's another PuffinPLC, then its remote configuration interface (hypothetical) can be used to obtain descriptions for the points, start up a new module to get another pipe, and so on. > Currently we have many ideas, but very few people to code them. Do you > want to help out with writing code? If so, please email me directly with > what kind of code you prefer writing, and I'm sure we'll find something > for you to do. Have a look at lplc-article.txt and structure.txt in the doc directory (if you haven't already), they explain some of the architecture of PuffinPLC. If you don't have CVS handy, you can get them off the web at http://www.linuxplc.org/cgi-bin/viewcvs.cgi/~checkout~/doc/lplc-article.txt and http://www.linuxplc.org/cgi-bin/viewcvs.cgi/~checkout~/doc/structure.txt Other than that, like Mario said, what do you want to code? Jiri -- Jiri Baum <[email protected]> Q: Why did the chicken cross the Moebius Strip? A: To get to the other... um... er... --r.h.f.r _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Hello Jiri, --- Jiri Baum wrote: > I'm not sure what sort of handshaking you envision, > apart from the data > transfer being atomic, and the protocol required to > make the data exchange > happen at all. Anything else? My main desire is a practical one. The simplest handshaking would be a "Node Exists" point. When I'm on the plant floor, I'd like to be able to go out and check if all the communications links are working. If I can establish a pipe to a node, then I know everything is talking. That's a big step when you're doing integration. > > I want to be able to dynamically create a virtual > Pipe from wherever I'm > > currently logged on, to that new PLC Node, through > any number of > > intermediate Nodes, so that I can do an online > test and configuration of > > that new hardware. > > Why? You can simply telnet or X to the machine you > want to test/configure > and skip the intermediate steps. > > Unlike certain other systems, Unix already *has* > remote administration; we > don't need to re-implement it. This is where I'm trying to extend your PuffinPLC concept - past Linux and Unix. You are right to use Linux as your development and test platform, but I'd like to port these ideas to the QNX RealTime Platform - available for free. A system vendor could use whatever OS they wanted as a base, and when you plugged their node into the system, it wouldn't necessarily need you go *administer* that computer - just navigate to that node through your other Nodes. The Pipe is just a *reliable* way to access points on any remote node, just by supplying a path to get there. > > Basically, every PLC Node also needs to act as a > *bridge* between any two > > of its communication links (modules). > > In some ways, it can't help but do that. That's its > primary function - to > act as the bridge between all its modules (pipes, > io, logic, whatever). > > On the other hand, every node in the chain will add > latency. The integrator > will need to be careful with those, and design the > topology appropriately. You're right about latency, but I'm mostly concerned with exchanging low priority data over these connections - like on-line status and programs. I want to be able to on-line program several different PuffinPLC Nodes from one programming terminal. Perhaps I'm stealing the idea from Allen-Bradley's RSLinx idea, but not really. With the new ControlLogix platform, if I'm connected to a ControlLogix controller, that immediately bridges me to the controller backplane, and allows me to see all the modules in the local rack (and even flash upgrade them, if I want). I can also use all of their bridging ability to go out on a ControlNet or DeviceNet segment to access all the devices on those networks. I can now actually remotely download HMI programs to HMI modules through a Controller that has a ControlNet bridge in the rack, and the HMI is on the ControlNet network. I just want the ability to plug my laptop with programming software into any one PuffinPLC Node that provides a suitable connector, and be able to see the coils in any other Node. This is because perhaps I'm debugging a system in the field and that other node is across the plant - I just want the ability to go online with any remote (or local) Node. If the latencies get too high, then it's my own problem as an integrator, and I should plug into something closer to the target Node. Even so, I really don't care about latencies if I just want to force an input or output on some remote system. The same applies for flash upgrades of remote hardware that's connected to the system. If it can get there via a Pipe, then I should be able to access any of the system dependant functions that the vendor provides me with. All I have to do is give their configuration software a network path to find their node. Perhaps I'm not saying this clearly enough... sorry. I'll keep trying to explain myself. As for diving into the programming, I'd like to try porting this to a non-Linux platform. Perhaps it's too early, but if we keep in mind that the software doesn't have to be Linux dependant, then the earlier we try to make it cross-platform, the easier it will be to manage in the future. Scott _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Scott Whitlock wrote: Hi Scott, and welcome. If you can write what you want in C before the other guys get done, it stands a great chance of being in there :^). Suggestions are taken into consideration. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Yeah, yeah, I know... "Shut up and show me the code!", as Mr. Torvalds would say. Okay, you've convinced me to compile this on the QNX Real Time Platform - or at least see if there are any major hurdles to doing so. Then I'll work at implementing some pipe ideas so I can show them to all of you. Don't stay on the edge of your seat, though - I'm renovating my house, and work pretty long hours these days. Cheers, Scott _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Scott Whitlock <[email protected]> wrote: > I'm renovating my house, and work pretty long > hours these days. What about a different (real-time) scheduling algorithm? Curt would surely help you adjusting priorities for LPLC and your house properly... Sorry, could'nt resist the QNX pun. Harald _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Actually I think we'd do better with the standard "fair" scheduling on Linux. One third of all the brain cycles would make LPLC happen faster. We could even get more as I'm sure work and remodeling would sleep waiting for I/O :^). Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

This is getting worse and worse... You guys really DO have a lot of time on your hands, don't you... ha ha! Besides, the work task only *needs* to execute when the *supervisor* routine is running locally, and the home renovation task sometimes blocks waiting for resources when Home Depot is closed. That's it! Now I'm scaring myself! I have to go... talk to all of you later! - Scott _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

--- Curt Wuollet <[email protected]> wrote: > Suggestions are taken into consideration. Alright... one more *suggestion* before I start. I'm a little confused with the PuffinPLC vs. LinuxPLC nomenclature, so here is a suggestion for you: PuffinPLC can be an open standard that allows various PLC's to talk to each other, whereas LinuxPLC is a particular implementation of that standard on the Linux platform. That way, LinuxPLC is the 'killer app' that sells PuffinPLC. &lt;Scott ducks> Don't throw anything! - Scott _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc