Modbus Question

[tuncos]

I've never dealt with Modbus and it looks like the time is coming soon.

We are being asked to monitor some equipment and they are giving us a choice of Modbus RTU or Modbus TCP. Does anyone have an opinion of which would be the best to tie in with a JACE-600?

Thanks!

[crab master]

I haven't worked with a JACE but the simple/obvious answer is what's easier for you? I suspect IP, otherwise you will have to run a modbus rated comm wire between the JACE and the equipment. Many times it's easier to jump onto existing IP than to get a wire between your device and the equipment.

BTW - I hope you get the correct register list the first time!

[lontshooter]

Modbus IP would be better to use with the JACE box, the Modbus RTU will have communication issue with the JACE.
Make sure that when you connect the two togehter that you have the correct register value setup to respond.
Some times on the JACE it does not see the Modbus signal correctly if you have more than 5 TCP/IP connected Modbus device.
Aslo I agree with crabmaster on the easier use with existing network verus have to run a communication line for the RTU.

Lontshooter

[NINAX]

the Modbus RTU will have communication issue with the JACE.

Can you expand on this?

I've never experienced the issue you've stated.

[NINAX]

I've never dealt with Modbus and it looks like the time is coming soon.

We are being asked to monitor some equipment and they are giving us a choice of Modbus RTU or Modbus TCP. Does anyone have an opinion of which would be the best to tie in with a JACE-600?

Thanks!

You would also want to consider the IP network stability, IT relationship, and the use of the integration, prior to jumping on a network controlled by others.

We have exclusively used 232/485 networks. The data is usually used with logic that the JACE contains. So even if the IP network goes down, the JACE-Modbus continues a normal operation/control.

[crab master]

You would also want to consider the IP network stability, IT relationship, and the use of the integration, prior to jumping on a network controlled by others.

We have exclusively used 232/485 networks. The data is usually used with logic that the JACE contains. So even if the IP network goes down, the JACE-Modbus continues a normal operation/control.

Good points - I've had IT people take months to set things up, but lately I've been working in places with competent and quick acting IT staff.

[smokeout]

I have not experienced any comm issues either. I have only used rtu though.

[tuncos]

Thanks all for the good info.

I'll discuss this with the field guys and see what they want to do.

[osiyo]

Good points - I've had IT people take months to set things up, but lately I've been working in places with competent and quick acting IT staff.

Yeah, working with the customer's IT folks can be a pain sometimes. Or, easy at other times. It's highly variable, depending on not only the competency of the IT staff, but also their willingness to work with you.

i.e. We did a job where we installed controls that used a proprietary RS-485 network, where we outfitted controls into some 20 plus small buildings scattered around a county. Each building had only the freely programmable controllers needed to control the equipment. No front end located in those small buildings themselves. Instead, we used Digi's to connect those physically isolated RS-485 networks to the customer's installed LAN/WAN system. Then reversed the procedure at the other end, the building where the front end resided. Reverting back to the proprietary RS-485 communications prior to connecting to the front end device.

Gad, comm was slow, many errors, timeouts, etc. We checked and double checked, everything seemed fine on our end. So we asked the customer's IT folks to check their system. They claimed they had no problems. This went back and forth for months. Took nearly an act of Congress to get their IT folks to check, each time we asked them to do so. I've no idea what they checked or how closely. Just know that each time they reported, "Not our problem."

We finally put in place the software to capture and analyze the network traffic over their LAN/WAN moving between that front end and the remote controllers, recorded the traffic for days and showed them, beyond a doubt, that their system had issues. Presented the info we'd gathered at a meeting that included THEIR bosses (the IT department's), and suddenly they got VERY busy and within a couple days they did whatever (they never revealed what they found once they really looked into the problem) and things started working fine. And have for several years now.

OTOH, I've worked with IT folks who were there, Johnny on the spot, interested, motivated, knowledgeable, and willing to get er done NOW, and get er done right.

<Shrug> Depends on who you're dealing with.

In any event, I started reading all the posts in this thread when someone mentioned having trouble with Jaces and Modbus RTU over RS-485.

This was news to me as we've done this several times and not have any significant problems. So I was hoping to learn something new, maybe something I haven't run into yet. But so far, no one has mentioned details as concerns that assertion.

As concerns Modbus over RS-485 or using Modbus IP, you have a point. If its a long distance or unusually difficult pull, certainly Modbus IP is an option.

Where I work, however, we tend to try to avoid Modbus IP, routed along the customer's standard LAN, whenever possible.

For one, sh*t happens, and it happens regularly. For one reason or another, from time to time a customer's data network coughs, burps, or dies (hopefully not for long). The IT guys make a mistake, or they're doing a system modification, or some piece of equipment fails, whatever the case may be. It's not as if this sort of thing happens frequently, but neither is it a rarity.

So we make every effort to design and install things so that when such events occur, no vital service or function in the equipment we're controlling is interrupted. By a variety of methods. i.e. Its a freely programmable and everything it needs to do its job is self contained and connected directly to the controller, and/or the program is designed to recognize a fault in getting necessary data from the network and utilizes a fallback action, and/or a needed piece of data is gotten directly from another controller on the same control network bus segment and hasn't got to be moved over the customer's data network.

Beyond that consideration, there is also just the fact that often enough, more often than not in the jobs I've done, pulling that RS-485 comm cable really isn't that much of an issue. Not for an experienced wire puller.

Consider a recent job I completed. We got a change order, after everything was in. Some new boilers that were installed had their own DDC controls (Siemens). Originally customer just wanted us to do an enable/disable of each boiler and to monitor HW supply temps, etc. A few points. Now customer decided why not be able to see and access a lot more? Those controllers could do Modbus comms. Now the question became Modbus RTU over RS-485 or Modbus IP?

Didn't need any additional hardware to do Modbus RTU over RS-485. Would have to buy cards for Modbus IP. And there were no LAN connections right in that boiler room anyway.

Simple decision. Modbus RTU it over RS-485 it was. The nearest Jace was on a different floor of the building, plus perhaps a couple hundred feet away horizontally. The comm wire costs were negligible. Took our installer maybe 3 hours labor to do the pull, terminations, etc. Done. No big deal.

If we'd gone the IP route, would've still had to pull some cable, just a different kind and a shorter run. Buy the cards. Then dink around and spend the time to call customer's IT, arrange time schedule and such for them to do their thing, so we could actually get IP's assigned, routing done, etc so front end could actually talk to those controllers.

Personally, I think its a wash, with perhaps an advantage to the RS-485 comm method. And that is that in years of working with this stuff, once you've got your RS-485 network installed and tested correctly ... I RARELY see future network issues later. It becomes one of those things you can forget about and not worry about. Mostly. RS-485 is pretty darned bullet proof in most cases. Works fine, lasts a long time. And yah don't have to worry about some IT guy goofing and changing something, or a disconnect due to failure work being done. After all, in most commercial buildings IT types are usually kept pretty busy changing this or that, dealing with a failed this or that, adding something, moving something, upgrading something, etc. To deal with new requirements, offices being moved around, or whatever. So that LAN/WAN system gets dinked with fairly regularly. OTOH, that RS-485 cable rarely gets touched, or even noticed.

Just my thoughts and what I've experienced. Certainly neither is comprehensive. I just look at things with the opposite point of view. I prefer to use the customer's LAN/WAN system as little as is practical. Not saying I don't or won't use it.

[tuncos]

Osiyo, I appreciate your comments.

Every bit of information helps when preparing to embark on a new adventure...

[MaxBurn]

It can also help a lot if the building has a separate BMS IP network, separate from production equipment. They might let you in to manage the IT gear and issue your own IP etc. It may or may not have a portal to the production side or the internet. Generally they leave the equipment alone too. A vlan is a mix of both, still tied to production hardware so if that is lost your toast but generally when working you are free to do what you want in there.

All this IT equipment has some steep costs, sometimes running that pipe, spool of wire and a bunch of man hours for a 485 makes more sense in reliability and cost.

[BACnet]

Perhaps I'm coming at this the wrong way but-

I always assumed that Modbus RTU was the de-facto way to speak modbus. It's reliable, simple and as pointed out above it takes only a normal twisted pair, not an ethernet wire, comm cards and all the headache and heartache that can come with interfacing with someone else's network.

Of course since modbus does not pass a token, if you have more than one master the only way to set up the network is to have both masters on modbus IP. That way the router can put both masters' requests on the 485 line and they can coexist happily. That said, I see very few cases where people really need multiple masters on a modbus trunk.

When there is only a single master involved Modbus IP seems to be more effort for zero gain.

[MaxBurn]

Perhaps I'm coming at this the wrong way but-

I always assumed that Modbus RTU was the de-facto way to speak modbus. It's reliable, simple and as pointed out above it takes only a normal twisted pair, not an ethernet wire, comm cards and all the headache and heartache that can come with interfacing with someone else's network.

Of course since modbus does not pass a token, if you have more than one master the only way to set up the network is to have both masters on modbus IP. That way the router can put both masters' requests on the 485 line and they can coexist happily. That said, I see very few cases where people really need multiple masters on a modbus trunk.

When there is only a single master involved Modbus IP seems to be more effort for zero gain.

Very true but it all goes out the window when you have a perfectly fine LGR in one building with points available to add and a device you need to read in the next building but you have no hardware there. Assuming the customer already has network between the two all you need is one new LAN drop for the remote equipment and you are set.

[D1G]

I'm not a fan of MODBUS/TCP if it's riding the enterprise IP network. You're asking some very limited devices (limited relative to the rest of the network appliances) to manage a session based connection usually with a static set of parameters on a network that can be extremely dynamic. Not to mention that device is going to be exposed to things it was never designed for. Also, some implementations of MODBUS/TCP can cause real headaches with ID(P)S and session tracking firewalls.

There is the fact that MODBUS was never intended to reside in the hostile environment of current enterprise networks. It offers literally zero security, anyone with access to the network can read from or write to any available registers.

FWIW I'm a big fan of MODBUS. Its maturity and simplicity make it a solid process control protocol but you have to keep in mind when it was developed and what the original intent was.

Like Mr. BACnet previously mentioned I can't see any benefit if you only have one master. Is the JACE going to be located in the same facility? If so, I think you'd be better off using RTU and a dedicated field network.

Respectfully,
D1G