Thanks for the reply Mark.
(1) Yes I thought this was the case. Whenever I enable some asyn trace lines in the IOC, I can see the initial modbus request. It looks like this:
... drvModbusAsynConfigure("Z8TC1_Config", "SenecaBus", 5, 6, 53, 4, "UINT16", 400, "SenecaZ") 2023/04/14 08:32:01.482 SenecaBus asynManager::queueLockPort locking port 2023/04/14 08:32:01.482 SenecaBus asynManager::queueLockPort created queueLockPortPvt=0x55ec3aba5df0 2023/04/14 08:32:01.482 SenecaBus asynManager::queueLockPort created queueLockPortPvt=0x55ec3aba5df0, event=0x55ec3aba5e10, mutex=0x55ec3aba5eb0 2023/04/14 08:32:01.482 SenecaBus asynManager::queueLockPort taking mutex 0x55ec3aba5eb0 2023/04/14 08:32:01.482 SenecaBus asynManager::queueLockPort queueing request 2023/04/14 08:32:01.482 SenecaBus addr -1 queueRequest priority 0 not lockHolder 2023/04/14 08:32:01.482 SenecaBus schedule queueRequest timeout in 2.000000 seconds 2023/04/14 08:32:01.482 SenecaBus asynManager::queueLockPort waiting for event 2023/04/14 08:32:01.482 asynManager::portThread port=SenecaBus callback 2023/04/14 08:32:01.482 SenecaBus asynManager::queueLockPortCallback signaling begin event 2023/04/14 08:32:01.482 SenecaBus asynManager::queueLockPortCallback waiting for mutex from queueUnlockPort 2023/04/14 08:32:01.482 SenecaBus asynManager::queueLockPort got event from callback 2023/04/14 08:32:01.482 SenecaBus flush 2023/04/14 08:32:01.482 /dev/ttyUSB0 flush 2023/04/14 08:32:01.487 /dev/ttyUSB0 write. 2023/04/14 08:32:01.487 /dev/ttyUSB0 write 8
05 03 00 35 00 04 55 83 2023/04/14 08:32:01.487 wrote 8 to /dev/ttyUSB0, return asynSuccess 2023/04/14 08:32:01.487 asynOctetSyncIO wrote:
05 03 00 35 00 04 2023/04/14 08:32:01.487 /dev/ttyUSB0 read. 2023/04/14 08:32:01.495 /dev/ttyUSB0 read 13
05 03 08 d0 11 d2 00 d2 00 d2 11 3b 1c 2023/04/14 08:32:01.495 /dev/ttyUSB0 read 13, return 0 2023/04/14 08:32:01.495 SenecaBus read 13 bytes eom=0
05 03 08 d0 11 d2 00 d2 00 d2 11 3b 1c 2023/04/14 08:32:01.495 asynOctetSyncIO read:
03 08 d0 11 d2 00 d2 00 d2 11 2023/04/14 08:32:01.495 SenecaBus queueUnlockPort 2023/04/14 08:32:01.495 SenecaBus asynManager::queueUnlockPort waiting for event 2023/04/14 08:32:01.495 SenecaBus queueUnlockPort unlock mutex 0x55ec3aba5eb0 complete.
...
So I'm getting the requested registers back on that port, and you can see their values there. d0 11 is 1101000000010001 in binary, so when I look at the 15th bit, it should return back a 1. when I do a caget on that PV, I get a 0 (I get 0's for all of the records associated with these registers).
Is it supposed to say "asynSuccess" at the end of the highlighted section? I get a "return 0".
Thanks for helping me troubleshoot.
Dale
Hi Dale,
- My issue is that the PV values aren't being updated when the IOC starts -- meaning that after the IOC start, the bo and mbbo values stored in that register don't match what was returned
via the initial modbus request.
I am not sure I completely understand what you are saying. Here is what should happen:
- Because this port you created uses function code 6 (write single register) and because you have a non-zero poll time, the driver will do one initial read of that register using function
code 3.
- EPICS device support for the bo records does a read operation from the port during init_record. If this read returns asynSuccess (which it should) then the value of the bo record
is set to the value read from the driver. This is the “bumpless reboot” concept.
- You have not set PINI=YES in these records, so the value from the record will not be written back to the device during iocInit. However, the record value should still match the device,
because of steps 1 and 2 above.
If I understand correctly you are saying that the bo record does have the correct value read from the device during steps 1-2. But now the device has a different value from that in the record? I don’t understand that, since it seems like
there must have been a write to the device to change the value?
Mark
Good Morning,
I have an IOC that is currently reading registers via modbus rtu over rs485. There are a set of registers that store multiple configuration options in a single register. I set up the port using this line:
> drvModbusAsynConfigure("Z8TC1_Config", "SenecaBus", 5, 6, 53, 4, "UINT16", 100, "SenecaZ")
I've enabled the debugging lines on this IOC. When the IOC starts, I can see that the correct registers are being retrieved when the port is created. I can also write config changes to those registers at their assigned PV's with no issues
that I have found. My issue is that the PV values aren't being updated when the IOC starts -- meaning that after the IOC start, the bo and mbbo values stored in that register don't match what was returned via the initial modbus request.
Here are a couple of the DB entries that I'm using:
record(bo,"$(P)$(R)-TC1_enable") {
field(DTYP,"asynUInt32Digital")
field(OUT,"@asynMask($(PORT), 0, 0x8000 )")
field(ZNAM,"Disabled")
field(ONAM,"Enabled")
}
record(bo,"$(P)$(R)-TC2_enable") {
field(DTYP,"asynUInt32Digital")
field(OUT,"@asynMask($(PORT), 0, 0x4000 )")
field(ZNAM,"Disabled")
field(ONAM,"Enabled")
}
record(bo,"$(P)$(R)-TC1-2_units") {
field(DTYP,"asynUInt32Digital")
field(OUT,"@asynMask($(PORT), 0, 0x2000 )")
field(ZNAM,"tempDegC")
field(ONAM,"mV")
}
--
Dale Cox
Instrumentation and Electrical Engineer
- Replies:
- Re: modbus ioc start Torsten Bögershausen via Tech-talk
- Re: modbus ioc start Mark Rivers via Tech-talk
- References:
- modbus ioc start Dale Cox via Tech-talk
- RE: modbus ioc start Mark Rivers via Tech-talk
- Navigate by Date:
- Prev:
Re: Is the Sequencer and SNL still widely used? Hu, Yong via Tech-talk
- Next:
Re: Is the Sequencer and SNL still widely used? Murray, Doug via Tech-talk
- 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:
RE: modbus ioc start Mark Rivers via Tech-talk
- Next:
Re: modbus ioc start Torsten Bögershausen via Tech-talk
- 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
|