RE: CARS modbus output record initialization

[Mark Rivers <rivers@cars.uchicago.edu>]

Folks,

I've made the change to the Modbus driver to treat Wago devices specially, setting the address for the initial readback on write functions to x200 greater than the write function address.

I've updated the documentation:
http://cars9.uchicago.edu/software/epics/modbusDoc.html

and the release notes:
http://cars9.uchicago.edu/software/epics/modbusReleaseNotes.html

The new code can be obtained at:
https://subversion.xor.aps.anl.gov/synApps/

Once someone tests the code and tells me it is working I will release Modbus R2-4.

Thanks,
Mark



-----Original Message-----
From: Mark Rivers 
Sent: Friday, February 03, 2012 1:13 PM
To: 'John Dobbins'
Cc: EPICS Tech-Talk
Subject: RE: CARS modbus output record initialization

Hi John,

> I guess I would have to modify drvModbusAsynConfigure to accept another parameter if I want output record initialization to work.

My suggestion would be different.

Let's come up with a convention for the plcName argument for Wago controllers.  I suggest it should just contain the string "Wago".  If it does then the initial readbacks have the offset 0x200 added to the address.  Normal reads will continue to require the user to use the actual address (including the offset) as you are doing now.

This has actually been on my to-do list for a long time, but I never found anyone with a Wago who could test it.  I can modify the code and put it on our Subversion server:

https://subversion.xor.aps.anl.gov/synApps/modbus/trunk/

Can you upgrade asyn (R4-18) and test the Subversion code?  If it works I will release modbus R2-4.

>From the Wago documentation, can you tell what write function codes (5, 15, 6, 16) have an offset for the read address?

Mark


-----Original Message-----
From: John Dobbins [mailto:john.dobbins@cornell.edu] 
Sent: Friday, February 03, 2012 12:55 PM
To: Mark Rivers
Cc: EPICS Tech-Talk
Subject: RE: CARS modbus output record initialization

Mark,

Sorry. My mistake. I do have that offset added in the drvModbusAsynConfigure for  F-code 3.

I guess I would have to modify drvModbusAsynConfigure to accept another parameter if I want output record initialization to work.

John


________________________________________
From: Mark Rivers [rivers@cars.uchicago.edu]
Sent: Friday, February 03, 2012 1:45 PM
To: John Dobbins
Cc: EPICS Tech-Talk
Subject: RE: CARS modbus output record initialization

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:john.dobbins@cornell.edu]
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: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] 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
>
>
>
>