TotalVolumes ramp upwards at different FlowRates ranging 3-10 per second.
In Ignition, I am reading TotalVolume as [PLC1]HRF3, [PLC1]HRF7, … [PLC1]HRF[3N+4].
I noticed that once my TotalVolume gets between 1000 and 4000 it gradually slows how often it updates the value in Ignition, and I realized it was because as the value gets larger Words[1] changes less often, and since Ignition is only subscribed to HRF3, 7, … it is only looking at Words[1].
I am first wondering if this is a practical way of learning/simulating Modbus TCP, real values, and reading them in Ignition, as I’ve gotten this far mostly by blindly following the advice of my favorite LLM. Secondly, if this is practical, then how do I get my Ignition tags to poll more often than Words[1] updates?
I don't understand your setup, nor your addressing. But it comes from an LLM, so I guess that is par for the course.
Modbus has 16-bit registers. So you need two at a time to carry a 32-bit IEEE float, and four at a time to carry a 64-bit float. Ignition types HRF and HRD use consecutive addresses automatically.
I don't use Codesys, so I cannot help you with that part, but setting up unions seems strange.
If using one-based addressing (the default in Ignition's driver), and packing the floats together, you would have addresses like HRF1, HRF3, HRF5, and so on. Or HRD1, HRD5, HRD9, and so on.
Maybe a screenshot would be more helpful here. This is the Codesys environment. As you can see, I’m using HR0 - HR18 and so forth. FlowRate is irrelevant for now, I’m just focused on TotalVolume. The first one starts at HR2, then HR6, …
My first attempt at this (not shown) was just using the REAL variables as-is in the hold registers. So, say “RampingTag” is a REAL and I mapped it to HR0, I would then go into Ignition and make an OPC tag for [PLC1]HR0. That didn’t exist, nor did HRF0. HR1 and HRF1 were both very large or very small value depending on if I had “Reverse Word Ordering” selected in the PLC configuration. So I asked the LLM for guidance and it said I needed to use a UNION so that I could read it as either a word array or a real value and so that word order would be predictable. I didn’t understand why, but after implementing it I was actually able to read the real value correctly from the PLC.
Do you know any other good resources for what I’m trying to learn? I’d prefer not to have to rely solely on an LLM for all of this. I’ve been using the Ignition forum and documentation for what I can, so I do understand what you mean by 16-bit registers, HRF, HRD, and consecutive addresses, but I’ve run out of resources trying to figure out how to make a float tag update when either one of its 16-bit registers updates instead of just the high one.
I haven’t had enough time to delve into Codesys stuff yet (I have been meaning to) so I can’t comment on that too much. But if you are trying to learn the Protocol works then you can use Modbus Simulators that run on your local machine or if you want to get really in-depth try using PyModbus / PyModbusTCP, they’re Python libraries that allow you to create Modbus Clients and Servers (and ModbusRTU Slaves & Masters). Doing these exercises are really help develop your understanding of Modbus.
Also, for testing your reads from the PLC try using ModScan32 / ModScan64 by WinTECH Software it’s a trusted industry tool and has been in use for decades. I have used it for years and most of the engineers I know use it. The free version of Modscan does have limitations (3minutes of reading before you need to restart the software) so as an alternative a free open-source version does exist of called OpenModScan which you can give a go!
Thanks for the support. If you say just using real tags as-is in my I/O map are more conventional than unions then I’ll focus on getting that to work.
I do already have zero-based addressing selected for my PLC.
Thanks for sharing the resources! I’ll check out ModScan for sure. I’m starting to get familiar with Codesys, so I’ll keep the Python libraries in mind if ultimately I can’t get my simulation to work.
If your goal is to learn Modbus via Codesys, you might find my Advanced Modbus module for Ignition to be more friendly (and focused) than CoDeSys. It provides both server and client Modbus driver types. (With a very detailed user manual.)
