I would look at using a semaphore or atomic counter to protect access to the shared memory region. Simple flags usually cause simply impossible to debug race conditions.

Another thought is that synchronization between the logic engine and the scanner is going to be difficult if they are both of asychronously doing their thing. I'd consider allowing the logic engine to tell the scanner when to scan. That way if you want to implement the typical PLC model of scan inputs, solve, write outputs, you can easily coordinate the actions. Else you'll have no control and coordination of the two processes.

Pete

> -----Original Message-----
> From: Curt Wuollet [mailto:[email protected]]
>
> Hi Stan and all.
> I'm simply amazed, but, you are right at what I have in mind, I was a little worried for a while as the discussion wandered far afield. Let me put what I am actually doing in perspective. My modbus/TCP scanner will be an I/O task that writes to the shared memory page. This could run asynchronously with a simple "in use" flag to prevent reads or writes during a scan. For the sake of determinisn and predictable behaviour, we may want two way sync though, to preserve the read solve write sequence. This I/O table can be used directly or with a second table for the solver to read for abstraction and the features folks have been talking about.
They can reside in the same place and update and ops between them would just involve pointers (very fast). This is a subsystem. On the "other side" of this interface would lie the solver and other "users" of the data. I wanted to scream "YES!" , but restrained myself, when I saw your post. The one question I have though, is: If we use two pages, which "side" handles the updates and ops between them. I would say the solver, because some of them will be programmable.

We may need a "master" I/O program to fire all the I/O scanners in sequence.

Stan Brown wrote:
> > On Fri Jan 14 09:25:58 2000 Mark Bayern wrote...
> > >
> > >Stan Brown wrote:
> > >> You know, this thing is really starting to come together in my mind.
> > >> Let me run some thoughts by the group.
> > >> The way I see things we have multiple co-operating tasks. We have I/O scanner task(s), logic engine, tasks, timer execution tasks, pid execution tasks. motion control execution tasks. etc.
> > >>
> > >> These tasks all talk to each other via the data tables we have sketched out earlier. The question about where to execute that timers really formulated this in my mind.
> > >>
> > >> The user would set up the data tables, and all the processes would communicate with each other via these. These would be in shared memory, and the various tasks would all pass data through them.
> > >>
> > >> This ties in very well with the thoughts I have previously posted about I/O scanner tasks and logic processor tasks.
> > >>
> > >> How does this sound?
> > >>
> > >Does the phrase 'make it so...' sound too presumptious??
> > >
> > Well then, may I humbly suggest that we start coding the routines to access this shared memory data table? ...<clip>

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

 

"Sage, Pete (IndSys, GEFanuc, Albany)" wrote:

> I would look at using a semaphore or atomic counter to protect access to the
> shared memory region. Simple flags usually cause simply impossible to debug
> race conditions.

Yes, but just exactly how to do it depends on whether we're synchronous, parallel, or whatever. We could also use a token to enforce exclusion.

> Another thought is that synchronization between the logic engine and the
> scanner is going to be difficult if they are both of asychronously doing
> their thing. I'd consider allowing the logic engine to tell the scanner
> when to scan. That way if you want to implement the typical PLC model of
> scan inputs, solve, write outputs, you can easily coordinate the actions.
> Else you'll have no control and coordination of the two processes.
>

I agree, but others don't want to be limited to lock-step. It depends, I suppose on if you can live with an occasional delay on coincidence. For bandwidth considerations we would probably want to pace the I/O in a programmable manner. If these intervals are long enough we could simply prevent conflict. Using network I/O introduces some challanges too.


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