# A lurker speaks up...

S

J

#### Jiri Baum

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

M

#### Mario de Sousa

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

J

#### Jiri Baum

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

S

C

#### Curt Wuollet

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

S

#### Scott Whitlock

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

H

#### Harald Albrecht

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

C

#### Curt Wuollet

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

S

#### Scott Whitlock

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

S

#### Scott Whitlock

--- 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