on-line changes (was: [Fwd: ENGR: Ladder Logic, Automation replacing people])

J

Thread Starter

Jiri Baum

Curt:
> I've been thinking about how to make several front ends work. For now
> that can be separate but some sort of intermediate language would make it
> much easier to implement on line editing. My first thought is to have a
> simple list of equations to be solved. If the list were in core we could,
> with proper synchronization, edit it between cycles.

I can't see what benefit such equations would give us (or, how to do them
so that they'd bring us such benefit).

There are several ways to handle on-line changes within the existing
architecture:

1) module replacement. The new version of the module (B) is compiled (if
necessary), loaded and initialized up to the point where it's ready to take
control, and blocked until the old version (A) has completed its cycle. Then A is blocked and B is unblocked.

At this point, version B is running and version A is still in memory, blocked but ready to go. This means that if there's a problem with B, instant back-out is available.

Obviously, something like a PID module isn't going to like this kind of
replacement, because there's no protocol for handing over the I (reset) or
any other internal information. The new module will have to make do with what it can see in the global map.


2) forced module replacement: Like module replacement, but instead of waiting for A to finish its cycle it's killed outright.


3) module-integrated on-line change: Some modules may have facilities for
on-line changes built in. This will depend on the module: for instance, I
think the tcl scripting language already allows on-line changes, so not much more is required. The dsp module or a neural network module might re-load their configurations at an opportune moment.

For modules written in C directly, it would be very challenging to provide
an on-line change facility, and it properly belongs in the OS anyway. If I
wanted to look it up, I'd probably start with a search for `persistent
systems', because they have had to solve this kind of problem before.

Such modules can still be replaced or force-replaced, but obviously this may not work all that well if they keep a lot of stuff internally (which would be good programming style).

Jiri
--
Jiri Baum <[email protected]>
http://www.csse.monash.edu.au/~jiribvisit the MAT LinuxPLC project at http://mat.sf.net

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

Curt Wuollet

Hi Jiri

I'm just facilitating the discussion, you can throw my idea away. I've already seen serious knowledge available. This just got me thinking about how we plan for this capability. I am mostly talking about the compiled C solver case for the logic languages. What is the target for an RLL editor, for example. Right now it would plug logic in a skeleton solver program that would then be compiled. My question that I have been thinking through is how to change the code
with the solver running. This avoids some messy issues and creates some others. If the solver _is_ the program, restarting it where it left off will be interesting. If we externalize the user logic and only change the scan list we can preserve state in the solver itself. I don't know if I'm communicating that well, but that's where my contemplation took me.

Regards

cww

--
Free Tools!: Machine Automation Tools (LinuxPLC) Free, Truly Open,and Publicly
Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation and ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business and Automation to Linux.

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

Johan Bengtsson

Is there really any reason all modules must follow the same way? a PID does normally never have to be replaced at all (only it's parameters, not the actual implementation of the PID)

A logic solving program (such as ladder, FBD, or similar) needs to be possible to replace, some kind of interpreted byte-code would probably solve this easiest (and still fast enough) If the speed of this really isn't enough in some case you could have a harder-to-replace compiled module, even if the need fort that would be quite rare.

Changing parameters ot a module (any module) would be quite easy as long as the module is prepared for a parmater change and accept it
between scans (only acceptable point anyway probably). The ladder or grafcet program is in reality a parameter to an interpreter for this and therefor easily changed between scans if the module accepts this. Ok the parameter might get quite large, but so what? how much does memory cost anyway? It could grow to several kilobytes
probably (ie a 64k limit for a paramter would be too small)

/Johan Bengtsson

----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

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