I am a beginner in Python (FYI) and trying to communicate with the Gefran 800P programmer/controller using minimal Modbus library (Python + Mac). I am using USB to RS485 Serial Converter Cable (http://www.ftdichip.com/Support/Documents/DataSheets/Cables/DS_USB_RS485_CABLES.pdf) to communicate with the Gefran device. Pins from the rear of the device (15+17 (Rx+Tx) & 16+18 (Gnd+Gnd)) are connected to Data +(A) and Data -(B) of the converter cable, respectively (RS485 - 2wired connection). I don't know the slave address for this device and there is no where mentioned about the address in the manual (http://www.primusthai.com/marketing/Gefran%20800%20(Controller).pdf).
I have tried:
Changing address of the slave form 0 to 247 and I always get the same message.
Tried checking for different register address and played around with function codes (3&4)
Played around with the programmer settings making sure both parameters in the code and the device are the same.
Maybe I am missing something. Looking forward for your help. I am really stuck at this point for more than a week now!
When I run it, it gives me an error "ValueError: Too short Modbus RTU response (minimum length 4 bytes). Response: '\x00' ".
I enabled the local echo setting in the FTDI chip in the converter cable and I got a new error "ValueError: Checksum error in rtu mode: '\x00\xff' instead of '$\x00' . The response is: '\x00\x00\x00\x00\x00\x00\xff' (plain response: '\x00\x00\x00\x00\x00\x00\xff')
but if I run my code again, I get the old error (Too short modbus RTU...) back!
Looking forward for the help!
1) There's a setting, SEr.P in the controller to select either the Modbus RTU protocol or Cencal Gefran protocol.
Are you sure you've selected Modbus RTU?
2) It isn't clear whether those zeros are real traffic or fillers in the program you're using. If you are not getting any response, you might not have a working RS-485 connection. The A/B (+)/(-) lines are labeled differently by different vendors.
Connection should be A to A, B to B or (+) to (+), (-) to (-), but sometimes the labeling is inverted. The fix is to swap the wires at one end and try again to see if the connection is established. Wiring backwards will not damage the 485 drivers, but it will never communicate.
>1)There's a setting, SEr.P in the controller to select either the
>Modbus RTU protocol or Cencal Gefran protocol.
>Are you sure you've selected Modbus RTU?
Yes, first thing I did was that.
>2)t isn't clear whether those zeros are real traffic or fillers in
>the program you're using. If you are not getting any response, you >might not have a working RS-485 connection. The A/B (+)/(-) lines are >labeled differently by different vendors.
I tried all the combinations but nothing works :( I am stuck at this issue for almost two weeks now... I was thinking of trying 'pymodbus' library instead of the minimal Modbus.
Okay. I don't know if its some progress. When I connect the device in the original software (GF_eXpress for Windows only), and then when I run my python code with the same pins (15&17 to + and 16&18 to -) connected to my Mac, I get this error now:
ValueError: Checksum error in rtu mode: '\x00\xff' instead of '\xd6\xda'. The response is: '\x00\xff\xff\xba\xd6\x00\xff' (plain response: '\x00\xff\xff\xba\xd6\x00\xff'). I am not sure what is working, what is not... I am so stuck at this for weeks now :(
Any suggestions please?
1) Going back to your original post, >I don't know the slave address for this device.
The slave address is called CodE in the serial setup section, as shown in the image from the manual:
Slave address should not be zero.
2) For your own peace of mind, you might want to get a generic Window Modbus master program and get it running and communicating with the Gefran slave to prove to yourself that it does indeed talk Modbus RTU when polled.
Here's a link to a freebie:
I don't keep track what Modbus software is Mac compatible, so if you're not running Windows in a virtual machine, then you might have to borrow a PC. The FTDI USB/485 connverter should work on a PC, FTDI registers with Microsoft.
Thanks David, for all the hints.. I finally managed to get the device communicating using Gefran Cable. I am not 100% sure what really worked, but I tried the following:
1. Install software "modpoll" to poll for the modbus devices to compare the parameters in the GF_eXpress software and the device and to know what is happening in the background.
2. Tried to use pyserial to serially communicate with the device - I think this did the trick, you have to first initialise the port and then communicate. In my case opening a serial port and connecting to the port and then using modbus, worked like magic.
3. I restarted the programmer, my Mac, gave basic parameters baudrate - 9600, parity - none, address - 1 and stop bits - 1 and it started working..
If nothing works, it is always good to restart every single device that you are using and reset the parameters and set it again to basic/standard values.
Glad you got it running. Thanks for the feedback to the forum and your insight.
I agree with your insight about needing to reset devices for them to accept any change you've made. In the PC world, the processing power is so much greater that changes can be accepted on-the-fly, but devices don't have that same functionality.