I wanted to experiment Node-RED with some device using Modbus. I already worked with many different types of interfaces but never did a project with Modbus protocol. It happens that my electronic bench power supply has a serial interface with this capability. This is quite impressive as this protocol is normally found only in advanced instrumentation devices as well as on industrial devices. This small and cheap power supply has an extremely good cost/benefit ratio and is widely used by the hobbyist community (tons of good of reviews on youtube channels). Just to explain for those who do not have the feet on electronics: this is an adjustable DC-DC down converter that delivers stable (low noise, low ripple) voltage and current to its output. We can power a wide variety of electronic boards (like Arduino, esp, SBCs, etc), circuits and sensors with such power supply. Data can be visualized in a nice but small OLED display. The power supply has a bank of 10 preset memories where we can store voltage, current over protection values (for voltage, current, and power) and brightness of the OLED display. On the negative side changing the values stored in the memory is far from friendly. It is necessary to press the keys and the rotary encoder of the device quite many times for a simple change.
The manufacturer even provides a desktop application that runs on Windows, and it works well, but I decided to spend some time to design my own user interface. It is not that the original software is not good. I just wanted to gain more experience playing with the dashboard. I estimate that I spent one day working on the logic flow and on learning how to use Modbus nodes and four or five days playing with the dashboard design.
A couple of pictures from the Windows software from the manufacturer:
I will resume this project in the future aiming to add some features from the original software: the capability to preset memory values and the ability to run scripts to automatically change output voltage/current over time. When this is done I will make this project available in github (but not before that).
All in all the project was easier than I first thought. So far the flow is clean and easy to maintain. The dashboard design seems acceptable after several changes. I can scale the amplitude of the charts with three sliders which is good to improve the visualization.
The data shown is the dashboard is real-time since Modbus node is polling the device at a fast rate. By the way, there is a major difference between the original software and the Node-RED version. The first thing the original software does, after establishing the serial connection, is to lock the keyboard (and rotary encoder knob) of the power supply so any control is driven only by the software. In the Node-RED version, I can control and change parameters in any side (device or dashboard). When I change something in the device the change is quickly updated to the dashboard. When I extract (copy values) from a preset memory to the working memory (bank 0) in Node-Red the device is quickly updated.
I continue to be astonished that Modbus is still used. I first met it in 1980 and even then it was a horrible interface. You only have to look at the number of questions here on decoding/encoding modbus data to see that. The fact that that this arcane protocol is still in use nearly 40 years later is beyond my comprehension. I would not touch it with a barge pole unless there was absolutely no alternative.
This is not in any way to be considered a criticism of this project of course, merely as me having a rant about the protocol itself.
Not really so bad! Modbus has been a de facto standard for a long time, especially for the communication between PLC (Modicon) and Computer. I've developed "drivers" and applications based on it for many industrial companies.
But I agree! it's a quite old protocol and I didn't use it for almost 20 years.
one of the great advantage about the communication protocol is its robustness.
I have been in building automation for the pased 20 years, and used many .
Lon, bacnet mstp and ip, N2, CAN, MODBUS and many others...
My job is integration and troubleshooting.
Modbus is an old master slave. not considered very efficient, without any auto discovery and so on, BUT... on a pair of wires in RS485, you can use any crappy wire, and run amazing distances up to 4000 ft, and in most case will work quite good.
I have ben to places where they had CAT5 running 4500ft with zero errors.
I agree about the way the data need to be processed can sometimes be challenging,
if you get any industrial drive unit , they always have modbus as the default protocol, as it is very resilient, and still a standard among all industrial controllers and PLC.
also note that China is playing a large part reintroducing this protocol into the market. There is no license to use Modbus unlike Bacnet for example. Modbus is a low cost solution for networking anything.
I will add that Modbus works very well trough most wireless such as xbee, BT , wifi and other similar mesh and non mesh networking layers... you can basically turn anything modbus into wireless with off the shelf hardware and very few timing adjustments.
long explanation, but many reasons why it is still in use ...
hope this help !
Hi @drmibell, as a matter of fact, I never took the time to resume the project and add the couple of features that I wanted. What is done so far is working good so I guess I will make it public as soon as I am back home (for the last testing with the device).
Have you made the code for this public. I am working on a project where i need to control 3 of these power units via nodered, your code would be extremely useful! Great work.
The reason that I was astonished (the post you replied to was over a year ago) was that there doesn't seem to be an obvious alternative to what is now a 40 year old protocol. I can't think of much else in IT from that date that is still in regular use.
Agree that Modbus probably should have been strangled in its cradle, but depending on what you mean by "regular use", there are still some old-timers out there, some doing better than others.
At the risk of thread hijacking, putting in my two cents here, just cause I like to talk Modbus.
COBOL is still used in business, and FORTRAN 77 is still widely-used in academia and numerics. Ada is still used in avionics. C++ isn't too much older..etc.
As a controls engineer who deals with Modbus on a daily basis, and has implemented TCP/RTU clients in several different programming languages....I can say that even though Modbus kind of sucks, it's stood the test of time because of ease of implementation. I haven't seen a lot else that does the same and is as simple. I have a TCP/RTU client Python code with scheduler and no external dependencies except pyserial that's a little over a page long. OPC, EtherNet/IP, etc. are much more complicated....
The governing (Modbus) organization has come out with a secure version, Modbus/TCP Security, which is basically Modbus TCP + TLS encryption, but it probably won't catch on, no one wants to deal with certificate nonsense.
I've only recently become acquainted with MQTT, but it really seems like it will be the logical successor to Modbus, as it improves upon many of the weaknesses: having to convert types, only supporting certain types (no one really does anything with text), and having numeric register addresses instead of human readable labels (topics).
What keeps Modbus (RTU) around is serial connections...don't really have a better choice that I know of. Think Modbus is bad? Try dealing with HART, which is actually newer than Modbus, but crappier, slower, and less reliable. It would be nice to have MQTT v5 over serial.
Yes I agree 100%, plus if you need a more sophisticated set-up, Modbus can be transmitted through a TCP/IP network either as native Modbus TCP or a Modbus RTU over Ethernet. The first is its one implementation the second one can use off the shelf hardware and you can make an old device only supporting Modbus RS485, talk on routed TCP/IP with near unlimited distances wher it can be accessed from. I also can confirm that Modbus works great through wireless when the polling master can be configured to be forgiving for timeout timing as it might take a bit longer to get an answer. Try this with a "newer" protocol with tight timing and you will go nowhere.
