At one of of my customers I have 17 historical transaction groups running. Of those 17, 16 are working perfectly. Unfortunately, the other one keeps producing poor quality data. The device is a CompactLogix L32E that is using v18 of the Allen Bradley firmware, all other Logix devices devices are using v16 or v17 of the firmware. Is there something about v18 that could be causing this?
I am running Ignition 7.1.8
Is there anything in the logs that would indicate the gateway is losing communication with the device? I’ll ask around about that revision (I remember hearing that particular versions might have been more prone to timeouts), but any further information as to what the gateway is seeing might be helpful.
Regards,
I am still learning my way around Ignition. What log/s do you want me to look at?
Ah, right, should have been more specific.
The easiest thing to look at is the “wrapper.log” file in the install directory. You can look at the most recent logs in the gateway by logging into the config section and clicking on “console” on the left hand side, but everything shown there is stored in that log file as well.
If you want, feel free to email that file to support@inductiveautomation.com or post it here and we’ll take a look at it.
Regards,
A little more information if it might be helpful. Looking at the data as it is coming in on the OPC status page, 5 of the 53 tags are coming in with “no data available” for quality. The tags seem to contain the correct data. All five tags are float4. There are other float4 tags within the group that are working correctly.
Hi,
Sorry for the late reply- I tried asking various PLC engineers if they knew of any particular firmware problems, but there wasn’t a consensus.
What’s the name of the device with the problem? The logs show a number of timeout errors, but if we know which one to look at in particular, perhaps we can notice something different.
Version 7.2 has some new device diagnostic features that could help track down what’s going on, but if you don’t feel like it’s a good time to upgrade, perhaps you could try increasing the communication timeout (default 2 seconds) on the device configuration, and perhaps increasing the “concurrent requests” (default 1- try setting to 2).
If you’ve already modified these, let me know what the currently are set to. These settings can help, but it depends on the cause of the problem.
Regards,
The device is CP2B. I haven’t tried adjusting the settings but I will based on your recommendation. I expect to upgrade this system to 7.2, I was just waiting a little while for debugging since this is a production system.
Interesting… out of all the devices, that one actually has the fewest messages in the log. One connection timeout error, and then nothing else.
I understand not wanting to just jump in and upgrade the system, so try what I suggested above first. One of the guys here also suggested using RS5000 Task Monitor to try and see how busy the processor is, if possible. I don’t have specifics on what to look for, but seeing if the processor is overloaded on the communication side could help narrow down what’s going wrong.
Regards,
I tried increasing timeout to 4 seconds and concurrent connections to 2. Neither change helped. I looked at task monitor and this PLC is hardly working. Its a new one that might be expanded later but for now CPU activity is so low it should have nothing to do with it the problems I am seeing.
It is always the same five items that are causing the problem. Sometimes they’ll work for a few minutes after refreshing the browse. They are float4 values and they are the last 5 data points in the transaction group of 53 data points.
I’ll upgrade to 7.2.3 when it comes out. When is it due?
I suspect 7.2.3 will be released around thursday. In the mean time I see if there’s anything else we can look into…
Regards,
Upgrading to 7.2.3 fixed the problem. 