OPC UA struct data type?

No that shouldn’t be necessary. Let me see if we can reproduce this here, it’s possible that something is broken right now.

Ok thanks,

if i make this two tag not derived but OPC with correct path ( but it is not performing as explained in post above) it work perfectly.

My opc server is S7-1500 siemens.

Hmm. I cannot reproduce this unfortunately. I think you will have to call support and open a ticket so this can be tracked and investigated.

Are you running the Designer on a different computer than the Ignition Gateway by any chance?

No is in the same computer…

Ok thanks…

Hi,
today, i don’t know why, I can set the 2 bits C_Mon and C_Moff at the same time, but if I change a value from the plc, the status in the tag is not read …

The strange thing is that if I force it from the browser tag I write and read …
if instead I set the same tag in the plc, it does not change the status in the browser tag.

Today I just turned the system back on without making changes since yesterday …

PS: if i’m not force tag from struct in tag browser, i can read from plc
if i force one time, write to plc, but nor read any tag of struct

Can you try editing your gateway’s ignition.conf and adding this parameter to the “Java Additional Parameters” section:

-Dignition.tags.processbackfill=true

It would end up looking something like this:

# Java Additional Parameters
wrapper.java.additional.1=-Ddata.dir=data
wrapper.java.additional.2=-Dignition.tags.processbackfill=true
#wrapper.java.additional.2=-Xdebug
#wrapper.java.additional.3=-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=*:8000

You will have to restart your gateway for this to take effect.

perfect… now work !!! :star_struck:

Thanks a lot…

I had the same issue and just thought it is what it is. What does this process backfill do?

In something like 8.1.1 or 8.1.2 a change to the tag system was made where values that come in with timestamps older than the current one are treated as historical values and stored if history is on, but otherwise ignored when it comes to updating the value or running scripts etc…

This flag is an escape hatch to revert to the previous behavior, and it’s a good thing it’s there because the change wasn’t very well thought out and we’re chasing down bugs and side effects of it right now.

2021-04-27 17_09_33-Window

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?

https://docs.inductiveautomation.com/display/DOC81/Diagnostics+-+Logs#DiagnosticsLogs-ChangingLoggingLevels

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?

I put 2 second and work… Thanks a lot

So, everything is working here, it’s just not ideal. Here’s what happens:

  1. you write true to the variable in the PLC
  2. the PLC logic writes it back to false more or less immediately
  3. the variable is eventually sampled and it sees false, the same as the previous value it reported, so there is no change to report to the client.
  4. the optimistic write timeout elapses and the value is reverted to its previous value.

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.