Two months ago I had absolute zero knowledge about professional kitchens and Modbus. But with Node-Red I have gained a lot of experience and now I am in the edge of falling way too deep or making a success story.

I’m a bit of a late bloomer when it comes to MODBUS, so apologies in advance if some of these questions sound naïve. I’d genuinely appreciate honest, professional opinions rather than sugar-coating.

To put things into perspective: two months ago MODBUS was, for me, mostly just a term associated with RS-485. Since then I’ve managed to get up to speed with the basics quite rapidly — I now understand how RTU TCP gateways work, how polling behaves, and I’m already successfully reading live data from one kitchen’s MODBUS bus.

That said, what I’m discovering is that the physical and architectural reality of the bus itself is extremely limited.

I’m working in an environment with POSSIBILITY to include multiple professional kitchens, spanning different decades and manufacturers. What I keep running into is this:

• Devices from f. ex Carel, Dixell, and many others
• No ready-made or unified MODBUS cabling between them
• Different generations of controllers, different assumptions
• In many cases, no clear documentation of addresses, baud rates, or even whether MODBUS was ever properly commissioned
• Existing wiring that appears to have been designed for very narrow original use cases

My concern is whether I’m facing an unreasonably large challenge trying to bring these under one umbrella.

I already have a fair amount of success reading data from a sizable set of temperature sensors and some other values that are on a shared bus. That part I’m comfortable with: polling, decoding registers, mapping data, etc.

Node-Red reads the registers and make them MQTT devices.

Where I start to question my sanity is the next step:

• Each controller likely needs individual addressing?
• Vendor-specific register maps
• Different expectations around termination, biasing, and topology
• And on top of that, trying to include other HACCP-relevant devices beyond “just temperatures”
• And of course any important alert data from any kitchen device

So my core questions are:

• Is there any modern or pragmatic way to unify this kind of mixed kitchen environment?
• Or is the reality that each device more or less needs to be treated as a bespoke integration project?
• At what point do professionals usually draw the line and say “this should have been designed centrally from day one”?

I’m not afraid of work, but I am trying to understand whether this is a reasonable one-man effort, or whether I’m trying to eat an elephant whole.

Any real-world experience, architectural advice, or “don’t do this, do that instead” stories are very welcome.

Thanks in advance for your patience.

 

Just to clarify one point that might otherwise sound contradictory:

If someone is wondering how I’m already reading MODBUS data when many of the kitchen devices are not physically on the same RS-485 bus — the reason is that there is a separate, dedicated measurement layer in place for storage rooms and freezers.

Those environments use wireless sensors, and their data is bridged into MODBUS (e.g. Zigbee → MODBUS gateways). That layer is intentionally isolated and works reliably.

The challenge I’m describing concerns the actual kitchen equipment controllers (Carel, Dixell, etc.) and the lack of a unified or well-planned field bus between them.

Hope that clears it up before even it starts

 

You hit the nail on the head: the reality that each device more or less needs to be treated as a bespoke integration project.

There's no magic wand to make Modbus into something it isn't.

But it is still out there because it has such widespread implementation, primarily because of the low cost to the manufacturer.

RS-485 has limited common mode voltage spec, which can create problems when interfacing devices on different AC power feeds which Ethernet does not have, because Ethernet is inherently electrically isolated, by design and by its electrical standard.

 

Welcome to the Modbus community. Is it one of the most simple and reliable fieldbus interfaces that I know of.
I'm working with it successfully now for about 15 years implementing all kinds of catering equipment (deep fat frying furnaces, grillplates) and also for wireless haccp datalogging systems.
Mostly in combination with the awesome Pro-face touchpanels that perform the human machine interface and PLC functionality.
Modbus is in my opinion really designed for temperature controllers as well as frequency inverters. But also power electronics driving electrical heating elements.
I also use modbus to communicate with Honeywell (now Resideo) burner controllers: it works like a dream

The most important part of all the equipment is that you find a Modbus address list of the temperature controller, Honeywell burner controller or frequency inverter.
These addresses can often be read/written to the equipment, but this is dependent of how it was designed.

For example: I can read an actual temperature from a temperature controller (=the process value) but, of course, I cannot write this value back (that's a little bit silly, to write a measurement back).
So for the desired temperature, the setpoint (SV, setvalue) there is another address.

Now......it is just depending on the specific implementation, for read only 16-bit registers, officially the 300000 range is being used, and for read/write you have the 400000 range.
But there are often implementations that only use the read/write 400000 range of registers, but many registers are still read only. It just depends on the decisions made by the developer.

And what also often happens, is that in the address list is for example address 0 for the measured temperature, but -actually- it is in the 400000 range, and often (also dependent on the implementation) you need to write 1 address higher, so actually you read modbus address 400001 (but the manual states address 0).

When writing setvalues back, look out with the modbus commands for multiple addresses at once (depends on the function call). Most simple equipment only accepts single word read/write commands but often the standard settings for the drivers are with multiple read/write modbus function calls, and you need to manually configure the driver to use the single word read/write modbus function calls.

You also need to check if the data you read is either 16-bit (most of it normally) or 32-bit.
And if the data is signed or unsigned (most of it). For example, a measured temperature is signed because it can also become negative.
So: the map of the addresses of the equipment is most important. And of course, how the communication parameters are set (addressing, communication speed, parity etc.)

Modbus RS-485 is ultra reliable and noise immune, I use that for the low level signals in noisy environment.
Modbus TCP ethernet is ultra ultra fast, and what is really really nice of it: more than 1 modbus tcp master can access the same slave (RTU RS-485 can only have 1 master).
I use the Modbus TCP for the layer on top of the RS-485 network, for intercommunication with higher level equipment.

When you get the hang of it you don't want anything else.

Lets keep discussing, it is a nice topic. Just tell us what you want to do and how, and....maybe....we can guide you a bit and save you time and prevent making the mistakes we already made.

Here is a very important one, don't make the mistake of using the wrong cabling.
RS-485 is an 120ohm impedance bus, so, in order to keep the signals going in the same as going out, please use the proper cable for it, it is not too expensive and you can buy it per meter from Conrad.
So, in onder to prevent unneccesary nasty problems, please use the Lapp unitronic bus LD 120ohm impedance corrected cable for RS-485.
Here you can buy it per meter from Conrad
https://www.conrad.nl/nl/p/lapp-2170204-1-buskabel-unitronic-bus-2-x-2-x-0-22-mm-violet-per-meter-600618.html?experience=b2c&utm_source=google&utm_medium=surfaces&utm_campaign=shopping-feed&utm_content=free-google-shopping-clicks&utm_term=600618&qwer=Cj0KCQiAjJTKBhCjARIsAIMC448sO5VHiO6fgn3b4-g3WsA71s6G4AxOQqiTpf4TW_RYbL_DPUce_oIaAlbGEALw_wcB&utm_source=google&utm_medium=cpc&utm_campaign=NL - PMAX - Nonbrand - High&utm_id=17213980048&gad_source=1&gad_campaignid=17210850642&gbraid=0AAAAAD48pcjc27TfqxxOofxVVfQ4isBwn&gclid=Cj0KCQiAjJTKBhCjARIsAIMC448sO5VHiO6fgn3b4-g3WsA71s6G4AxOQqiTpf4TW_RYbL_DPUce_oIaAlbGEALw_wcB

The last slave in the communication bus must often have a 120ohm (just a normal 1/8W metal film will do) between the RS-485 A and B lines.
Some slave only use the A and B lines (if you cannot get it working, just swap the A and B and in 50% of the cases the problem is solved)
Some use also the GND signal.
It just depends.

Here are some of my catering related projects that are used very successfully. All communication is Modbus RTU RS-485 or TCP ethernet (often also both).

We do also many many bespoke projects using Modbus and Pro-face touchpanels. Feel free to ask.

We also do many revision work on existing catering equipment, replacing temperature controllers, replacing electrical power controllers (thyristors/solid state relays) incl. HACCP registration.

Here some of the projects to give you an idea of what is possible using Modbus in catering equipment (but there is many many more):
- Deep fat frying furnaces control: https://cascade.net/en/frymanagers/
- Universal industrial tilting boiling kettle control with recipe management: https://cascade.net/en/cascade-kettle-manager/
- Wireless 6 channel temperature datalogging into cloud based protected registration, also for HACCP, pharmaceutical/medical: https://cascade.net/en/easylog/
- Power management of electrical heating elements: https://cascade.net/wp-content/uplo..._Revo_C_REVEX_service_GP4116_V100_001_008.pdf
- Climate simulation: https://cascade.net/en/climate-manager-test-chamber-temperature-and-humidity-control/

But also in more heavy industry, modbus works marvellous and reliable:
- Heat-tracing: https://cascade.net/en/heat-tracing-temperature-control-and-monitoring-with-remote-scada-hmi/
- Metal heat-treatment / post-weld heat-treatment temperature control & datalogging, incl. remote operation: https://cascade.net/en/heatmanagers/

And I do these projects using the marvellous HMI/PLC touchpanels of Pro-face.
If I have an address list of Modbus registers of new equipment I never saw before......I have most communication with it up and running with these Pro-face touchpanels in just a matter of minutes (try that with complex Profibus fieldbus equipment......no way.....it once took me 1 week to read in just 1 bit of a Allen Bradley canbus fieldbus slave that was, already after 5 years, not supported anymore......none of this nonsense with Modbus: you have the modbus register address: so you're up and running in no time with it).

Japanese design Pro-face touchpanels with modbus RTU RS-485/TCP ethernet interfaces: super simple and easy to program using their GP Pro EX tool: https://cascade.net/en/visualisation/
Japanese built RKC Instrument (family owned company) temperature controllers with modbus RTU RS-485 interface: https://cascade.net/en/controllers/
Italian made CD Automation (family owned company) ultra reliable flexible power electronics/thyristors/solid state relays with modbus RTU RS-485 and TCP ethernet interfaces: https://cascade.net/en/thyristor-units-and-solid-state-relays/
Temperature sensors: also bespoke made according to your specification as well as calibrated when desired: https://cascade.net/en/thermocouple/

Have a great weekend, and looking forward to discussing with you.
Patrick Duis
Project Engineer
CasCade Automation Systems
Ridderkerk (near Rotterdam), The Netherlands

 

Patrick is correct on everything. My top three sources of Modbus RTU frustrations:

1. Wiring is probably the source of most Modbus RTU issues. Make sure you have the right cable, the terminations are absolutely perfect and you have the terminations correct. One inperfect termination could cost you hours.

2. The second source of issues is lack of documentation. Modbus is old (even older than me) and devices from earlier eras have gone through a lot of documentation revs. If you aren't sure, you have the latest doc telling you the address, format, data type and the rest of each register, test them to be sure what you have. There are a lot of good Modbus testing tools.

3. A third issue might be intermessage delay. Modbus RTU is sensitive to the time between messages. Not all devices will play together well.

John Rinaldi
Real Time Automation
Author of the Everyman's Gude to Modbus
https://www.amazon.com/Modbus-Everymans-Guide-John-Rinaldi/dp/1517764688

 

With home automation flourishing there's a lot of discontent with users who expect Modbus documentation, but many vendors apparently just do not publish documentation. I suspect they're aware of the support costs and just do not want to bear the support costs for a user community that largely expects "plug-and-play" technology, which Modbus is most certainly not.

 

Modbus in particular has devices that are almost 40 years old. Those devices have who knows how many revisions. Finding documentation for a particular device can feel like Christmas. Finding doc for the version of the device you have is like they say on the TV commercial "PRICELESS".

Best to just use a Modbus tool and look at the registers and coils and see what changes under what circumstances and go from there.

 

John is right on points 1, 2 and 3.
Extra about point 3: some slaves take time to switch from receiving to transmitting and visa versa. There is often a setting in your driver for that. In the pro-face driver that I use for modbus it is the wait to send setting. So the master activates the bus and waits an adjustable time before actually starting to transmit on the line. This is to let the signals on the line to become electrically stable so the slaves can read the message correctly.

 

After a very good vacation, I first want to thank you all for your insightful and enlightening replies.

Before Christmas, I was honestly quite proud of my steep learning curve with MODBUS. It felt exciting to work with low-level tools, explore devices directly on the bus, and then modify their behavior by writing new settings back to them.

However, after returning to work yesterday, I had to admit something a bit sobering.

Every time I now look at a stack of professional kitchen devices, it feels like a mountain that no one ever considered as a whole. From my perspective, it often looks like a combination of fragmented design decisions, and in some cases even poor procurement choices - but also a lack of a truly system-level, professional mindset from the solution providers.

That realization has been eye-opening, and probably a healthy one for me.

What genuinely bothers me is how much capability is left unused in these devices, while HACCP procedures are still carried out manually, despite the technology already being there for years. Or decades.

 

With home automation flourishing there's a lot of discontent with users who expect Modbus documentation, but many vendors apparently just do not publish documentation. I suspect they're aware of the support costs and just do not want to bear the support costs for a user community that largely expects "plug-and-play" technology, which Modbus is most certainly not.

That’s a fair point, and I’ll openly admit that my background also comes more from the home-automation / IoT side than from traditional fieldbus engineering. But I have a history from 90's when 9600baud RS-232 was a norm to access data outside from your home. So serial communication protocols are not new to me.

At the same time, I was very happy that (for example) Carel support was very helpful and gave all the documents as requested without any hesitation. Danfoss seemed to publish all the necessary things online.

I fully understand that MODBUS serves a very different purpose than modern automation: it’s simple, deterministic, and well suited for field-level communication. So I’m not expecting it to behave like a modern plug-and-play protocol.

Where I see potential is in bridging these worlds: using MODBUS where it makes sense at the device level, and then exposing that data upwards in a more flexible, modern way (MQTT, APIs, centralized logging) and particularly in regulated environments like HACCP monitoring. Node-Red has been a very enlightening experience so far, but I admit that I am still a novice.

So yes, I’m coming from the home-automation side. It’s about making better use of data that already exists, without forcing field devices to become something they were never designed to be. The biggest real world problem seems to be total lack of physical wiring and/or missing device configurations for MODBUS RTU.

 

I fully understand, that is why I always implement HACCP datalogging as standard in my equipment and give it to customers as an surprise.
They ask: can you also do HACCP?
I say yes: just stick the usb stick in and it logs the temperature with an adjustable interval into a CSV file.
It is very simple to do with a Pro-face touchpanel, it is standard functionality. Just a few clicks and ready!

 

Few questions about wiring. I have not seen any yet really

I know it should be logical chain with termination both ends and star-model is not supported. But how the device chaining is actually made in connector level? Double wiring (in-out) for every connector screw and some extra ensuring to move the unit out of its place?

For example: if there is already MODBUS wiring and you need to install a new device between two old units. How do you install the wiring?

And if there is many separate bunches of devices and let's say 50 meter distance between them each. Is it easier to install several TCP/RTU units than unite them by cable?