Match Responses by the Request TID

[bashwork]

Since the order of the asynchronous responses are not guaranteed to be in order if many requests are sent at the same time, the deferred needs to be matched by its TID. In order to do this, the deferred queue should be changed to a deferred dictionary. If a response doesn't match a TID in the queue, it should be logged and dropped.

The following discussion addresses this issue: https://groups.google.com/forum/?fromgroups#!topic/pymodbus/VdcsmIUtHt0

[douglatornell]

I'm sorry to report that this issue appears to have come back in v1.1.0.

I'm the person who reported it in the discussion thread linked above.

I just upgraded pymodbus from the build at e921ec0 that I was using to v1.1.0 from PyPI and got the same errors described in the thread. Dropping back to v1.0.0 from PyPI I found all was well, so something between 1.0.0 and 1.1.0 broke the TID ordering.

I can see that client/async.py has change a lot, so it will likely take me a while to figure out the difference that is causing the trouble. I may be able to do some bisecting later in the week.

[bashwork]

Doug,

Sorry I missed this, I am working on this and would be grateful if you could quickly test the latest commit:

996dff2

I will continue trying to resolve the issue regardless.

[douglatornell]

No worries. I never delivered on my promise to try to narrow down the change that caused the problem, so I can't complain :-) And 1.0.0 works just fine in my application.

I tested 996dff2 and got some strange results. There were lots of AttributeError exceptions like:

exceptions.AttributeError: 'ReadHoldingRegistersResponse' object has no attribute 'getBit'

and

exceptions.AttributeError: 'ReadCoilsResponse' object has no attribute 'getRegister'

which, I think, imply the same kind of response mix-ups that this issue was originally about. However, there were also some successfully returned values from the PLC, but those values were incorrect; e.g. holding registers that I know to contain zero, and that return zero when I run with v1.0.0 were suddenly showing values of 140 with 996dff2,

This is all in the context of a quick test of my data logging application that does about 150 reads per second across 3 PLCs. I will work tomorrow on producing minimal test case code that demonstrates the issue.

[douglatornell]

This code:

import logging
from twisted.internet import reactor
from twisted.internet.endpoints import TCP4ClientEndpoint
from pymodbus.constants import Defaults
from pymodbus.client.async import ModbusClientFactory

logging.basicConfig()
log = logging.getLogger()
log.setLevel(logging.DEBUG)

def show_bit(response):
    log.debug('65th bit = {0}'.format(response.getBit(65)))

def show_hreg(response):
    log.debug('42nd hreg = {0}'.format(response.getRegister(42)))

def foo(protocol):
    r1 = protocol.read_coils(1400, 400)
    r1.addCallback(show_bit)
    r2 = protocol.read_holding_registers(1400, 100)
    r2.addCallback(show_hreg)
    reactor.callLater(1, protocol.transport.loseConnection)
    reactor.callLater(1.5, reactor.stop)

endpoint = TCP4ClientEndpoint(reactor, '172.20.1.1', Defaults.Port)
protocol = endpoint.connect(ModbusClientFactory())
protocol.addCallback(foo)
reactor.run()

demonstrated the issue and produces this traceback:

DEBUG:pymodbus.client.async:Client connected to modbus server
DEBUG:pymodbus.transaction:adding transaction 1
DEBUG:pymodbus.transaction:adding transaction 2
DEBUG:pymodbus.transaction:0x0 0x2 0x0 0x0 0x0 0xcb 0x0 0x3 0xc8 0x2 0x8b 0x2 0xab 0x2 0x92 0x2 0x26 0x2 0x94 0x2 0x93 0x2 0x92 0x2 0x5e 0x2 0x5f 0x2 0x9f 0x2 0x8 0x14 0x82 0x14 0x79 0x14 0x7c 0x14 0x73 0x14 0x56 0x14 0x90 0x14 0x8c 0x14 0x8d 0x14 0x88 0x14 0x69 0x14 0x8a 0x14 0x89 0x14 0x59 0x3 0x84 0x14 0xe3 0x14 0xc4 0x14 0xde 0x14 0xda 0x1 0x90 0x0 0x0 0x2 0x3c 0x0 0x2 0x0 0x1 0x0 0x0 0x1 0x61 0x0 0x0 0x0 0x0 0x1 0x9 0x1 0x70 0x0 0xc9 0x2 0xd6 0x0 0x1 0x2 0xdb 0x0 0x0 0x0 0x4 0x0 0x46 0x0 0xa4 0x0 0x4 0x0 0x4 0x0 0x0 0x0 0x4 0x0 0x4 0x0 0x0 0x1 0x60 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x2 0x0 0x2 0x0 0x2 0x0 0x2 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x1 0x11 0x2 0xa1 0x2 0x73 0x0 0x0 0x2 0x9d 0x1 0x90 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0xd 0x48 0xc 0xe4 0xd 0x48 0xc 0xe4 0x1e 0x78 0x1d 0x4c 0x1c 0xe8 0x1a 0xc2 0x19 0x64 0x19 0x0 0x15 0x4a 0x14 0x50 0x14 0x28 0x15 0x4a 0x14 0x50 0x14 0x28 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0xd 0x48
DEBUG:pymodbus.factory:Factory Response[3]
DEBUG:pymodbus.transaction:getting transaction 2
Unhandled error in Deferred:
Unhandled Error
Traceback (most recent call last):
  File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/pymodbus/transaction.py", line 346, in processIncomingPacket
    callback(result)  # defer or push to a thread?
  File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/pymodbus/client/async.py", line 113, in _handleResponse
    handler.callback(reply)
  File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/twisted/internet/defer.py", line 381, in callback
    self._startRunCallbacks(result)
  File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/twisted/internet/defer.py", line 489, in _startRunCallbacks
    self._runCallbacks()
--- <exception caught here> ---
  File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/twisted/internet/defer.py", line 576, in _runCallbacks
    current.result = callback(current.result, *args, **kw)
  File "/home/doug/pymodbus-test.py", line 12, in show_bit
    log.debug('65th bit = {0}'.format(response.getBit(65)))
exceptions.AttributeError: 'ReadHoldingRegistersResponse' object has no attribute 'getBit'
DEBUG:pymodbus.transaction:0x0 0x1 0x0 0x0 0x0 0x35 0x0 0x1 0x32 0x1 0xff 0xa7 0x11 0x90 0x0 0x4e 0x2d 0x9 0x0 0x80 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x34 0x4c 0x9b 0xd1 0xb6 0xf 0xe0 0x3 0x30 0x0 0x80 0x43 0xc0 0x31 0xe6 0x80 0x3 0x0 0x0 0x80 0xf0 0x7f 0x40 0xfd 0x7
DEBUG:pymodbus.factory:Factory Response[1]
DEBUG:pymodbus.transaction:getting transaction 1
Unhandled error in Deferred:
Unhandled Error
Traceback (most recent call last):
  File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/pymodbus/transaction.py", line 346, in processIncomingPacket
    callback(result)  # defer or push to a thread?
  File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/pymodbus/client/async.py", line 113, in _handleResponse
    handler.callback(reply)
  File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/twisted/internet/defer.py", line 381, in callback
    self._startRunCallbacks(result)
  File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/twisted/internet/defer.py", line 489, in _startRunCallbacks
    self._runCallbacks()
--- <exception caught here> ---
  File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/twisted/internet/defer.py", line 576, in _runCallbacks
    current.result = callback(current.result, *args, **kw)
  File "/home/doug/pymodbus-test.py", line 15, in show_hreg
    log.debug('42nd hreg = {0}'.format(response.getRegister(42)))
exceptions.AttributeError: 'ReadCoilsResponse' object has no attribute 'getRegister'
DEBUG:pymodbus.client.async:Client disconnected from modbus server: [Failure instance: Traceback (failure with no frames): <class 'twisted.internet.error.ConnectionDone'>: Connection was closed cleanly.
]

python 2.7.3
twisted 12.3.0
pymodbus 996dff2

[bashwork]

Well that is a little unsettling, however I am going to reproduce your
error when I get home and attempt to track down where the mixup is
happening. Essentially what the client code is doing is::

request.transaction_id = get_next_tid()
defer = defer.Deferred()
transactions[request.transaction_id] = defer
execute(request)
return defer

... some time later ...

defer = transactions[response.transaction_id]
defer.callback(response)

So either the transaction ids are getting confused or it is using the FIFO
transaction manager.

Galen

On Wed, Apr 3, 2013 at 2:59 PM, Doug Latornell notifications@github.comwrote:

This code:

import loggingfrom twisted.internet import reactorfrom twisted.internet.endpoints import TCP4ClientEndpointfrom pymodbus.constants import Defaultsfrom pymodbus.client.async import ModbusClientFactory
logging.basicConfig()log = logging.getLogger()log.setLevel(logging.DEBUG)
def show_bit(response):
log.debug('65th bit = {0}'.format(response.getBit(65)))
def show_hreg(response):
log.debug('42nd hreg = {0}'.format(response.getRegister(42)))
def foo(protocol):
r1 = protocol.read_coils(1400, 400)
r1.addCallback(show_bit)
r2 = protocol.read_holding_registers(1400, 100)
r2.addCallback(show_hreg)
reactor.callLater(1, protocol.transport.loseConnection)
reactor.callLater(1.5, reactor.stop)
endpoint = TCP4ClientEndpoint(reactor, '172.20.1.1', Defaults.Port)protocol = endpoint.connect(ModbusClientFactory())protocol.addCallback(foo)reactor.run()

demonstrated the issue and produces this traceback:

DEBUG:pymodbus.client.async:Client connected to modbus serverDEBUG:pymodbus.transaction:adding transaction 1DEBUG:pymodbus.transaction:adding transaction 2DEBUG:pymodbus.transaction:0x0 0x2 0x0 0x0 0x0 0xcb 0x0 0x3 0xc8 0x2 0x8b 0x2 0xab 0x2 0x92 0x2 0x26 0x2 0x94 0x2 0x93 0x2 0x92 0x2 0x5e 0x2 0x5f 0x2 0x9f <
span class="mh">0x2 0x8 0x14 0x82 0x14 0x79 0x14 0x7c 0x14 0x73 0x14 0x56 0x14 0x90 0x14 0x8c 0x14 0x8d 0x14 0x88 0x14 0x69 0x14 0x8a 0x14 0x89 0x14 0x59 0x3 0x84 0x14 0xe3 0x14 0xc4 0x14 0xde 0x14 0xda 0x1 0x90 0x0 0x0 0x2 0x3c 0x0 0x2 0x0 0x1 0x0 0x0 0x1 0x61 0x0 0x0 0x0 0x0 0x1 0x9 0x1 0x70 0x0 0xc9 0x2 0xd6 0x0 0x1 0x2 0xdb 0x0 0x0 0x0 0x4 0x0 0x46 0x0 0xa4 0x0 0x4 0x0 0x4 0x0 0x0 0x0 0x4 0x0 0x4 0x0 0x0 0x1 0x60 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x2 0x0 0x2 0x0 0x2 0x0 0x2 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x1 0x11 0x2 0xa1 0x2 0x73 0x0 0x0 0x2 0x9d 0x1 0x90 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0xd 0x48 0xc 0xe4 0xd 0x48 0xc 0xe4 0x1e 0x78 0x1d 0x4c 0x1c 0xe8 0x1a 0xc2 0x19 0x64 0x19 0x0 0x15 0x4a 0x14 0x50 0x14 0x28 0x15 0x4a 0x14 0x50 0x14 0x28 0x0 0x0 0x0 0x0** 0x0 0x0 0x0 0x0 0xd 0x48DEBUG:pymodbus.factory:Factory Response[3]DEBUG:pymodbus.transaction:getting transaction 2Unhandled error in Deferred:Unhandled ErrorTraceback (most recent call last):
File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/pymodbus/transaction.py", line 346, in processIncomingPacket
callback(result) # defer or push to a thread?
File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/pymodbus/client/async.py", line 113, in _handleResponse
handler.callback(reply)
File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/twisted/internet/defer.py", line 381, in callback
self._startRunCallbacks(result)
File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/twisted/internet/defer.py", line 489, in _startRunCallbacks
self._runCallbacks()--- ---
File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/twisted/internet/defer.py", line 576, in _runCallbacks
current.result = callback(current.result, _args, *_kw)
File "/home/doug/pymodbus-test.py", line 12, in show_bit
log.debug('65th bit = {0}'.format(response.getBit(65)))exceptions.AttributeError: 'ReadHoldingRegistersResponse' object has no attribute 'getBit'DEBUG:pymodbus.transaction:0x0 0x1 0x0 0x0 0x0 0x35 0x0 0x1 0x32 0x1 0xff 0xa7 0x11 0x90 0x0 0x4e 0x2d 0x9 0x0 0x80 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 *_0x0 0x0 0x0 0x0 0x0 0x34 0x4c 0x9b 0xd1 0xb6 0xf 0xe0 0x3 0x30 0x0 0x80 0x43 0xc0 0x31 0xe6 0x80 0x3 0x0 0x0 0x80 0xf0 0x7f 0x40 0xfd 0x7DEBUG:pymodbus.factory:Factory Response[1]DEBUG:pymodbus.transaction:getting transaction 1Unhandled error in Deferred:Unhandled ErrorTraceback (most recent call last):
File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/pymodbus/transaction.py", line 346, in processIncomingPacket
callback(result) # defer or push to a thread?
File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/pymodbus/client/async.py", line 113, in _handleResponse
handler.callback(reply)
File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/twisted/internet/defer.py", line 381, in callback
self._startRunCallbacks(result)
File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/twisted/internet/defer.py", line 489, in _startRunCallbacks
self._runCallbacks()--- ---
File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/twisted/internet/defer.py", line 576, in _runCallbacks
current.result = callback(current.result, *args, *_kw)
File "/home/doug/pymodbus-test.py", line 15, in show_hreg
log.debug('42nd hreg = {0}'.format(response.getRegister(42)))exceptions.AttributeError: 'ReadCoilsResponse' object has no attribute 'getRegister'DEBUG:pymodbus.client.async:Client disconnected from modbus server: [Failure instance: Traceback (failure with no frames): <class 'twisted.internet.error.ConnectionDone'>: Connection was closed cleanly.]

python 2.7.3
twisted 12.3.0
pymodbus 996dff2 996dff2

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-15868071
.

[bashwork]

Is there any chance you could add two lines to your script for me::

def foo(protocol):
print protocol.framer
print protocol.transaction

That will quickly rule out the simple error case.

On Wed, Apr 3, 2013 at 4:05 PM, Galen Collins bashwork@gmail.com wrote:

Well that is a little unsettling, however I am going to reproduce your
error when I get home and attempt to track down where the mixup is
happening. Essentially what the client code is doing is::

request.transaction_id = get_next_tid()
defer = defer.Deferred()
transactions[request.transaction_id] = defer
execute(request)
return defer

... some time later ...

defer = transactions[response.transaction_id]
defer.callback(response)

So either the transaction ids are getting confused or it is using the FIFO
transaction manager.

Galen

On Wed, Apr 3, 2013 at 2:59 PM, Doug Latornell notifications@github.comwrote:

This code:

import loggingfrom twisted.internet import reactorfrom twisted.internet.endpoints import TCP4ClientEndpointfrom pymodbus.constants import Defaultsfrom pymodbus.client.async import ModbusClientFactory
logging.basicConfig()log = logging.getLogger()log.setLevel(logging.DEBUG)
def show_bit(response):
log.debug('65th bit = {0}'.format(response.getBit(65)))
def show_hreg(response):
log.debug('42nd hreg = {0}'.format(response.getRegister(42)))
def foo(protocol):
r1 = protocol.read_coils(1400, 400)
r1.addCallback(show_bit)
r2 = protocol.read_holding_registers(1400, 100)
r2.addCallback(show_hreg)
reactor.callLater(1, protocol.transport.loseConnection)
reactor.callLater(1.5, reactor.stop)
endpoint = TCP4ClientEndpoint(reactor, '172.20.1.1', Defaults.Port)protocol = endpoint.connect(ModbusClientFactory())protocol.addCallback(foo)reactor.run()

demonstrated the issue and produces this traceback:

DEBUG:pymodbus.client.async:Client connected to modbus serverDEBUG:pymodbus.transaction:adding transaction 1DEBUG:pymodbus.transaction:adding transaction 2DEBUG:pymodbus.transaction:0x0 0x2 0x0 0x0 0x0 0xcb 0x0 0x3 0xc8 0x2 0x8b 0x2 0xab 0x2 0x92 0x2 0x26 0x2 0x94 0x2 0x93 0x2 0x92 0x2 0x5e 0x2 0x5f 0x2 0x9f <
span class="mh">0x2 0x8 0x14 0x82 0x14 0x79 0x14 0x7c 0x14 0x73 0x14 0x56 0x14 0x90 0x14 0x8c 0x14 0x8d 0x14 0x88 0x14 0x69 0x14 0x8a 0x14 0x89 0x14 0x59 0x3 0x84 0x14 0xe3 0x14 0xc4 0x14 0xde 0x14 0xda 0x1 0x90 0x0 0x0 0x2 0x3c 0x0 0x2 0x0 0x1 0x0 0x0 0x1 0x61 0x0 0x0 0x0 0x0 0x1 0x9 0x1 0x70 0x0 0xc9 0x2 0xd6 0x0 0x1 0x2 0xdb 0x0 0x0 0x0 0x4 0x0 0x46 0x0 0xa4 0x0 0x4 0x0 0x4 0x0 0x0 0x0 0x4 0x0 0x4 0x0 0x0 0x1 0x60 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x2 0x0 0x2 0x0 0x2 0x0 0x2 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x1 0x11 0x2 0xa1 0x2 0x73 0x0 0x0 0x2 0x9d 0x1 0x90 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0xd 0x48 0xc 0xe4 0xd 0x48 0xc 0xe4 0x1e 0x78 0x1d 0x4c 0x1c 0xe8 0x1a 0xc2 0x19 0x64 0x19 0x0 0x15 0x4a 0x14 0x50 0x14 0x28 0x15 0x4a 0x14 0x50 0x14 0x28 0x0 0x0 0x0 0x0** 0x0 0x0 0x0 0x0 0xd 0x48DEBUG:pymodbus.factory:Factory Response[3]DEBUG:pymodbus.transaction:getting transaction 2Unhandled error in Deferred:Unhandled ErrorTraceback (most recent call last):
File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/pymodbus/transaction.py", line 346, in processIncomingPacket
callback(result) # defer or push to a thread?
File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/pymodbus/client/async.py", line 113, in _handleResponse
handler.callback(reply)
File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/twisted/internet/defer.py", line 381, in callback
self._startRunCallbacks(result)
File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/twisted/internet/defer.py", line 489, in _startRunCallbacks
self._runCallbacks()--- ---
File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/twisted/internet/defer.py", line 576, in _runCallbacks
current.result = callback(current.result, _args, *_kw)
File "/home/doug/pymodbus-test.py", line 12, in show_bit
log.debug('65th bit = {0}'.format(response.getBit(65)))exceptions.AttributeError: 'ReadHoldingRegistersResponse' object has no attribute 'getBit'DEBUG:pymodbus.transaction:0x0 0x1 0x0 0x0 0x0 0x35 0x0 0x1 0x32 0x1 0xff 0xa7 0x11 0x90 0x0 0x4e 0x2d 0x9 0x0 0x80 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 *_0x0 0x0 0x0 0x0 0x0 0x34 0x4c 0x9b 0xd1 0xb6 0xf 0xe0 0x3 0x30 0x0 0x80 0x43 0xc0 0x31 0xe6 0x80 0x3 0x0 0x0 0x80 0xf0 0x7f 0x40 0xfd 0x7DEBUG:pymodbus.factory:Factory Response[1]DEBUG:pymodbus.transaction:getting transaction 1Unhandled error in Deferred:Unhandled ErrorTraceback (most recent call last):
File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/pymodbus/transaction.py", line 346, in processIncomingPacket
callback(result) # defer or push to a thread?
File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/pymodbus/client/async.py", line 113, in _handleResponse
handler.callback(reply)
File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/twisted/internet/defer.py", line 381, in callback
self._startRunCallbacks(result)
File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/twisted/internet/defer.py", line 489, in _startRunCallbacks
self._runCallbacks()--- ---
File "/home/doug/.virtualenvs/beaver-test/lib/python2.7/site-packages/twisted/internet/defer.py", line 576, in _runCallbacks
current.result = callback(current.result, *args, *_kw)
File "/home/doug/pymodbus-test.py", line 15, in show_hreg
log.debug('42nd hreg = {0}'.format(response.getRegister(42)))exceptions.AttributeError: 'ReadCoilsResponse' object has no attribute 'getRegister'DEBUG:pymodbus.client.async:Client disconnected from modbus server: [Failure instance: Traceback (failure with no frames): <class 'twisted.internet.error.ConnectionDone'>: Connection was closed cleanly.]

python 2.7.3
twisted 12.3.0
pymodbus 996dff2 996dff2

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-15868071
.

[douglatornell]

Added those 2 lines, and now the output begins:

DEBUG:pymodbus.client.async:Client connected to modbus server
<pymodbus.transaction.ModbusSocketFramer object at 0x7f2a640c>
<pymodbus.transaction.FifoTransactionManager object at 0x7f2a65ec>
DEBUG:pymodbus.transaction:adding transaction 1
DEBUG:pymodbus.transaction:adding transaction 2

So, yeah, looks like it is using the FIFO transaction manager, if object names are anything to go by...

[bashwork]

Okay well that is the problem, but now I am curious how that can possibly
happen as the transaction is set as follows:

    if isinstance(framer, ModbusSocketFramer):
        self.transaction = DictTransactionManager(self)
    else: self.transaction = FifoTransactionManager(self)

On Wed, Apr 3, 2013 at 4:19 PM, Doug Latornell notifications@github.comwrote:

Added those 2 lines, and now the output begins:

DEBUG:pymodbus.client.async:Client connected to modbus server
<pymodbus.transaction.ModbusSocketFramer object at 0x7f2a640c><pymodbus.transaction.FifoTransactionManager object at 0x7f2a65ec>
DEBUG:pymodbus.transaction:adding transaction 1DEBUG:pymodbus.transaction:adding transaction 2

So, yeah, looks like it is using the FIFO transaction manager, if object
names are anything to go by...

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-15871579
.

[bashwork]

Oh geez I'm stupid. I'll have a fix momentarily.

On Wed, Apr 3, 2013 at 4:24 PM, Galen Collins bashwork@gmail.com wrote:

Okay well that is the problem, but now I am curious how that can possibly
happen as the transaction is set as follows:

    if isinstance(framer, ModbusSocketFramer):
        self.transaction = DictTransactionManager(self)
    else: self.transaction = FifoTransactionManager(self)

On Wed, Apr 3, 2013 at 4:19 PM, Doug Latornell notifications@github.comwrote:

Added those 2 lines, and now the output begins:

DEBUG:pymodbus.client.async:Client connected to modbus server
<pymodbus.transaction.ModbusSocketFramer object at 0x7f2a640c><pymodbus.transaction.FifoTransactionManager object at 0x7f2a65ec>
DEBUG:pymodbus.transaction:adding transaction 1DEBUG:pymodbus.transaction:adding transaction 2

So, yeah, looks like it is using the FIFO transaction manager, if object
names are anything to go by...

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-15871579
.

[bashwork]

Please pull latest: 87b1138

Sorry for the spam,

Galen

On Wed, Apr 3, 2013 at 4:25 PM, Galen Collins bashwork@gmail.com wrote:

Oh geez I'm stupid. I'll have a fix momentarily.

On Wed, Apr 3, 2013 at 4:24 PM, Galen Collins bashwork@gmail.com wrote:

Okay well that is the problem, but now I am curious how that can possibly
happen as the transaction is set as follows:

    if isinstance(framer, ModbusSocketFramer):

        self.transaction = DictTransactionManager(self)

    else: self.transaction = FifoTransactionManager(self)

On Wed, Apr 3, 2013 at 4:19 PM, Doug Latornell notifications@github.comwrote:

Added those 2 lines, and now the output begins:

DEBUG:pymodbus.client.async:Client connected to modbus server
<pymodbus.transaction.ModbusSocketFramer object at 0x7f2a640c><pymodbus.transaction.FifoTransactionManager object at 0x7f2a65ec>
DEBUG:pymodbus.transaction:adding transaction 1DEBUG:pymodbus.transaction:adding transaction 2

So, yeah, looks like it is using the FIFO transaction manager, if object
names are anything to go by...

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-15871579
.

[douglatornell]

Test case runs cleanly now. I'll have to wait until tomorrow to be able to test the full app in an environment with 87b1138 applied.

Thanks for your help with this, Galen!