I have a modbus OPC Kepware server setup that I need it to update as the data comes in. It basically has counter tags in it that counts up. It seems to be working fairly good with the settings I have it at now but it still misses a count every now and again it'll go 101, 102, 103, 105, 106, 107, 108, 109, 111. Is there another setting I can change. I just created a new tag group and set it to as fast as it can go. Is there anything else I can do to speed it up more:
You cannot magically make modbus go faster, and putting kepware between Ignition and the device will make more opportunities to miss stuff. You certainly do not want the Data Mode to be "polled".
Sampling and publishing intervals of 1ms are just ridiculous for Modbus.
Why is this Modbus? (High speed things are usually done with I/O protocols that can handle them.)
How fast is the counter running, and what happens when you miss a count?
It's part of a lot of other information that comes in like product number, counts failed vs passed, weight of current product. It's for a scale. And basically they want to be able to track it for analytic purposes so missing one would throw there analytics off since the data wouldn't be complete
Stick something at the device to collect data and send it off in chunks at a slower rate. Click PLC's from Automation Direct are pretty cheap.
Modbus has a very small max packet size and can only do request/response transfers. It simply is the wrong protocol for high-speed traffic.
How fast is truly new data arriving?
Are you able to change the device's program to make batches of data in a ring buffer?
Well when the machine is running they can expect maybe about 62-68 products a minute
You can probably make Modbus do this with a custom designed data table organized as a ring buffer of structures. It can be tricky to make the PLC code deliver and flag the data such that data that belong together are read and recorded together.
You should share more details about the device, it's register layout, and the data you are trying to capture.
The line is basically of boxes packaged material. It is the last spot that takes the weight of the package and determines if it is under weight, over weight or proper weight. It then adds the weight to the total weight to determine if something is too far over weight, what the average of the whole run is and so forth. While this is going on through Modbus it sends this data live over to a Kepware Server the data includes (currentWeight, CurrentProperCount, currentWeightCount, currentUnderwightCount, total weight, Average weight, TotalCount and a couple of other information belonging to the current box on the scale. All this information is suppose to be captured by Ignition and stored in a db where then a report is made showing each box that has gone through organized by totalCountNumber in a csv. So to give an idea once this is all done it should show:
TotalCount = 1, CurrentWeight = 100g, CurrentProperCount = 1, UnderweightCount = 0, Total weight = 100g
TotalCount = 2, CurrentWeight = 100.25g, CurrentProperCount = 1, UnderweightCount = 0, Total weight = 200.25
TotalCount = 3, CurrentWeight = 45g, CurrentProperCount = 2, UnderweightCount = 1, Total weight = 245.25
And so on.
That is why I need a consistent count of the numbers so that no count is missed. Is this possible with what I have? It almost always catches it now but maybe the 7th or 8th count skips. It'll go
1,2,3,4,5,6,7,9,10,11,12,13,14,15,17,18,19,20
So I miss two values in there.
This should be achievable with ~300ms tag group rate. That you cannot do it suggests the fault is not in Ignition, but probably in Kepware. You should try directly communicating with the device from Ignition. Turn off the Kepware connection so it cannot interfere.
If Ignition doesn't have a LAN connection to the device, you're probably [expletive]ed.
Ok I will give that a try on Monday when I get access to the machine again. In the meantime what should my settings be set to on the tag group
Not at a computer with Kepware, but there are settings in Kepware for client scan rate. One setting is something like no faster than 1000ms or whatever it's set to. Make sure it's set to respect client requested scan rate.
Yea on the Kepware side I have set at the respect client that's how I managed to capture at the speed it's capturing now. Before it was grabbing every 3 or 4 seconds now it's at least grabbing faster but still missing a couple
Just wanted to give an update on this. I noticed that if I disable the Kepware connection to Ignition and run a quick client on Kepware the information comes in without missing anything at all. If I enable it back in Ignition information slows down and then as it was before data becomes slow on Ignition and the quick client
Change your tag group settings.
Use Subscribe mode.
Under the OPC UA settings, set:
- Sampling Interval 10ms
- Publishing Interval 500ms
- Queue Size 100
10ms may not be realistic, but you can certainly ask Kepware to try.
edit: I think I misread earlier posts, thought you said 60-68 per second, not per minute... you can slow this down.
Are you still using the ridiculous one millisecond sampling rate in your Ignition tag group? For the product pace you describe, a 300 millisecond sampling interval would suffice. (I would have it publish at 300ms, too.)
Ok here is my updated settings. But data is still being missed. Even more now before it was missing 1 every couple of counts now every count its missing 1 after
A publishing interval faster than the sampling interval is harmful.
Sorry I changed them both to 300ms but still skipping information
"62-68 changes per minute" isn't actually enough information to know what the sampling interval should be. Are the changes uniformly distributed (every ~882ms) or are can they come one after the other really quickly? faster than 300ms?
1 Like
They technically could as its a boxing machine. So it just depends how fast they are going but on Kepware if I set the poll rate to 200ms it works as expected