In this section we'll go over some troubleshooting tips. If you are seeing data already, feel free to skip to the next section.
Unfortunately, if you aren't seeing any data, there are a number of things that could be wrong when doing serial or Ethernet communications. Fortunately, you can usually just step through all the possibilities, double checking yourself, and the source of the problem will become apparent.
To help with troubleshooting serial and Ethernet communications, DAQFactory provides a communications monitor. To view this monitor, click View - Comm Monitor from the DAQFactory main menu. This will display a docking window, usually at the bottom of the DAQFactory window. Right click in the main part of this window and select the communication port you wish to monitor. Unless you are doing Modbus ASCII, you will probably also want to enable the Display All Chars as ASCII codes option also available from the right click menu (and probably Display codes as Hex and Display Time of Rx/Tx. Do not check New line with CR or LF unless you are doing Modbus ASCII).
Here are the things that can be wrong and cause communications to fail:
1) bad wiring: this is typically only a problem with RS422/485 connections as RS232 and Ethernet usually use prebuilt cabling, but it still happens. For 422/485 make sure you have proper termination, watch for polarity, and despite the fact that 422/485 are differential signals, you do need the ground (Gnd) line hooked up.
2) incorrect port settings:
For serial: your comm port settings much match exactly with your device. Even an incorrect Parity or Stop bit setting will kill all communications so double check yourself. Likewise, make sure you are plugged into the correct port and that the port isn't in use by another program. DAQFactory will generate an error in the Command / Alert window if the port doesn't exist or it is in use.
For Ethernet: an incorrect IP or port will cause comm failure as well. The DAQFactory comm monitor can help. If you don't see any Tx: lines after you create your channel then DAQFactory was unable to connect to the remote device and the IP or port must be wrong, or the IP is on the wrong subnet (meaning DAQFactory, for example is at 192.168.1.3 and your device is at 10.0.0.5). If you do see Tx: lines than DAQFactory was able to connect to something, so unless you connected to the wrong port and that port happens to have some other protocol running, you probably have the correct port settings and good wiring and can move on to the next possibilities.
3) wrong Modbus ID: even in ModbusTCP, most device require the Modbus ID to match the D# specified in your DAQFactory channel. Double check the device to find the current Modbus ID setting and make sure the D# of your channel is the same.
The above problems typical result in either no comms, or comm timeouts, meaning you'll see Tx: lines in the comm monitor but no Rx. The ones below typically have a response, but it is an error, though some devices won't respond even when a standard Modbus error is called for.
4) noise on the line (serial only): if you see Rx lines but they don't look similar to the Tx lines you probably have noise on the line and should evaluate your cabling. The first few characters of a Modbus response are identical to the query, so the first few numbers in Rx should match Tx.
5) wrong I/O type: some devices only support Input Registers or Holding Registers, or have no registers at all, just coils. Most will return a standard Modbus error, which will appear in the Command / Alert window (View - Command / Alert from the main menu), but some just ignore the request and don't respond.
6) wrong Modbus register (channel #): double check your hardware manual.
That covers the basic failure modes. If you continue to have problems, please contact AzeoTech support or post to our forum at support.azeotech.com.