Hi Mark,
I think that the timeout you refer to is controlled via the third
argument to modbusInterposeConfig routine. This is set to 1000 for all
Beckhoff IOCs.
I have not used the asyn trace facility because there are large number
of IOs happening in one second. I will try it.
I verified using a print statement in the readIt routine in
modbusInterpose.c that the pPvt->timeout is 1.0, so, if this is the real
timeout, then it is not used in the IO request.
Is there a timeout in the drvAsynIPPort driver?
I am looking at modbusInterpose.c and I find it difficult to tell what
timeout the read routine is using. Here is the line from modbusInterpose.c:
status = pPvt->pasynOctet->read(pPvt->octetPvt, pasynUser,
pPvt->buffer, nRead, &nbytesActual, eomReason);
I can't tell how the pasyOctet->read routine is coded; not sure where it
is defined and what timeout is used in the routine which ultimately
issues the modbus read request.
Now, in my new code, I put print statements in the writeIt and readIt
routines in the modbusInterpose.c file and I see that the readIt fails
immediately after writeIt completes with no perceivable delay.
So I am confused.
In the case of the IOCs using your modbus support module, there could be
some other effect causing the error.
For better or worse in these IOCs, I am setting up the IOCs such that
drvModbusAsynConfigure is called for each Beckhoff bus terminal type. I
use 100 ms period for the poller loop in each. I think each thread
loops asynchronously with respect other threads. Therefore it is
conceivable that often a write is issued from one thread when the
coupler is not ready as it is processing some IO from another thread. I
did not test this to see if this is indeed happening.
To avoid this I have created a separate modbus IO class object in my new
code, which uses a message queue to coordinate orderly execution of IO
requests, which is done in a poller loop in this class. Requests for IO
from multiple threads are scheduled for execution via the message queue.
Thanks Mark,
Zen
On 08/05/13 10:23, Mark Rivers wrote:
Hi Zen,
What timeout are you using for your TCP read? The read does not actually put anything on the Ethernet, it just waits for a message to arrive from the Beckoff. So if you use a timeout of 1 second or so then it should never time out, assuming the module really does answer within 20 ms or so.
You need to turn on asynTrace in the underlying drvAsynIPPort driver to see exactly the timing of what is being sent and received by that driver.
Mark
________________________________________
From: Zenon Szalata [[email protected]]
Sent: Monday, August 05, 2013 11:33 AM
To: Mark Rivers; Ernest Williams; [email protected]
Subject: Modbus
Hi Mark,
I am nearly done with my version of modbus TCP for use with Beckhoff
hardware. I have a few IOCs using this support module and all seems to
be working well in my test area.
I have deployed an IOC for a couple of stepper motors controlled by
Beckhoff devices in a production area and discovered that the IOC is
generating many errors.
The error is:
2013/08/05 08:55:14.982 modbusAsyn::doModbusIO port BKH15 error
calling writeRead, error=sioc-esb-bkh15:502 timeout: Resource
temporarily unavailable, nwrite=6/6, nread=0
Now, modbusAsyn is the name I used for the file which has the two
routines I took from your file drvModbusAsyn. Looking at the log files
of the IOCs used in the same production area which control Beckhoff
devices and which are built with your modbus support module, I see that
the same errors are generated. Here is an example:
2013/06/16 13:19:25.918 drvModbusAsyn::doModbusIO port BKH10_CPL_R0
error calling writeRead, error=sioc-esb-bkh10:502 timeout: Resource
temporarily unavailable, nwrite=6/6, nread=0
People who use these IOCs ignored these errors because mostly they did
not matter.
In the case of the stepper motor controller IOC it does matter. First of
all I realized that the difference between my testing environment and
that of production is the computer speed and a different networking
environment. The production computer used for the Beckhoff IOCs is much
faster. So it seems that there is some timing issue at work here.
After putting print statements in various places, I see that the routine
writeIt in modbusInterpose.c file always succeeds but the routine readIt
in the same file fails from time to time. I reread the manual for the
Beckhoff BK9000 Ethernet coupler and came across a statement saying that
the coupler takes from 13 to 15 ms to process a modbus message. So it
seems that the read comes too soon after the write. In my version of
the modbus support module for Beckhoff, I have added a 20 ms delay after
the pasynOctet->write in modbusInterpose.c and this has mostly solved
the problem. I say mostly, because I still see this error message but
very infrequently.
I am writing all this because I don't understand why this error is
generated so I am not sure if the direction I took to fix the problem is
correct. I also think that your modbus support module may need to be
modified if it is to be used with Beckhoff devices.
I would like to hear what you think about this.
Thanks,
Zen
- Replies:
- RE: Modbus Mark Rivers
- References:
- Modbus Zenon Szalata
- RE: Modbus Mark Rivers
- Navigate by Date:
- Prev:
RE: Record Parameters in Asyn Port Driver Mark Rivers
- Next:
RE: Modbus Mark Rivers
- 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: Modbus Mark Rivers
- Next:
RE: Modbus Mark Rivers
- 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
|