Jace and Modbus

[trickndude]

Need to add a modbus device to a fx60 with modbus driver. No experience with modbus. Can anyone tell me briefly what I need to do and purchase. Thanks

[davem]

You need to know what media you are using to get the MODbus points - in general, if it's over Ethernet, you'll need the MODbus TCP driver; if it's over an RS-485 connection, use the MDObus RTU driver. (Actually, my JCI price book only lists the RTU driver, so hopefully you're connecting with an RS-485 connection) In all likelihood, you don't need the MODbus "server" driver (the one with an S at the end of part number), because you're most likely not serving FX-60 data to a MODbus network, but rather you're picking up MODbus data for use in the FX-60. Use the client RTU driver.

There's no auto-discovery of MODbus controllers or points, so you'll need to know quite a bit about the controller to be able to integrate it into the FX-60. It shouldn't be hard to come up with a points list that lists all the MODbus registers for the device you're integrating, so getting started won't take to long.

Post some specific questions here once you get started - there's quite a few of us who have done various MODbus integrations to FX-60's (or any of their Tridium-manufactured cousins) with a variety of MODbus equipment.

[lwarren]

Just so happens that I am fixing to do my first AX modbus job to some APC units through a Carel gateway this week.

Any tips on this?

[davem]

Be sure you've got all the documentation for the gateway - it'll show you the pinout for their 9-pin serial ports. I recommend bringing a couple 9-pin serial cables with you; you'll hack off an end for each connection to the gateway - one to JACE's RS-485 port, the other to the field equipment bus. If memory serves (check the docs to be sure), you can use just one serial cable with a male end and a female end - you'll use one of each for the two connections to the gateway.

Be aware, too, that the temperatures and setpoints come across as unscaled - so to display the temperatures (and write the setpoints) as something more realistic than 694 degrees, you'll need to massage the points in and out of the gateway.

[lwarren]

As far as the temp values, are you saying just play with the scale and offset of the linear conversion in the proxy point?

[davem]

I don't think it's that complicated - I simply divided the incoming values by 10 before displaying them, and multiplied the outgoing setpoint values by 10 before writing them...

[lwarren]

Gotcha, thanks for the info.

[gnomethang]

lwarren (and possibly davem!)

First off I am talking from a UK based point of view.
I have found that there is a massive variance on data types that you can get from any one Carel gateway - as you say you must really know where the device is coming from. Can you identify the device and application and whether or not it is OEM??.

If it is an OEM product then you are going to be be better placed if it is coming from a straight RS232/485 gateway. If it is the generic modbus gateway then there are additional problems with addressing etc that I managed to overcome with an excel spreadsheet for translating variables to registers (and register types).

I have integrated McQuay chillers, Carel Humifog systems and bespoke Carel apps in R2 but not in Ax (although I do not believe there is any difference on the Carel interface in this regard). I have also integrated APC units on SNMP to R2 and Carel on SNMP to AX.

Apart from rememberng the nasty +/- 1 number in the registers it is not too bad but from experience if you have a nice modbus interrogation program over RS232 then this can help considerably - particularly when deciding how many registers you can interrogate on one module.

Be aware that their documentation may not be up to date (if from Carel direct)

Please Email me if you think I can help - goodness knows I owe this (and other places) some payback.

Barry

[gnomethang]

I don't think it's that complicated - I simply divided the incoming values by 10 before displaying them, and multiplied the outgoing setpoint values by 10 before writing them...

That is usually the case - most points are defined as 0 - 999 integer so 22.2 DegC will be 0222 (int) but MIGHT be 22.2 as an analogue This is where knowing the software helps and trial and error, although successful, will take a bit of time. It depends on how they declare the variable through the gateway device.

I have a pretty good relationship with Carel UK and through them to some of the Italian development guys. They will help but if it is OEM then they will send you there first.

Barry

[NINAX]

You need to know what media you are using to get the MODbus points - in general, if it's over Ethernet, you'll need the MODbus TCP driver; if it's over an RS-485 connection, use the MDObus RTU driver. (Actually, my JCI price book only lists the RTU driver, so hopefully you're connecting with an RS-485 connection) In all likelihood, you don't need the MODbus "server" driver (the one with an S at the end of part number), because you're most likely not serving FX-60 data to a MODbus network, but rather you're picking up MODbus data for use in the FX-60. Use the client RTU driver.


Probably just an oversight, but I'll throw in that the RTU driver will work just fine with the FX60 RS-232 port also.

[gnomethang]

Sorry, just realised that you guys were only talking about the FX/Ax issues!.
I'll get me coat!

[davem]

Probably just an oversight, but I'll throw in that the RTU driver will work just fine with the FX60 RS-232 port also.

An oversight of the ignorant kind - I've never used MODbus through the RS-232 port (but I'm glad I know that now - I know some switchgear spits out MODbus points via 232...now if I can just get my JACE within 50' of the switchgear...:rolleyes:)

[gnomethang]

An oversight of the ignorant kind - I've never used MODbus through the RS-232 port (but I'm glad I know that now - I know some switchgear spits out MODbus points via 232...now if I can just get my JACE within 50' of the switchgear...:rolleyes:)

We have used RS485 converters!

[NINAX]

An oversight of the ignorant kind - I've never used MODbus through the RS-232 port (but I'm glad I know that now - I know some switchgear spits out MODbus points via 232...now if I can just get my JACE within 50' of the switchgear...:rolleyes:)

I'm just throwing that out.

Sure, it may not fit every app, but on a new install, like with an Aerco BMS, you could get the BMS set close to a JACE and run the RS-485 the longer distance to the individual boilers.

[davem]

Of course! I don't why I didn't think of that...a rs-485 converter!! Geez, do I look silly...
But it's all about getting the most functionality out of a given JACE model, so knowing I've got that port available is a nice little thing to remember.

(Now if I could just figure out why the 232 port on a JACE-4 is an RJ-45 jack...rhetorical question - don't answer that...)

[Chris_Worthington]

I just did a large data center job, integrating all kinds of Mod Bus stuff; among a few other protocols into a Jace 6.

The only issues were that some of the devices had fixed parameters such as the baud rate and the parity were different then the others :rolleyes:

I ended up having to using (2) 485 expansion cards to bring in the 3 Mod Bus RTU'S, N2 and Bachnet MSTP into the Jace 6, running out of places to plug stuff into the last modbus connection ended up being ModBus TCP/IP that was tied in with the SNMP stuff.

The long and short of it......

Make SURE you have as much information as possible on the field devices ;) This job information was hard to come by and once we discovered that these devices had fixed parameters, we ended up having to re-run the bus(s) to accommodate :eek:

Other then that, its a cake walk ;)

[lwarren]

Well I played with this today. I got the Jace talking to the Carel gateway no problem, but the gateway does not seem to be talking to the APC units very well. Not much info on this stuff.

I will bang my head on it some more tomorrow.

[davem]

You do have the little configuration program on a disk, right? It offers a command line for reading and writing certain configuration parameters.

Also, be sure to crack the box open, and confirm that the jumpers are set on the correct pins for 422 vs. 485 communication.

[lwarren]

You do have the little configuration program on a disk, right? It offers a command line for reading and writing certain configuration parameters.

Also, be sure to crack the box open, and confirm that the jumpers are set on the correct pins for 422 vs. 485 communication.

Thanks for the Info Dave. Yes the jumpers are set correctly and I did configure the gateway with the floppy. I set the gateway addy to 1, devices -2, baud -9600, bit -1 parity none. The alarm 2 led is rapid flashing which means it cannot see one or more of the units. The tx and rx leds will flutter every 3 or 4 sec. The two units are adrressed to 1 and 2 and 9600 baud.

[gnomethang]

Thanks for the Info Dave. Yes the jumpers are set correctly and I did configure the gateway with the floppy. I set the gateway addy to 1, devices -2, baud -9600, bit -1 parity none. The alarm 2 led is rapid flashing which means it cannot see one or more of the units. The tx and rx leds will flutter every 3 or 4 sec. The two units are adrressed to 1 and 2 and 9600 baud.

From memory the gateway address should not be 1 as you have devices 1 and 2. Try setting gateway address to 3 and keep field device addresses as 1 and 2

Barry

**EDIT - I have checked my installation and I have 3 devices at 1,2, and 3 and my gateway device is 4. Try that. Also note that you may get warning LED on the gateway if once field device gets disconnected.

Barry

[lwarren]

From memory the gateway address should not be 1 as you have devices 1 and 2. Try setting gateway address to 3 and keep field device addresses as 1 and 2

Barry

**EDIT - I have checked my installation and I have 3 devices at 1,2, and 3 and my gateway device is 4. Try that. Also note that you may get warning LED on the gateway if once field device gets disconnected.

Barry

Well I tried that and it still is doing the same thing. I talked to Carel and they said that the gateway address does not interfere with the device addresses because they are two separate networks. After talking with tech support at Carel and APC they don't know what the problem is. The units have to be talking to the gateway because the TX and RX lights are a constant rapid flash.

As a test I reconfigured the gateway for one device and connected only on unit with a device address of 1. The TX and RX lights stayed constant flash and the Alarm2 led stayed flashing. I could disconnect the wires to the unit and the TX and RX would stop flashing. Connect them back and boom they are off and running again. Tried the same with the other unit and it did the same thing. I even went through all of the different baud rates.

I am sending the gateway and both cards back for testing.

By the way, what should my ping address start at? I have it set currently at
40001.

Thanks for the help.

[davem]

I've got my ping address set as hex:0.

[tuncos]

I don't think it's that complicated - I simply divided the incoming values by 10 before displaying them, and multiplied the outgoing setpoint values by 10 before writing them...
Do you need the "Server" feature to write setpoints back to the ModBus device?

Or is like a LON nvi and nvo?

[davem]

The "server" license is used if you need the JACE to appear as a MODbus device on a MODbus network, "serving" up JACE data as MODbus data.

In this particular case with the gateway, you can write to whatever MODbus registers support read/write functions. In my case, some of the higher 40xxx registers supported writing, for temperature and humidity setpoints.

[lwarren]

This is my first modbus job, but so far I would have to say I am not a fan.

[davem]

My sentiments exactly - our MODbus experience was definitely not by choice, but simply a contractual requirement to integrate certain equipment. I think the ability to do this integration is nothing I'd go out of my way to capitalize on..."yeah, we can integrate that, but..."

MODbus is actually a fairly simplistic protocol, which probably explains why manufacturers of everything from electrical meters to gateways to CO2 sensors support MODbus first, but also explains why it lacks all the "modern" features like auto-discovery. Fortunately, it also explains why it's quite robust. Once you get everything addressed correctly, there's not much to go wrong - messages are 'simple', timing is 'simple', etc.