Design tickler

C

Thread Starter

Curt Wuollet

Here's a QAD outline for an I/O process just to get people thinking about it. This is a single process approach, I think it's safer to have a single process than multiple autonomous processes. At the expense of complexity we could
achieve the same thing with multiple processes by having a monitor or mgr process watching things.

It's attached


cww
 
Hello,

Curt Wuollet:
> Here's a QAD outline for an I/O process just to get people thinking about
> it. This is a single process approach, I think it's safer to have a
> single process than multiple autonomous processes.

Safer in what ways?

Access to the global map is already semaphore-protected.

As for timing, it's probably actually better the other way: slow I/O shouldn't be holding up fast I/O. (Though we'll have to provide for
specifying timing later, anyway.)

Anything I'm missing?

> At the expense of complexity we could achieve the same thing with
> multiple processes by having a monitor or mgr process watching things.

> I/O Process outline

...

> Here we could do several things:

> for each entity
> {
> trigger read for all inputs
> wait for result
> translate to private map
> }

> or

> for each entity
> {
> fork/exec a reader
> }
> wait for results
> translate to private map

> update mmap to/from private map

I don't think there's any point in having two levels at which data from different sources are integrated; the SMM should be capable of handling it.

Especially if you are forking anyway, just have give each entity its own private map and access to the SMM.


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

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

Curt Wuollet

Jiri Baum wrote:

> Hello,
>
> Curt Wuollet:
> > Here's a QAD outline for an I/O process just to get people thinking about
> > it. This is a single process approach, I think it's safer to have a
> > single process than multiple autonomous processes.
>
> Safer in what ways?

I was worrying about mixing old data with new data because some procs would complete much sooner than others. If they are all free
running, we could have some serious timing skew. With one proc or a monitor program we could ensure that if one hangs we fault and that we actually read all inputs or updated all outs.
This is an issue we have to think through, I don't want to hold everything up for the slowest responder either, but it's implicit that simultanious inputs were in fact, simultanious. I don't see any way we would want to sync the maps until we had at least one scan from all inputs. We can ignore it for now, but there's
such a a wide difference between say a card and serial modbus that you would have to be careful as to what inputs you were comparing.

> Access to the global map is already semaphore-protected.
>
> As for timing, it's probably actually better the other way: slow I/O
> shouldn't be holding up fast I/O. (Though we'll have to provide for
> specifying timing later, anyway.)
>
> Anything I'm missing?
>
> > At the expense of complexity we could achieve the same thing with
> > multiple processes by having a monitor or mgr process watching things.
>
> > I/O Process outline
>
> ...
>
> > Here we could do several things:
>
> > for each entity
> > {
> > trigger read for all inputs
> > wait for result
> > translate to private map
> > }
>
> > or
>
> > for each entity
> > {
> > fork/exec a reader
> > }
> > wait for results
> > translate to private map
>
> > update mmap to/from private map
>
> I don't think there's any point in having two levels at which data from
> different sources are integrated; the SMM should be capable of handling it.

It all depends on if we need to maintain timing assumptions. I see what you mean, but aren't there things that depend on inputs being read before outputs are set? (flipflops come to mind). All I'm trying to achieve is what a PLC
guarantees about order of execution. That all inputs are scanned before solving and the outputs are set dependent on the last input scan. You guys
are the experts on how it's done on exixting PLCs but updating the map asynchronously could really raise hell with logic. I thought we need to to
guarantee solving ladders left to right top to bottom, last man wins. If totally asynchrounous is OK, I'd say we give up the scanning model and
read and write on demand from the solver.

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

Curt Wuollet

Reply to myself and the list:

I had a heart to heart with our local PLC expert and I guess all timing is the responsibility of the programmer. If one input takes 1msec to flow to the map and it is anded with another input that takes 100 msec to flow to the map they may be coincidental and never be seen as such. I guess that means we can pretty much ignore timing and blame it on the PLC programmer if it doesn't
work. That certainly is the easiest approach. In the world I come from, we were adjusting board trace length and physical layout to maintain timing. Different world I guess.

Regards

cww

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

Gilles Allard

Hi Curt!
Here's my opinion.
A Jiri DataPoint is only owned by a single process (a owned data point). This is good. It insures synchronous timing. Asynchronous data values is another domain that should be handled by snapshots (plc_update). I do not see the problem with FlipFlops.
Gilles


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Curt Wuollet:
> All I'm trying to achieve is what a PLC guarantees about order of
> execution. That all inputs are scanned before solving and the outputs are
> set dependent on the last input scan.

Yes, that's how it'll work.

> You guys are the experts on how it's done on exixting PLCs but updating
> the map asynchronously could really raise hell with logic.

Definitely. That's why there's the private map. As far as the logic engine is concerned, it's working with inputs as they were at the last ioscan, and its outputs don't get written until the next ioscan.

> I thought we need to to guarantee solving ladders left to right top to
> bottom, last man wins.

That's right.

> If totally asynchrounous is OK, I'd say we give up the scanning model and
> read and write on demand from the solver.

Read and write on demand has function headers in smm.h, but it's unimplemented and undocumented. Should be relatively quick to implement, though.


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

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

Curt Wuollet

Jiri Baum wrote:

> Curt Wuollet:
> > All I'm trying to achieve is what a PLC guarantees about order of
> > execution. That all inputs are scanned before solving and the outputs are
> > set dependent on the last input scan.
>
> Yes, that's how it'll work.
>
> > You guys are the experts on how it's done on exixting PLCs but updating
> > the map asynchronously could really raise hell with logic.
>
> Definitely. That's why there's the private map. As far as the logic engine
> is concerned, it's working with inputs as they were at the last ioscan, and
> its outputs don't get written until the next ioscan.

That's where I'm misunderstanding. You were suggesting we make each driver a process and give it it's own private map. Each proc scans it's
inputs and translates them onto it's private map then syncs with the shared map and writes it's outputs. If these procs are free running and
scanning at different speeds, we still have asynchronous updates.

Or we could use one private map for a parent process that sequences the drivers and waits till they are all done. OR.........?

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Don't forget the logic engine has a private map too. The logic engine's private map won't be updated until it wants to, which is at the bottom/top of the ladder.

The rest of it is asynchronous, but that doesn't make any difference to the logic; merely adds some latency.

(Granted, latency can be a problem too, especially if it varies. But it's a different problem, and it should only ever vary problematically if the speeds of two of those free-running loops are similar.)


Hope that makes more sense now...

Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
J
This can be handled fairly easy in the ladder (or whatever) code as well. If timing becomes critical between the two processes, bits can be passed back and forth to keep sequencing in order. The faster process would just spend some of its time waiting for the other to catch up. As long as we maintain the Input - Logic - Output sequence in order within each process, there should be no problem....

--Joe

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

Johan Bengtsson

Ok, I try a little bit longer explanantion:

Several I/O processes reads their physical inputs,
and stores their values in their private copy of the map.
When each of them have done that they sync with the shared map, only one proces at a time can change values in the shared map. After each I/O process have synced they put out their physical output and starts over.

The logic solver runs simultaneosly in the following loop:
1. sync it's private map with the shared
2. solve logic
3. repeat

This will mean inputs from different I/O processes will arrive to the shared map asyncronusly, inputs from the same I/O process will arrive syncronusly or asyncronusly
depending on the actual driver (fieldbuses will probably most often be asyncronusly read anyway)

When the logic solver updates it's private map it takes a (somewhat delayed) snapshot of the physical inputs and puts it in's private map. These values will not change during one scan for the solver.

I think this is the closest we will get to a real PLC. The inputs are not changing (in the solvers view) for the entire logic scanning. They will be changed in the shared map but not the logic solvers private copy.

I don't think inputs are guaranteed to be 100% syncronus between I/O racks (within the same rack is probably not an issue) and most certanly not guaranteed to be syncronus if fieldbuses are used (some fieldbuses handle that, but not all)

Normally I don't think this is required anyway, and I don't see a reason to request it in most cases. What is required is that they don't change from the logic solving parts point of view during a scan.


/Johan Bengtsson

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


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Jansen, Joe:
> If timing becomes critical between the two processes, bits can be passed
> back and forth to keep sequencing in order. The faster process would
> just spend some of it's time waiting for the other to catch up.

You really want to use semaphores for this, so the faster process can sleep.


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
I guess I didn't misunderstand after all. No wonder PLC folks spend a lot of time chasing after bugs. Fortunately, the mechanical world doesn't move very fast. Anyway, as soon as the board arrives, I'll start on a first pass IO process. The configuration for the IO and the config for the mm will have to be aware of each other so we can go from a name to a pin. As I understand it now, I'll be getting inputs byte
wide and getting a handle for each bit. It would be handy to implement word handles. I suppose I could just get a pointer and write words anyway.

Regards

cww.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Jansen, Joe:
> Absolutely. I was just using "PLC-ese" for a moment. Semaphores are a
> foriegn idea to ladder logic.

No worries. Just as long as we keep in mind that we *can't* really do it well in ladder logic unless we extend it.

(Which we might. But we'd have to think carefully.)


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

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