Raspberry pi 2 + Modbus RTU + Ltd FT232 USB-Serial (UART) IC

[Omar Cacciotti]

Hi,

I'm writing here for a "None" common issue.

I readed many posts but actually I've not solved the problem.

#Environment

Linux raspberrypi 3.18.11-v7+ #781 SMP PREEMPT Tue Apr 21 18:07:59 BST 2015 armv7l GNU/Linux

PRETTY_NAME="Raspbian GNU/Linux 7 (wheezy)"

Python 2.7.3

######################################################

I've a RTU device and i need to get data from it.

This is a short description that the vendor gived to me:

ADDR    BYTES  HEX     Description      BYTES

40068 130    Ch3 TGP mmHg 4

40070 134    Ch4 Temp Deg C 4

40072 138    Ch5 BP mmHg         4

40074 142    Ch6 TGP %         4

40076 146    Ch7 dP mmHg         4

#######################################################

MY BASIC CODE HERE:

import pymodbus

import serial

from pymodbus.pdu import ModbusRequest

from pymodbus.client.sync import ModbusSerialClient as ModbusClient #initialize a serial RTU client instance

from pymodbus.transaction import ModbusRtuFramer

import logging

logging.basicConfig()

log = logging.getLogger()

log.setLevel(logging.DEBUG)

#count= the number of registers to read

#unit= the slave unit this request is targeting

#address= the starting address to read from

client= ModbusClient(method = "rtu", port="/dev/ttyUSB0",stopbits = 1, bytesize = 8, parity = 'E', baudrate= 9600, timeout= 10)

#connect to the serial modbus server

connection = client.connect()

print connection

#starting add, num of reg to read, slave unit.

result= client.read_holding_registers(40068,3,unit=1)

print "Result: %s" %(result)

#closes the underlying socket connection

client.close()

################################################

MY RESULT

True

DEBUG:pymodbus.transaction:Running transaction 1

DEBUG:pymodbus.transaction:recv: 0x1 0x3 0x9c 0x84 0x0 0x3 0x6b 0xb2 0x0

DEBUG:pymodbus.transaction:getting transaction 1

Result: None

################################################

I installed pymodbus from apt-get (due to previous gcc error by twisted in github package)

And then I reinstalled from github (by removing any reference to twisted as suggested by bashwork in other post)

Any help would be appreciated

Thanks in advance

Omar Cacciotti

[Omar Cacciotti]

I've corrected, as Stuart suggested, 

result= client.read_holding_registers(4,67,unit=1)

for value stored in 40068 but "NONE" is the result

[stu...@longlandclan.yi.org]

[Posted via the Google Groups frontend, my emails seem to be getting eaten.]

On 22/08/15 22:39, Omar Cacciotti wrote:

Hi,
I'm writing here for a "None" common issue.
I readed many posts but actually I've not solved the problem.

#Environment

Linux raspberrypi 3.18.11-v7+ #781 SMP PREEMPT Tue Apr 21 18:07:59 BST
2015 armv7l GNU/Linux
PRETTY_NAME="Raspbian GNU/Linux 7 (wheezy)"
Python 2.7.3

######################################################

I've a RTU device and i need to get data from it.

This is a short description that the vendor gived to me:

ADDR    BYTES  HEX     Description      BYTES
*40068*130   Ch3TGP mmHg4

#starting add, num of reg to read, slave unit.
result= client.read_holding_registers(*40068*,3,unit=1)

Try register 67 or 68.  A common (but confusing!) notation with Modbus
is that the first digit gives the register type; 4 being for a holding
register.  So register 40068 is in reality type 4 register 68 (or 4/68).

I suggest 67, because the Modbus standard (see [1] section 4.4) actually
numbers registers from 1 onwards: the official register range is from 1
to 65536, with one being subtracted when the register number is
serialised in the Modbus frame.  Software like ModScan or MacroView
number from 1 onwards.

pyModbus on the other hand, just passes the register number through
unchanged, thus you need to subtract 1 from the number given in some
datasheets (assuming they use traditional Modbus addressing).

Regards,
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

1. http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf

[stu...@longlandclan.yi.org]

On 23/08/15 00:14, Omar Cacciotti wrote:

result= client.read_holding_registers(4,67,unit=1)

That just told it to read 67 registers starting at register address 4
(register ID 5).  Try:

result= client.read_holding_registers(67,unit=1)

[Omar Cacciotti]

Hi, 

thanks for the support,

I've not solved my problem.

This kind of probe is an rs485 so I think it's asyncronous device.

Some ideas?

Thank you in advance

[stu...@longlandclan.yi.org]

On 25/08/15 04:07, Omar Cacciotti wrote:

I've not solved my problem. This kind of probe is an rs485 so I
think it's asyncronous device.

I assume the USB serial device is RS-485 as well?  Have you tried
plugging it into another box and trying an alternate package like
qModMaster to verify the device communications?

[Omar Cacciotti]

I think that the usb serial is RS-232 and RS-485 (as they say).

Tomorrow I will check the communication at low level with bus sniffer to check if the probe send replies.

I've not used others packages now (I'm searching the simplest way to use a "normal RTU serial" in async mode ).

I've printed the manual that you linked to me about modbus protocol, to study the strucutre as well.

The probe's vendor is not qualified to help me with linux/python... modbus is an old 1970 protocol..and I've some difficulties.

I need only to get some values and realize a simplest script as possible, in attach the "vendor docs" plus some notes

I’ve attached the MODBUS structure for the transmitter. Please refer to row 202. There you’ll see 8 floats for the different sensor channels. You will be interested in TGP mmHg, BP mmHg, TGP % and dP mmHg. These are in MODBUS registers 40068 to 40077.

 

You will need to use the following MODBUS settings:

 

Baud: 9600

Byte Size: 8

Parity: Even

Stop Bits: 1

Modbus ID: 1

Protocol: Modbus RTU

--
You received this message because you are subscribed to a topic in the Google Groups "pymodbus" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pymodbus/IwdkEU4ZL2s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pymodbus+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Omar Cacciotti]

Hi,

I've checked that FT232 USB-Serial is RS485, and I've tested the bus and it works well.

I changed from pymodbus to MINIMALMODBUS and here my code:

#!/usr/bin/env python

import minimalmodbus

instrument = minimalmodbus.Instrument('/dev/ttyUSB0', 1) # port name, slave address (in decimal)

instrument.serial.parity = minimalmodbus.serial.PARITY_EVEN

instrument.serial.baudrate = 9600

instrument.serial.timeout  = 1

print "Serial Settings: %s" % (instrument)

instrument.debug = True

print instrument.read_register(68, 2)

but here i get CRC error instead a "None" error of pymodbus

ValueError: Checksum error in rtu mode: '\x01e' instead of '+\xe4' . The response is: '\x01\x03\x00F\x00\x01e' (plain response: '\x01\x03\x00F\x00\x01e')

Please help me, I found too many posts without replyies about this problem.

Is the raspberry the black hole?

Is my code wrong?

Some one had a working code?

Thank you in advance

[Stuart Longland]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 30/08/15 21:40, Omar Cacciotti wrote:
> I've checked that FT232 USB-Serial is RS485, and I've tested the
> bus and it works well.
>
> I changed from pymodbus to MINIMALMODBUS and here my code:
>
> #!/usr/bin/env python import minimalmodbus
>

> […]

>
> Please help me, I found too many posts without replyies about this
> problem.

You might want to try contacting the minimalmodbus group about that
one (this isn't it).

The error message seems to suggest a bad checksum in the Modbus frame,
which suggests the device is sending a bad reply. Assuming this to be
the case, you'd need to take this up with whomever made the device in
question.

Regards,
- --

Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iJ4EARMKAAYFAlXjXzAACgkQoCQEvFhlDPlkLQH6AslTRWjK1ZeLTpizrNKzSt3J
N1Bg7I6BacG1kqzMPLT+SJgEBWUZ3XsPyOZgrIwJim2nPgPXuRf8Vgl250e1NAH/
XK3pt1utnaRSkh/rOMXCMC8KD+zn0d3CZoKICiTYAFbZ2sEpfFOrGuQydvhpU4u1
prlp+osA0vOTBpX0bXapsQ==
=lbnM
-----END PGP SIGNATURE-----

[Beering]

I found, that CH340 USB-RS485 adapter not worked with EVEN parity, but was fine with NONE at booth ends.