Hi Greg,
I'm glad to hear you got it working. I think you actually should have been able to read the floats without changing the hardware settings. The Modbus driver supports 4 versions of 32-bit floats: https://epics-modbus.readthedocs.io/en/latest/#modbus-register-data-types
FLOAT32_LE
FLOAT32_LE_BS
FLOAT32_BE
FLOAT32_BE_BS
LE/BE is little endian/big endian and BS does byte-swapping within each 16-bit word. I believe one of those options would have worked with the original hardware setting.
Mark
________________________________
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Leblanc, Gregory via Tech-talk <tech-talk at aps.anl.gov>
Sent: Friday, August 27, 2021 8:56 AM
To: Taufer, Gary; tech-talk at aps.anl.gov
Subject: RE: Watlow_PM communication
I was able to get out to the controller today and switch the Modbus Word Order parameter from Lohi to hiLo, and now I can read the floats without getting garbled data. I'll put you down for a beverage! Thanks so much,
Greg
-----Original Message-----
From: Taufer, Gary <tauferga at ornl.gov>
Sent: Wednesday, August 25, 2021 2:26 PM
To: tech-talk at aps.anl.gov; Leblanc, Gregory <leblanc at ohio.edu>
Subject: RE: Watlow_PM communication
Greg,
Defining the addressing for the Watlows was a challenge due to exactly what you're mentioning about the data type. It would have been nice if the registers were organized in the Watlows by Data Type when it comes to connectivity with EPICS. There are definitely better ways to deal with the addressing but since this was an early project in my EPICS career it's less efficient.
The range of addresses for similar data types are organized primarily by the Menu function so for instance the watlow_AI_Num_1.1 are to address registers related to the Analog Input functions with Float data types. Since the modbusFunction is defined as '4' the maximum address range (modbusLength) would be 125. We simplified this and defined the port configuration limit as 100 as stated in the st.cmd file. The full range of register addresses for the Analog Input function exceeds this maximum, ranging from 360 to 510 totaling a span of 150 relative addresses. So the Analog Input port addressing was split into 2 port configurations, watlow_AI_Num_1.1 and watlow_AI_Num_2.1 (The '.1' at the end of the port name relates to a module index where we have hardware configurations that use 1 or 4 controllers. So we would have '.2', '.3' and '.4' port configurations for the 4 controller configuration. You could drop these extra indexes to simplify your file.
If we look at the first grouping of port configurations it looks like this:
drvModbusAsynConfigure("watlow_AI_Num_1.1", "watlow1", 0, 4, 360, 62, 7, 2000, "watlow1");
drvModbusAsynConfigure("watlow_AI_Num_2.1", "watlow1", 0, 4, 450, 62, 7, 2000, "watlow1");
drvModbusAsynConfigure("watlow_AI_Enum_1.1", "watlow1", 0, 4, 362, 82, 6, 2000, "watlow1");
drvModbusAsynConfigure("watlow_AI_Enum_2.1", "watlow1", 0, 4, 452, 82, 6, 2000, "watlow1");
All of these addressed are related to the Analog Input function. The first 2 are for float data types, the last 2 are for Enumerated or integer data types. Each broken down into 2 groups to cover the full range of addresses for this function.
The remainder of port configurations are for the other functions of the Watlow controller, Limits (Lim), Control Loop (CL), Analog Output (AO), etc.
I've added a few records from the Analog Input template as examples of how this port configuration is used. You'll also need to look in the substitution file to obtain the macro values for the Analog Input records. The substitution files is what contains the actual address for that particular register.
# Analog Input #
record(ai, "$(s):$(ta):$(ss):$(mod):AnalogInput$(ch)")
{
field(SCAN, "1 second")
field(PINI, "YES")
field(DTYP, "asynFloat64")
field(INP, "@asyn(watlow_AI_Num_1.$(mod),$(Ain=0),2000)FLOAT32_BE")
field(EGU, "°")
field(PREC, "3")
field(ADEL, "0.1")
field(MDEL, "0.1")
}
The field
field(INP, "@asyn(watlow_AI_Num_1.$(mod),$(Ain=0),2000)FLOAT32_BE")
where $(Ain=0) is the macro definition for the Analog Input Value register address offset (from 360 as defined in the port configuration) with '0' being the default address offset.
after building the modules will resolve as
field(INP, "@asyn(watlow_AI_Num_1.1,0,2000)FLOAT32_BE")
# Units
record(mbbi, "$(s):$(ta):$(ss):$(mod):AIUnits$(ch)RB")
{
field(SCAN, "1 second")
field(PINI, "YES")
field(DTYP, "asynUInt32Digital")
field(INP, "@asynMask(watlow_AI_Enum_$(ch).$(mod),80,0xFF,2000)UINT16")
field(ZRST, "Process")
field(ZRVL, "75")
field(ONST, "Power")
field(ONVL, "73")
}
In the enumerated record the field
field(INP, "@asynMask(watlow_AI_Enum_$(ch).$(mod),80,0xFF,2000)UINT16")
would resolve as
field(INP, "@asynMask(watlow_AI_Enum_1,80,0xFF,2000)UINT16")
where the address offset (80) for the Analog Input Units register is defined.
As for the Little/Big Endian question, that must be consistent also. In my manual under a section called "Modbus Introduction to the Modbus Protocol" there is a description of this setting in the controller. If memory serves me, I believe we using the 'hilo' setting. Also remember, we used Map 2 for our addressing if you need to crossreference anything.
Regards,
Gary Taufer
ORNL DAQ and Controls Software Engineer
Instrument Data Acquisition and Controls Group Neutron Technologies Division
-----Original Message-----
From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Mark Rivers via Tech-talk
Sent: Tuesday, August 24, 2021 10:37 PM
To: Leblanc, Gregory <leblanc at ohio.edu>
Cc: tech-talk at aps.anl.gov
Subject: [EXTERNAL] Re: Watlow_PM communication
Hi Greg,
You need to keep in mind that the data types specified in command like this:
drvModbusAsynConfigure("watlow_AI_Num_1.1", "watlow1", 0, 4, 360, 62, 7, 2000, "watlow1");
can be overridden in the .template file with lines like this:
field(INP, "@asyn(watlow_AI_Num_1.$(mod),$(Ain=0),2000)FLOAT32_BE")
So the data type in the drvModbusAsynConfigure is just a default and may not be used at all.
Mark
Sent from my iPhone
On Aug 24, 2021, at 5:24 PM, Leblanc, Gregory via Tech-talk <tech-talk at aps.anl.gov> wrote:
Hi folks!
This question is probably specific to Gary, but I’m sending it to the list, because the information will hopefully be helpful to the next person who tries this.
Also, apologies for the lengthy email, but I’m trying to make sure all the information is included.
I’m trying to understand how the modbus read functions are designed. I see following line in your st.cmd [1]:
drvModbusAsynConfigure("watlow_AI_Num_1.1", "watlow1", 0, 4, 360, 62, 7, 2000, "watlow1"); which is reading 62 bytes starting at modbus address 360, and assume that they are type INT32_BE
2 lines later it says:
drvModbusAsynConfigure("watlow_AI_Enum_1.1", "watlow1", 0, 4, 362, 82, 6, 2000, "watlow1"); Which says read 82 bytes starting at address 362, and assume that they are type INT32_LE_BS [2]
I mapped the information from the manual, and put it in a file at:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgregoryleblanc%2FCsHeater%2Fblob%2Fmain%2FAnalogInput.md&data=04%7C01%7Cleblanc%40ohio.edu%7C99b8429f82ff4d8f74ea08d967f5de2c%7Cf3308007477c4a70888934611817c55a%7C0%7C0%7C637655127961033706%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3dWZVqKrYQi8imTTmU8wOqE%2B3rHJyFHLboqcXLqZdDg%3D&reserved=0
I’m guessing that the num line is reading in floats, and the enum line is reading in the same data, but reading the uint values, and there is something wonky about the byte order that you can’t read them into the same space.
Based on what I’ve gleaned, I’ve pared things down to a small config. I’m not seeing any errors when I run st.cmd, and inside my ioc I see:
epics> dbl
:SE:Watlow:1:ControlModeActive1
:SE:Watlow:1:AutotuneStatus1
:SE:Watlow:1:ControlModeActive2
:SE:Watlow:1:AutotuneStatus2
:SE:Watlow:1:HeatPower1
:SE:Watlow:1:CoolPower1
:SE:Watlow:1:ProcessValue1
:SE:Watlow:1:ActiveSV1
:SE:Watlow:1:HeatPower2
:SE:Watlow:1:CoolPower2
:SE:Watlow:1:ProcessValue2
:SE:Watlow:1:ActiveSV2
Next, I tried grabbing ProcessValue 1 and 2:
$ caget :SE:Watlow:1:ProcessValue1 :SE:Watlow:1:ProcessValue2
:SE:Watlow:1:ProcessValue1 3.59505e-06
:SE:Watlow:1:ProcessValue2 0
Which doesn’t seem to match up at all with what I see on the controller:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.flickr.com%2Fgp%2Fgregoryleblanc%2FgD9270&data=04%7C01%7Cleblanc%40ohio.edu%7C99b8429f82ff4d8f74ea08d967f5de2c%7Cf3308007477c4a70888934611817c55a%7C0%7C0%7C637655127961038682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=HY9GhExNpRRIYuAo5BvCssUIhqJ0%2ByxZl9k21Hw56sA%3D&reserved=0
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.flickr.com%2Fgp%2Fgregoryleblanc%2F2TRm59&data=04%7C01%7Cleblanc%40ohio.edu%7C99b8429f82ff4d8f74ea08d967f5de2c%7Cf3308007477c4a70888934611817c55a%7C0%7C0%7C637655127961038682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=N4os1EkCTS6IqbwwsuxW8xUPe1Q%2F9gst5F6woDFfdaQ%3D&reserved=0
I’m not sure where to go from here.
Greg
P.S. I’m hoping to map out the other data read blocks later in the week.
P.P.S. I have a patch to replace the numerical datatypes in your st.cmd with more descriptive strings. Should I submit a pull request?
1: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftauferg%2FWatlow-PM%2Fblob%2Fea5096bf72f29eb42e3f2c2f5ee1a12ceb089863%2FWatlow_PM862FJ-3LEJAA_IOC%2Fst.cmd.ModbusAddresses%2520Only%23L27&data=04%7C01%7Cleblanc%40ohio.edu%7C99b8429f82ff4d8f74ea08d967f5de2c%7Cf3308007477c4a70888934611817c55a%7C0%7C0%7C637655127961038682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=pavTPqlltTRpsrwDyIY3FhxAG%2Fx9M%2FPkSz59lamRa50%3D&reserved=0
2: Little-endian byte swapped? Somehow there’s got to be a tie between PDPs and Modbus, and I’m a bit scared.
--
Gregory Leblanc
Accelerator Engineer
Edwards Accelerator Lab - Ohio University
123 University Terrace
Athens, OH 45701
leblanc at ohio.edu<mailto:leblanc at ohio.edu>
M: (401) 52-OUAL1 or (401) 526-8251
- References:
- Watlow_PM communication Leblanc, Gregory via Tech-talk
- Re: Watlow_PM communication Mark Rivers via Tech-talk
- RE: Watlow_PM communication Taufer, Gary via Tech-talk
- RE: Watlow_PM communication Leblanc, Gregory via Tech-talk
- Navigate by Date:
- Prev:
RE: Watlow_PM communication Leblanc, Gregory via Tech-talk
- Next:
Download prblem for sequenzer Jörn Dreyer 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>
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: Watlow_PM communication Leblanc, Gregory via Tech-talk
- Next:
aravisGigE: no device found Hasan SANSAR 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>
2022
2023
2024
|