Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

First Steps /help #25

Closed
brandonfwl opened this issue Jul 3, 2013 · 20 comments
Closed

First Steps /help #25

brandonfwl opened this issue Jul 3, 2013 · 20 comments

Comments

@brandonfwl
Copy link

I tried to run:

//
from pymodbus.client.sync import ModbusTcpClient

client = ModbusTcpClient('myStaticIP, port=myPort')
client.connect()
rr = client.connect()
print rr
client.write_coil(1, True)
result = client.read_coils(1,1)
print result.bits[0]
client.close()
//

Output is as follows:
//
True
Traceback (most recent call last):
File "./test.py", line 11, in
print result.bits[0]
AttributeError: 'NoneType' object has no attribute 'bits'
//

Tried on Ubuntu 12.10, Linux Mint 15 and BeagleBone (Black). All different boxes, with good ping responses from Modbus client. Modbus client is an IDEC FC5A-D12 running as Modbus TCP Slave.

Any help would be great!

@bashwork
Copy link
Collaborator

bashwork commented Jul 8, 2013

So it appears that you are not getting anything back from the device. Could you enable logging and post that here so I can see what is going on?

@brandonfwl
Copy link
Author

DEBUG:pymodbus.transaction:Running transaction 1
DEBUG:pymodbus.transaction:Transaction failed. (timed out)
DEBUG:pymodbus.transaction:
DEBUG:pymodbus.transaction:getting transaction 1
Traceback (most recent call last):
File "./test.py", line 11, in
print result.bits[0]
AttributeError: 'NoneType' object has no attribute 'bits'

@bashwork
Copy link
Collaborator

bashwork commented Jul 9, 2013

So your device is not responding. Is there anyway that you can test a basic read with the following tool and see if you can get a successful coil read over TCP:

http://www.modbusdriver.com/modpoll.html

@brandonfwl
Copy link
Author

I was able to get a successful coil read with the modpoll tool using the default command listed:

'modpoll -c 5 -r 100 -p 50002 -m tcp xxx.xx.x.xx'

I manually set the port to 50002 as the default 502 is trouble with my linux box.

@bashwork
Copy link
Collaborator

bashwork commented Jul 9, 2013

Great so your device is fine, the following test should pass as long as you
have permission to write to the device::

https://gist.github.com/bashwork/f6c1c67375b9fd88de22

On Tue, Jul 9, 2013 at 3:16 PM, brandonfwl [email protected] wrote:

I was able to get a successful coil read with the modpoll tool using the
default command listed:

'modpoll -c 5 -r 100 -p 50002 -m tcp xxx.xx.x.xx'

I manually set the port to 50002 as the default 502 is trouble with my
linux box.


Reply to this email directly or view it on GitHubhttps://github.com//issues/25#issuecomment-20681197
.

@brandonfwl
Copy link
Author

client connected: True
DEBUG:pymodbus.transaction:Running transaction 1
DEBUG:pymodbus.transaction:Transaction failed. (timed out)
DEBUG:pymodbus.transaction:
DEBUG:pymodbus.transaction:getting transaction 1
Traceback (most recent call last):
File "./pytest.py", line 15, in
assert(rq != None)
AssertionError

@brandonfwl
Copy link
Author

I did have a question about this line : 'assert(rq.function_code < 0x80)'

What does the 0x80 function code do? As I understand the function code to 'write single register' is 0x05. Is the 0x80 an offset for something? Please excuse my lack of knowledge on this, I'm still learning.

@bashwork
Copy link
Collaborator

bashwork commented Jul 9, 2013

Any function code that is greater than 0x80 is an error response, so hopefully all returned messages have a function code below 0x80. What I am wondering is if your device is just slow to response and thus timing out. Can you attempt to copy the advice from this issue: #21

@brandonfwl
Copy link
Author

would that be in 'transaction.py' in pymodules?

would you use

import time

time.sleep()?

what's a good starting value?

@brandonfwl
Copy link
Author

Tried a few different timing schema to delay between send() & recv(1024). Same result as before. Edke indicates that he modified the function but doesn't indicate in what way.

@mesias
Copy link

mesias commented Jul 10, 2013

I've modified and printed the result of recv(1024) when i got trouble. Any
data are received ?

On Tue, Jul 9, 2013 at 8:05 PM, brandonfwl [email protected] wrote:

Tried a few different timing schema to delay between send() & recv(1024).
Same result as before. Edke indicates that he modified the function but
doesn't indicate in what way.


Reply to this email directly or view it on GitHubhttps://github.com//issues/25#issuecomment-20711758
.

Alejandro Mesias André Nebra Perez
Java/Python/Js/Something else Developer
Twitter: @meszias
Linux User #442506

Campinas - SP - Brasil - South America

@brandonfwl
Copy link
Author

No data received. Same result as before.

@brandonfwl
Copy link
Author

Think I've got somewhere with this. Here is the current DEBUG output:

client connected: True
DEBUG:pymodbus.transaction:Running transaction 1
DEBUG:pymodbus.transaction:����
DEBUG:pymodbus.transaction:0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x5 0x0 0x5 0xff 0x0
DEBUG:pymodbus.factory:Factory Response[5]
DEBUG:pymodbus.transaction:adding transaction 1
DEBUG:pymodbus.transaction:getting transaction 1
DEBUG:pymodbus.transaction:Running transaction 2
DEBUG:pymodbus.transaction:������
DEBUG:pymodbus.transaction:0x0 0x2 0x0 0x0 0x0 0x4 0x1 0x1 0x1 0x1
DEBUG:pymodbus.factory:Factory Response[1]
DEBUG:pymodbus.transaction:adding transaction 2
DEBUG:pymodbus.transaction:getting transaction 2

For some reason the PLC I'm using does require the UnitID to specified. In 'constants' the default is 0, while my test device ID is slave 1. Changed the 0 to a 1 and this is what I have. I ended up removing the time delay between send() and recv in TransactionManager (connection does not appear to be slow from the device). I'm hoping this is a good response.

@brandonfwl
Copy link
Author

Oh, I did want to reference the device that I'm using. Here is the manual for the FC5A Micro Smart Pentra Basic and Advanced http://us.idec.com/Common/Download.aspx?d=30 and the Modbus TCP point of interest is on page 33-9, where it does list that Unit ID is required.

@bashwork
Copy link
Collaborator

Awesome, I'm glad you got things working. I was going to suggest the slave
id be changed, but I had read (apparently the wrong) application note that
said it didn't matter. Anyways, you can specify the unit as a request
parameter::

client.read_coils(0x01, count=2, unit=1)

I will make sure to better illuminate these options in the examples; here
is the relevant documentation if you are interested:

https://pymodbus.readthedocs.org/en/latest/library/client-common.html

On Wed, Jul 10, 2013 at 3:10 PM, brandonfwl [email protected]:

Oh, I did want to reference the device that I'm using. Here is the manual
for the FC5A Micro Smart Pentra Basic and Advanced
http://us.idec.com/Common/Download.aspx?d=30 and the Modbus TCP point of
interest is on page 33-9, where it does list that Unit ID is required.


Reply to this email directly or view it on GitHubhttps://github.com//issues/25#issuecomment-20748886
.

@brandonfwl
Copy link
Author

So, am I correct in assuming that the response output was a good one?

@brandonfwl
Copy link
Author

Another question. If, in my case the Unit ID is required and I have more that one slave; is there a way to address the unit ID when the object is created rather than changing the 'constants'?

@brandonfwl
Copy link
Author

Sorry, didn't see that you already answered the above question with the client.read example.

@bashwork
Copy link
Collaborator

So are you good to go brandon or do I need to keep this issue open?

@brandonfwl
Copy link
Author

Think I'm good to go for the time being. Thanks for the awesome work!

ocschwar pushed a commit to ocschwar/pymodbus that referenced this issue Jun 22, 2016
Prevent setup_logging() from creating multiple root handlers
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants