My first message was incorrect - sorry.
I meant to say that the slave pvs update but the device does not. So, I
guess this is an EthernetIP device support question.
So, I will instead ask if anyone has seen this behavior?
John
-----------------------------------------------------------
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
- Replies:
- RE: record linking question Mark Rivers
- Re: record linking question Tim Mooney
- Navigate by Date:
- Prev:
record linking question John Sinclair
- Next:
RE: record linking question Mark Rivers
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
record linking question John Sinclair
- Next:
RE: record linking question Mark Rivers
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
<2009>
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|