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  <20122013  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  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: CARS modbus output record initialization
From: Mark Rivers <[email protected]>
To: "'John Dobbins'" <[email protected]>
Cc: EPICS Tech-Talk <[email protected]>
Date: Fri, 3 Feb 2012 18:45:03 +0000
Hi John,

That offset of 0x200 is not being added by my Modbus software, I'm sure of that.  That would be a very Wago-specific thing, and there is nothing Wago-specific in the driver.  Unless someone modified it on your end?

I think it must be in the drvModbusAsynConfigure for the Holding register readback you wrote.  Please send your entire startup script.

Mark


-----Original Message-----
From: John Dobbins [mailto:[email protected]] 
Sent: Friday, February 03, 2012 12:19 PM
To: Mark Rivers
Cc: EPICS Tech-Talk
Subject: Re: CARS modbus output record initialization

Mark,

I turns out that the manual for the WAGO 750-341 includes the line:

"When using MODBUS protocol, output data can be read back with an offset 
of 200hex (0x0200) added to the MODBUS address."

The interesting thing is that when I look at the trace output from the 
R3.14.11 IOC (which exhibits the same problem) I see the following:

The first F-code 3 (read holding registers) which I assume is from 
initialization is:

2012/02/03 12:28:24.754 asynOctetSyncIO wrote:
\001\003\000\000\000\004

which is asking for four resisters beginning at address 0, but returns 
incorrect data


However the next F-code 3 reading ( from the Holding register readback 
block I created) is

2012/02/03 12:28:24.981 asynOctetSyncIO wrote:
\001\003\002\000\000\004

which is asking for four resisters beginning at address 0 + 200hex and 
returns the correct data from this address.

So modbus device support seems to know about this offset in one case but 
not in the other!


John






On 2/3/2012 11:04 AM, Mark Rivers wrote:
> Hi John,
>
> We need to figure out if this is a general problem in the EPICS modbus driver, or something specific to the Wago.  I don't think it is anything that has changed since Modbus R1-2, because there is nothing in the release notes about it.
>
> I do seem to vaguely recall that the Wago may be different from other Modbus devices in that the Modbus address for register read operations may be different from the Modbus address for register write operations.  That was the reason for the final plcType argument to drvModbusAsynConfigure, so we could do any model-dependent differences.  But there is no model-dependent code in the driver yet, because we have not yet found a need for it. But perhaps the Wago will need it.
>
> Here's what I suggest you do.  You need to turn on asynTrace debugging beginning in the drvModbusAsynConfigure() function. This will let us see that the initial readOnce data read back from the device is correct. However, that is before you could specify change the asynTrace flags in your startup script for that port, because it is the port creation function.
>
> If you were running asyn R4-11 or later you could do the following in your startup script before the drvModbusAsynConfigure command:
>
> asynSetTraceIOMask "",0,2
> asynSetTraceMask "",0,255
>
> That would set the default asynTrace mask, so you would get debugging information even in the drvModbusAsynConfigure function.  However, since you are running R4-9 you cannot do this.  Instead you need to temporarily modify the source code as follows:
>
>      /* Connect to device */
>      status = pasynManager->connectDevice(pPlc->pasynUserTrace, pPlc->portName, 0);
>      if (status != asynSuccess) {
>          errlogPrintf("%s::drvModbusAsynConfigure port %s"
>                       " connectDevice failed %s\n",
>                       driver, pPlc->portName, pPlc->pasynUserTrace->errorMessage);
>           return(asynError);
>      }
> pasynTrace->setTraceIOMask(pPlc->pasynUserTrace, 2);
> pasynTrace->setTraceMask(pPlc->pasynUserTrace, 255);
>
> You are adding the last 2 lines above.
>
> That should provide complete debugging information starting near the end of the drvModbusAsynConfigure function, when it does the readOnce operation on output records.
>
> You need to see whether the initial value read from the device and the initial values passed to the ao device support from the readInt32() function are correct.
>
> You should also read the Wago documentation to see if my vague memory is correct: are the Modbus addresses used to read the registers different from the Modbus addresses used to write the registers?
>
> Cheers,
> Mark
>
>
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of John Dobbins
> Sent: Friday, February 03, 2012 8:52 AM
> To: EPICS Tech-Talk
> Subject: CARS modbus output record initialization
>
> I am using the CARS modbus device support with a WAGO I/O System (controller 750-341)
>
> One thing I am having trouble getting to work is output record initialization. This is an old version of modbus support R1-2, asyn R4-9, base R3.14.9
>
> Specifically, for modbus function code 6 I create a block
>
> # Write 1 register,  Function code=6
> drvModbusAsynConfigure("WAGO_OUTS", "WAGO", 6, 0, 4, 0,    1, "WAGO_750_341")
>
>
> There are four analog output records attached to this block which look like
>
> record(ao,"wagoTest_out_0") {
>      field(DTYP,"asynInt32")
>      field(OUT, "@asynMask(WAGO_OUTS 0 -16 1000)")
>      field(LINR,"LINEAR")
>      field(EGUL,"-10")
>      field(EGUF,"10")
>      field(LOPR,"-10")
>      field(HOPR,"10")
>      field(PREC, "3")
> }
>
>
>   When the IOC starst up only the first of the four records is initialized with the value currently in the controller.
>
> All four records show UDF = 0, the second has a non-zero but incorrect value, the third and fourth have the value zero.
>
> Thanks for you advice.
>
> John Dobbins
>
> Cornell University
>
>
>
>


Replies:
RE: CARS modbus output record initialization John Dobbins
References:
CARS modbus output record initialization John Dobbins
RE: CARS modbus output record initialization Mark Rivers
Re: CARS modbus output record initialization John Dobbins

Navigate by Date:
Prev: Re: CARS modbus output record initialization John Dobbins
Next: RE: CARS modbus output record initialization John Dobbins
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: CARS modbus output record initialization John Dobbins
Next: RE: CARS modbus output record initialization John Dobbins
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·