Turn the logger for drivers.LogixDriver.LogixBrowseStateManager to DEBUG and see if a rebrowse happens at the same time you get write errors.
I think it’s possible you’re trying to write at a time when a write isn’t possible because a browse is in progress or the results of it are being processed.
sorry that is the wrong processor.
I did disable the automatic rebrowse for the PLC that I am having issues with.
Don't do this unless you are not making edits to the PLC program.
i dont see any debugs for that PLC with that drivers.LogixDriver.LogixBrowseStateManager
gotcha
Any updates on this @drinaldi ?
I’m having a similar issue where i get this error message, but it seems to be on random tags, for example when it’s on a button and i get the message, if i just click it again a second later, the write happens normally.
This happened at my client’s while using an Rockwell L33ER, and the L73 I’m using for testing at my office, both on firmware 31, Ignition is 8.1.13.
So this happens on two different gateways and PLCs, seemingly on random tags with no modification made on them, but the only times I’ve personally seen this happen is when someone is also online with the PLC.
I saw it occur today with a ControlLogix. It seems to occur when someone compiles/accepts edits. It takes about 10 seconds for OPC writing to function again. The scary part is that if you are holding a jog and then someone compiles/accepts edits, the bit is just stuck on ‘1’ until the OPC can write again, and then you have to poke the button again to get the ‘0’ to write on release!
Has this always been the case or is this new? Is there any mitigation?
It’s not really new. Every change someone makes online or every time a download occurs it forces any CIP messaging client (the driver, in this case) to re-browse and discover the new symbol instance IDs. During this time all reads stop happening and writes will fail.
Would turning off the automatic re-browse mitigate this? You said earlier in this thread not to do that unless no changes are made to the PLC, but can’t you manually rebrowse with a browse window refresh?
Now I think about it, does a browse refresh have the same effect?
No, those aren’t the same kinds of browse. The OPC Browser is just asking the OPC server what it currently has.
If you turn off automatic re-browse in the driver and someone makes a significant change the symbol instance IDs can change in the controller and Ignition will be reading/writing with IDs that possibly correspond to different tags or don’t exist at all.
Incredibly dangerous.
That said, I do wonder if some recent change has “widened” the window where writes where fail. Some time back we fixed a long-standing bug where a tag DataType change in the controller wasn’t reflected in the OPC UA address space until you edit/saved or restart the UA module or something. I wonder if something happened as a side effect of that.
I’m not sure how soon I’ll be able to dig deep into this, though.
I think I understand - it is an OPC thing.
I can say that a mere edit>accept edits in the PLC, with no actual change to either tags or logic, will trigger this condition.
I don’t think there is any bit in the PLC that can be used to clear jog buttons, or even detect this condition- so I guess extra care needs to be taken for now.
Thank you for looking into this, Kevin!
I have a support ticket open for this very issue - #39794. Just sent in a bunch of thread dumps.
Your issue does not sound like the same thing we're talking about.
I think your problem is solved in 8.1.15, under the changes introduced with the following release note:
Prevent the accumulation of Requests and long delays before execution while driver is not connected. This had impacts on memory usages and read/write timeouts from scripting.
I’m at 8.1.14 now. I’ll upgrade tomorrow and give it a try.
Following up: I can confirm that upgrading form 8.1.14 to 8.1.15-rc resolved my AB communication issues.
Kevin, in these cases where a write fails, will the tag quality change?
If so, then would it make sense (at least in an OPC context) to use a Tag Change script per pushbutton tag to write another zero on every transition to ‘Good’? I would like to, at least, clear pushbutton bits after a quality drop is cleared. But would a tag.writeBlocking() actually trigger an OPC write?
I don't think the tag quality changes, just the write returns a bad quality.
Yes, it does trigger an OPC write when the tag is an OPC tag.
Would this ‘bad quality’ return from the write be anywhere it could be caught with a tag change script (or something else?) to do what I was trying to do?
I figure you must be at least as busy as I am, and I want to be sure you know that I appreciate you taking the time to respond to these questions as I plumb the depths of what is possible!
