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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Modbus for Huber Pilotone |
From: | Florian Feldbauer via Tech-talk <tech-talk at aps.anl.gov> |
To: | tech-talk at aps.anl.gov |
Date: | Thu, 19 May 2022 17:14:56 +0200 |
Hey all,
we have a Huber Unistat chiller with "PilotOne" Controller. The
Controller has a modbus/TCP interface.
For reading out the status of the chiller, I have set the SCAN field of the first input record and use a chain of forward links to all the other input records.
Sometimes I can see messages of the following type in my IOC:
epics> 2022/05/19 16:46:36.370 drvModbusAsyn::doModbusIO port
chillerReadReg error calling writeRead, error=PilotONE-187144:502
TCP timeout: Resource temporarily unavailable, nwrite=6/6, nread=0
2022/05/19 16:46:36.370 SCATTERCHAMBER:COOLING:FillLevel
devAsynInt32::processCallbackInput process read error
2022/05/19 16:46:36.469 drvModbusAsyn::doModbusIO port
chillerReadReg writeRead status back to normal having had 1
errors, nwrite=6/6, nread=4
My guess is, the forward links are processed "too fast" for the
controller and it cannot reply.
Is this plausible or could this error messages have a different
cause?
What would be a good idea to "slow down" the readout?
Using a seq record with delays instead of forward links?
Another issue, that I have is writing the Setpoint of the device. From the manual:
The client sends the following request to the Modbus slave:
00 02 00 00 00 06 FF 06 00 00 05 DC
The command is made up as follows:
00 02 TID (any number that can be used to assign a response to a query)
00 00 PID (always 0x0000)
00 06 The message length is 6 bytes. Of these, 1 byte is used for the unit identifier, 1 byte
for the function code, 2 bytes for the PB address and 2 bytes are used for the value
to be written.
FF Unit identifier (UID, always 0xFF)
06 Function code 0x06 is used for Writing Single Holding Registers
00 00 PB address (vSP 0x00)
05 DC The setpoint temperature is to be set to 15.00 °C. The value 1500 equals 0x05DC in
hex notation.
The Modbus slave returns the following response:
00 02 00 00 00 06 FF 06 00 00 05 DC
For me it looks like this:
epics> dbpf SCATTERCHAMBER:COOLING:Setpoint 15
DBF_DOUBLE: 15
2022/05/19 17:04:09.078 drvModbusAsyn::doModbusIO port chillerWriteReg WRITE_SINGLE_REGISTER address=00 value=0x0
epics> 2022/05/19 17:04:09.078 PilotONE-187144:502 TCP write 12
a2 3e 00 00 00 06 ff 06 00 00 00 00
2022/05/19 17:04:09.078 PilotONE-187144:502 TCP read 0
2022/05/19 17:04:09.079 drvModbusAsyn::doModbusIO port chillerWriteReg called pasynOctetSyncIO->writeRead, status=3, requestSize=6, replySize=5, nwrite=6, nread=0, eomReason=0
epics>
First, the value (15) is not send, instead 00 00 is send. Second
I do not get a reply from the device.
I load the driver with
drvAsynIPPortConfigure( "chiller", "PilotONE-187144:502 TCP", 0,
0, 0 )
modbusInterposeConfig( "chiller", 0, 300, 0 )
drvModbusAsynConfigure( "chillerWriteReg", "chiller", 0xff, 6,
-1, 1, "INT16", 0, "Huber PilotOne" )
The record looks like this:
record( ao, "$(H):$(N):Setpoint" ) {
field( DTYP, "asynInt32" )
field( OUT, "@asyn($(PORT_W) 0x00)INT16" )
field( EGU, "degC" )
field( PREC, "2" )
field( ADEL, "1" )
field( MDEL, "1" )
field( ASLO, "100" )
field( AOFF, "0" )
}
Any idea what am I doing wrong here?
Thanks for your help,
Florian
-- Ruhr-Universität Bochum AG der Experimentalphysik I Dr. Florian Feldbauer NB 2/131 / Fach 125 Universitätsstr. 150 D-44801 Bochum Office: NB 2/134 Phone: (+49)234 / 32-23563 Fax: (+49)234 / 32-14170 https://paluma.ruhr-uni-bochum.de