I think you have an issue with you line driving RE and DE because you set the D3 line high to transmit, then you issue a modbus function 3 (read holding registers). After this you check if the request was a success and after this you set the D3 line low and you read the response from the library buffer from the node.
The issues stands that a modbus transaction includes the master querying the slave and the slave responding which seems to be taken care of by the node.readHoldingRegisters() fucntion therefore the master releasing the RS485 bus should happen within this fucntion not after it.
What I guess its the problem, its that the modbus library you used is intended for RS232 as the physical layer therefore you might have to modify the library so the RS485 bus is released as soon as the master completely finishes sending the query
Hope this helps
This sounds like it should be easy to diagnose. You say the signals on the RS-485 bus look OK, so check the next point. Keep following the signal until you find it not right somewhere.
The next logical point to test after the RS-485 bus would be when it gets converted back to a single-ended signal that presumably gets presented to UART receive pin of the device. Does that look right? If not, there is a problem with the RS-485 receiver circuitry. If so, then either the device is not working or you have a protocol problem.
In general, it's good to keep dividing up the suspect parts of the system to isolate what is not working, or to test them in isolation. For example, you could either try to tap the UART line into the device and see if you get what is expected by looking at the bytes on a PC with a low level program, or you could try a program on the PC to inject what you think is the right sequence of bytes and see if the device responds as you expect.
Chances are that if the UART signal at the device looks OK (including the obvious issue of baud rate), then you have a protocol problem. In other words, somehow you're not sending the right data to the device. Early on in bringing up a system like this, I often use a low level test program on the PC that sends and receives individual bytes. I can type byte values in decimal, hex, and as ASCII character, and it displays everything it receives likewise. This can be very useful for verifying that you really do understand the protocol the device expects.
Do some of these experiments and tell us what you find. It would also help to provide some information on this device you are trying to talk to from the micro.
Best Answer
After fixing signal ground issues, you need to confirm signal polarity by sending data packets and checking for confirmation. If a corrupted or messy packet is received, the receiver will request the packet be resent. If this happens continuously then reverse polarity and try again. If polarity is correct then data should flow in both directions per USB protocol.
RS-485 requires a separate signal ground to avoid too much DC offset in the signal, or baseline drift as some call it. Also with LabView you can use NI MAX to configure your Ni-DAQ and communication boards with arbitrary timeouts. This must be a USB issue, as USB does have 1 ms timeouts as it sends packets at a 1 ms rate.
RS-485 only has the timeout restrictions you put in it, but using USB as a source restricts you to USB protocols. RS-485 is a hardware standard, not a software protocol. You will need to make sure events on the RS-485 side return a "ACK" or similar USB response within 1 ms. This means short hops to each RS-485 node, and each node must respond within 1 ms. A saving grace would be if NI-MAX has control over USB functions such as timeouts.
Also with LabView it is easy to decimate data into fixed-rate packets before being sent to a USB port-->RS-485. Also USB high-speed uses 100 us time delay between packets. Check what USB standard is being used, and chose a slower data rate such as 48 mbps. This is where you may have to compromise to make things work - along with adding a signal ground wire (20 ga or 22 ga will work) that hops from node to node. Do NOT Earth ground the signal ground wire.
Try adding the signal ground wire first. Baseline drift can make many low-voltage differential communications work poorly or not at all.
Remember that NI-MAX and LabView are very expensive and powerful software tools. In an hours time you can create diagnostic indicators for polarity match, send inverted data, bit error rate, DC offset in data lines, etc. Build these to take the guess work out of the equation.