minimalmodbus-list — Mailing list for minimalmodbus

[Minimalmodbus-list] Using computer as slave

[Paweł J. <jab...@po...>]

Hello,
is it possible to use computer as a slave with minimalmodbus library? In a
documentation is only how to use as a master, but I will connect computer
with text panel SH-300 which is running only as a master via RS-485 (modbus
RTU).
Best regards
Paweł

Re: [Minimalmodbus-list] it dosn't write to register

[Jonas B. <jon...@ho...>]

Best Ralf!
It seems that the slave is indicating an error condition, Perhaps you
are not allowed to write to that particular register.

I suggest that you first verify that the command generated by
MinimalModbus is correct. Compare it with the documentation of your
instrument.

These are the bytes:
\x10 Slave address 16
\x10 Function code 16
\xf0 
\x03
\x00
\x01
\x02
\x00
o
\xd
6
\x10


I have made a detailed example here:
http://minimalmodbus.sourceforge.net/#debug-mode
See especially the 'example' subsection.

The response from the instrument is this error code:
\x10
\x90
\x01
\xdd
\xc5

You need to figure out what this means for your particular instrument.

Best regards
Jonas

<-----Ursprungligt Meddelande----->

 	 	From: Techritz, Ralf [rt...@st...]
Sent: 20/5/2014 5:26:33 PM
To: min...@li...
Subject: [Minimalmodbus-list] it dosn't write to register 



I have to do some test and should use therefor minimalmodbus.

So far so good. 

Reading works great, but writing doesn't

 

Could you give me a tip why?

 

Thanks a lot.

 

The code that does not write to the register is the following

 

-WrError.py-------------------------------------------------------------
----------------------------

import minimalmodbus

import serial

 

ModBusPort = minimalmodbus.Instrument('COM12', 16)

ModBusPort.serial.baudrate = 115000

ModBusPort.serial.setTimeout (5)

ModBusPort.serial.setParity(serial.PARITY_EVEN)

ModBusPort.debug = True

 

 

# Reading is OK

print '\n %s Register seted ? %s'%(61443,
ModBusPort.read_register(61443, 0, 3,True))

 

# but writing does not work!

# WHY NOT?

 

ModBusPort.serial.VERBOUSE = True         

print '\nModBusPort.debug-state :',ModBusPort.debug      

 

RdHwOffset = 0x0006

# setze Temp-Fuehler-IOs in Simulationsmode

print '\nsetze Temp-Fuehler-IOs in Simulationsmode:'

 

try:

      print '%s - %s'%(61443 ,ModBusPort.write_register(61443, 111))

except ValueError, Argument:

    print 'ValueError', Argument

except TypeError:

    print 'TypeError'

except IOError:

    print 'IOError'

else:

    print 'else'

 

# Whats wrong with my code?

 

 

--this is what I get back
------------------------------------------------------------------------
----------------

>>> 

MinimalModbus debug mode. Writing to instrument (expecting 7 bytes
back): '\x10\x03\xf0\x03\x00\x01DK'

MinimalModbus debug mode. No sleep required before write. Time since
previous read: 1400599268847.0 ms, minimum silent period: 0.33 ms.

MinimalModbus debug mode. Response from instrument:
'\x10\x03\x02\x00\x01\x85\x87' (7 bytes), roundtrip time: 15.0 ms.
Timeout setting: 5000.0 ms.

 

 

61443 Register seted ? 1

 

ModBusPort.debug-state : True

 

setze Temp-Fuehler-IOs in Simulationsmode:

 

MinimalModbus debug mode. Writing to instrument (expecting 8 bytes
back): '\x10\x10\xf0\x03\x00\x01\x02\x00o\xd6\x10'

MinimalModbus debug mode. No sleep required before write. Time since
previous read: 33.0 ms, minimum silent period: 0.33 ms.

MinimalModbus debug mode. Response from instrument:
'\x10\x90\x01\xdd\xc5' (5 bytes), roundtrip time: 5001.0 ms. Timeout
setting: 5000.0 ms.

 

ValueError The slave is indicating an error. The response is:
'\x10\x90\x01\xdd\xc5'

>>> 

 

 

-----_getDiagnosticString()
------------------------------------------------------------------------
-------------

 

The used configuration of COM-Port:

minimalmodbus.Instrument<id=0x2c05670, address=16,
close_port_after_each_call=False, precalculate_read_size=True,
debug=True, serial=Serial<id=0x2be4c10, open=True>(port='COM12',
baudrate=115000, bytesize=8, parity='E', stopbits=1, timeout=10,
xonxoff=False, rtscts=False, dsrdtr=False)>

 

The register address I want to write : StartAdr : 4358  

 

MinimalModbus debug mode. Writing to instrument (expecting 8 bytes
back): "\x10\x10\x11\x06\x00\x01\x02\x00o'K"

MinimalModbus debug mode. No sleep required before write. Time since
previous read: 42.0 ms, minimum silent period: 0.33 ms.

MinimalModbus debug mode. Response from instrument:
'\x10\x90\x01\xdd\xc5' (5 bytes), roundtrip time: 10001.0 ms. Timeout
setting: 10000.0 ms.

 

Mit freundlichenGrüßen

 

Ralf Techritz

 

[Minimalmodbus-list] it dosn't write to register

[Techritz, R. <rt...@st...>]

I have to do some test and should use therefor minimalmodbus.
So far so good.
Reading works great, but writing doesn't

Could you give me a tip why?

Thanks a lot.

The code that does not write to the register is the following

-WrError.py-----------------------------------------------------------------------------------------
import minimalmodbus
import serial

ModBusPort = minimalmodbus.Instrument('COM12', 16)
ModBusPort.serial.baudrate = 115000
ModBusPort.serial.setTimeout (5)
ModBusPort.serial.setParity(serial.PARITY_EVEN)
ModBusPort.debug = True


# Reading is OK
print '\n %s Register seted ? %s'%(61443, ModBusPort.read_register(61443, 0, 3,True))

# but writing does not work!
# WHY NOT?

ModBusPort.serial.VERBOUSE = True
print '\nModBusPort.debug-state :',ModBusPort.debug

RdHwOffset = 0x0006
# setze Temp-Fuehler-IOs in Simulationsmode
print '\nsetze Temp-Fuehler-IOs in Simulationsmode:'

try:
      print '%s - %s'%(61443 ,ModBusPort.write_register(61443, 111))
except ValueError, Argument:
    print 'ValueError', Argument
except TypeError:
    print 'TypeError'
except IOError:
    print 'IOError'
else:
    print 'else'

# Whats wrong with my code?


--this is what I get back ----------------------------------------------------------------------------------------
>>>
MinimalModbus debug mode. Writing to instrument (expecting 7 bytes back): '\x10\x03\xf0\x03\x00\x01DK'
MinimalModbus debug mode. No sleep required before write. Time since previous read: 1400599268847.0 ms, minimum silent period: 0.33 ms.
MinimalModbus debug mode. Response from instrument: '\x10\x03\x02\x00\x01\x85\x87' (7 bytes), roundtrip time: 15.0 ms. Timeout setting: 5000.0 ms.


61443 Register seted ? 1

ModBusPort.debug-state : True

setze Temp-Fuehler-IOs in Simulationsmode:

MinimalModbus debug mode. Writing to instrument (expecting 8 bytes back): '\x10\x10\xf0\x03\x00\x01\x02\x00o\xd6\x10'
MinimalModbus debug mode. No sleep required before write. Time since previous read: 33.0 ms, minimum silent period: 0.33 ms.
MinimalModbus debug mode. Response from instrument: '\x10\x90\x01\xdd\xc5' (5 bytes), roundtrip time: 5001.0 ms. Timeout setting: 5000.0 ms.

ValueError The slave is indicating an error. The response is: '\x10\x90\x01\xdd\xc5'
>>>


-----_getDiagnosticString() -------------------------------------------------------------------------------------

The used configuration of COM-Port:
minimalmodbus.Instrument<id=0x2c05670, address=16, close_port_after_each_call=False, precalculate_read_size=True, debug=True, serial=Serial<id=0x2be4c10, open=True>(port='COM12', baudrate=115000, bytesize=8, parity='E', stopbits=1, timeout=10, xonxoff=False, rtscts=False, dsrdtr=False)>

The register address I want to write : StartAdr : 4358

MinimalModbus debug mode. Writing to instrument (expecting 8 bytes back): "\x10\x10\x11\x06\x00\x01\x02\x00o'K"
MinimalModbus debug mode. No sleep required before write. Time since previous read: 42.0 ms, minimum silent period: 0.33 ms.
MinimalModbus debug mode. Response from instrument: '\x10\x90\x01\xdd\xc5' (5 bytes), roundtrip time: 10001.0 ms. Timeout setting: 10000.0 ms.

Mit freundlichenGrüßen

Ralf Techritz

[Minimalmodbus-list] Serial port handling

[Pascal D. <pas...@gm...>]

Hi

I want to use 2 programs to communicate with the same device (=same serial
port).
I have 2 questions:
 - in case the port is already opened by one of the program, I don't see in
the API what is the return of minimalmodbus.Instrument function? FALSE?
I would like to loop until the opening is succesful

- let's say I don't want to use minimalmodbus.CLOSE_PORT_AFTER_EACH_CALL to
true because I want to make several read and write in a shot. I don't see
in the API what is the function to intentionality close the serial port? I
open the port with minimalmodbus.Instrument, I do my read and write and
then I want to close the port, to free it for the other program

Hope I am clear enough :)

thanks for your help
Pascal

[Minimalmodbus-list] Serial port handling

[Pascal D. <pas...@gm...>]

Hi

I want to use 2 programs to communicate with the same device (=same serial
port).
I have 2 questions:
 - in case the port is already opened by one of the program, I don't see in
the API what is the return of minimalmodbus.Instrument function? FALSE?
I would like to loop until the opening is succesful

- let's say I don't want to use minimalmodbus.CLOSE_PORT_AFTER_EACH_CALL to
true because I want to make several read and write in a shot. I don't see
in the API what is the function to intentionality close the serial port? I
open the port with minimalmodbus.Instrument, I do my read and write and
then I want to close the port, to free it for the other program

Hope I am clear enough :)

thanks for your help
Pascal

Re: [Minimalmodbus-list] timing of silent period

[Dominik S. <Dom...@de...>]

Hi

Unfortunately I'm not expert on multi-platform programming.
As for running on multiple python versions I've seen some tricks like:
If it's python 2.x you write i.e
"from __future__ import print_function"
And then you can use print functions in python 3 under python 2.

I never had to worry about porting scripts to different versions of python as we use only 2.7 version. So unfortunately I can't tell you that too much about this topic as well.

You can find some more info in here https://docs.python.org/3/howto/pyporting.html

Good luck with your project!


Best Regards,
Dominik Socha



From: Jonas Berg [mailto:jon...@ho...]
Sent: Thursday, April 10, 2014 10:30 PM
To: Dominik Socha
Cc: min...@li...
Subject: Re: [Minimalmodbus-list] timing of silent period

Hi, thanks for your input!

Yes, it might be a better idea to use time.clock() instead.

Do you know how to adapt the code to run on Python2.6 to Python3.4 with same code base on both Windows and Linux? Any detailed timing suggestions would be appreciated.

Best regards
Jonas
<-----Ursprungligt Meddelande----->




From: Dominik Socha [Dominik.Socha@ xxx .com]
Sent: 7/4/2014 10:55:29 AM
To: min...@li...<mailto:min...@li...>
Subject: [Minimalmodbus-list] timing of silent period


Hi
I'm implementing custom modbus stack for my company. I was looking briefly at your code (unfortunately I can't use your library). I think it's nice job!
I saw that you are using time.time() for calculating silent period between frames. As you mentioned in comments it's not too accurate. So maybe it's better to replace it with time.clock()? It has way better resolution under windows and linux.

Also if you want you may use attached crc calculation function to get some performace boost on crc calculation.

Best Regards,
Dominik Socha


********************************************************************************************************************************
This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
[Delta Energy Systems]
********************************************************************************************************************************


Delta Energy Systems (Germany) GmbH
Domicile:            Soest
Commercial registration:    AG Arnsberg HRB 5717
Managing director: Dr. Basile Margaritis
********************************************************************************************************************************


_______________________________________________________________
Annons: Hitta k?rleken p? M?tesplatsen.se ? Bli medlem Gratis nu<http://adserver.adtech.de/?adlink|3.0|1297|4819575|1|16|AdId=9776362;BnId=1;link=http://rms.admeta.com/public/transfer.asp?sitebanner_id=4723912>
********************************************************************************************************************************
This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain 
confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. 
If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. 
[Delta Energy Systems]
********************************************************************************************************************************

Delta Energy Systems (Germany) GmbH 
Domicile:			Soest
Commercial registration:	AG Arnsberg HRB 5717 
Managing director:		Dr. Basile Margaritis
********************************************************************************************************************************

Re: [Minimalmodbus-list] timing of silent period

[Jonas B. <jon...@ho...>]

Hi, thanks for your input!

Yes, it might be a better idea to use time.clock() instead.

Do you know how to adapt the code to run on Python2.6 to Python3.4 with
same code base on both Windows and Linux? Any detailed timing
suggestions would be appreciated.

Best regards
Jonas


<-----Ursprungligt Meddelande----->

 	 	From: Dominik Socha [Dominik.Socha@ xxx .com]
Sent: 7/4/2014 10:55:29 AM
To: min...@li...
Subject: [Minimalmodbus-list] timing of silent period 



Hi 

I'm implementing custom modbus stack for my company. I was looking
briefly at your code (unfortunately I can't use your library). I think
it's nice job!

I saw that you are using time.time() for calculating silent period
between frames. As you mentioned in comments it's not too accurate. So
maybe it's better to replace it with time.clock()? It has way better
resolution under windows and linux.

 

Also if you want you may use attached crc calculation function to get
some performace boost on crc calculation.

 

Best Regards,

Dominik Socha

 

************************************************************************
********************************************************
This email message, including any attachments, is for the sole use of
the intended recipient(s) and may contain 
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. 
If you are not the intended recipient, please contact the sender by
reply e-mail and destroy all copies of the original message. 
[Delta Energy Systems]
************************************************************************
********************************************************


Delta Energy Systems (Germany) GmbH 
Domicile:            Soest
Commercial registration:    AG Arnsberg HRB 5717 
Managing director: Dr. Basile Margaritis
************************************************************************
********************************************************



<P><p><font face="Arial, Helvetica, sans-serif" size="2" style="font-size:13.5px">_______________________________________________________________<BR>Annons: <a href="http://adserver.adtech.de/?adlink|3.0|1297|4819575|1|16|AdId=9776362;BnId=1;link=http://rms.admeta.com/public/transfer.asp?sitebanner_id=4723912" target="_blank">Hitta kärleken på Mötesplatsen.se – Bli medlem Gratis nu</a></font>

[Minimalmodbus-list] Release of MinimalModbus 0.5

[Jonas B. <jon...@ho...>]

MinimalModbus 0.5 has now been released! The speed is increased by
precalculating number of bytes to read, and it has better compliance
with Modbus timing requirements.

Now there is better handling of several instruments on the same serial
port, especially for Windows.



<P><p><font face="Arial, Helvetica, sans-serif" size="2" style="font-size:13.5px">_______________________________________________________________<BR>Annons: <a href="http://adserver.adtech.de/?adlink|3.0|1297|4819575|1|16|AdId=9776362;BnId=1;link=http://rms.admeta.com/public/transfer.asp?sitebanner_id=4723912" target="_blank">Hitta kärleken på Mötesplatsen.se – Bli medlem Gratis nu</a></font>

Re: [Minimalmodbus-list] MinimalModBus for Watlow F4 Series

[Monaghan, T. (G. I. Platforms) <tim...@ge...>]

Hi

First ensure the wiring you have is correct.

Image for the wiring looking at the female RS232 connector, the pins are those from marked on the watlow F4.
https://www.dropbox.com/s/julo6oyup6qrpd0/watlow_wiring.png

Photo of mine wired up, only using Watlow F4  pins 14,15 & 16
https://www.dropbox.com/s/1lxowl4vgtmtf8e/watlow_wiring_photo.jpg

That is how mine is wired, ensure the baud rate and slave ID is setup correctly on the Watlow, refer to the manual if required.
http://www.cszindustrial.com/portals/1/pdf/WatlowF4_UserManual.pdf

-----Original Message-----
From: min...@li... [mailto:min...@li...] 
Sent: 14 February 2014 17:04
To: min...@li...
Subject: Minimalmodbus-list Digest, Vol 12, Issue 1

Send Minimalmodbus-list mailing list submissions to
	min...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/minimalmodbus-list
or, via email, send a message with subject or body 'help' to
	min...@li...

You can reach the person managing the list at
	min...@li...

When replying, please edit your Subject line so it is more specific than "Re: Contents of Minimalmodbus-list digest..."


Today's Topics:

   1. Re: Modbus ASCII Support (Michael Penza)
   2. MinimalModBus for Watlow F4 Series (Angelo Gagliardi)
   3. Windows amd64 (Monaghan, Timothy (GE, Intelligent Platforms))


----------------------------------------------------------------------

Message: 1
Date: Sun, 5 Jan 2014 15:53:52 +0000
From: Michael Penza <mp...@pe...>
Subject: Re: [Minimalmodbus-list] Modbus ASCII Support
To: Jonas Berg <jon...@ho...>
Cc: "min...@li..."
	<min...@li...>
Message-ID:
	<ff2...@BL...>
	
Content-Type: text/plain; charset="us-ascii"

Jonas,
I can certainly help with the testing.  The device I have is a railroad industry specific event recorder (http://goo.gl/QFsCok).  It supports reading of holding registers, but not much else.  But I do have it sitting in my office and can run tests against it.
Mike

From: Jonas Berg [mailto:jon...@ho...]
Sent: Saturday, January 4, 2014 7:41 PM
To: Michael Penza
Cc: min...@li...
Subject: RE: [Minimalmodbus-list] Modbus ASCII Support

Hi again Mike,
you are of course completely right!
I am very  impressed by your work! Of course it will go into MinimalModbus.

A new version of MinimalModbus will be released during the spring. I plan to write some unit tests also for the ASCII parts of it.
As I do not have access to any Modbus ASCII hardware, it would be great if you could help with some tests. I guess it will take a few weeks before it is ready.

Best regards
Jonas

<-----Ursprungligt Meddelande----->




From: Michael Penza [mp...@pe...]
Sent: 4/1/2014 3:38:15 PM
To: jon...@ho...<mailto:jon...@ho...>
Cc: min...@li...<mailto:min...@li...>
Subject: RE: [Minimalmodbus-list] Modbus ASCII Support


Jonas,

Modbus RTU and Modbus ASCII are very similar, so a found it pretty easy to adapt the library to support both.  ASCII adds a start and end character and uses and LRC instead of CRC, but otherwise the message is a direct ASCII representation of the hexadecimal data in the RTU message.

I've attached the modified version of your library that supports both RTU and ASCII.  I've been using this successfully for about a month now.  If you would like to incorporate my changes into your library, that would be great.  If you still think it would be better as a separate library that, let me know and I'll look turning it into its own library.

Thanks.

Mike

From: Jonas Berg [mailto:jon...@ho...]
Sent: Saturday, January 4, 2014 8:17 AM
To: Michael Penza
Cc: min...@li...<mailto:min...@li...>
Subject: Re: [Minimalmodbus-list] Modbus ASCII Support

Hi Michael!
Thanks for your input, and sorry for my late reply.

I think it would be quite a substantial amount of work to adapt MinimalModbus to ASCII, and I would really like to keep it minimal. If you can suggest the changes needed to be done in order to support ASCII to the same amount of functionality as there is for Modbus RTU right now, it can be considered.

If you would like to make a python Modbus ASCII library, you can start off by the MinimalModbus code and make adaptions. I will help you in all ways possible. There are lots of developer info on this page: http://minimalmodbus.sourceforge.net/develop.html
So I guess a separate Python library with ASCII Modbus would be easier to maintain than a single one for both (unless you have some good suggestions).

Please let me know what you think.
Best regards
Jonas




<-----Ursprungligt Meddelande----->




From: Michael Penza [mp...@pe...]
Sent: 15/11/2013 7:12:58 PM
To: min...@li...<mailto:min...@li...>
Subject: [Minimalmodbus-list] Modbus ASCII Support Hi. I hope this is the right place for this type of question.

I had a need to communicate with an older device that only talks Modbus ASCII. I tried the other Python Modbus libraries that support Modbus ASCII, but couldn't get any of them working correctly. MinimalModbus looked perfect, except for its lack of support for the ASCII flavor of Modbus.  So a modified version 0.4.1 of MinimalModbus to add support for Modbus ASCII.  My use case is limited (I'm just reading holding registers), but I do have it working. I've also added an option to flush the input buffer prior to each call to better handle garbage on the serial line.

I would like to make this code available for inclusion in the official MinimalModbus distribution, but I'm unsure of how to go about doing that. Would anybody like this code and how do I go about making it available?  Thanks.

Michael Penza


_______________________________________________________________
Annons: Hitta k?rleken p? M?tesplatsen.se ? Bli medlem Gratis nu<http://adserver.adtech.de/?adlink|3.0|1297|4819575|1|16|AdId=9776362;BnId=1;link=http://rms.admeta.com/public/transfer.asp?sitebanner_id=4723912>


_______________________________________________________________
Annons: Hitta k?rleken p? M?tesplatsen.se ? Bli medlem Gratis nu<http://adserver.adtech.de/?adlink|3.0|1297|4819575|1|16|AdId=9776362;BnId=1;link=http://rms.admeta.com/public/transfer.asp?sitebanner_id=4723912>
-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

Message: 2
Date: Wed, 29 Jan 2014 10:16:30 -0800
From: Angelo Gagliardi <ang...@gm...>
Subject: [Minimalmodbus-list] MinimalModBus for Watlow F4 Series
To: min...@li...
Message-ID:
	<CAG...@ma...>
Content-Type: text/plain; charset="iso-8859-1"

Hi there,

Im trying to set up automation testing for a temperature chamber that is controlled by a Watlow F4 Series controller, with a DB9 RS-232 interface.
 I've been trying to use the MinimalModBus module to get controller talking to my computer but can not get any response when sending it a read command (or at least I think I'm sending it read command) The minimalmodbus object is set to the right serial port with the right settings.  I was wondering if anyone has test code or experience with this controller around the MinimalModBus community, I really need to get it talking asap and any help would be great! Thanks!

-- 

*Angelo Gagliardi*

*Electrical Engineering, Cal Poly*Ang...@gm...
*1-415-259-8990*
-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

Message: 3
Date: Fri, 14 Feb 2014 16:47:27 +0000
From: "Monaghan, Timothy (GE, Intelligent Platforms)"
	<tim...@ge...>
Subject: [Minimalmodbus-list] Windows amd64
To: "min...@li..."
	<min...@li...>
Message-ID:
	<36D...@LO...>
Content-Type: text/plain; charset="us-ascii"

Hi

Would it be possible to produce a 64 bit windows installer for python 3.x

Regards

Tim Monaghan
Software Engineer
GE Intelligent Platforms Ltd

Telephone: +44 (0) 1327 359444
Direct Dial: +44 (0) 1327 322674
Email: tim...@ge...<mailto:tim...@ge...>
Web: www.defence.ge-ip.com

GE Imagination at work
GE Intelligent Platforms Ltd, registered in England and Wales (3828642) at 100 Barbirolli Square, Manchester, M2 3AB, VAT GB 927 5591 89


-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk

------------------------------

_______________________________________________
Minimalmodbus-list mailing list
Min...@li...
https://lists.sourceforge.net/lists/listinfo/minimalmodbus-list


End of Minimalmodbus-list Digest, Vol 12, Issue 1
*************************************************

[Minimalmodbus-list] Windows amd64

[Monaghan, T. (G. I. Platforms) <tim...@ge...>]

Hi

Would it be possible to produce a 64 bit windows installer for python 3.x

Regards

Tim Monaghan
Software Engineer
GE Intelligent Platforms Ltd

Telephone: +44 (0) 1327 359444
Direct Dial: +44 (0) 1327 322674
Email: tim...@ge...<mailto:tim...@ge...>
Web: www.defence.ge-ip.com

GE Imagination at work
GE Intelligent Platforms Ltd, registered in England and Wales (3828642) at 100 Barbirolli Square, Manchester, M2 3AB, VAT GB 927 5591 89

[Minimalmodbus-list] MinimalModBus for Watlow F4 Series

[Angelo G. <ang...@gm...>]

Hi there,

Im trying to set up automation testing for a temperature chamber that is
controlled by a Watlow F4 Series controller, with a DB9 RS-232 interface.
 I've been trying to use the MinimalModBus module to get controller talking
to my computer but can not get any response when sending it a read command
(or at least I think I'm sending it read command) The minimalmodbus object
is set to the right serial port with the right settings.  I was wondering
if anyone has test code or experience with this controller around the
MinimalModBus community, I really need to get it talking asap and any help
would be great! Thanks!

-- 

*Angelo Gagliardi*

*Electrical Engineering, Cal Poly*Ang...@gm...
*1-415-259-8990*

Re: [Minimalmodbus-list] Modbus ASCII Support

[Michael P. <mp...@pe...>]

Jonas,
I can certainly help with the testing.  The device I have is a railroad industry specific event recorder (http://goo.gl/QFsCok).  It supports reading of holding registers, but not much else.  But I do have it sitting in my office and can run tests against it.
Mike

From: Jonas Berg [mailto:jon...@ho...]
Sent: Saturday, January 4, 2014 7:41 PM
To: Michael Penza
Cc: min...@li...
Subject: RE: [Minimalmodbus-list] Modbus ASCII Support

Hi again Mike,
you are of course completely right!
I am very  impressed by your work! Of course it will go into MinimalModbus.

A new version of MinimalModbus will be released during the spring. I plan to write some unit tests also for the ASCII parts of it.
As I do not have access to any Modbus ASCII hardware, it would be great if you could help with some tests. I guess it will take a few weeks before it is ready.

Best regards
Jonas

<-----Ursprungligt Meddelande----->




From: Michael Penza [mp...@pe...]
Sent: 4/1/2014 3:38:15 PM
To: jon...@ho...<mailto:jon...@ho...>
Cc: min...@li...<mailto:min...@li...>
Subject: RE: [Minimalmodbus-list] Modbus ASCII Support


Jonas,

Modbus RTU and Modbus ASCII are very similar, so a found it pretty easy to adapt the library to support both.  ASCII adds a start and end character and uses and LRC instead of CRC, but otherwise the message is a direct ASCII representation of the hexadecimal data in the RTU message.

I've attached the modified version of your library that supports both RTU and ASCII.  I've been using this successfully for about a month now.  If you would like to incorporate my changes into your library, that would be great.  If you still think it would be better as a separate library that, let me know and I'll look turning it into its own library.

Thanks.

Mike

From: Jonas Berg [mailto:jon...@ho...]
Sent: Saturday, January 4, 2014 8:17 AM
To: Michael Penza
Cc: min...@li...<mailto:min...@li...>
Subject: Re: [Minimalmodbus-list] Modbus ASCII Support

Hi Michael!
Thanks for your input, and sorry for my late reply.

I think it would be quite a substantial amount of work to adapt MinimalModbus to ASCII, and I would really like to keep it minimal. If you can suggest the changes needed to be done in order to support ASCII to the same amount of functionality as there is for Modbus RTU right now, it can be considered.

If you would like to make a python Modbus ASCII library, you can start off by the MinimalModbus code and make adaptions. I will help you in all ways possible. There are lots of developer info on this page: http://minimalmodbus.sourceforge.net/develop.html
So I guess a separate Python library with ASCII Modbus would be easier to maintain than a single one for both (unless you have some good suggestions).

Please let me know what you think.
Best regards
Jonas




<-----Ursprungligt Meddelande----->




From: Michael Penza [mp...@pe...]
Sent: 15/11/2013 7:12:58 PM
To: min...@li...<mailto:min...@li...>
Subject: [Minimalmodbus-list] Modbus ASCII Support
Hi. I hope this is the right place for this type of question.

I had a need to communicate with an older device that only talks Modbus ASCII. I tried the other Python Modbus libraries that support Modbus ASCII, but couldn't get any of them working correctly. MinimalModbus looked perfect, except for its lack of support for the ASCII flavor of Modbus.  So a modified version 0.4.1 of MinimalModbus to add support for Modbus ASCII.  My use case is limited (I'm just reading holding registers), but I do have it working. I've also added an option to flush the input buffer prior to each call to better handle garbage on the serial line.

I would like to make this code available for inclusion in the official MinimalModbus distribution, but I'm unsure of how to go about doing that. Would anybody like this code and how do I go about making it available?  Thanks.

Michael Penza


_______________________________________________________________
Annons: Hitta k?rleken p? M?tesplatsen.se ? Bli medlem Gratis nu<http://adserver.adtech.de/?adlink|3.0|1297|4819575|1|16|AdId=9776362;BnId=1;link=http://rms.admeta.com/public/transfer.asp?sitebanner_id=4723912>


_______________________________________________________________
Annons: Hitta k?rleken p? M?tesplatsen.se ? Bli medlem Gratis nu<http://adserver.adtech.de/?adlink|3.0|1297|4819575|1|16|AdId=9776362;BnId=1;link=http://rms.admeta.com/public/transfer.asp?sitebanner_id=4723912>

Re: [Minimalmodbus-list] Catching CRC-error with read_registers

[Jonas B. <jon...@ho...>]

Hi again Olav!

In order to see the error, use:


try:  
    result = modbus_slave.read_registers(0,60,3) 
except Exception as err: 
    print err

and then the timestamp code etc.

I need to see the error message and debug print-outs to be able to
locate the problem.

Best regards
Jons




<-----Ursprungligt Meddelande----->

 	 	From: Olav Viken [ola...@gm...]
Sent: 4/1/2014 4:15:06 PM
To: jon...@ho...
Subject: Re: [Minimalmodbus-list] Catching CRC-error with read_registers
Hi

I have already enabled debug mode.

Here is my code:

------------------------------------------------------------------------
---------------------------

import minimalmodbus
import time
import datetime

def getTimeStamp():
    dt = datetime.datetime.now()
    return dt.strftime("%Y.%m.%d %H:%M:%S:") + str(dt.microsecond)


modbus_slave = minimalmodbus.Instrument('com1', 1) 
modbus_slave.debug = True
modbus_slave.serial.baudrate = 19200
modbus_slave.serial.timeout = 1

print 'Port:'                   ,modbus_slave.serial.port
print 'Baudrate:'               ,modbus_slave.serial.baudrate
print 'Databits:'               ,modbus_slave.serial.bytesize
print 'Parity:'                 ,modbus_slave.serial.parity
print 'Stopbit:'                ,modbus_slave.serial.stopbits
print 'Timeout'                 ,modbus_slave.serial.timeout
print 'InterCharacter Timout'   ,modbus_slave.serial.interCharTimeout

errors = 0

while True:
    time.sleep(2)

    try:
        result = modbus_slave.read_registers(0,60,3)
    except:
        errors += 1
        print '\n\n'
        print getTimeStamp(),'Error reading modbus_slave'
        print 'Total errors: ', errors
        print '\n\n'

------------------------------------------------------------------------
-----------------------------------------------

I have used different tools to track this problem, and I'm pretty sure
the problem occurs when the message is sent with a "gap" in the date
resulting in two messages containing invalid data,
In my case I may be able to communicate with the device for 2-3 days
before one or more failures occurs.


When I use minimal modbus - I can not see what data I received - only
that something went wrong.  

Best regards Olav




2014/1/4 Jonas Berg < jon...@ho... <mailto:jon...@ho...>
>


	Hi Olav!
	I suggest that you enable the MinimalModbus debug mode, and
paste the output  in a mail to this list. Then it is easy to see what is
actually sent and received. See
http://minimalmodbus.sourceforge.net/index.html#debug-mode
	
	Please work your way through the example given, so you
understand the details.
	
	Best regards
	Jonas
	

	<-----Ursprungligt Meddelande----->
	
 	 	From: Olav Viken [ ola...@gm...
<mailto:ola...@gm...> ]
Sent: 3/1/2014 9:14:18 AM
To: min...@li...
<mailto:min...@li...> 
Subject: [Minimalmodbus-list] Catching CRC-error with read_registers 



Hi

I'm trying to use minimalmodbus to debug a problem we have with a
modbus-instrument (over a serial line). This instrument (the slave) 
seems to (in some cases) send the response with a "gap" (inter
character).  
The result is that this response is treated as two messages. 

In my code I use the following command:

try:
    response = slave.read_registers(0,114,3)

I need to catch what kind of error occurs ( CRC-error) and the complete
payload.



Is this possible?


Best regards Olav

	

	_______________________________________________________________
	Annons: Hitta kärleken på Mötesplatsen.se - Bli medlem Gratis nu
<http://adserver.adtech.de/?adlink%7C3.0%7C1297%7C4819575%7C1%7C16%7CAdI
d=9776362;BnId=1;link=http://rms.admeta.com/public/transfer.asp?sitebann
er_id=4723912> 

	




<P><p><font face="Arial, Helvetica, sans-serif" size="2" style="font-size:13.5px">_______________________________________________________________<BR>Annons: <a href="http://adserver.adtech.de/?adlink|3.0|1297|4819575|1|16|AdId—76362;BnId=1;link=http://rms.admeta.com/public/transfer.asp?sitebanner_idG23912" target="_blank">Hitta kärleken på Mötesplatsen.se – Bli medlem Gratis nu</a></font>

Re: [Minimalmodbus-list] Modbus ASCII Support

[Jonas B. <jon...@ho...>]

Hi again Mike,
you are of course completely right!
I am very  impressed by your work! Of course it will go into
MinimalModbus. 


A new version of MinimalModbus will be released during the spring. I
plan to write some unit tests also for the ASCII parts of it.
As I do not have access to any Modbus ASCII hardware, it would be great
if you could help with some tests. I guess it will take a few weeks
before it is ready.

Best regards
Jonas

<-----Ursprungligt Meddelande----->

 	 	From: Michael Penza [mp...@pe...]
Sent: 4/1/2014 3:38:15 PM
To: jon...@ho...
Cc: min...@li...
Subject: RE: [Minimalmodbus-list] Modbus ASCII Support 



Jonas,

 

Modbus RTU and Modbus ASCII are very similar, so a found it pretty easy
to adapt the library to support both.  ASCII adds a start and end
character and uses and LRC instead of CRC, but otherwise the message is
a direct ASCII representation of the hexadecimal data in the RTU
message.

 

I've attached the modified version of your library that supports both
RTU and ASCII.  I've been using this successfully for about a month now.
If you would like to incorporate my changes into your library, that
would be great.  If you still think it would be better as a separate
library that, let me know and I'll look turning it into its own library.

 

Thanks.

 

Mike

 

From: Jonas Berg [mailto:jon...@ho...] 
Sent: Saturday, January 4, 2014 8:17 AM
To: Michael Penza
Cc: min...@li...
Subject: Re: [Minimalmodbus-list] Modbus ASCII Support

 

Hi Michael!
Thanks for your input, and sorry for my late reply.

I think it would be quite a substantial amount of work to adapt
MinimalModbus to ASCII, and I would really like to keep it minimal. If
you can suggest the changes needed to be done in order to support ASCII
to the same amount of functionality as there is for Modbus RTU right
now, it can be considered. 

If you would like to make a python Modbus ASCII library, you can start
off by the MinimalModbus code and make adaptions. I will help you in all
ways possible. There are lots of developer info on this page:
http://minimalmodbus.sourceforge.net/develop.html
So I guess a separate Python library with ASCII Modbus would be easier
to maintain than a single one for both (unless you have some good
suggestions).

Please let me know what you think.
Best regards
Jonas





<-----Ursprungligt Meddelande----->

 

 

From: Michael Penza [mp...@pe...]
Sent: 15/11/2013 7:12:58 PM
To: min...@li...
<mailto:min...@li...> 
Subject: [Minimalmodbus-list] Modbus ASCII Support 

Hi. I hope this is the right place for this type of question. 

 

I had a need to communicate with an older device that only talks Modbus
ASCII. I tried the other Python Modbus libraries that support Modbus
ASCII, but couldn't get any of them working correctly. MinimalModbus
looked perfect, except for its lack of support for the ASCII flavor of
Modbus.  So a modified version 0.4.1 of MinimalModbus to add support for
Modbus ASCII.  My use case is limited (I'm just reading holding
registers), but I do have it working. I've also added an option to flush
the input buffer prior to each call to better handle garbage on the
serial line.

 

I would like to make this code available for inclusion in the official
MinimalModbus distribution, but I'm unsure of how to go about doing
that. Would anybody like this code and how do I go about making it
available?  Thanks.

 

Michael Penza

_______________________________________________________________
Annons: Hitta k?rleken p? M?tesplatsen.se ? Bli medlem Gratis nu
<http://adserver.adtech.de/?adlink|3.0|1297|4819575|1|16|AdId=9776362;Bn
Id=1;link=http://rms.admeta.com/public/transfer.asp?sitebanner_id=472391
2> 



<P><p><font face="Arial, Helvetica, sans-serif" size="2" style="font-size:13.5px">_______________________________________________________________<BR>Annons: <a href="http://adserver.adtech.de/?adlink|3.0|1297|4819575|1|16|AdId=9776362;BnId=1;link=http://rms.admeta.com/public/transfer.asp?sitebanner_id=4723912" target="_blank">Hitta kärleken på Mötesplatsen.se – Bli medlem Gratis nu</a></font>

Re: [Minimalmodbus-list] Modbus ASCII Support

[Jonas B. <jon...@ho...>]

Hi Michael!
Thanks for your input, and sorry for my late reply.

I think it would be quite a substantial amount of work to adapt
MinimalModbus to ASCII, and I would really like to keep it minimal. If
you can suggest the changes needed to be done in order to support ASCII
to the same amount of functionality as there is for Modbus RTU right
now, it can be considered. 

If you would like to make a python Modbus ASCII library, you can start
off by the MinimalModbus code and make adaptions. I will help you in all
ways possible. There are lots of developer info on this page:
http://minimalmodbus.sourceforge.net/develop.html
So I guess a separate Python library with ASCII Modbus would be easier
to maintain than a single one for both (unless you have some good
suggestions).

Please let me know what you think.
Best regards
Jonas





<-----Ursprungligt Meddelande----->

 	 	From: Michael Penza [mp...@pe...]
Sent: 15/11/2013 7:12:58 PM
To: min...@li...
Subject: [Minimalmodbus-list] Modbus ASCII Support 


Hi. I hope this is the right place for this type of question. 

I had a need to communicate with an older device that only talks Modbus
ASCII. I tried the other Python Modbus libraries that support Modbus
ASCII, but couldn't get any of them working correctly. MinimalModbus
looked perfect, except for its lack of support for the ASCII flavor of
Modbus.  So a modified version 0.4.1 of MinimalModbus to add support for
Modbus ASCII.  My use case is limited (I'm just reading holding
registers), but I do have it working. I've also added an option to flush
the input buffer prior to each call to better handle garbage on the
serial line.

I would like to make this code available for inclusion in the official
MinimalModbus distribution, but I'm unsure of how to go about doing
that. Would anybody like this code and how do I go about making it
available?  Thanks.

Michael Penza


<P><p><font face="Arial, Helvetica, sans-serif" size="2" style="font-size:13.5px">_______________________________________________________________<BR>Annons: <a href="http://adserver.adtech.de/?adlink|3.0|1297|4819575|1|16|AdId=9776362;BnId=1;link=http://rms.admeta.com/public/transfer.asp?sitebanner_id=4723912" target="_blank">Hitta kärleken på Mötesplatsen.se – Bli medlem Gratis nu</a></font>

Re: [Minimalmodbus-list] half duplex on pi - hook before read/writes

[Jonas B. <jon...@ho...>]

Hi Mouse,
yes RS485 can be somewhat problematic.
It would be much better if the serial driver in the Pi could take care
of this, but unfortunately that is not implemented for all architectures
in Linux. Please see the text on RS485 below that will later on go into
the documentation of MinimalModbus.

If it not can be avoided, we can include a hook in the MinimalModbus to
control a GPIO pin from userspace. I suggest a callback to be registered
with the Instrument object.
Something like:

instrument.on_sender_activate = your_function_to_set_the_GPIO_pin_high
instrument.on_sender_deactivate = your_function_to_set_the_GPIO_pin_low

Please suggest better name for the callbacks. I think they should at
least start with "on_".

The changes should be made in this function:
http://minimalmodbus.sourceforge.net/_modules/minimalmodbus.html#Instrum
ent._communicate

Note that the _communicate function is undergoing changes to increase
the read speed. See:
http://sourceforge.net/p/minimalmodbus/code/HEAD/tree/trunk/minimalmodbu
s.py at line 739.

The structure of _communicate function will probably change as well, so
you do not have to consider the changes too much. But I guess that the
number of bytes to read should be passed to self.serial.read in order to
avoid waiting for timeout.

Also the flush() function of pySerial probably needs to be called, in
order to wait for the data to be sent out of the serial buffer before
changing back the GPIO pin state.

It would be great if you can give it a try with the callbacks. See for
example how callbacks are used in the Mosquitto library:
http://mosquitto.org/documentation/python/

Best regards
Jonas



Text on RS485:

RS485 introduction
###################
Several nodes (instruments) can be connected to one RS485 bus. The bus
consists of two lines, A and B, carrying differential voltages. In both
ends of the bus, a 120 Ohm termination resistor is connected between
line A and B. Most often a common ground line is connected between the
nodes as well.

At idle, both line A and B rest at the same voltage (or almost the same
voltage). When a logic 1 is transmitted, line A is pulled towards lower
voltage and line B is pulled towards higher voltage. Note that the A/B
nameing is sometimes mixed up by some manufacturers.

Each node uses a transceiver chip, containing a sender and a receiver.
Only one sender can be active on the bus simultaneously. 

Pins on the bus side of the transceiver chip:
* A: inverting line
* B: non-inverting line
* GND

Pins on the microcontroller side of the transceiver chip:
* TX: Data to be transmitted
* TXENABLE: For enabling/disabling the sender
* RX: Received data
* RXENABLE: For enabling/disabling the receiver

If the receiver is enabled simultaneusly with the transmitter, the sent
data is echoed back to the microcontroller. This echo functionality is
sometimes useful, but most often the TXENABLE and RXENABLE pins are
connected in such a way that the receiver is disabled when the
transmitter is active.

For detailed information, see http://en.wikipedia.org/wiki/RS-485.

Controlling the RS485 sender
############################
Controlling the TXENABLE pin on the transceiver chip is the tricky part
when it comes to RS485 communication. There are some options:

Using a USB-to-serial conversion chip that is capable of setting the
TXENABLE pin properly. See for example the FTDI chip FT232RL
http://www.ftdichip.com/Products/ICs/FT232R.htm, which has a separate
output for this purpose (TXDEN in their terminology). The Sparkfun
breakout board BOB-09822 https://www.sparkfun.com/products/9822 combines
this FTDI chip with a RS485 transceiver chip. The TXDEN output from the
FTDI chip is high (+5 V) when the transceiver is to be activated. The
FTDI chip calculates when the sender should be activated, so you do not
have to do anything in your application software.

Using a RS232-to-RS485 converter capable of figuring out this by it
self. This typically requires a microcontroller in the converter, and
that you configure the baud rate, stop bits etc. This is a
straight-forward and easy to use alternative, as you can use it together
with a standard USB-to-RS232 cable and nothing needs to be done in your
application software. One example of this type of converter is Westermo
MDW-45 http://www.westermo.com, which I have been using with great
success.

Using a converter where the TXENABLE pin is controlled by the TX pin,
sometimes via some timer circuit. I am not conviced that this is a good
idea.

Controlling a separate GPIO pin from kernelspace software on embedded
Linux machines. See for example
http://blog.savoirfairelinux.com/en/2013/rs-485-for-beaglebone-a-quick-p
eek-at-the-omap-uart/ This is a very elegant solution, as the TXENABLE
pin is controlled by the kernel driver and you don't have to worry about
it in your application program.

Controlling a separate GPIO pin from userspace software on embedded
Linux machines. This could also be useful, but I guess that the time
delay could be unacceptably large.

Controlling the RTS pin in the RS232 interface, and connecting it to the
TXENABLE pin of the transceiver. This can be done from userspace, but
will then lead to large time delays. I have tested this with a 3.3V FTDI
USB-to-serial cable using pySerial on a Linux laptop. The cable has a
RTS output, but no TXDEN output. Note that the RTS output is +3.3 V at
idle, and 0 V when RTS is set to True. The delay time is around 1 ms, as
measured with an oscilloscope. This corresponds to approx 100 bit times
when running at 115200 bps, but this value also includes delays caused
by the Python intepreter.
  


<-----Ursprungligt Meddelande----->

 	 	From: Matthew Gates [mat...@gm...]
Sent: 3/1/2014 5:25:01 PM
To: min...@li...
Subject: [Minimalmodbus-list] half duplex on pi - hook before
read/writes 

Hi, 

I'm new to minimalmodbus. I have a setup where my Raspberry Pi talks 
to an arduino with modbus. With a direct serial connection it works 
well - I found it very easy to get going, so thanks for your work. 

I'd like to put RS-485 in my serial connection, but the hardware I 
have is half duplex. This means I need to set a pin high when the Pi 
transmits. and then low before I read from the serial bus. 

Is there any hook in the minimalmodbus code I can use to call my own 
function before read and write? I started looking in the code and I 
don't see one, but I might be missing something (I'm fairly new to 
Python too, so maybe there's a pythonesque way to do it I don't know 
about). 

Assuming there's not a feature to do this already, I can have a go at 
adding one - would you be interested in a patch? 

Regards, 
Mouse 

------------------------------------------------------------------------
------ 
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into
your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics Pro! 
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk
trk 
_______________________________________________ 
Minimalmodbus-list mailing list 
Min...@li... 
https://lists.sourceforge.net/lists/listinfo/minimalmodbus-list 
. 
	


<P><p><font face="Arial, Helvetica, sans-serif" size="2" style="font-size:13.5px">_______________________________________________________________<BR>Annons: <a href="http://adserver.adtech.de/?adlink|3.0|1297|4819575|1|16|AdId=9776362;BnId=1;link=http://rms.admeta.com/public/transfer.asp?sitebanner_id=4723912" target="_blank">Hitta kärleken på Mötesplatsen.se – Bli medlem Gratis nu</a></font>

Re: [Minimalmodbus-list] Catching CRC-error with read_registers

[Jonas B. <jon...@ho...>]

Hi Olav!
I suggest that you enable the MinimalModbus debug mode, and paste the
output  in a mail to this list. Then it is easy to see what is actually
sent and received. See
http://minimalmodbus.sourceforge.net/index.html#debug-mode

Please work your way through the example given, so you understand the
details.

Best regards
Jonas


<-----Ursprungligt Meddelande----->

 	 	From: Olav Viken [ola...@gm...]
Sent: 3/1/2014 9:14:18 AM
To: min...@li...
Subject: [Minimalmodbus-list] Catching CRC-error with read_registers 


Hi

I'm trying to use minimalmodbus to debug a problem we have with a
modbus-instrument (over a serial line). This instrument (the slave) 
seems to (in some cases) send the response with a "gap" (inter
character).  
The result is that this response is treated as two messages. 

In my code I use the following command:

try:
    response = slave.read_registers(0,114,3)

I need to catch what kind of error occurs ( CRC-error) and the complete
payload.



Is this possible?


Best regards Olav


<P><p><font face="Arial, Helvetica, sans-serif" size="2" style="font-size:13.5px">_______________________________________________________________<BR>Annons: <a href="http://adserver.adtech.de/?adlink|3.0|1297|4819575|1|16|AdId=9776362;BnId=1;link=http://rms.admeta.com/public/transfer.asp?sitebanner_id=4723912" target="_blank">Hitta kärleken på Mötesplatsen.se – Bli medlem Gratis nu</a></font>

Re: [Minimalmodbus-list] 32-bit floats

[Jonas B. <jon...@ho...>]

Hi,
you are right that there is some work involved to adapt MinimalModbus to
another byte order for floats. But here is a workaround for you to read
the floats, at least.

This is your data:

MinimalModbus debug mode. Writing to instrument:
'\x02\x03\x0fT\x00\x02\x86\xfc'
 
 \x02 Slave address (here 2)
 \x03 Function code (here 3 = read registers)
 \x0f Start address MSB. Here 15.
 T    Start address LSB. Here ASCII letter T = 84 (dec) = 54 (hex).
 \x00 Number of registers MSB (here 0)
 \x02 Number of registers LSB (here 2)
 \x86 CRC LSB
 \xfc CRC MSB
 
15*256 + 84 = 3924
You are reading two registers (starting with register 3924) from slave
number 2. 
See http://minimalmodbus.sourceforge.net/index.html#example 
   
MinimalModbus debug mode. Response from instrument:
'\x02\x03\x04\x93\x9dCPD\x95'

\x02 Slave address (here 2)
\x03 Function code (here 3 = read registers)
\x04 Byte count (here 4 bytes)
\x93 Payload. Here 93 (hex) = 147 (dec)
\x9d Payload. Here 9d (hex) = 157 (dec)
C    Payload. Here ASCII letter C = 43 (hex) = 67 (dec).
P    Payload. Here ASCII letter P = 50 (hex) = 80 (dec).
D    CRC LSB
\x95 CRC MSB

So the payload is \x93\x9dCP, which is 4 bytes (as each register stores
2 bytes)

You should try this in interactive mode in Python, and to manually
re-shuffle the bytes:

~$ python
Python 2.7.3 (default, Sep 26 2013, 20:08:41) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import minimalmodbus
>>> 
>>> minimalmodbus._bytestringToFloat("\x93\x9dCP")
-3.9698747127906995e-27
>>> 
>>> minimalmodbus._bytestringToFloat("CP\x93\x9d")
208.5766143798828
>>> 

Suggested work-around:
Read the register values directly using the read_registers function.
Then reshuffle the bytes, and convert it to a float using the internal
function _bytestringToFloat. Something like:

values = read_registers(3924, numberOfRegisters=2)
registerstring = chr(values[2]) + chr(values[3]) + chr(values[0]) +
chr(values[1])
floatvalue = minimalmodbus._bytestringToFloat(registerstring)

See
http://minimalmodbus.sourceforge.net/apiminimalmodbus.html#minimalmodbus
.Instrument.read_registers
and
http://minimalmodbus.sourceforge.net/_modules/minimalmodbus.html#_bytest
ringToFloat

Give it a try, and I will help you with the details.


Hope this helps
/Jonas


<-----Ursprungligt Meddelande----->

 	 	From: Glendale2x [gle...@gm...]
Sent: 28/12/2013 9:33:21 PM
To: min...@li...
Subject: [Minimalmodbus-list] 32-bit floats 


So I'm trying to use minimalmodbus in place of a similar, but not as
fully featured Perl modbus moudle. I'm having a problem with 32-bit
floats returned by a power meter.

These are registers for voltage (A-B, B-C, A-C) and line frequency,
obviously all very wrong:

MinimalModbus debug mode. Writing to instrument:
'\x02\x03\x0fT\x00\x02\x86\xfc'
MinimalModbus debug mode. Response from instrument:
'\x02\x03\x04\x93\x9dCPD\x95'
-3.96987471279e-27
MinimalModbus debug mode. Writing to instrument:
'\x02\x03\x0fb\x00\x02f\xf2'
MinimalModbus debug mode. Response from instrument:
'\x02\x03\x04Z\xfeCP\x8b\x17'
3.57843274805e+16
MinimalModbus debug mode. Writing to instrument:
'\x02\x03\x0fp\x00\x02\xc6\xf7'
MinimalModbus debug mode. Response from instrument:
'\x02\x03\x04\x93fCP5d'
-2.90632689369e-27
MinimalModbus debug mode. Writing to instrument:
'\x02\x03\x0fJ\x00\x02\xe6\xfa'
MinimalModbus debug mode. Response from instrument:
'\x02\x03\x04\x0b\xa4Bp\xbb\xb0'
6.32704662155e-32

The first three should be 208 volts nominal and the last one should be
60 Hz nominal. The documentation says "It is pretty straight-forward" to
fix this, which may be true if one is familiar with python, but I've
never programmed in python before and my hacking at it for the last two
days hasn't produced any values close to the expected ones.

I'm just doing "datapoint = instrument.read_float(3924)" to get the
above values.

So what's the trivial way to fix this in python?


<P><p><font face="Arial, Helvetica, sans-serif" size="2" style="font-size:13.5px">_______________________________________________________________<BR>Annons: <a href="http://adserver.adtech.de/?adlink|3.0|1297|4819575|1|16|AdId=9776362;BnId=1;link=http://rms.admeta.com/public/transfer.asp?sitebanner_id=4723912" target="_blank">Hitta kärleken på Mötesplatsen.se – Bli medlem Gratis nu</a></font>

[Minimalmodbus-list] half duplex on pi - hook before read/writes

[Matthew G. <mat...@gm...>]

Hi,

I'm new to minimalmodbus.  I have a setup where my Raspberry Pi talks
to an arduino with modbus.  With a direct serial connection it works
well - I found it very easy to get going, so thanks for your work.

I'd like to put RS-485 in my serial connection, but the hardware I
have is half duplex.  This means I need to set a pin high when the Pi
transmits. and then low before I read from the serial bus.

Is there any hook in the minimalmodbus code I can use to call my own
function before read and write?  I started looking in the code and I
don't see one, but I might be missing something (I'm fairly new to
Python too, so maybe there's a pythonesque way to do it I don't know
about).

Assuming there's not a feature to do this already, I can have a go at
adding one - would you be interested in a patch?

Regards,
Mouse

[Minimalmodbus-list] Catching CRC-error with read_registers

[Olav V. <ola...@gm...>]

Hi

I'm trying to use minimalmodbus to debug a problem we have with a
modbus-instrument (over a serial line). This instrument (the slave)
seems to (in some cases) send the response with a "gap" (inter character).
The result is that this response is treated as two messages.

In my code I use the following command:

try:
    response = slave.read_registers(0,114,3)

I need to catch what kind of error occurs ( CRC-error) and the complete
payload.



Is this possible?


Best regards Olav

[Minimalmodbus-list] 32-bit floats

[Glendale2x <gle...@gm...>]

So I'm trying to use minimalmodbus in place of a similar, but not as fully
featured Perl modbus moudle. I'm having a problem with 32-bit floats
returned by a power meter.

These are registers for voltage (A-B, B-C, A-C) and line frequency,
obviously all very wrong:

MinimalModbus debug mode. Writing to instrument:
'\x02\x03\x0fT\x00\x02\x86\xfc'
MinimalModbus debug mode. Response from instrument:
'\x02\x03\x04\x93\x9dCPD\x95'
-3.96987471279e-27
MinimalModbus debug mode. Writing to instrument:
'\x02\x03\x0fb\x00\x02f\xf2'
MinimalModbus debug mode. Response from instrument:
'\x02\x03\x04Z\xfeCP\x8b\x17'
3.57843274805e+16
MinimalModbus debug mode. Writing to instrument:
'\x02\x03\x0fp\x00\x02\xc6\xf7'
MinimalModbus debug mode. Response from instrument: '\x02\x03\x04\x93fCP5d'
-2.90632689369e-27
MinimalModbus debug mode. Writing to instrument:
'\x02\x03\x0fJ\x00\x02\xe6\xfa'
MinimalModbus debug mode. Response from instrument:
'\x02\x03\x04\x0b\xa4Bp\xbb\xb0'
6.32704662155e-32

The first three should be 208 volts nominal and the last one should be 60
Hz nominal. The documentation says "It is pretty straight-forward" to fix
this, which may be true if one is familiar with python, but I've never
programmed in python before and my hacking at it for the last two days
hasn't produced any values close to the expected ones.

I'm just doing "datapoint = instrument.read_float(3924)" to get the above
values.

So what's the trivial way to fix this in python?

Re: [Minimalmodbus-list] MinimalModbus - read_register()

[Jonas B. <jon...@ho...>]

Best Rob!

> '5 parameters only 4 allowed',
This seems that you give the read_register() too many parameters.

Please paste appropriate parts of your code as well as the full error
output, and I will try helping you.

Best regards
Jonas




<-----Ursprungligt Meddelande----->

 	 	From: go exitus [ro...@ex...]
Sent: 26/11/2013 1:35:31 AM
To: min...@li...
Subject: [Minimalmodbus-list] MinimalModbus - read_register() 


Hello,
I have a DDS353 electricity meter which uses RTU - 9600,8,1,1,None;
address 1; regs 40001,40002,40003; function 3.   The hardware works with
another test programme but no luck with linux python no matter what
parameters are sent with "read_register(..)" ?
 
error results either '5 parameters only 4 allowed', and 'no answer' .
 
also failed to figure out " numberOfDecimals=numberOfDecimals"
 
do you have any ideas ?
 
thanks
rob davies
 
 
## Diagnostic output from minimalmodbus ##
 
Minimalmodbus version: 0.3.2
Minimalmodbus status: Alpha
Revision: $Rev: 130 $
Revision date: $Date: 2012-01-25 21:22:28 +0100 (Wed, 25 Jan 2012) $
File name (with relative path):
/usr/local/lib/python3.2/dist-packages/minimalmo
dbus.py
Full file path: /usr/local/lib/python3.2/dist-packages/minimalmodbus.py
 
pySerial version: 2.5
pySerial full file path:
/usr/lib/python3/dist-packages/serial/__init__.py
 
Platform: linux2
Python version: 3.2.3 (default, Mar  1 2013, 11:53:50)
[GCC 4.6.3]
Python flags: sys.flags(debug=0, division_warning=0, inspect=0,
interactive=0, o                            ptimize=0,
dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=
0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=0)
Variable __name__: minimalmodbus
Current directory: /home/pi
 
Python path:
/home/pi
/usr/lib/python3.2
/usr/lib/python3.2/plat-linux2
/usr/lib/python3.2/lib-dynload
/usr/local/lib/python3.2/dist-packages
/usr/lib/python3/dist-packages
 
## End of diagnostic output ##
 
 


<P><p><font face="Arial, Helvetica, sans-serif" size="2" style="font-size:13.5px">_______________________________________________________________<BR>Annons: <a href="http://adserver.adtech.de/?adlink|3.0|1297|4819575|1|16|AdId=9776362;BnId=1;link=http://rms.admeta.com/public/transfer.asp?sitebanner_id=4723912" target="_blank">Hitta kärleken på Mötesplatsen.se – Bli medlem Gratis nu</a></font>

Re: [Minimalmodbus-list] RS-485 2-wire and 4-wire strange issue

[Jonas B. <jon...@ho...>]

Best Luca!
This is probably local echo in the RS-485 adapter. 

See the section 'local echo' in the not-yet released documentation:
http://sourceforge.net/p/minimalmodbus/code/HEAD/tree/trunk/README.txt

Best regards
Jonas




<-----Ursprungligt Meddelande----->

 	 	From: Luca Lenardi [luc...@at...]
Sent: 29/11/2013 8:19:48 PM
To: min...@li...
Subject: [Minimalmodbus-list] RS-485 2-wire and 4-wire strange issue 


Hello and thanks for the great work done with minimalmodbus.

First of all let me say that I'm new to the RS-485 interface and Modbus,
and I just want to report a strange issue that we are experiencing with
the following configuration:

a) we have a master host PC with Ubuntu 12.04 and Python 2.7.5
b) minimal modbus v0.4
c) interacting with a modbus RTU device over RS-485 (2-wire) (24 DI
module)
d) using an RS-232 to RS-485 converter (
http://www.aten.com/products/Data-Communication/Industry-Controls/RS-232
RS-485-Interface-Converter~IC485SI.html)

Basically the problem is that every request we made, is answered from
the device as expected, but with the full request appended to it on top.

This is the outline of the process:
a) master sends the request;
b) the device behave as expected (Rx/Tx LEDs blink), processes the CRC,
creates the response calculating the correct CRC;
c) the master receives the response, but with the request repeated on
top and obviously it fails because the CRC doesn't match.

This is the I/O from minimal modbus:
ipdb>  instrument.read_register(1, 0, functioncode=3)
MinimalModbus debug mode. Writing to instrument:
'\x01\x03\x00\x01\x00\x01\xd5\xca'
MinimalModbus debug mode. Response from instrument:
'\x01\x03\x00\x01\x00\x01\xd5\xca\x01\x03\x02\x08\xac\xbf\xf9'
*** ValueError: CRC error: 49145 ('\xbf\xf9') instead of 39929
('\x9b\xf9'). The response is:
'\x01\x03\x00\x01\x00\x01\xd5\xca\x01\x03\x02\x08\xac\xbf\xf9'


As you can see the request is repeated before the response as part of
it.

To me this seems related to the RS-232/485 converter, and the only
noticeable thing regarding that device is that it is a 4-wire RS-485
converter. The compatibility with 2-wire devices seems to be guaranteed
(at least standing at what the producer said) by connecting together the
pins as follow:

Tx + and Rx + -> Data + 
Tx - and Rx - -> Data -
Gnd


So, has anybody experienced the same problem? Is it simply something
hardware related or is it possible to manage this kind of situation in
the software? I've easily modified minimalmodbus to manage this
situation by removing the request from the response (as it happens in a
deterministic manner with this setup), but eventually it could be useful
to have a flags to manage the 4-wire configuration.

Thanks!

--
Luca Lenardi
Atrasoftware - Atra S.r.l.
www.atrasoftware.it <http://www.atrasoftware.it> 
PGP keyID: 11FDF475






<P><p><font face="Arial, Helvetica, sans-serif" size="2" style="font-size:13.5px">_______________________________________________________________<BR>Annons: <a href="http://adserver.adtech.de/?adlink|3.0|1297|4819575|1|16|AdId=9776362;BnId=1;link=http://rms.admeta.com/public/transfer.asp?sitebanner_id=4723912" target="_blank">Hitta kärleken på Mötesplatsen.se – Bli medlem Gratis nu</a></font>

[Minimalmodbus-list] RS-485 2-wire and 4-wire strange issue

[Luca L. <luc...@at...>]

Hello and thanks for the great work done with minimalmodbus.

First of all let me say that I’m new to the RS-485 interface and Modbus, and I just want to report a strange issue that we are experiencing with the following configuration:

a) we have a master host PC with Ubuntu 12.04 and Python 2.7.5
b) minimal modbus v0.4
c) interacting with a modbus RTU device over RS-485 (2-wire) (24 DI module)
d) using an RS-232 to RS-485 converter (http://www.aten.com/products/Data-Communication/Industry-Controls/RS-232RS-485-Interface-Converter~IC485SI.html)

Basically the problem is that every request we made, is answered from the device as expected, but with the full request appended to it on top.

This is the outline of the process:
a) master sends the request;
b) the device behave as expected (Rx/Tx LEDs blink), processes the CRC, creates the response calculating the correct CRC;
c) the master receives the response, but with the request repeated on top and obviously it fails because the CRC doesn’t match.

This is the I/O from minimal modbus:
ipdb>  instrument.read_register(1, 0, functioncode=3)
MinimalModbus debug mode. Writing to instrument: '\x01\x03\x00\x01\x00\x01\xd5\xca'
MinimalModbus debug mode. Response from instrument: '\x01\x03\x00\x01\x00\x01\xd5\xca\x01\x03\x02\x08\xac\xbf\xf9'
*** ValueError: CRC error: 49145 ('\xbf\xf9') instead of 39929 ('\x9b\xf9'). The response is:
'\x01\x03\x00\x01\x00\x01\xd5\xca\x01\x03\x02\x08\xac\xbf\xf9'

As you can see the request is repeated before the response as part of it.

To me this seems related to the RS-232/485 converter, and the only noticeable thing regarding that device is that it is a 4-wire RS-485 converter. The compatibility with 2-wire devices seems to be guaranteed (at least standing at what the producer said) by connecting together the pins as follow:

Tx + and Rx + -> Data + 
Tx - and Rx - -> Data -
Gnd

So, has anybody experienced the same problem? Is it simply something hardware related or is it possible to manage this kind of situation in the software? I’ve easily modified minimalmodbus to manage this situation by removing the request from the response (as it happens in a deterministic manner with this setup), but eventually it could be useful to have a flags to manage the 4-wire configuration.

Thanks!

--
Luca Lenardi
Atrasoftware — Atra S.r.l.
www.atrasoftware.it
PGP keyID: 11FDF475

[Minimalmodbus-list] RS-485 2-wire and 4-wire strange issue

[Luca L. <luc...@at...>]

Hello and thanks for the great work done with minimalmodbus.

First of all let me say that I’m new to the RS-485 interface and Modbus, and I just want to report a strange issue that we are experiencing with the following configuration:

a) we have a master host PC with Ubuntu 12.04 and Python 2.7.5
b) minimal modbus v0.4
c) interacting with a modbus RTU device over RS-485 (2-wire) (24 DI module)
d) using an RS-232 to RS-485 converter (http://www.aten.com/products/Data-Communication/Industry-Controls/RS-232RS-485-Interface-Converter~IC485SI.html)

Basically the problem is that every request we made, is answered from the device as expected, but with the full request appended to it on top.

This is the outline of the process:
a) master sends the request;
b) the device behave as expected (Rx/Tx LEDs blink), processes the CRC, creates the response calculating the correct CRC;
c) the master receives the response, but with the request repeated on top and obviously it fails because the CRC doesn’t match.

This is the I/O from minimal modbus:
ipdb>  instrument.read_register(1, 0, functioncode=3)
MinimalModbus debug mode. Writing to instrument: '\x01\x03\x00\x01\x00\x01\xd5\xca'
MinimalModbus debug mode. Response from instrument: '\x01\x03\x00\x01\x00\x01\xd5\xca\x01\x03\x02\x08\xac\xbf\xf9'
*** ValueError: CRC error: 49145 ('\xbf\xf9') instead of 39929 ('\x9b\xf9'). The response is:
'\x01\x03\x00\x01\x00\x01\xd5\xca\x01\x03\x02\x08\xac\xbf\xf9'

As you can see the request is repeated before the response as part of it.

To me this seems related to the RS-232/485 converter, and the only noticeable thing regarding that device is that it is a 4-wire RS-485 converter. The compatibility with 2-wire devices seems to be guaranteed (at least standing at what the producer said) by connecting together the pins as follow:

Tx + and Rx + -> Data + 
Tx - and Rx - -> Data -
Gnd

So, has anybody experienced the same problem? Is it simply something hardware related or is it possible to manage this kind of situation in the software? I’ve easily modified minimalmodbus to manage this situation by removing the request from the response (as it happens in a deterministic manner with this setup), but eventually it could be useful to have a flags to manage the 4-wire configuration.

Thanks!

--
Luca Lenardi
Atrasoftware — Atra S.r.l.
www.atrasoftware.it
PGP keyID: 11FDF475