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