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: | Watlow_PM communication |
From: | "Leblanc, Gregory via Tech-talk" <tech-talk at aps.anl.gov> |
To: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Date: | Tue, 24 Aug 2021 21:24:31 +0000 |
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://github.com/gregoryleblanc/CsHeater/blob/main/AnalogInput.md 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://www.flickr.com/gp/gregoryleblanc/gD9270 https://www.flickr.com/gp/gregoryleblanc/2TRm59 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? 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 M: (401) 52-OUAL1 or (401) 526-8251 |