Jocelyn Boily:
> One of the main advantages of PLC languages is that you can change the
> program while it is running.

In some ways, this is a different problem again. The config tool and MMI could easily be written in C and still allow on-line changes.

> I would hate to see Our LinuxPLC to shy away from this feature.
> Interpretative languages would allows to do this quite easily, but would
> it be possible with a compiling language?

Actually, it's not necessarily such a great difference - in either case the interpreter/compiler has to have special provision for it... Most likely it won't be there in the initial version, but it must be there eventually.

An interesting problem is how to design such a feature, in general. For a stateless language like stepladder, it's fairly obvious - but what about other languages?

(If you have a correct program running, and you replace it on-line with another correct program, it's possible that the overall effect will be
incorrect. Can that be solved?)


Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

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

 

> (If you have a correct program running, and you replace it on-line with
> another correct program, it's possible that the overall effect will be
> incorrect. Can that be solved?)
>
Ya, that is true.

However, there is few things that help predict the behaviour of the system throughout the change.

-First, only the line of code (ladder rungs) are change, not the whole program.
-Usually, only one rung is changed.
-If more then one rung is changed, added or deleted, usually, it is possible to implement the changes, while the PLC is running the old program. Then when everything is ready, the new lines are enabled, and the old ones are disabled.
-There also, I believe, some control when the switch is done like witching between the old and the new lines while between ladder scans. This way, the rungs changed are never change while being executed.

Of course, it is possible that the change you make has error/bugs in them which could cause problems, so you have to be careful of what you are doing. Allan Bradley have a function that allow you to test the new program and to revert back to the original program with only 2 key strokes. This is the feature I like the most from this line of PLC.

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

 

Hi All,

I have been reading the linuxplc thread with interest. I think this is an interesting project because it goes beyond the software and into the real world. It would be interesting to see if GNU type of concept could go beyond software and into in PCB layouts for example and who knows into what else (every way that knowledge could be represented I guess).

I work in a company that does industrial automation and process controls, we use Siemens S7 PLC's and sometimes we use our own MMI using
java.

I have some comments on the "On-Line changes" thread, first of all we where talking of using an interpreted language or script language for the
configuration files customization and later on it was suggested that we could probably use the same language for the MMI to ease on the learning
curve of the developers and users (sorry for the "we" generalization, I don't remember who said what and I'm too busy to look for it). Nonetheless
the subject of on the fly software updates is a very important issue, and I think we could do this on compiled code using something similar as Jocelyn suggests. The PLC process loop is normally OS Housekeeping, read inputs, execute user code, write outputs. In the OS Housekeeping there are many tasks, i.e. download a piece of code for a standalone PLC, serve interruptions, update timers, send debug information (which is by the way another very important issue "on-line debugging"), etc. Here we could also recognize that there is a modified version of the certain module named X, in this part of the cycle (no user code is executing currently at least not the
modified module) we change the reference call in a table to the new module like in a dynamic linked library I guess. If something fails there could be the option for the user to the old module. I agree that there is no way of assuring that the new code is going to work, this is just a way of replacing a code module for a modified one. One last comment the way PLC OS work is
very simplistic because it assumes total control (no other code are allowed to run as in multithreading) every cycle and also the maximum time allowed for the cycle is checked and limited, but this is because of the deterministic nature as a very high priority. We could relax this assumption by saying that no other PLC user code could be running while PLC OS housekeeping or even further by saying that the modified module code should not be running when we change the call reference from the table to the new
version of this module.

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