EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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  <20222023  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  <20222023  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

Replies:
RE: Modbus for Huber Pilotone Mark Rivers via Tech-talk

Navigate by Date:
Prev: Bus errors accessing VME with base 7.0.6.1 and latest synApps modules Mark Rivers via Tech-talk
Next: RE: Modbus for Huber Pilotone Mark Rivers 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  <20222023  2024 
Navigate by Thread:
Prev: RE: Bus errors accessing VME with base 7.0.6.1 and latest synApps modules Mark Rivers via Tech-talk
Next: RE: Modbus for Huber Pilotone Mark Rivers 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  <20222023  2024 
ANJ, 14 Sep 2022 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·