The background:

I am a student researcher attempting to build a grain monitoring system using the tools provided by Liros Electronic in their Grain Watch System (all of the documentation is available here: http://www.grain-watch.com/downloads.html), but without using their software, as the eventual goal is to use an Intel Galileo/Arduino as the master.

The materials:

I am using the EasySYNC ES-U-2101-M (http://www.easysync-ltd.com/search.php?phrase=es-u-2101-m) in order to connect to a PC running Modbus Poll as the master. The system uses a network controller (GWAB) and network switch (GWNET) to connect to temperature sensor cables (GWSL). Grain Watch implements Modbus RTU, although they don't meet the protocol requirements exactly due to some hardware limitations: (http://www.grain-watch.com/documents/GWABModbus.pdf).

The problem:

I am able to transmit a message from master to slave, but the response never comes; I always receive a timeout error. The Tx LED in the EasySYNC lights up, and the Rx LED in the GWAB lights up, but Modbus Poll never receives a response from the slave. I can see the hexadecimal message transmitted, but I don't get any information in return. I have tried a variety of address, and I have tried incrementing/decrementing the addresses, but I still receive timeout errors.

I have wired and re-wired the system (I am a computer science student, not an engineer, but I received some help from people with proper training), and there doesn't appear to be a problem in the physical wiring. I have tried reversing cables in order to see if that makes a difference, but nothing changes.

In an attempt to troubleshoot, I have eliminated the GWNET switch from the system and attached the GWSL temperature cable directly to the GWAB controller in the NET1 connection (I have also tried NET3 and NET4, with addresses modified accordingly). I believe, based on the documentation that I should be polling address 40257, so I have entered 256 into the Modbus Poll line, per instructions (although I have tried 40257, 257, 258, etc.). I have also tried requesting anywhere from 1 to 77 registers, with 64 being the number I think I should be requesting. I have set all rotary switches according to the plans (SW1 to 1 and SW2 to 4) and the jumpers and dip switches are also set according to specifications. I am using Slave ID 1, but I have tried everything from 1 to 19 (the allowable addresses in this implementation). I have also adjusted response times in Modbus Poll, and that has no impact. If I try Slave ID 0, I get a response error rather than a timeout error, which I assume is correct, as it this represents a broadcast message, and there should be no response. Is this a correct?

I have contacted the manufacturer, and they have linked me to their documentation and another PLC simulator, but their developer no longer works with them, so there is only so much they can do to help me.

I am hoping that maybe someone here has familiarity with either the Grain Watch System itself or something similar or with the EasySYNC connector. I am also hoping that someone can provide me with some possible solutions or at least an idea of what I should be looking at as the culprit. Any suggestions that the community can offer are appreciated. I have been at this for about a week, and my inexperience with both Modbus and the hardware limits my ability to troubleshoot the problem effectively.

Thank you for taking the time to read this long post; I tried to be thorough, but if I missed anything important, please let me know.

 

I've never heard of this device, but here's several observations.

If the USB/RS-485 converter's Tx LED turns on for a poll and the receiver's Rx LED turns on, then Modpoll is likely sending the message and the converter is on the correct COM port.

The lack of any slave response could be

1) incorrect serial settings on the master. The serial comm settings are fixed in the slave controller (GWAB) to:
19200 bits per second
1 startbit
8 databits
1 parity bit - even parity
1 stop bit

You setup the ModPoll comm settings for those exact settings?

2) Wrong slave address. A Modbus slave ignores any message not addressed to itself.

a) Are you sure which node address SW1 or SW2 rotary switch is low order or high order? If backwards, what you think is slave ID 01 is really 10.

b) I don't have the time to study the decryption method for a "Sensor line Address" as described in Appendix B.

Impress the services of your best buddy to go through Appendix B line by line to confirm that you are addressing the correct address for your particular hardware setup (minus the multiplexor switch)

3) Jumpers J1/J2 - terminating resistors

If this is on the bench testing, at 19.2K baud, you are not likely to have a reflection problem. If you're sure that the terminating resistor should be there (last device on the RS-485 network, use the terminating resistor, but if you're not sure, run without termination. It's likely to work on the bench without termination.

4) I noticed a green ground wire on page 11:16 hanging free. On the bench, RS-485 will usually work without a 3rd wire signal ground. It gets dicier in the field where there can be common mode issues. But on occasion, disassembled devices can not find a common ground reference and 485 doesn't work.

If the RS-485 connections have a terminal for signal ground, use it; connect the signal grounds. If not, connect the earth grounds, like that free hanging green earth ground wire on page 11:16.

5) This device has a very long initialization period, well over a minute. You're doing ModPoll testing only after having powered up the device for well over a minute?

 

First of all, David_2, thank you for taking the time to post such a thorough response and for taking the time to look at some of the Grain Watch documentation.

>The lack of any slave response could be
>
>1) incorrect serial settings on the master. The serial comm
>settings are fixed in the slave controller (GWAB) to:
> 19200 bits per second
> 1 startbit
> 8 databits
> 1 parity bit - even parity
> 1 stop bit
>
>You setup the ModPoll comm settings for those exact
>settings?

I am using those exact settings with the exception of the fact that it doesn't allow me to select the number of start bits; I assume that it is set to 1 by default. Is this a reasonable assumption?

>2) Wrong slave address. A Modbus slave ignores any message
>not addressed to itself.
>
> a) Are you sure which node address SW1 or SW2 rotary
>switch is low order or high order? If backwards, what you
>think is slave ID 01 is really 10.

I am not 100% sure of the Slave ID, so I recognize that this is the likely problem. I have, however, tried both 01 and 10, as well as 14 and 41 (just in case), plus the others between 1 and 19, and nothing seems to work. I guess maybe there are a few in the teens that I haven't tried reversing; I will be sure to do so and let you know if that is successful.

> b) I don't have the time to study the decryption method
>for a "Sensor line Address" as described in Appendix B.

I don't blame you! Luckily, it looks like the actual calculation isn't particularly important, as they provide the chart of all the addresses. I have done the calculation anyway, and it matches up with the chart, so I think I am getting this correct, but I will be sure to have someone else go through and check my work.

>3) Jumpers J1/J2 - terminating resistors
>
>If this is on the bench testing, at 19.2K baud, you are not
>likely to have a reflection problem. If you're sure that
>the terminating resistor should be there (last device on the
>RS-485 network, use the terminating resistor, but if you're
>not sure, run without termination. It's likely to work on
>the bench without termination.

This is the only GWAB on the network, so I have set the jumpers accordingly. Should I try without termination anyway?

>4) I noticed a green ground wire on page 11:16 hanging
>free. On the bench, RS-485 will usually work without a 3rd
>wire signal ground. It gets dicier in the field where there
>can be common mode issues. But on occasion, disassembled
>devices can not find a common ground reference and 485
>doesn't work.

>If the RS-485 connections have a terminal for signal ground,
>use it; connect the signal grounds. If not, connect the
>earth grounds, like that free hanging green earth ground
>wire on page 11:16.

The actual unit has a case, and the green ground wire is attached at both ends to the case, as seen here on 2 (10):

http://www.grain-watch.com/documents/C209B00_GWAB_Connection_Instructions_EN.pdf


>5) This device has a very long initialization period, well
>over a minute. You're doing ModPoll testing only after
>having powered up the device for well over a minute?

I am doing so, yes.

At this point I am assuming it is either an incorrect Slave ID, incorrect address or an issue with the GWAB itself. I think the last option is the least likely and that it is probably my own error that is causing the problem. I will go through the addressing again and try some more addresses. I will try to be a little more methodical.

My only other question is: how important is the number of registers I poll? For example, if I have the correct slave ID and starting address and only poll 1 register, will that work, or do I have to poll exactly the correct number of registers?

Thank you again for your thorough response. I appreciate your help, and hopefully I can solve this problem soon.

 

1) > number of start bits; I assume that it is set to 1 by default. Is this a reasonable assumption?

Ans: Correct, always 1 start bit, it is rarely, if ever, settable to anything else.

2) Rotary switches SW1, SW 2
from the manual (with some edits):

SW2 determines which protocol is in use and what address range SW1 covers. Position 4 and 5 is used for the Modbus protocol.
SW1 sets the device address to one of 0 - 9 when SW2 is in position 4 and one of 10 - 19 when SW 2 is in position 5.

SW1 set to 0 and SW2 set to 4 is not valid since it results in the device address 0, which is used for broadcast messages with Modbus.

My interpretation is
SW 2 is position 4 for Modbus which uses the low order 0-9 addresses
SW 1 is position 1 for slave address #1.

The connections instructions, page 7 of 10, has a good photo showing the labels for which switch is switch.
SW1 is closest to the reset switch.

3) Termination - should be OK.

4) RS-485 signal ground. If the USB/485 converter has a signal ground, I'd connect it to the COM terminal on what I think is the RS-485 port, CN6. You are connecting the PC CN6?

5) Do you know if the RS-232 port is a slave port? It might or might not be. If so, have you considered trying a connection to CN2, the RS-232 port?

6) I noticed a reset button on several of the diagrams. Although I didn't read such a statement, it is not uncommon for these types of devices to not recognize a DIP/rotary switch change unless power is cycled or the device goes through a reset cycle. I don't know if it applies to this, but it might be worth trying if you change hardware settings like that. I've been stung by the 'failed to cycle power' with the result that the device was using the same old settings, not the new ones.

7) What is the red LED ERR telling you when you attempt communications?

from the manual:
The red ERR LED indicates operational errors in the GWAB11 itself. It does this with a blink sequence and can show two types of faults:

0 blink: No error. See next page for the status of the NET1 - NET4 LEDs.

1 blink: There is a communication fault between the motherboard (the lower PCB) and the signal interface board (the upper PCB). As long as this fault is indicated, the NET - NET4 LEDs indicate with a constant lit LED in which of the four sensor cable input channels the error occurred. The error could be caused by e.g. a short circuit in the sensor cable inputs. Typically this fault is indicated on all channels at once.

1 blink: There is an error in the RS-485 communication. This could be caused by wrong baud rate, framing, parity, noise, or because the + and - signals for the RS-485 bus is reversed. The NET1 - NET4 LEDs operate as normal when this error is indicated on the ERR LED, see below. This error stops when either a command has been successfully received again or approximately after 60 seconds of no communication.

8) >how important is the number of registers I poll?

I always start by reading one register (non-zero) data register, until I establish communications and confirm that I am addressing the register I think I am (whatever the offset is).

Only then do I go and try multiple register reads. Although this device seems to have lots of data in holding registers, I never want to read an invalid register which might throw an exception.

Too many things to go wrong when one tries too much at once. But that's just my opinion.

 

David_2:

Thanks once again for your response. Here is where I am at:

> 2) My interpretation is
> SW 2 is position 4 for Modbus which uses the low order 0-9 addresses
> SW 1 is position 1 for slave address #1.

This is my interpretation as well, and the unit is fairly large, so it isn't too difficult to read which switch is which in the unit.

> 4) RS-485 signal ground. If the USB/485 converter has a signal
> ground, I'd connect it to the COM terminal on what I think is the
> RS-485 port, CN6. You are connecting the PC CN6?

The PC is connected to CN6 via the converter, yes.

> 5) Do you know if the RS-232 port is a slave port? It might or
> might not be. If so, have you considered trying a connection to
> CN2, the RS-232 port?

I do not know for sure if it is a slave port, but I assume it is, as the GWAB manual mentions connecting another GWAB to this port for systems that use multiple GWABs. I can certainly give this a shot... I don't have the unit here with me for the weekend, but I will be able to give this a shot tomorrow morning; I guess it can't hurt.

>6) I noticed a reset button on several of the diagrams.
>Although I didn't read such a statement, it is not uncommon
>for these types of devices to not recognize a DIP/rotary
>switch change unless power is cycled or the device goes
>through a reset cycle. I don't know if it applies to this,
>but it might be worth trying if you change hardware settings
>like that. I've been stung by the 'failed to cycle power'
>with the result that the device was using the same old
>settings, not the new ones.

I have pressed the reset button before with the power on, but I will definitely give it another shot, as I may not have done it in the past day or two, and it is quite possible I made some changes.

>7) What is the red LED ERR telling you when you attempt
>communications?
>
>from the manual:
>The red ERR LED indicates operational errors in the GWAB11
>itself. It does this with a blink sequence and can show two
>types of faults:
>
>0 blink: No error. See next page for the status of the
>NET1 - NET4 LEDs.
>
>1 blink: There is a communication fault between the
>motherboard (the lower PCB) and the signal interface board
>(the upper PCB). As long as this fault is indicated, the NET
>- NET4 LEDs indicate with a constant lit LED in which of the
>four sensor cable input channels the error occurred. The
>error could be caused by e.g. a short circuit in the sensor
>cable inputs. Typically this fault is indicated on all
>channels at once.
>
>1 blink: There is an error in the RS-485 communication.
>This could be caused by wrong baud rate, framing, parity,
>noise, or because the + and - signals for the RS-485 bus is
>reversed. The NET1 - NET4 LEDs operate as normal when this
>error is indicated on the ERR LED, see below. This error
>stops when either a command has been successfully received
>again or approximately after 60 seconds of no
>communication.

This is where my major frustration is: I get no blinks for the error LED, which suggests that things are fine, but I also don't get anything from any of the NET1 - NET4 LEDs. This is the reason I contacted the manufacturer in the first place, as I wondered if it was a hardware issue. I am sorry that I can't answer this question more thoroughly. I know it would make a big difference in troubleshooting.

>8) >how important is the number of registers I poll?
>
>I always start by reading one register (non-zero) data
>register, until I establish communications and confirm that
>I am addressing the register I think I am (whatever the
>offset is).
>
>Only then do I go and try multiple register reads.
>Although this device seems to have lots of data in holding
>registers, I never want to read an invalid register which
>might throw an exception.
>
>Too many things to go wrong when one tries too much at once.
> But that's just my opinion.

Thank you for this explanation. I have tried a couple of times with just one, but I wasn't sure if I had to have the exact number that had data; I assumed that wasn't the case, but my unfamiliarity led me to be unsure. I appreciate that you clarified this for me.

Once again, thank you very much for taking the time to look through some of the documents and to post such a thorough response.

 

You need to get the manual for the USB-RS-485 converter.

http://www.easysync-ltd.com/userfil...tation/USB to Serial Converters Manual(2).pdf

and check that the jumpers are set for RS-485 half duplex. It's a complex beast.

Given your silence on the topic, I'll assume that you're assuming it's configured to work for this application. It might well not be.

If the slave vendor had set the converter up (unlikely in my experience, that kind of thing gets shipped in its original carton untouched) and documented the settings so you can confirm the settings, great. But if it came out of box in its default state, it isn't even clear what the default settings are. Any of the wrong settings could be faulting the 485communication.

Note:
"(Bias) should be disabled if another device on your serial bus already provides biasing as biasing of data lines must only occur at a single point in the cabling."

It is particularly critical to make sure that only one device applies bias to the network, because if I recall properly the slave unit does biasing but you might search the slave unit document for the word 'bias' to confirm. So bias probably needs to be disabled on the converter if it is enabled on the slave.

There's separate instructions for the same model for 3 or 4 DIP switches, but page 16 summarizes jumper settings for RS-485

1-2 (termination) jumpered
5-6 and 7-8 need to be jumpered for half duplex
11-12 jumpered (tristate enable)
13-14 no jumper (echo disabled)
15-16 jumpered (No echo enabled)
29-30 jumpered (CTS enabled)
All other positions = no jumper

The three DIP switches on the outside should all be OFF for half duplex (2 wire), no echo.

I assume Modpoll knows the correct virtual COM port that the converter installed on because the Tx LED lights up when you attempt a poll.

I'll repeat my earlier question: 5) Do you know if the RS-232 port is a slave port? It might or might not be. If so, have you considered trying a connection to CN2, the RS-232 port?

Half duplex RS-232 with any FTDI USB/485 converter is 'easier' (just need to wire GND to GND, Tx to Rx, Rx to Tx, tell Modpoll the correct COM port) than half duplex RS-485, given the myriad of selectable options in your particular USB/RS-485 converter.

Another approach is to wire up and query some other Modbus RTU slave and see if you get a response. I'm thinking it probably will not connect, in its current 'unknown' state.

 

David_2:

>You need to get the manual for the USB-RS-485 converter.
>
>http://www.easysync-ltd.com/userfil...tation/USB to Serial Converters Manual(2).pdf

I have this manual, and you are right about the complex beast part. Unfortunately, coming from computer science rather than engineering, a lot of the information here was meaningless at first, and, even after researching it, I only feel like I have a basic grasp of the material.

>and check that the jumpers are set for RS-485 half duplex.
>It's a complex beast.
>
>Given your silence on the topic, I'll assume that you're
>assuming it's configured to work for this application. It
>might well not be.

This is the conclusion that I came to last night. The GWAB manufacturer provided me with test software. It has the same problem, with the converter Tx flashing but only the Rx flashing inside the unit (none of the errors or NET1-4 LEDs flashing). The manufacturer's software tells me that there is no reply, just like Modbus Poll.

>If the slave vendor had set the converter up (unlikely in my
>experience, that kind of thing gets shipped in its original
>carton untouched) and documented the settings so you can
>confirm the settings, great. But if it came out of box in
>its default state, it isn't even clear what the default
>settings are. Any of the wrong settings could be faulting
>the 485communication.

I bought the converter separately, but I set it up according to the GWAB manufacturer's specifications on page 2 of the following guide: http://www.grain-watch.com/documents/Connection instructions for the EasySYNC.pdf

>Note:
>"(Bias) should be disabled if another device on your serial
>bus already provides biasing as biasing of data lines must
>only occur at a single point in the cabling."
>
>It is particularly critical to make sure that only one
>device applies bias to the network, because if I recall
>properly the slave unit does biasing but you might search
>the slave unit document for the word 'bias' to confirm. So
>bias probably needs to be disabled on the converter if it is
>enabled on the slave.

I will do so.

>There's separate instructions for the same model for 3 or 4
>DIP switches, but page 16 summarizes jumper settings for RS-485

The model I have is the ES-U-2101-M with four DIP switches. According to the manual, page 16 only applies to the non-M models. Page 20, Tables 8 and 9 are where the settings for my particular unit are, but I must admit that a lot of it is beyond my understanding. I am reading up on this material in order to better understand what is going on. This is also why I just accepted the manufacturer's suggested settings. Now that it isn't working with their software either (which identifies addresses based on connection rather than me having to figure out the formula), it suggests that either their suggested settings are wrong, or there is potentially a larger hardware issue.

>I assume Modpoll knows the correct virtual COM port that the
>converter installed on because the Tx LED lights up when you
>attempt a poll.
>
>I'll repeat my earlier question: 5) Do you know if the
>RS-232 port is a slave port? It might or might not be. If
>so, have you considered trying a connection to CN2, the
>RS-232 port?

I am not sure about this. The documentation isn't all that clear, and obviously it is made less clear by my inexperience. I will ask the manufacturer about this.

>Half duplex RS-232 with any FTDI USB/485 converter is
>'easier' (just need to wire GND to GND, Tx to Rx, Rx to Tx,
>tell Modpoll the correct COM port) than half duplex RS-485,
>given the myriad of selectable options in your particular
>USB/RS-485 converter.
>
>Another approach is to wire up and query some other Modbus
>RTU slave and see if you get a response. I'm thinking it
>probably will not connect, in its current 'unknown' state.

I don't have access to another slave. I know that there are slave simulators out there. I assume I could use something like that?

You have been awesome in helping me through this, and I continue to be thankful. Even if things aren't working yet, I certainly feel like I understand the system better than I did a couple of days ago.

Thanks again!

 

Shoot, it looks like you've already examined the converter. I was hoping for a jumper out of place.

The way I read the photograph of the jumpers on page 20 is that jumpers 11-12 on the left, 1-2 on the far right. The exposed pins means unjumpered. Where the pins are not exposed means 'jumpered', the jumper covers the pins.

Table 9 on page 20 defines the jumper action for your model:

1-2 unjumpered (pull-up Tx bias disabled)
3-4 unjumpered (pull-down Tx bias disabled)
5-6 unjumpered (Rx termination disabled)
7-8 jumpered, (Pull-up Rx bias enabled)
9-10 jumpered (pull-down Rx bias enabled)
11-12 unjumpered (CTS termination disabled)

The converter is supplying the 485 network Rx bias with jumpers 7-8 and 9-10 installed.

I had thought I'd seen a statement that the slave provided bias, but that could have been another thread. I just searched the other two documents and did not find the word bias. So enabling Rx bias at the converter is probably OK, but if I were stuck like you, I'd remove the 7-8 and 9-10 jumpers and make a polling test, just to see. It can't damage anything.

Sorry it came to an impasse.

 

No problem, David_2.

The manufacturer decided that there must be a problem with the hardware, as the LEDs should be blinking no matter what. They believe that it is either a fuse that has blown out or a defective unit. They said to ensure that there was no power applied when I did anything, and I did so when I put things together, but I guess I will have to wait awhile to see what the exact issue is.

Thank you again for all of your help! I appreciate it.