Re: modbus ioc start

[Dale Cox via Tech-talk <tech-talk at aps.anl.gov>]

Ok, I did a pull of the master branch and all PV's are working as expected.

Cheers.

On Mon, Apr 17, 2023 at 11:59 AM Mark Rivers <rivers at cars.uchicago.edu> wrote:

Hi Dale,

 

Great news.  I am pretty sure I understand the problem, and I fixed it on the master branch.  Can I ask you to test the master branch again?  You can do this after your local edit:

 

cd modbusApp/src

git checkout master drvModbusAsyn.cpp

git pull

 

Thanks,

Mark

 

 

From: Dale Cox <dale.cox at acu.edu>
Sent: Monday, April 17, 2023 11:46 AM
To: Mark Rivers <rivers at cars.uchicago.edu>
Cc: Torsten Bögershausen <torsten.bogershausen at ess.eu>; tech-talk at aps.anl.gov
Subject: Re: modbus ioc start

 

Yes, I'm probably running master.

 

And that fixed it!  I'll put that in my list to make sure we're running R3-2.  Thank you for the help.

 

Dale

 

On Mon, Apr 17, 2023 at 11:19 AM Mark Rivers <rivers at cars.uchicago.edu> wrote:

Hi Dale,

 

Are you running the master branch of Modbus?  If so I may see a problem.  Can you try running the most recent release, R3-2 instead?  Alternatively you can just revert this change:

 

-    ioStatus_(asynSuccess),

+    ioStatus_(asynError),

 

In other words initialize ioStatus_ to asynSuccess, not asynError.

 

Mark

 

 

From: Dale Cox <dale.cox at acu.edu>
Sent: Monday, April 17, 2023 9:23 AM
To: Mark Rivers <rivers at cars.uchicago.edu>
Cc: Torsten Bögershausen <torsten.bogershausen at ess.eu>; tech-talk at aps.anl.gov
Subject: Re: modbus ioc start

 

Yes that's correct. On startup, I can see the initial modbus request:

2023/04/17 08:56:53.944 /dev/ttyUSB0 read.
2023/04/17 08:56:53.952 /dev/ttyUSB0 read 13

05 03 08 d0 11 d2 00 d2 00 d2 11 3b 1c
2023/04/17 08:56:53.952 /dev/ttyUSB0 read 13, return 0
2023/04/17 08:56:53.952 SenecaBus read 13 bytes eom=0

 

Then, if I do a "caput DALE:Z8TC:Z8TC1-Conf-TC1_enable Disabled", I can see the modbus register gets written in the IOC stdout - 

05 06 00 35 50 11 64 4c
2023/04/17 09:14:58.610 wrote 8 to /dev/ttyUSB0, return asynSuccess
2023/04/17 09:14:58.610 asynOctetSyncIO wrote:

 

 And if I restart the IOC, I can now see it does read that changed value on startup:

 

05 03 08 50 11 d2 00 d2 00 d2 11 33 7c
2023/04/17 09:19:52.195 /dev/ttyUSB0 read 13, return 0
2023/04/17 09:19:52.195 SenecaBus read 13 bytes eom=0

 

So the record does what is intended for writes.  It just doesn't update with the initial value on startup like it should.  It's all zeroes for the entire register. 

 

On Mon, Apr 17, 2023 at 8:59 AM Mark Rivers <rivers at cars.uchicago.edu> wrote:

“do process” not “due process “! Damn autocorrect!

Sent from my iPhone

 

On Apr 17, 2023, at 8:56 AM, Mark Rivers <rivers at cars.uchicago.edu> wrote:

 UDF is expected because the records have not yet processed. We know the records are communicating with the hardware because when they due process Dale reported that it controlled the hardware properly.

 

Mark

 

Sent from my iPhone

 

On Apr 17, 2023, at 8:28 AM, Torsten Bögershausen <torsten.bogershausen at ess.eu> wrote:



Hm, isn't it that all records are in state "undefined" (STAT: UDF) ?

Which means that I still want to see what the asynParameters have picked up.

And how they link to the records.

 

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>
Reply-To: Mark Rivers <rivers at cars.uchicago.edu>
Date: Monday, 17 April 2023 at 15:21
To: Dale Cox <dale.cox at acu.edu>
Cc: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Subject: Re: modbus ioc start

 

Hi Dale,

 

You forgot to put the "2" at the end of the dbpr commands.  That will print more information.  Please do again with the final 2.

 

I see that RVAL is 0 for all 3 records.  That is not what it should be, since we think a non-zero value was read back from the driver in init_record.

 

Mark

 

 

---

From: Dale Cox <dale.cox at acu.edu>
Sent: Monday, April 17, 2023 8:06 AM
To: Mark Rivers <rivers at cars.uchicago.edu>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: modbus ioc start

 

Mark, Here are the following returns for dbpr of those db records:

 

epics> dbpr DALE:Z8TC:Z8TC1-Conf-TC1_enable
AMSG:               ASG :               DESC:               DISA: 0            
DISV: 1             NAME: DALE:Z8TC:Z8TC1-Conf-TC1_enable   NAMSG:              
RBV : 0             RVAL: 0             SEVR: INVALID       STAT: UDF          
TPRO: 0             VAL : 0

 

 epics> dbpr DALE:Z8TC:Z8TC1-Conf-TC2_enable

AMSG:               ASG :               DESC:               DISA: 0            
DISV: 1             NAME: DALE:Z8TC:Z8TC1-Conf-TC2_enable   NAMSG:              
RBV : 0             RVAL: 0             SEVR: INVALID       STAT: UDF          
TPRO: 0             VAL : 0 

 

 epics> dbpr DALE:Z8TC:Z8TC1-Conf-TC1-2_units
AMSG:               ASG :               DESC:               DISA: 0            
DISV: 1             NAME: DALE:Z8TC:Z8TC1-Conf-TC1-2_units  NAMSG:              
RBV : 0             RVAL: 0             SEVR: INVALID       STAT: UDF          
TPRO: 0             VAL : 0 

 

I'm creating the longout record now. I'll post it's readouts in a bit. 

 

On Sat, Apr 15, 2023 at 8:24 AM Mark Rivers <rivers at cars.uchicago.edu> wrote:

Hi Dale,

 

> Is it supposed to say "asynSuccess" at the end of the highlighted section?  I get a "return 0".

 

Yes, asynSuccess is an enum with the value 0.

 

Mark

 

 

---

From: Dale Cox <dale.cox at acu.edu>
Sent: Friday, April 14, 2023 8:43 AM
To: Mark Rivers <rivers at cars.uchicago.edu>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: modbus ioc start

 

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

 

 

On Thu, Apr 13, 2023 at 4:38 PM Mark Rivers <rivers at cars.uchicago.edu> wrote:

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:

 

1. 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.
2. 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.
3. 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

 

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Dale Cox via Tech-talk
Sent: Thursday, April 13, 2023 8:29 AM
To: tech-talk at aps.anl.gov
Subject: modbus ioc start

 

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")
}

 

Any help is appreciated.

 

Dale 

 

--

Dale Cox

Instrumentation and Electrical Engineer

ACU NEXT Lab