Jace Controller To MODBUS Slave

T

Thread Starter

Trevor Adelman

My MODBUS slave device communicates normally with EasyIO FG-20 controller, but I can't get a successful ping response from the Jace WEB-300 controller.

I have a serial port sniffer in place on the RS-485 line between the controllers and the slave device and can provide details if that helps the troubleshooting process.

Has anyone successfully connected a Jace controller to a MODBUS slave device?
 
No, I don't have a Web300 so I have never connected one to a Modbus RTU slave.

But the product line has been out there for some time and the 70 page "NiagaraAX-3.x Modbus Guide" (the one I downloaded is dated 2007) is a hefty read. Given the depth of its documentation, I have to believe that the products, do in fact, talk Modbus when they're set up to do so.

According the Niagara Modbus Guide, the Ping Address function even accepts an exception reply to 'prove' the connection. Pg 4-14, "when enabled, a network's monitor periodically pings (queries) this address. While receiving any response from the device, including an exception response, this is considered proof of communication".

If the Ping Address feature is not successful, there's no reply from the slave. What can cause a lack of response by the slave?

1) Is your box Modbus 'licensed'?
Yes, I know Modbus is an open protocol, but it appears that there are multiple vendors of similar looking devices all of which use Niagara, so it's entirely likely that some offer Modbus as an 'option'.

I read through some of verbiage and I noticed that Honeywell's spec sheet made mention of including BacNet and Modbus 'licensing' in their product. Since Modbus is an open protocol, that has to be marketing talk for "unbundled modular communications protocols", meaning you get what you pay for.

So, the first thing to consider, is your box 'licensed' for Modbus?

2) Is the Web300 serial comm port enabled for Modbus?

3) Your serial comm settings, baud rate, 8 bit word size, parity are identical on both ends?

4) Are the (+)/(-) wires reversed?

The RS-485 connector is 3 pin, so it's half duplex 2 wire. Sometimes one vendors (+) is the other vendor's (-). It should be (+) to (+), (-) to (-), but the labeling is not consistent vendor to vendor. Backwards wiring disables communications. Have you tried swapping the +/- lines?

5) Are you addressing the correct slave ID number?
Modbus slaves will not respond to a query addressed to a different slave.

6) Configured for RTU, not ASCII?
I'm not sure what a slave expecting an 8bit RTU word does when it gets a 7 bit ASCII word. I doubt it would even throw an exception, but I'm not sure.

7) I noticed the Honeywell version has a nifty means of jumper-enabling line bias for the RS-485 lines. Apparently biasing is disabled by default and requires some disassembly in order to access the jumpers. If your trial is on the bench, point to point, lack of biasing is probably not disabling the comm connection, but you should be aware of it.
 
Top