Experimental Physics and
Industrial Control System

"Kasemir, Kay" <[email protected]> · Wed, 13 May 2009 08:45:17 -0400

Hi:

On 5/13/09 24:09 , "Mark Rivers" <[email protected]> wrote:
> I suspect that this is because the EtherIP is asynchronous device support...

The EtherIP output record support is somewhat asynchronous,
but not in the usual sense.

Processing slave1C will update the driver's copy of epics_outputs[0],
flag the array epics_outputs as 'needs to be written',
and record processing is done.

Processing slave2C will update the driver's copy of epics_outputs[1],
flag the array epics_outputs as 'needs to be written',
and record processing is done.

Depending on what happens first, either the processing of slave1C
or slave2C might notice that the epics_outputs array was already
flagged as 'needs to be written'. Not a problem.

Meanwhile, the driver has a separate thread the periodically checks
epics_outputs. If it's flagged as 'needs to be written',
the driver writes the whole epics_outputs array to the PLC
and resets the flag. If it's not flagged for writing,
the driver will read the array, check all records that refer to
elements of epics_outputs, and update them if their value differs.

So a typical output record operation is:
Record processes, informs the driver, and processing is done.
The driver performs the write after some delay.

On the other hand, if the tag on the PLC changes by other means
(ladder logic, access from Panel View, ...), the driver will notice
this because of the periodic reads and the _output_ record will
effectively _read_ the current value back from the PLC.

If you set the record's TPRO field, the driver should actually print
info on what it's writing or indicate that it's updated by the driver
because the tag changed on the PLC.
That might help to see what's happening in your case where
the records get processed OK, but the data on the PLC doesn't
seem to match.

Thanks,
-Kay

> From: [email protected] on behalf of John Sinclair
> I meant to say that the slave pvs update but the device does not. So, I
> guess this is an EthernetIP device support question.
> ...
> -----------------------------------------------------------
> 
> The following is an attempt to control two slave pvs by a master pv via
> a dfanout record.
> 
> The desired behavior is that wiggling masterC should cause both slave1C
> and slave2C to follow.
> 
> record(ao, "masterC") {
>    field(DTYP, "SoftChannel")
>    field(OUT,  "dfout PP")
>    field(SCAN, "Passive")
> }
> 
> record(dfanout,"dfout") {
>    field(SCAN, "Passive")
>    field(OUTA, "slave1C PP")
>    field(OUTB, "slave2C PP")
> }
> 
> record(ao,"slave1C") {
>    field(SCAN,"Passive")
>    field(DTYP,"EtherIP")
>    field(OUT, "@cpu epics_outputs[0]")
> }
> 
> record(ao,"slave2C") {
>    field(SCAN,"Passive")
>    field(DTYP,"EtherIP")
>    field(OUT, "@cpu epics_outputs[1]")
> }
> 
> ---------------------------------
> 
> If I create a script as follows:
> 
> caput -t masterC 1
> caput -t masterC 2
> 
> When executed, the result is that sometimes it works (i.e. slave1C and
> slave2C have the final value 2) and sometimes it does not (slave1C and
> slave2C have the final value 1).
> 
> Is the record linking in the above example flawed? If so, is there a way
> to make this reliable?
> 
> TIA,
> John Sinclair
> 
> 
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System