James,
You could try leaving off the leading 40 in 40150, i.e. just 150 and see
what you get. It says in my documentation that:
" Note that 16-bit Modbus addresses are commonly specified with an
offset of 400001 (or 300001). This offset is not used by the modbus
driver, it uses only the 16-bit address, not the offset."
This does not seem to apply in your case, since the address you list is
a valid 16-bit number, but it's worth a try.
Also, do you have the exact startup script syntax you used with the old
ModbusTCP driver? I could then look at that old code and see if it is
doing something differently.
I notice from your e-mail address that you are at the APS? I could walk
over and take a look if you'd like.
Mark
-----Original Message-----
From: Eric Norum [mailto:[email protected]]
Sent: Friday, November 18, 2011 1:24 PM
To: Mark Rivers
Cc: James Stevens; [email protected]
Subject: Re: using tcp with modbus over asyn
Could your equipment have another level of mapping/offset being applied
somewhere?
As an illustration, I am reading the values from a Horner PLC -- here's
the salient portion of the st.cmd file:
# ModbusStartAddress = Horner Register Number + 2999
# i.e. Horner %R1 is Modbus Offset 3000
#
# Read 97 starting at Modbus 4996: Horner %R1997 through %R2093,
inclusive
drvModbusAsynConfigure("rfDrive_r0i", "rfDrivePLC_1", 0, 3, 4996, 97, 0,
1000, "Horner")
# Write 1 starting at Modbus 3999: Horner %R1000
drvModbusAsynConfigure("rfDrive_r0o", "rfDrivePLC_1", 0, 6, 3999, 1, 0,
2000, "Horner")
You can see that there's an offset of 2999 between the register number
in the PLC and the number passed in the Modbus packet....
On Nov 17, 2011, at 9:01 PM, Mark Rivers wrote:
> Hi James,
>
> OK, so it appears the slave address is OK.
>
> The device is definitely answering your query.
>
> On page 85 of that manual it shows that where the Modbus slave module
gets its data is configurable. Is it possible that this meter is not
configured to get the data you think it is at addess 40150?
>
> Does this same exact meter work correctly with the older ModbusTCP
driver? If so then you may need to run "ethereal" and capture network
packets to see what the difference is between the old driver and the new
asyn driver.
>
> Mark
>
>
> ________________________________
>
> From: James Stevens [mailto:[email protected]]
> Sent: Thu 11/17/2011 6:49 PM
> To: Mark Rivers
> Cc: [email protected]
> Subject: Re: using tcp with modbus over asyn
>
>
>
>
> Mark,
>
> Thank you for your response.
>
> On page 85 of the user guide it states
> that "The Modbus Unit ID of the meter
> over Ethernet is 100."
>
>
http://www.sea.siemens.com/us/internet-dms/btlv/PowerDistributionComm/Po
werDistribution/Docs/9510_9610_User_Guide.pdf
>
> When I tried setting the slave address to
> zero, I got a timeout error.
>
> epics> 2011/11/17 18:46:33.771 drvModbusAsyn::doModbusIO port
UPSDASHCP2 error calling writeRead, error=164.54.2.216:502 timeout:
Resource temporarily unavailable, nwrite=6/6, nread=0
> 2011/11/17 18:46:38.269 S:UPS:CP2:I4ai:AI devAsynInt32 process read
error
> 2011/11/17 18:46:38.270 S:UPS:CP2:IAvgMax:AI devAsynInt32 process read
error
> 2011/11/17 18:46:38.270 S:UPS:CP2:IAvgMin:AI devAsynInt32 process read
error
> 2011/11/17 18:46:38.271 S:UPS:CP2:aa:AI devAsynInt32 process read
error
> 2011/11/17 18:46:38.271 S:UPS:CP2:f:AI devAsynInt32 process read error
> 2011/11/17 18:46:38.271 S:UPS:CP2:p1a:AI devAsynInt32 process read
error
> 2011/11/17 18:46:38.271 S:UPS:CP2:p2a:AI devAsynInt32 process read
error
> 2011/11/17 18:46:38.271 S:UPS:CP2:p3a:AI devAsynInt32 process read
error
>
> Regards--Jim Stevens
>
> ----- Original Message -----
> From: "Mark Rivers" <[email protected]>
> To: "James Stevens" <[email protected]>, [email protected]
> Sent: Thursday, November 17, 2011 6:23:43 PM
> Subject: RE: using tcp with modbus over asyn
>
> Hi James,
>
>> How can I verify that I am reading the correct base address?
>
> Here is the message that was sent to the Modbus device:
>
> 00 01 00 00 00 06 64 03 9c d6 00 10
>
> The first 6 bytes of this message are the modbusMBAPHeader:
>
> typedef struct modbusMBAPHeader_str
> {
> unsigned short transactId;
> unsigned short protocolType;
> unsigned short cmdLength;
> } modbusMBAPHeader;
>
> They are not very interesting, but they look correct. cmdLength=6,
> which is the length of the modbusReadRequest below.
>
> The next part of the message is the modbusReadRequest
>
> typedef struct modbusReadRequest_str
> {
> unsigned char slave;
> unsigned char fcode;
> unsigned short startReg;
> unsigned short numRead;
> } modbusReadRequest;
>
> So slave = 0x64 = 100
> That is the slave address you told it to use in
> drvModbusAsynConfigure(). Are you sure this is correct? All Modbus
TCP
> devices I have used had a slave address of 0.
>
> fcode = 03
> That is the function code you told it to use. That seems correct,
> 3=Read Holding Registers.
>
> startReg = 9c d6 = 40150
> That is the base address you told it to use.
>
> numRead = 00 10 = 16
> That is the length you told it to read.
>
> So it appears to me that the message being sent to the device is
> correct.
>
> Here is the response you are getting from the device:
>
> 00 01 00 00 00 23 64 03 20 ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ff
>
> The first 6 bytes of the response are again the modbusMBAPHeader:
>
> typedef struct modbusMBAPHeader_str
> {
> unsigned short transactId;
> unsigned short protocolType;
> unsigned short cmdLength;
> } modbusMBAPHeader;
>
> So the cmdLength = 0x23 = 35.
>
> I believe that what comes next is the slave address (0x64=100), though
> that is skipped in the driver.
>
> Next comes the modbusReadResponse:
>
> typedef struct modbusReadResponse_str
> {
> unsigned char fcode;
> unsigned char byteCount;
> unsigned char data[1];
> } modbusReadResponse;
>
> So the fcode=03 which is correct. If the device returns an error it
> changes the fcode on the return to "or" it with MODBUS_EXCEPTION_FCN.
>
> #define MODBUS_EXCEPTION_FCN 0x80
>
> That is tested as follows:
> if (readResp->fcode & MODBUS_EXCEPTION_FCN) {
> exceptionResp = (modbusExceptionResponse *)pPlc->modbusReply;
> asynPrint(pPlc->pasynUserTrace, ASYN_TRACE_ERROR,
> "%s::doModbusIO port %s Modbus exception=%d\n",
> driver, pPlc->portName, exceptionResp->exception);
>
> byteCount = 0x20=32, so it is returning you 32 bytes. That is
correct,
> since you asked for 16 holding registers.
>
> So it looks like the device is responding as expected. I don't know
why
> your data is wrong, except that perhaps you are using the wrong slave
> address?
>
> Cheers,
> Mark
>
>
>
>
>
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of James Stevens
> Sent: Thursday, November 17, 2011 5:43 PM
> To: [email protected]
> Subject: using tcp with modbus over asyn
>
>
> Let me restate my last post.
>
> I am trying to update a soft IOC using the modbusIP
> driver (version 1-1-asd6) from the Canadian Light
> Source to Mark Rivers' modbus over asyn version
> 2-1.
>
> The soft IOC is reading a Siemens 9610 Power
> Meter on the accelerator network.
>
> I started by trying to read an unsigned 16 bit
> register at the 40150 decimal base address, but
> the values read back from the power meter are
> all ff's.
>
> How can I verify that I am reading the correct
> base address?
>
> #ups-cp2
> drvAsynIPPortConfigure("L0","164.54.2.216:502",0,0,1)
> modbusInterposeConfig("L0",0,5500,0)
>
drvModbusAsynConfigure("UPSDASHCP2","L0",100,3,40150,16,0,5000,"9610PM")
> #asynSetTraceMask("L0",0,3)
> asynSetTraceIOMask("L0",0,2)
> ## Load record instances
> dbLoadRecords("db/SIEM9610.vdb","L=CP2")
>
dbLoadRecords("db/asynRecord.db","P=SR:,R=SIEM:9610,PORT=L0,ADDR=0,OMAX=
> 0,IMAX=0")
> cd /home/helios5/JBS/upsmbus/1/iocBoot/siocupsmon
> iocInit
> Starting iocInit
>
########################################################################
> ####
> ## EPICS R3.14.11-asd1 $R3-14-11$ $2009/08/28 18:47:36$
> ## EPICS Base built Aug 28 2009
>
########################################################################
> ####
> cas warning: Configured TCP port was unavailable.
> cas warning: Using dynamically assigned TCP port 52753,
> cas warning: but now two or more servers share the same UDP port.
> cas warning: Depending on your IP kernel this server may not be
> cas warning: reachable with UDP unicast (a host's IP in
> EPICS_CA_ADDR_LIST)
> iocRun: All initialization complete
> epics> 2011/11/17 17:40:24.571 164.54.2.216:502 write 12
>
> 00 01 00 00 00 06 64 03 9c d6 00 10
> 2011/11/17 17:40:24.574 164.54.2.216:502 read 41
>
> 00 01 00 00 00 23 64 03 20 ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ff
>
> Regards--Jim Stevens
>
>
>
--
Eric Norum
[email protected]
- Replies:
- Re: using tcp with modbus over asyn Eric Norum
- References:
- Re: using tcp with modbus over asyn James Stevens
- RE: using tcp with modbus over asyn Mark Rivers
- Re: using tcp with modbus over asyn Eric Norum
- Navigate by Date:
- Prev:
Re: using tcp with modbus over asyn Eric Norum
- Next:
Re: using tcp with modbus over asyn James Stevens
- 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: using tcp with modbus over asyn Eric Norum
- Next:
Re: using tcp with modbus over asyn Eric Norum
- 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
|
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·