I stumbled upon this problem daisy chaining from a previous problem.
Luckily I think this one should be easy to fix and I am just overlooking/misunderstanding a setting within the driver settings.
After wire-sharking the TCP connection that I am using to send Modbus TCP packets to a hardware gateway and on to a controller, I noticed that what I set the “Max Holding Registers Per Request” to is what Ignition asks for - it doesn’t seem to know what it is really looking for.
Example : I have 5 tags for a setpoint. These are at 40300, 40301, 40302, 40303, 40304. I had the setting to the default of 125. When this was the case Ignition would poll these five correctly…but also the 120 registers after these which makes these data requests huge - eventually just drowning the controller in useless data.
Now on the other hand : I have a large span of tags that I also need data (~1500 registers) with 125 registers this is still 12 requests, but if I set the Max HR per request to 5/10 to accomidate for the other registers this skyrockets to 300 requests and for a bps of 19200 this bogs down the controller in simple requests…not data.
I am sure there is somewhere in the settings that allows Ignition to only ask for what it needs and I am just missing the proper format.
I would assume it would be in the address set up of the controller - I have each “set” of tags in an individual definition on the table. To me this would mean that Ignition shouldn’t even know that the registers after the ones I have defined exist. Is this incorrect?
Unless there’s a bug, the behaviour you’ve described is not quite what happens.
By default the driver attempts to minimize the number of requests. The primary way this is accomplished is by spanning gaps between registers, up to the max register setting (default 125).
This means a request for {HR1, HR2, HR3} would request only HR1 through HR3 (3 registers), but a request for, say {HR1, HR2, HR10} would request HR1 though HR10 (10 registers) instead of using 2 requests to fetch HR1 + HR2 and HR10.
You can disable gap spanning entirely with the advanced “span gaps” property. You can also play around with lowering the amount of registers that can be requested at once, as you’ve found.
Either option is going to increase the number of requests required to get the data you’re asking for, sometimes dramatically.
If your data is distributed sparsely across the register range you’re going to have a bad time trying to reduce requests/traffic…
I actually went through all those options through 64 registers disabling/enabling gap spanning. I attached my data for it - not all of it is relevant for the question.
I will wireshark the 125 register requests to have an example shortly
EDIT: Here is the example of the packet size being consistent.
The second image is the request and the response. I understand what you mean about the wrapping and I guess it is not useful in this case.
EDIT 2 : After re-reading the context I understand what you meant by the wrapping. If you are asking for an assortment of registers it will make your packets huge.
Basically what the optimizer in the driver sees is that you want 2056, you want some stuff in between, and oh look, you even want as far as 2181 (part of the 2174-2514 range)! So one request it is, to 2056 for 125 registers, because that covers 2056-2073, 2089-2173, and part of the requested registers in 2174-2514.
The optimizer doesn’t that you’ve grouped these conceptually into something else. It just sees registers within a range that fit into one request. It doesn’t know whether a certain register contains valid data or not, and the only way to influence that is with the span gaps setting.
After re-reading the original response I understood what you meant - I removed the mapping because it wasn’t all that useful to someone else who comes looking.
Thank you for the help!
Is there a configuration that will allow Ignition to pull more then 1 register if it is sequential but if there are un-needed registers to form a new request? Wrapping makes every response 313 bytes and non-wrapping makes every response 67 bytes. One causes too much data, the other too many requests for the controller that I am attempting to use.
[quote=“c_hurd”]
Is there a configuration that will allow Ignition to pull more then 1 register if it is sequential but if there are un-needed registers to form a new request? Wrapping makes every response 313 bytes and non-wrapping makes every response 67 bytes. One causes too much data, the other too many requests for the controller that I am attempting to use.[/quote]
This is exactly what span gaps = false will do, so you must have have far smaller groups of sequential registers than you think you do.
Note that the driver is only optimizing for registers actually subscribed to, so the ranges you might have mapped aren’t necessarily the ones being optimized unless you’re subscribed to ALL the items in that range.
I have tried changing a few settings and layouts to get a response larger then 67 bytes and I have had no luck.
From 40001 to 49999 I have 3676 tags at the moment. I know at least a few are sequential . At the moment I have them all set to the default scan class (1000 ms slow rate 10000 stale timeout, subscribed, direct) I don’t expect this to work for any real application, I just needed a stream of requests. Is it possible that because it is trying to pass so many requests that it isn’t catching that the required tags are sequential? Looking at 5 minutes worth of wireshark I do not see 1 packet that is larger then 67 bytes response.
I have also tried 2 different addressing methods - 1st being just give the addresses that I will actually use (~100 different address “blocks” on the gateway menu) - 2nd being a single address declaration which gives 9999 OPC tags and I only tag the required values from the designer. (1 “block” on the gateway menu)