Hello, I am trying to read analog value from control Logix plc to the tag history, my requirement is to catch values between each 300ms in ignition for the analog sensor value. In the tag history, I enabled the tag history, and change the min time to 300ms. However, I can only see the value for each 10-12 sec.
Is there anything I miss or anything else i should do? thanks ahead for any suggestion!
You will have to put the tag in a tag group that reads that fast, before you can store that fast. Adjust the interval for your tag group (or probably create a new tag group just for the tag that runs this fast). The default read interval is one second, and the default storage policy is to store on change. You will have to set the maximum time to 300ms.
Thank you so much, my problem was exactly what you mentioned, I did not configure the reading part. Thank you!
I am running into a problem that somehow my data start to read every 9 second from plc while I am still putting the data in a tag group of executing each 300ms. I believe there is nothing has been changed. Is there anything that could influence this? thanks!
Did you add more tags in Ignition subscribed to that same Logix PLC? That could/would slow down any other tags. Older Logix PLCs also shared CPU time between tasks and communications: are there program changes in the PLC that would reduce available comms time?
FWIW, I don’t think you are likely to have satisfactory results with sub-second recording intervals with anything built on a query-response driver. (Like Ignition’s standard Logix drivers.) Such high speed tasks are precisely why I created my I/O-based Ethernet/IP Class 1 Communications module. You should consider re-designing your application to use an appropriate high-performance protocol.
Thank you for your advises, I did change things in PLC beforehand. However, right now I have changed back to before stage and have even less program that before, I still have the same issue. Is there anything that I should look at more? thanks!
I do believe it might relate to the change I made, but I changed it back, I still have the same issue.
What does the device diagnostics page in the Ignition gateway for this device look like?
I see the load factor at 1000ms schedule is 700%, is this the issue?
but the graph shows that all are generally finish less than 300ms
Yes, that’s probably the issue. Can you post some screenshots of that whole section?
Yeah, so, you’re requesting too much data too quickly and the device can’t keep up.
You can try messing with the Concurrent Requests and CIP Connection Size settings a little bit.
If there are only a handful of tags you need at a really fast rate and the rest can be slow then you could also move these to their own device connection that you use only for these tags so that they aren’t stuck waiting for the 400+ other requests that the driver is dealing with to service all the other tags you have subscribed.
Those are horribly slow response times. Logix should be responding in single digit milliseconds.
Thank you I got this fix by temporarily remove a big chunk of opc tags. But one interesting thing is that I have exactly tags in another ControlLogix drivers and they are working fine, but in this logix driver, I have the issue like this. Is this because of the different drivers?
Yes, that’s part of it. What firmware version is the device?
Rockwell disabled direct memory access starting in 20.19 and introduced a new “API” for accessing tags in v21+. It is not as fast as the old DMA method.
I think you are using the wrong driver, based on your logger name.
Then you must use the newer Logix driver.
But still, the response times should be single-digit milliseconds as @pturmel suggested. So either a bunch of other stuff is talking to the device as well or your network is b0rked. Or the comms load is just saturated.
edit: yeah, your screenshot has logs from a legacy driver… those are either there by mistake or you’re looking at a legacy driver hooked up to a PLC that cannot be running v30.11.
the logger:contrologixDriver was for something else, not the one we are talking about