Hi ,
sorry i have another issue, if i set a bit of derived tag json(RESET_ALL), and this bit is resetted from plc in real time with plc time cycle, in ignition this bit stay at TRUE, but in plc is FALSE.
Why? If this bit is not resetted from PLC is updated correctly.
i have the modified parameter in config “wrapper.java.additional.2=-Dignition.tags.processbackfill=true”
Thanks
What version of Ignition are you using? Does the Tag Group have “Optimistic Writes” enabled? Did you restart Ignition after setting that parameter in ignition.conf?
It might be easier to call support and troubleshoot this with them.
Version 8.1.4, Optimistic write enable, and restarted gateway.
If i set “read after write” in Tag Group it seem to work… it’s ok to set this parameter?
It’s okay… but I’m not sure it should be necessary.
Turning the logger tags.execution.actors.opc.writemanager to DEBUG level might log some useful information. You should probably call support and troubleshoot this live if possible.
Where i set this parameter to DEBUG?
Please call support.
With “read after write” in log after registering , there’s an event updating to read value at false when resetted from plc.
Without “read after write” in log there’s only event registering and not updating.
Is your optimistic write timeout set to 1 minute? What if you lower it to 5 seconds, does the value fallback/revert after 5 seconds without read-after-write enabled?
So, everything is working here, it’s just not ideal. Here’s what happens:
true to the variable in the PLCfalse more or less immediatelyfalse, the same as the previous value it reported, so there is no change to report to the client.It seemed broken because your timeout was set so long. Ideally you want to avoid this kind of scenario where both the PLC and an external system can be writing to the same tag. Using read-after-write if you know this is the case may help, but it’s still race condition prone.
FIFY. It really is an unfixable race. Just don't do it.
@Kevin.Herron is the escape flag:
wrapper.java.additional.2=-Dignition.tags.processbackfill=true
still functioning after 8.1.3? I opened a ticket with support regarding this issue and they pointed me towards this post, which fixed the issue in 8.1.3 but testing on gateways at 8.1.4 and 8.1.7 I am seeing the “old” behavior again where if I call system.tag.writeBlocking() against multiple tag paths only the last write succeeds.
I’m not sure that option and the scenario you described have anything to do with each other.
Can you start from the beginning with the problem you’re seeing, preferably in a new topic?
Hi , i have installed version 8.1.7 and problem writing 2 tags at the same time seem have old problem again...
I have this setting of tagGroup:
I turning the logger tags.execution.actors.opc.writemanager to DEBUG and this is the output:
Logger write : "Canceling previous write [tag=[default]ZONA_100/DVC/ARR_1/_jsonUDT]",
I Write the 2 tags with Script in a button (write to custom property UDT passed to template) :
event.source.parent.parent.DVC_Popup.C_Mon = 1
event.source.parent.parent.DVC_Popup.C_Moff = 0
How to solve this problem again???
Thanks
UPDATE:
if i write two tags directly , not passed from template custom property:
paths = ["[default]ZONA_100/DVC/ARR_1/C_Mon",
"[default]ZONA_100/DVC/ARR_1/C_Moff"]values = [1,0]
system.tag.writeBlocking(paths, values)
It work............... Why?
Thanks
2 posts were split to a new topic: Bad_DecodingError reading S7-1500 struct
I am struggling to get my OPC tags to work with my UDT in the PLC
I have an S7-1200 connected using the OPC server in the PLC.
I have watched the Inductive University video on connecting UDT using the parameter function but my OPC item path in the tag is totally different.
I have also read about a drag and drop function but I cannot find a video that explains it.
Is drag and drop possible with a Siemens PLC?
thank you
Drag and drop works, you’re not doing anything wrong really, but when using this “Service Interface” mechanism in the S7-1200 we’re not able to read structures.
