Sequntial vs. Non-Sequential I/O scan

S

Thread Starter

Stan Brown

There seems to be a bit of a debate about sequential versus non sequential I/O scans.

I thought I would step in and explain existing practice here.

In the majority of modern PLC systems the application program sees a unchanging view of the inputs as they were at the start of the scan, and
sees the outputs as they have been modified by the application program.
That is an output that was off at the start of the scan, but turned on during the scan will appear to be on to instruction later in the scan.

This is accomplished by having an I/O update task that runs in parallel with the logic solving engine. At the beginning of a scan the logic solving engine makes it's own copy of the I/O image table, and uses this for the remainder of the scan. Thus you get the dual benefit of a consistent view of the inputs for the application program, and allowing input scanning, and the setting of outputs to run in parallel, thus not delaying the logic solving engine.

I think we should adopt this technique.

--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.
--
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
B

Butler, Lawrence

> -----Original Message-----
> From: Stan Brown [SMTP:[email protected]]
> Sent: Thursday, January 13, 2000 7:11 PM
>
> There seems to be a bit of a debate about sequential versus non
> sequential I/O scans.
>
> I thought I would step in and explain existing practice here.
>
> In the majority of modern PLC systems the application program sees a
> unchanging view of the inputs as they were at the start of the scan,
> and
> sees the outputs as they have been modified by the application
> program.
> That is an output that was off at the start of the scan, but turned
> on
> during the scan will appear to be on to instruction later in the
> scan.
>
> This is accomplished by having an I/O update task that runs in
> parallel
> with the logic solving engine. At the beginning of a scan the logic
> solving engine makes it's own copy of the I/O image table, and uses
> this for the remainder of the scan. Thus you get the dual benefit of
> a
> consistent view of the inputs for the application program, and
> allowing
> input scanning, and the setting of outputs to run in parallel, thus
> not
> delaying the logic solving engine.
>
> I think we should adopt this technique.
<snip>

This is a good place to get a START any way........

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
Dave West wrote
<clip>
If it was any other way the programmer would have to make his own copy of the I/O tables at the start of a scan otherwise bits could change in the
middle of an instruction.
</clip>

Which is what you had to do with the AB PLC3. The asynchronous I/O scan meant that the state of an input could change from rung to rung so all the
I/O used for a particular function in a particular block of rungs had to be copied to a work area at the start of the code.

This is not a bad practice, and with moderen function block coding is often implicit, however, it proved to be a rigth pain on occasion and could
through in problems that were difficult to debug.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
On Mon Jan 17 03:36:04 2000 Mark Hutton wrote...
>
>Dave West wrote
><clip>
>If it was any other way the programmer would have to make his own copy of the I/O tables at the start of a scan otherwise bits could change in the middle of an instruction.
></clip>
>
>Which is what you had to do with the AB PLC3. The asynchronous I/O scan
>meant that the state of an input could change from rung to rung so all the
>I/O used for a particular function in a particular block of rungs had to be
>copied to a work area at the start of the code.
>
>This is not a bad practice, and with moderen function block coding is often
>implicit, however, it proved to be a rigth pain on occasion and could
>through in problems that were difficult to debug.

This option was available on AB PI's also, although I must admint I never used it. PLC-2's with remote I/O had this too, sort of.

--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.
--
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S

Simon Martin

This is more or less what I was trying to say. We have two pages, one is the input page for this scan, the other is the output page for the current scan and the where the io processes read/write their data. At the start of every
scan the pages are swapped (just pointers) this means that there is no memory copy overhead, just the process synchronization overhead.

Debian GNU User
Simon Martin
Project Manager
Isys
mailto: [email protected]

There is a chasm of carbon and silicon the software cannot bridge


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
Yep. I'm not too sure how to handle the output table, but if I was coding the controller (to execute ladder) I'd make a local copy of
the input table before starting the 'scan'. If I grabbed a copy of the output table before the scan and simply wrote it out after the scan, I'd
stand a chance of missing any output change that was made by another process during the processing of my ladder. ... Maybe another reason to
'lock' each output to a particular controlling process?

It seems to me the best way to implement force tables is to have an intermediate table. (I do this for forcing I/O on the PMAC motion
controller.) The input process reads the real inputs and places them in a table, the force processor applies the forces and write its results in a table that the control processes use for inputs. The control processes NEVER NEVER have direct access to the real input table. Same
thing happens for outputs.

Mark


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
>Yep. I'm not too sure how to handle the output table, but if I was
>coding the controller (to execute ladder<g>) I'd make a local copy of
>the input table before starting the 'scan'. If I grabbed a copy of the
>output table before the scan and simply wrote it out after the scan, I'd
>stand a chance of missing any output change that was made by another
>process during the processing of my ladder. ... Maybe another reason to
>'lock' each output to a particular controlling process?

Exactly.
>
>It seems to me the best way to implement force tables is to have an
>intermediate table. (I do this for forcing I/O on the PMAC motion
>controller.) The input process reads the real inputs and places them in
>a table, the force processor applies the forces and write its results in
>a table that the control processes use for inputs. The control
>processes NEVER NEVER have direct access to the real input table. Same
>thing happens for outputs.

Well, as I envision it, up until now we have a bunch of process that run without knowledge (other than the data table interfaces) of each other. If the logic engine is made responsible for dealing with the force tables, this model still holds. If we build a "force engine" then the logic engine, and the I/O scanner must call upon it for services. I think I like requiring the logic engine, and i/O scanner to understand the (respectively) input force table, and output force table is better.

--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.
--

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
At last somebody with some sense.
Most control system engineers expect the system yo operate as stated above wether they realise it or not. Most could not cope with it any other way.
If it was any other way the programmer would have to make his own copy of the I/O tables at the start of a scan otherwise bits could change in the
middle of an instruction. As an example consider the following pseudo code:
if ANALOGUE_INPUT == 25
display "= 25"
endif
.... may change here
if ANALOGUE_INPUT == 50
display "= 50"
endif

Using the above scan methodology the code works as expected but if the IO is updated "live" then the code WILL fail intermitantly by executing both
clauses. I suspect that those people calling for the logic engine to process real live I/O have never done anything like interrupt driven processing. Why do UNIX programmers use lock files when accessing serial devices etc (/var/loc/LCK..???) and why do they have to be very carefull about how
they test for and create these lock files?
(BTW I know, do others?)


Dave West E-Mail: [email protected]
Semiras Projects Ltd. PGP public key available on request.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
On Fri Jan 14 13:17:45 2000 Simon Martin wrote...
>
>One of the things most people seem to agree about is that we run multiple
>logic engines simultaneously, so how do we force them all to fit into a
>"scan" philosophy?

Actually, this is not a problem at all. There are several (many) scans. Each I/O scanner has a scan. It grabs a copy of the output image table before starting it's work, validates it with the force tables, and proceeds to set all the outputs it is responsible for. Then it collects the statuses of all the inputs it is responsible for, locks the appropriate input image tables, and updates them.

Meanwhile each logic engine has it's own "scan". At the beginning of it's scan it locks the appropriate input and output image tables, makes it's own copy, processes the inputs through the force tables, and proceeds to do it's logic scan. At the end of this, it locks the appropriate output image table, and sets the values in it to the calculated ones.

Thus we have several (many?) simultaneous scans going on at once.


--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.

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