We had an Edge device go down. I restored a backup and matched everything to the old system (Gateway Name, etc).
What is the best practice to add the replacement to the system? We have historical data that needs to be maintained. We want to make sure to not add a new device to the database. Do I remove the gateway Network Connection of the old Gateway first? Then add in the new one? Or will the same named Gateway replace the old if we do it as is and leave the existing?
Connected the new device with the old name on it. Waiting to here how to approach this. I do not want to add a new record in the database. Was told this should replace the old Edge device. Should I approve (will it overwrite) or should I remove the existing then approve the replacement?
Green is what is there now (dead device).
Blue is the device that needs to replace the old.
I have 3 device connections with historical data. 2 are Modbus TCP and 1 is a Logix PLC.
We upgraded from 8.1.29 to 8.1.53. The Opto22 finally had updated software. Prob should have maintained the old version, but we needed the increase in historical buffer. From 7 days to 35 I believe.
I had a new issue with the Logix driver causing an overload and not updating on the tags. Had to bump the CIP Connection setting to 4000 to get it talking. Not sure what changed on the driver.
My latest issue is the historian does not seem to be updating.
Sounds like you’ve a few problems, perhaps some unrelated to the upgrade?
Logix driver overload:
Lots of info to help with this problem over here (tip - wait to click the link until you’ve time to read the entire thread)…
Historical data retention:
Note that Ignition Edge is also limited by the number of rows of data that you’re collecting (at time of writing, I believe the limit is 10M). To check your current data collection, head over to your Edge gateway config webpage, then “Status” –> “Connections” –> “Store and Forward” –> “-Historian-” –> “Details”. Under “Local Storage”, you should an indication of “-used- / -total- Records”. If -used- is >= -total-, then you do not have 35 days of retention.
Edge –> Full Sync Services
What metric are you using to gauge that the Historian is not updating? If the metrics from #2 are updating, then Edge should be collecting & historizing the data. If Full gateway is unable to see those records being periodically sync’d, then there should be some breadcrumbs for additional troubleshooting in the logs (start on Edge @ “Status” –> “Diagnostics” –> “Logs”).
Setting CIP Connection Size from 500 (default) to 4000 fixed the comm issue. Will read up and see if anything can help from what you posted. Seems to be good now. We are using UDTs. Never had an issue before the version was upgraded.
Looks to be recording. I did see some data on the main Gateway. Does it take a bit to get caught back up?
I'm unaware of any changes between versions that would cause a drastic change. I speculate that optimizing tag requests on startup has always taken a long time, but eventually ‘worked itself out’. Theres a chance this would have been observed on each gateway restart with the old version? Regardless, I'm glad it's fixed! Do verify that your device’s overload % is around 0% for a majority of operation.
It can take awhile to catch up. Data publishes in batches from a FIFO queue (oldest first). You can estimate this time period by checking your Edge Sync settings on the Edge gateway, where batch size and publish period (perhaps also a schedule) are configured.
Those are the newer compact logix. They have a dedicated comms processor so it should be increasingly difficult to have such terrible comms with such a small number of items. Is this device not local to the gateway that is connecting to it?
Strings are terrible for performance if you're not careful. They're actually UDTs with 86 bytes each regardless of the actual string length, and that's if you're using the standard string and not some larger version. Total waste to poll at all if they never change, and expensive to poll often if they do.
Curious as to why we did not have this issue before. So far it seems to be working again. I was reading the strings to confirm the device from the vendor. We have tags that are generic. The PV associated with the tag name was helpful. Luckily we don't need to read them anymore.
Those are the newer compact logix. They have a dedicated comms processor so it should be increasingly difficult to have such terrible comms with such a small number of items. Is this device not local to the gateway that is connecting to it?
The device passes through a mGuard via a NAT. It is local to the network.
Looks like you’re able to zero in on the issue (string tags). How many strings are you reading in? How many requests are in the poll group which is reading strings in? I have a hard time believing that a few strings would contribute to several seconds of polling delays, especially with your current processor.
If you can, share a screenshot of the other poll groups.
I pulled info from another Edge Device that is running an older version of Ignition. No issues. Same data. This one is running 8.1.21. What changed on the Logix Driver between versions?
For consistency I am going to disable the string tags on this site aswell.
