Re: Modbus TCP and Omega

["S. Banerian" <banerian@u.washington.edu>]

Hi

If we take the data to be 2's complement, then, by referring to
modbusDoc.html, this would be modbusDataType value 4.

We use modbus function 4 in drvModbusAsynConfigure  and then create a
record:

record(ai, temp:bar) {
  field(DESC, "temp probe input")
  field(SCAN, "Passive")
  field(DTYP, "asynInt32")
  field(INP, "@asynMask(TempProbeRead, 0, 16,100) INT16 ")
 field(LINR,"LINEAR")
}

but when starting the IOC, we get error output:
temp:bar devAsynInt32::initCommon findInterface asynInt32Type invalid
INST_IO Must be asyn(<port> <addr> <timeout>)userParams

asynMask  syntax is rejected, and only with
asyn(TempProbeRead, 0, 100) INT16)
do we get no _startup_ erors.

asyn version 4-17
modbus 2-2
base 3.14.12.3


stefani banerian



On 05/13/2013 03:53 PM, Mark Rivers wrote:
> Hi Stefani,
> 
> I looked a little more closely at the Omega manual:
> 
> http://www.omega.com/manuals/manualpdf/M3397.pdf
> 
> On page 40 they give an example of setting Alarm2 to -100.0.  This is done in 2 steps:
> 
> - Set the decimal point to position 2 (FFF.F).
> - Send the value -1000 in 2's complement format.
> 
> This shows that the meter does use 2's complement for signed integers.
> 
> Mark
> 
> 
> -----Original Message-----
> From: Mark Rivers 
> Sent: Monday, May 13, 2013 5:12 PM
> To: 'banerian@u.washington.edu'; EPICS Tech Talk
> Subject: RE: Modbus TCP and Omega
> 
> Hi Stefani,
> 
> Are you using my EPICS Modbus module?  
> 
> When you say "it sends back its data as hex", how are you getting the 00 e6 value?  Using asynTrace?
> 
> I suspect the device is actually returning 16-bit binary data, which is the most common Modbus data type.
> 
> You need to look at the Omega manual to determine:
> 
> - How many bits is the data (12, 14, 16, etc.)
> - What binary format does it use (2's complement, sign and offset, etc.)
> 
> I took a quick look at the Omega iSeries communications manual:
> 
> http://www.omega.com/manuals/manualpdf/M3397.pdf
> 
> It has a reasonable description of their Modbus protocol.  However, I could not find a description of how they handle signed numbers - 2's complement or sign and offset. 
> 
> You should then use a record definition like the following:
> 
> # ai record template for register inputs
> record(ai, "$(P)$(R)") {
>     field(DTYP,"asynInt32")
>     field(INP,"@asynMask($(PORT) $(OFFSET) $(BITS))INT16")
>     field(LINR,"LINEAR")
>     field(EGUL,"$(EGUL)")
>     field(EGUF,"$(EGUF)")
>     field(HOPR,"$(EGUF)")
>     field(LOPR,"$(EGUL)")
>     field(PREC,"$(PREC)")
>     field(SCAN,"$(SCAN)")
> }
> 
> The UINT16 drvUser field assumes the device has signed 16-bit 2's complement data.  Other possibilities are UINT16 (unsigned 16-bit integers), INT16SM (16-bit integers in sign-magnitude format), etc.  This document provides more information:
> 
> http://cars9.uchicago.edu/software/epics/modbusDoc.html
> 
> Let me know if you have more questions or problems.
> 
> Cheers,
> Mark
> 
> 
> 
> -----Original Message-----
> From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of S. Banerian
> Sent: Monday, May 13, 2013 4:24 PM
> To: EPICS Tech Talk
> Subject: Modbus TCP and Omega
> 
> 
> I have an Omega CNi853-EIT device, with thermocouple attached, which can
> be accessed via Modbus TCP.
> 
> I've been able to get an IOC to query the Omega, and it does reply, but
> it sends back its data as hex, so, e.g. 00 e6 is its representation for
> 230 (23.0 C).
> 
> In my databases, I've tried mbbi bi and ai  types, but probe tells me
> the PV is always in an "invalid" state.
> 
> What would folks suggest I use to read this hex value?
> 
> 


-- 
Stefani Banerian
UW Clinical Cyclotron
UW School of Medicine
206-598-0302
gpg key 6642E7EE
fingerprint = BD13 875D 2D03 5E1D 1E3B  8BF7 F4B8 63AD 6642 E7EE