REST API calls versus Modbus TCP

[harncw]

We have been using a "koyo" dl06 and communicating to it well over Modbus TCP, we read inputs and set outputs at a high rate, 4-10 times a second. Have working systems in place for over 10 years. Controlling an asphalt loadout system.

Our inputs and outputs are 120vac and would prefer a plc able to interface directly as opposed to "stepping it down" for the inputs.

I have a consulting client who wants to build a system similar to what we already have but is interested in using REST API calls to do the communication instead of Modbus TCP.

In your opinion are REST API calls up to the task? Any PLC manufacturers out there you can recommend?

 

[ojz0r]

Hey why asphalt and not concrete, arent they the same?
If you know what both are you would not make such a suggestion. But sure, both could be used to walk and drive on. The same goes for modbus and REST, they both communicate information but have fundamentally different purposes.
REST is a web (think HTTP) technology, not jndustrial communication.

 

[lfe]

It is not an industrial protocol but it seems to be increasingly used in industrial applications.

Receiving a good amount of data in JSON format in a single request is an interesting option.

It seems that some Automation Direct model supports REST API, also CodeSys

 

[Corsair]

The REST approach seems to be of interest to computer people that think everything has to have the potential to have a password somewhere. It may be easier to implement with some programming languages. I'm sure there are many ways to hit Modbus TCP from any language. Many years ago I managed to get register reads working with my C compiler within a few hours.

Modbus critics will justifiably say it suffers from lack of definition - byte ordering, data type storage, and so on. Yet the basic layer that gets 50 registers starting at 4### from point A to point B is clearly defined and works very well between different manufacturers (as long as you adjust the addresses up or down as needed). 125 integers in a single Ethernet packet is pretty efficient. The same protocol can be used for HMI, peer-to-peer, and sometimes I/O. The TCP port number is unique to the protocol so traffic can be isolated. WireShark knows what to do with it.

I will admit that I have no experience with the REST thing and PLC communications but maybe there's a reason for that - that I have had no reason to use it. I would question if it is as clearly defined in a cross-vender way as Modbus is. Writing something that is unnecessarily brand-specific doesn't seem to be a good idea to me, especially in a world of chip shortages and supply-chain problems.

Don't listen too much to the Modbus-haters on this website. Don't be too quick to walk away from something that has (mostly) functioned for 50 years in the industrial world just to appease some computer science type. Consider his reasons before making the switch. Make the switch if the reasons are valid but don't make it if he does not have any.

 

[drbitboy]

Yet the basic [Modbus] layer that gets 50 registers starting at 4### from point A to point B is clearly defined and works very well between different manufacturers (as long as you adjust the addresses up or down as needed). 125 integers in a single Ethernet packet is pretty efficient.

+1

Many of us are probably familiar with the old saw "When all you have is a hammer, everything looks like a nail."

The corollary is that "If you have a really excellent hammer, sometimes it is simpler to make everything look like a nail."

IMNSHO (and probably because of my bias of being comfortable with bits), Modbus is one of those really excellent hammers; not very subtle, but KISS and robust. The various mis-implementations and and traps (byte-order; one-based vs. zero-based address mapping) are so few and boil down to not much more than bookkeeping that, with simple diagnostic tools it rarely takes more than a couple dozen minutes to implement a reliable and correct connection between any master/slave pair.

As I watch the various posts go by on this forum, a significant percentage are about comms, whether E/IP or Profinet or DeviceNet etc., and the answer sometimes involves some obscure bit of info that you won't know about until someone sees your post. E.g.

I managed to get the L61S controller to connect to the drive by upgrading the firmware of the 1756-ENBT (ethernet bridge module in the ControlLogix PLC, was 4, upgraded to rev 6). Works very well, now.

And those protocols can be necessary and/or trivial to implement for a given application, especially if all devices are from the same vendor.

But not always, and when they don't work, the diagnostic tools to help are few, far between, and expensive (e.g. TechConnect).

There is a reason why so many PLC brands and so many field devices implement Modbus.

 

[lfe]

More and more modern PLC programming references variables by name and not by memory address. Modbus cannot access a tag by name.

 

[the_msp]

Ignition supports REST (and SOAP) API calls.

Have I used it? Yes. Do I use it for sending IO signals to a PLC? No.

Does it (Ignition) support ModbusTCP? Yes. Do I use it for turning on relays? Yes.

 

[ojz0r]

More and more modern PLC programming references variables by name and not by memory address. Modbus cannot access a tag by name.

This depends on what the communication is for. Are we talking remote io then the server (node) probably wont know the variable names - only addresses like %i10.3.