Re: Modbus for Huber Pilotone

[Florian Feldbauer via Tech-talk <tech-talk at aps.anl.gov>]

Hey Mark,

thanks for your reply.

I'm using tag R3-2 from github. I'm new to modbus, and wasn't aware that it makes a difference if I use absolute or relative addressing.
In my first try relative did not work, I guess I did something wrong with calculating the offsets correctly. I will give it another try.

As for the ao record: those who can read are at a clear advantage
From the record reference manual

> Conversion proceeds as follows:
>         1. If LINR==LINEAR or LINR==SLOPE, then X = (VAL - EOFF) / ESLO,
>         else if LINR==NO_CONVERSION, then X = VAL, else X is obtained
>         via breakpoint table.
>         2. X = (X - AOFF) / ASLO
>         3. RVAL = round(X) - ROFF
>

15/100 = 0.15....round(0.15) = 0.....I thought VAL is multiplied by ASLO not divided.
Setting ASLO to 0.01 instead of 100 leads to the expected output:

epics> dbpf SCATTERCHAMBER:COOLING:Setpoint 15
2022/05/20 10:06:23.565 drvModbusAsyn::doModbusIO port chillerWriteReg WRITE_SINGLE_REGISTER address=00 value=0x5dc
DBF_DOUBLE:         15        
2022/05/20 10:06:23.565 PilotONE-187144:502 TCP write 12

15 75 00 00 00 06 ff 06 00 00 05 dc
2022/05/20 10:06:23.618 PilotONE-187144:502 TCP read 12

15 75 00 00 00 06 ff 06 00 00 05 dc
2022/05/20 10:06:23.620 drvModbusAsyn::doModbusIO port chillerWriteReg called pasynOctetSyncIO->writeRead, status=0, requestSize=6, replySize=5, nwrite=6, nread=5, eomReason=1
2022/05/20 10:06:23.621 drvModbusAsyn::writeInt32 port chillerWriteReg function=0x6, modbusAddress=00, buffer[0]=0x5dc, bufferLen=1

VG Florian

On 5/19/22 21:03, Mark Rivers wrote:

Hi Florian,

Ø  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.

Ø  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?

I see you defined your driver to use absolute addressing.  That is not the way it is typically used.  If you change to relative addressing then when you process your input records they don’t actually cause any Modbus I/O, they just return the most recent poll reading from the driver.  That means there is no reason to “slow down” the readout, since it is not affecting the Modbus communications.  If your drivers are polling (not absolute addresses) then you should probably not set your input records to periodically scan, but rather set them SCAN=I/O Intr.  Then the records will only process when the polled value changes.

 

I am not sure why it is not sending the correct value for the temperature.

 

What version of the Modbus driver are you using?  If the device sends a Modbus exception then I believe some older versions of the driver would not show you that, and it would appear that you received no response. 

 

Mark

 

 

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Florian Feldbauer via Tech-talk
Sent: Thursday, May 19, 2022 10:15 AM
To: tech-talk at aps.anl.gov
Subject: Modbus for Huber Pilotone

 

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

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