Curt, Personally I would never use another PLC, in all but perhaps a strictly cost driven project (e.g. very small SLC's etc.), for the reasons you describe. Engineers tend to have a narrow range of focus - that is on tasks rather than whole systems, or whole systems within a operating business. Such is the design of the PLC, dedicated hardware, task based developed with fear of failure. There was a time this fear was justified, however we have proven 99.99% uptime with servers in the past five years. So while it is a consideration, in presentations over the past year we have been able to cleary demonstrate to major corporations, the advantages of the Linux control server based approach. Of course the LPLC within automationX is just one facet of the system. But go further than "replace" PLC's just as PLC replaced relays. Be careful NOT to translate the hardware box approach into the LPLC, as the name implies. You have the ability, from a computing standpoint to create a Linux Automation Server. Such is the approach of automationX. As a matter of fact as I have been monitoring the list a lot of the issues faced in the LPLC development, have been overcome or decided in automationX. If I were sketching the the functionality of the LPLC, or Linux Automation Server, I would give automationX a very good look, and to be frank pattern the product after what we did. Long time listener, first time contributor... Paul Jager CEO automationX www.mnrcan.com _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

In a lot of ways, RLL IS a 4GL. It hides a lot of details, yet has an amazing amount of power for doing discrete and analog control. Where it fails miserably is in such things as CNC or motion control type applications, where the graphical nature of RLL does not lend itself to describing what is actually going on. _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

It is becoming clear to me that people in automation have very distinct and different needs. Also, I don't think that anybody has any intention of replacing ladder logic in this project with any enhanced industrial languages, but, in fact leaving that as an option in the system. To each their own. It is pretty amazing how the suggestion of adding a text based language extension has caused so much flame. Still thinking outside the rungs ... ~Ken _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

First my very general overview of project (or application) stages. I will then try to fit the puffinplc modules into these stages Project (application) stages: 1. Analysis: Determine need for custom module, can not find one in the library of modules. 2. Custom module development: C, iec 61131, etc. The text-based programs or diagrams are compiled into custom modules. 3. Configuration definition: Selects the required modules from the standard and custom module library. . Synchronizes the execution of the modules…. …. Stores the results in a configuration file (puffinplc.conf by default). 4. Set up: (the user executes a utility called puffinplc) using the data stored in a configuration file. puffinplc sets up the shared memory areas and the semaphore sets (The memory blocks are allocated by the cmm?). Copies the configuration into the configuration memory. Loads configuration data of synch points into configuration memory. and launches the modules the configuration requires. 5. Run time: every access to the configuration memory area is made through the cmm and through the gmm. _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

This is from the lplc.txt but with a lot of white space and a few questions added: Would appreciate some help with this. Thanks Bob Page [email protected] The Synchronization Library The mechanism employed by the gmm enforces semantics very similar to those in existing standard PLCs, but the two are not exactly the same. synchronization library resolves Situations where the exact same semantics are required. simplifies the task of the module programmer, but leaves a lot of flexibility for the end user. uses standard semaphores to synchronize the modules, but does not make this apparent at its higher level interface. Module synchronization revolves around the concept of synchronization points. End user configures PuffinPLC with a certain number of synchronization points (or synch points). Load configuration data of synch points into the configuration memory upon PLC setup. Modules obtain handles to these points(at set-up?) and then call a synchronization primitive to wait at a specified synch point (at run time?). Having the module obtain the name (handle) of the synch point from the configuration file (created during configuration definition stage) allows the end user complete flexibility in specifying the synchronization sequence for the application. The end user must also define a petri net model (see sidebar) of the sequence of events they wish to enforce. Support the association of synchronization points to (Synchronization points may be associated with ) the complete firing of a transition, the removal of tokens of a firing transition, or the insertion of tokens of a firing transition. the existence of a certain number of tokens in a place, the arrival of tokens in a place, or the removal of tokens from a place, but some of these require more support from the Operating System than is currently offered. (elaborate please) (BobP: It is probably my lack of understanding of the petri net model but I do not understand "removal of tokens of a firing transition". A transition, when fired, removes one or more tokens from a place or places. In other words, the transition generates the remove action and the place receives the action (to remove the tokens). Are we saying that the synch point may be associated with the action at either end of the directed arc (which connects a transition to a place).) Modules waiting on a synchronization point associated with the firing of a transition will block (not be executed?) until the transition is fired. Synchronization points associated with the insertion of places of a firing transition will never block, but will insert the appropriate number of tokens into the places whenever a module synchronizes with this point. (BobP: I do not understand this dependency. It would seem that the response of a place to the firing of a transition would be independent of any synch point. In other words the transition/place pair would do its think while the synch point would watch and do its thing.) This, and the fact that the PuffinPLC will not fire a transition unless there is a module waiting on a synchronization point associated with that transition, (BobP: I do not understand this dependency. Isn't this like leaving a coil in a ladder that responds to other signals but does not do anything. I think this dependency will cause more trouble than it is worth.) implies that the semantics the PuffinPLC supports for the synchronization petri net are not exactly those of standard petri nets. But a modified petri net provides a base from which to work. Using a petri net model allows very complex synchronization semantics. Nevertheless, due to the complexity of configuring this model, a simplified configuration syntax is also supported; it consists of a simple execution sequence for modules. This sequence is automatically transformed into its equivalent petri net model upon setup. (During run time, ) Every module is required to call plc_scan_beg() and plc_scan_end() before commencing and upon completion of its scan loop. These functions synchronize with two default synch points that, if not configured, will map to the null synch point that continues execution without delay. These two functions provide the hooks for the synch library to provide module synchronization in a standard form. Modules that wish to synchronize at other locations of their execution can use additional synch points as desired. _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Hi Paul Glad to know you're lurking. As you know, I have looked at AutomationX and was even considering distributing it. That's what I think of it. I think our focus is more towards machine control than process control so we should be complimentary. It would be good if we could have some commonality. Drivers for instance. One can never have enough drivers. I have set AutomationX aside to avoid any appearance of plagerism, but as luck would have it, I have some prospects that are interested. And selling Linux in automation is more important than appearances, so I may take another look. I also agree that we should look at the best way to solve automation problems rather than blindly duplicate the status quo. Fortunately we can do both comfortably. For what it's worth, I may never use a PLC again either. This cell I am implimenting has gone so much better with a Linux approach that I think I will be required to use Linux again. Much faster to develop even inventing stuff and fabricating hardware along the way. Of course, your opinion would be highly respected if you were to make suggestions, we really only differ in license philosophy and other religious issues. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

"Ken Emmons, Jr." wrote: > > It is becoming clear to me that people in automation have very distinct and different needs. Also, I don't think that anybody has any intention of replacing ladder logic in this project with any enhanced industrial languages, but, in fact leaving that as an option in the system. To each their own. > > It is pretty amazing how the suggestion of adding a text based language extension has caused so much flame. > > Still thinking outside the rungs ... Hang in there Ken, we need all types of viewpoints. cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Bob, Personally, I prefer using Ladder logic. I find the function blocks to cumbersome and the Statement list is not graphical enough. However, my Ladder editor (Step 7, from Siemens) allow me to write the logic in on language, and then view it in an other. The editor actually translate the code in some source code, and only shows it in the graphical form of my choice. I seldom use any other language, but sometime will when I can not avoid it. This is not because I do not know Basic or C++ ..., but because most electricians don't. They already have difficulty to understand LADDER Logic. I spend sometime 50% of my time just trying to make the code simple and easy to understand. The extended documentation I add to the rungs are not for me, but for them. When you design the code on a plant power system, a single shutdown will cost any where from $250K per shutdown plus $100K per hours. The clients can not afford to have the electricians looking around a cryptic code. Now, it seem that some form of GRAFSET/Sequential Charts is preferred in Europe. Their technique uses a lot of functions calls, and the I/O is buffered by the code. Their technician are used to this, and use it very effectively. However, the American technicians get confused by it. It just a question of training. The main thing is to design your code so that your technicians can read it. jb _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

This is from the lplc.txt but with a little rearrangement, a lot of white space, and a few questions added: Would appreciate some help with this. Maybe this would be better using CVS? Can I use CVS with IE5? or do I need Linux? Thanks Bob Page [email protected] Global or Shared Memory. The shared memory (also known as the `global map') is the common data area for the linuxPLC. It contains all of the data (plc points, plc internal coils, or live variables) that is used by all parts of the LinuxPLC, including physical I/O, internal coils, and any data to be shared between modules. Private data may still be maintained inside each module, but it is not going to be available to any other module if it is not written to the global memory map. Plc points, with a size between 0 and 32 bits, are configured in the configuration file with a unique name. Private memory. Each module has its own private memory map and a private map mask, both created upon module initialization (set-up?), and both independent from the global memory map. When a module accesses a plc point, it is actually accessing its private memory map. The Global Memory Manager (gmm) The gmm manages the global shared memory. It allocates and initializes the shared memory or shuts down and deallocates the shared memory. The gmm is the only way to access the shared memory. At setup, the configuration is copied into the configuration memory. Gmm allocates a private map and also a map mask. The mask is used to determine whether a module has write access to a particular data point. Each module is given a private copy of a subset of the global memory map. All functions performed by a module are done to this private memory map. A map mask is created to declare to which plc points the module has write access. At run time, modules access the plc points solely through the gmm library by using handles. A handle to a point is obtained by calling a gmm function to which the name of the point is passed. (The private memory is freed when the module terminates?) gmm function plc_update() synchronizes the global memory with the private memory. Synchronization is semaphore controlled, which provides atomic updates. All plc points without write access are copied from the global memory into the private memory Only the plc points to which the module has write access are copied into the global memory map. When run with a single logic engine (single control module plus i/o and communication modules?), this allows the LinuxPLC to mimic the behaviour of a traditional PLC. All three maps, the map mask, the global memory, and the private memory, are exactly the same size and use the same locations to store the plc points, which allows updates to be made as a simple bit-for-bit logical function. The update must be made quickly because it requires access to a common shared resource (the global memory map) and may therefore become a bottleneck. Because of the use of a common shared resource controlled by a semaphore, using the PuffinPLC in a hard real-time environment will require the use of a scheduling mechanism that bounds priority inversion. (BobPage: Does Linux employ a scheduling mechanism that bounds priority inversion?) The use of private memory maps allows modules to run asynchronously without interfering with each other. Although it is not mandatory, it is expected that modules will run in an infinite loop, synchronizing their private memory maps at the beginning and end of each loop iteration. This guarantees that while the module is running its logic, the state of the plc points will not be changed by other modules executing their own logic or doing I/O. (BobPage: Does Linux allow more than one module to execute at a time? If so and if two modules are running, what is to prevent each module from setting the value of a point at the end of each iteration? Sometimes this may be desirable, sometimes not. If not, isn't the programmer or configurator responsible for sorting this out? Like in the statement "If a module tries to modify a data point to which it does not have write access, the changes are discarded during the update. Although writing to a data point in the private memory map to which the module does not have write access in the global map is not specifically disallowed, this is considered poor programming practice, and is discouraged.") Nevertheless, the PuffinPLC architecture is sufficiently flexible to support modules that do not execute in an infinite loop; these may synchronize their private maps (in whole or in part) when they see fit. Currently the gmm provides two alternative strategies to achieve the described functionality. Either of these strategies may be chosen when a module is launched by including one of two command line options (--PLClocal or --PLCisolate). The default strategy (--PLClocal) places the private memory map and the memory map mask in the module's heap, and accesses the global memory as shared memory mapped onto the module's virtual memory address space. This has the drawback that if the module is badly written, a stray pointer may access the PLC's global memory map without going through the gmm, potentially creating havoc. In the second strategy, (--PLCisolate), the module forks a second process. The first process executes the module logic and accesses the private memory map, but never actually maps the global memory into its virtual address space. The second process uses the shared memory mechanism, to access both the global memory and the private map of the first process. Whenever the first process requests a memory map synchronization, it sends the request through a socket to the second process. The second process actually performs the memory map synchronization. This strategy involves large delays for each memory synchronization, but allows a developer to isolate a module that has not been thoroughly tested, making debugging easier.

 

Jocelyn, Thanks for the response. Your memory is much better than mine. My comments are for me too so that my memory is refreshed when I return to a job some months or years later. If we were able to make the documentation clear and understandable, including the comments, and if we were able to provide graphical checkout tools, we might be able to interest users in a significant cost savings. So, documentation and checkout tools become critical. Regards, Bob _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Curt, I do not understand your statement "I think our focus is more towards machine control than process control so we should be complimentary." Perhaps that is because I spend all my time in process control. As I am sure you know, within process control we have a wide range of applications, each with a different distribution of signal types and different timing requirements. I would have thought that the flexibility of Linux would allow many common modules. For example does the global memory manager in a machine control application have to be different than the global memory manager in a process control application? Since I gather you are implementing a Linux based system to control a machine control cell, such a system is feasible. Do you plan to offer that system to the market? By marketing the system, aren't you promoting Linux? If there is a hole in the offerings of your company and such companies as automationX, why not identify the specific hole(s) and promote development to fill those holes? What am I missing? Regards, Bob Page [email protected] _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Hi Bob Bob Page wrote: > > Jocelyn, > Thanks for the response. Your memory is much better than mine. My comments > are for me too so that my memory is refreshed when I return to a job some > months or years later. > If we were able to make the documentation clear and understandable, > including the comments, and > if we were able to provide graphical checkout tools, > we might be able to interest users in a significant cost savings. > So, documentation and checkout tools become critical. Mission Critical, in fact. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Bob Page wrote: > > Curt, > > I do not understand your statement "I think our focus is more towards > machine control than process control so we should be complimentary." Perhaps > that is because I spend all my time in process control. As I am sure you > know, within process control we have a wide range of applications, each with > a different distribution of signal types and different timing requirements. > I would have thought that the flexibility of Linux would allow many common > modules. For example does the global memory manager in a machine control > application have to be different than the global memory manager in a process > control application? Absolutely not. I was operating on the impression of AX I got from the published materials which seem aimed at process control and a systems approach rather than for example, replacing a single PLC. This would make sense as that product would not be cost effective in such a case. One of our stated goals is to be modular and distributable, meaning that we can run in configurations that range from a direct PLC replacement to a complete factory system. > Since I gather you are implementing a Linux based system to control a > machine control cell, such a system is feasible. Do you plan to offer > that system to the market? Interesting question. I did it for in-house use. If someone saw it and needed a similar cell, we _are_ in the automation business. Am I promoting a "forked" version of LPLC? No, I simply had to go with what I understand as I am under extreme time pressure and this is the moment of truth. The project was in trouble and I was asked if I could do it faster with Linux :^) Could I say no? There is absolutely no way I would fail to meet that challange. Do or die, Put up or Shut up. The project is looking much better and LPLC has gained the "real world" hardware I needed to do it. Would I rather have done it with LPLC, absolutely. At this stage Mario or Jiri probably could, I could not under the circumstances. In another sense, I already have. For the cell I am currently building, the "PLC" portion is identical to the first small C demo I published for this project. This is of course, available to anyone so I suppose you could say it is offered to the market. It has little resemblence to the current LPLC direction but it suits my needs for this project. I do not consider it to be "marketable" as there are no tools that the average PLC user would be familiar with and the logic is expressed as boolean C statements. Hardly user friendly. But anyone who wishes to can certainly use it. I intend to replace it with LPLC as soon as we have a first release. It has spurred my thinking in new directions as the rest of the cell control package is a more or less "standard" custom C program that does machine vision, communications and those things which are best addressed with procedural code. I have been casting about for opinions on how we could make this bimodal approach a feature in LPLC with a language easier, faster and more "marketable" than C. At this point I am solving the specific case and brainstorming on how to solve the general case. So, yes I intend to "market" this if the group supports the effort. The exact code I wrote for this cell belongs to my employer so, no, I can't directly publish that without their consent. It is very specific to that project. The part that my company did, the DIO48 ttl to industrial board, I contributed to LPLC. > By marketing the system, aren't you promoting Linux? I sure hope so. What I was saying is that I would be happy to suggest AutomationX if it suits their needs to sell a Linux solution. I don't think anyone would have a problem with that. We are simply not ready for prime time yet with LPLC. I was also extending a friendly non-competitive invite to Paul in the spirit of the Linux community. > If there is a hole in the offerings of your company and such companies as automationX, why not identify the specific hole(s) and promote development to fill those holes? I thought that was what I was doing. I was proposing simultanious cooperating procedural and asynchronous logic processes and a 4GL type language that would make that power accessable to folks other than Linux systems programmers. To the target market, to put it in business terms. The only other holes we have are well known in that we don't have all the pieces for a complete release usable by non-developers. > What am I missing? I don't think you're missing anything but context. I hope I have explained myself a little. The other thing to remember is that I sometimes try to serve several purposes and address the group as a whole in replies. When I'm off into blue sky this can get really confusing, as can mixing my day job, my company, the project and the LPLC project. If it doesn't seem lucid, don't worry about you, it's me :^) Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Hi Curt, Thanks for the reply. If looking at automationX is going to make the LPLC better, you have no choice, end users deserve it. Having said that I know there are a few patents for some of the design features in automationX. automationX is making gear cases for a large German automaker, electric toothbrushes (to be launched soon), doing quality control and assembly in auto parts, electronics, steel stamping & welding, etc. aX is also pumping 5,500 I/O in one server (with a backup) as part of an environmental control scheme for a large complex, and doing many plant process missions. So aX covers manufacturing, building automation, and plant process. It targets the commonality across all industries and applications, and thus is not suited for every specialized requirement. If you were developing a equivalent product for sale, that would represent healthy competition, and that would be good. It's not easy being pioneers. The LPLC is based on a much different strategic focus, and you are right - that is complimentary. We view aX as an automation server environment. When needed, to dovetail a LPLC in there would be great. We've done that with other specialized packages too. Regards, Paul _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Hi Bob, Sorry for the delay in my reply. I have been on holidays for the last week. > Bob Page wrote: > > This is from the lplc.txt but with a lot of white space and a > few questions added: > Would appreciate some help with this. > Thanks > Bob Page [email protected] > > The Synchronization Library > (...) > > (BobP: It is probably my lack of understanding of the petri net > model but I do not understand "removal of tokens of a firing > transition". A transition, when fired, removes one or more > tokens from a place or places. In other words, the transition > generates the remove action and the place receives the action > (to remove the tokens). Are we saying that the synch point may > be associated with the action at either end of the directed arc > (which connects a transition to a place).) > You seem a bit confused here, so let me re-state a few things. To start off, try and clear your mind of a transition generating remove 'actions', and the places executing them. These 'actions' don't get generated and then executed. They are simply executed when the time is right. This is all done atomically and automagically. How this is all implemented should be transparent to the user. The user only needs to know what exactly occurs to the petri net. - In a petri net, all the dynamics occur when a transition fires. But many changes can occur when a single transition fires, i.e. many tokens can be removed or inserted from/into lots of places. What we are trying to do is allow modules to synchronise with one of several actions that occur in the petri net. We want a module to be able to block until a transition is fired, but also allow other modules to block until a single token is placed into a specific place, whatever transition may have fired. In essence, we want to allow modules to synchronise not only with the firing of transitions in a petri net, but also with other related actions. - What we try to do is create the notion of a synchronisation point. Modules only synchronise with sunchronisation points. These synchronisation points may be mapped with one of several actions that occur to the petri net. - In a petri net, the firing of a transition is instantaneous and atomic. Tokens are removed from all the required places (i.e. the places from which arcs that point to that transition start off from), and tokens are inserted into the required places (i.e. the places pointed to by the arcs that start off at that transition), all at the same instant. - For the LPLC, we have relaxed this somewhat. what I really mean is, appart from supporting the firing of a transition atomically (as explained above), we also support the firing of the same transition in two phases. In the first phase we do the removal of all the tokens, in the second phase we insert all the tokens. We can associate a synch point to either: a) the complete firing of a transition b) the removal of tokens that occurs when a transition is fired c) the insertion of tokens that occurs when a transition is fired. - A module waiting on a synch point of type a) will block untill the transition can be fired. When the transition is finally fired, the tokens are removed and inserted atomically (i.e. instantaneously), and the module continues executing. - A module waiting on a synch point of type b) will block untill the transition can be fired. When the transition fires, tokens are removed atomically, but none are inserted, and the module continues executing. - A module waiting on a synch point of type c) will never block, but simply atomically insert all the required tokens, and then continue executing. - We would also like to be able to associate a synch point to: d) the insertion of a token (or n tokens) into a place e) the removal of a token (or n tokens) from a place - The above two synch points would not really be connected to any one transition. They would synchronise with any transition that inserts/remove the required number of tokens from the required place. - Modules waiting on a type d) synch point would block until some transition is fired (by another module waiting on a synch point of type a) or c) ), and the firing of that transition introduced the required number of tokens into the required place. Once the above occurs, the module blocking on this synch point would simply continue executing and have no effects whatsoever on the petri net itself. - Modules waiting on a type e) synch point would block until some transition is fired (by another module waiting on a synch point of type a) or b) ), and the firing of that transition removed the required number of tokens from the required place. Once the above occurs, the module blocking on this synch point would simply continue executing and have no effects whatsoever on the petri net itself. > (...) > Synchronization points associated with the insertion of places > of a firing transition will never block, but will insert the > appropriate number of tokens into the places whenever a module > synchronizes with this point. (BobP: I do not understand this > dependency. It would seem that the response of a place to the > firing of a transition would be independent of any synch point. Yes, in a correct petri net, that is how things would happen. In our modified ptri net, transitions can only fire if there is some module waiting on a synch point of type a) associated with that transition. As I said above, we also allow a transition to fire in two stages. In the text you didn't understand I was referring to the synch points of type c), that do the second phase of the firing of the transition. > In other words the transition/place pair would do its think > while the synch point would watch and do its thing.) > Yes, that is what we are striving to achieve, but we cannot isolate the petri net completely from the execution of the modules. Imagine the following scenario, where we keep the two isoloated: - 1 linux process does the petri net thing, i.e. it fires the transitions and updates all the required places with the correct number of tokens. - The modules only watch and synchronise with the firing of a transition (we will only assumte this method to keep things simple in this scenario). In the above scenario the petri net process would just keep firing away independently of whether or not some module has finished the execution of some piece of code. In reality, we would not be synchronising anything anymore. > This, and the fact that the PuffinPLC will not fire a > transition unless there is a module waiting on a > synchronization point associated with that transition, (BobP: I > do not understand this dependency. Isn't this like leaving a > coil in a ladder that responds to other signals but does not do > anything. I think this dependency will cause more trouble than > it is worth.) > I think that without this dependency, the whole thing would be useless. Please refer to the scenario I explained previously. Bob, keep you questions coming...! 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

 

Hi Bob, It is nice to see people taking the article seriously ;-) > Global or Shared Memory. > >(...) > Private memory. > > Each module has its own private memory map and a private map mask, both >created upon module initialization (set-up?), Mario: These memory areas are created when the process executing the module starts executing (i.e. when it calls the plc_init() fucntion). Note that PLC memory areas are created during two distinct phases. 1) Memory areas shared by every module are created at set-up time by the puffinplc utility (that simply calls the plc_setup() function). 2) Memory areas private to a module ar initialised when that module starts executing (i.e. when the module calls plc_init() ). >(...) > (The private memory is freed when the module terminates?) Mario: Yes. >(...) >Because of the use of a common shared resource controlled by a semaphore, >using the PuffinPLC in a hard real-time environment will require the use of >a scheduling mechanism that bounds priority inversion. (BobPage: Does Linux >employ a scheduling mechanism that bounds priority inversion?) Mario: Yes, I know of at least one Real-Time Linux variant that uses the priority inheritance protocol (i.e. scheduling mechanism). This mechanism bounds priority inversion. >(...) > This guarantees that while the module is running its logic, the state of >the plc points will not be changed by other modules executing their own >logic or doing I/O. > > (BobPage: Does Linux allow more than one module to execute at a time? If >so and if two modules are running, what is to prevent each module from >setting the value of a point at the end of each iteration? Sometimes this >may be desirable, sometimes not. If not, isn't the programmer or >configurator responsible for sorting this out? Like in the statement "If a >module tries to modify a data point to which it does not have write access, >the changes are discarded during the update. Although writing to a data >point in the private memory map to which the module does not have write >access in the global map is not specifically disallowed, this is >considered poor programming practice, and is discouraged.") Mario: Yes, two modules may seem to execute simultaneously (actually they time share the CPU during short time periods seeming to run simultaneously). Two modules can set the same point during the same interation, but this only changes their private copy of the global map. During their iteration this point may have two different values for each of the modules. The value is copied to the global shared map typically at the end of the iteration (i.e. when plc_update() is called). Only the module with write acces to the point will actually affaect the value of the point in the global shared memory. For the other module that does not have write access to the point, the value stored in the global shared memory is copied back to the private copy of the global memory. This can lead to seemingly confusing situations. That is why this, although supported, is heavily frowned uppon and discouraged. If you want two modules writing to the same output (let's call it Out), then the correct way of going about it is to use three points (Out, OutA and OutB). Module A (B) has write access to OutA (OutB), while a third module will have write access to Out. Module A (B) will place in OutA (OutB) the value it wants written to Out. The third module will read OutA and OutB and decide which value to place in Out. This way, everything is very explicit, and isolated. 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

 

Hi Mario I take the article very seriously, particularly the parts about memory and scheduling. I am thinking hard about interrupts on miscompare of maps as a possible solution to the priority inversion and scheduling problem. (cycle stealing from known slow processes.) PLC's do a lot of busywork. We would classify IO as inherently realtime or not. E.g., Nothing on a serial connection needs to be hard scheduled. For that matter sub-millisecond scans are somewhat dubious when inputs are filtered at 5-20 ms. Low demand IO can ease the scheduling problems. Something to think about is a scheme where nothing is scanned more often than it can possibly react, smart scanning. cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc

 

Mario de Sousa wrote: > > - For the LPLC, we have relaxed this somewhat. what I really > mean is, appart from supporting the firing of a transition > atomically (as explained above), we also support the firing of > the same transition in two phases. In the first phase we do the > removal of all the tokens, in the second phase we insert all the > tokens. We can associate a synch point to either: > a) the complete firing of a transition > b) the removal of tokens that occurs when a transition is fired > c) the insertion of tokens that occurs when a transition is > fired. > > - A module waiting on a synch point of type a) will block untill > the transition can be fired. When the transition is finally > fired, the tokens are removed and inserted atomically (i.e. > instantaneously), and the module continues executing. > > - A module waiting on a synch point of type b) will block untill > the transition can be fired. When the transition fires, tokens > are removed atomically, but none are inserted, and the module > continues executing. > > - A module waiting on a synch point of type c) will never block, > but simply atomically insert all the required tokens, and then > continue executing. > Let me just explain this a little further... Synch points of type b) and c) are not explicitly required. The same can be done by b) having a trsnition that does not have any arcs leaving off from it, so when it fires no tokens are ever inserted. c) having a transition that does not have any arcs pointing to it, so that it can always fire, but only ever inserts tokens. The above two synch point types are merely shortcuts to achieving the same thing... 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

 

> I am not necessarily a big AB fan, but it works a whole lot better then you let on.

Having experience with AB products, I can state that it is not the quality of their product that is a liabilty, as much as the marketing strategy that is used. Is it really necessary to make minor enhancements to a processor in such a way that in order to updrade, one must also change the chassis that the processor resides in? And why must there be so many different processors to handle different specific functions? It is all about money. AB forces the end user to by more hardware and software.

>> constant change, debugging, and patching, often on the fly, and usually by the plant electricain, while the plant continues to run. Can you system do that?

Sure AB can do that, and EVERYTHING is done in a ladder diagram, but have you ever tried to do much analog control from a ladder program? What a pain!

>>, and a LOT of the changes are on the fly with the machine running. Stopping to recompile is not an option.

I would like to suggest that you investigate the Reliance Electric Corporation's AutoMAX product as a very good model for a mix of high and low level programming functions. This system has been around for at least 12 years, virtually unchanged, and is still more functional than anything I have seen AB come out with. The AutoMAX supports multiple processors in a rack, user configurable task prioritization for real-time control, and three levels of programming language that cover every need I have run across so far. The real shame is that Rockwell International now owns both AB and Relaince, and is slowly choking the life out of the AutoMAX line, so that they can replace it with AB's ControlLogix product. What a sad day for the automation world. I only hope that this Linux-based PLC project can produce something anywhere near as useful as the AutoMAX.

_______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc