I've got the same problem as @nskoog.
i've try this solution but without result.
It's not working when the derived tag is in more than 1 folder level.
Any ideas?
Regards
can you provide a screenshot of your tag structure and how you’re configuring your derived tag?
This is my tag structure. I've found that each time i add a folder level in the derived Tag path i need to add an extra "../" in the source tag path.
Then it works.
But is this logical when the sourceTag path doesn't change?
Regards
Yes- because it’s relative to how much you’re nesting. Similar to directory access in linux, you have to direct how many folders out you need to go to reach your destination (think cp commands where you have a copy from x to y).
Normally you’d create a UDT encapsulating that tag structure, then youre relative paths should always be the same.
This is a UDT (Motor 1).
So to have always the same source path i sould put the sourcetag into a UDT and Nesting this udt into the udt containing the derived tags.
I'm correct ?
Regards
exactly. this way the source tag and the derived tags will always be relative to one another and your derived path will never need to change.
Hi at all,
I have created derived opc tags as indicated, all UDT and therefore all derived tags work correctly both in reading and writing.
My problem is, I created a button that via script sets 2 derived tags at the same time to value 0 within a parameterized popup:
the script is as follows:
if system.gui.confirm (u'Are you sure? ',' Confirm '):
event.source.parent.DVC_Popup.C_Moff = 0
event.source.parent.DVC_Popup.C_Mon = 0
Only the C_Mon tag is set because the values are changed in the same time, i thinkj before the update time of the OPC tag from which the tags are derived.
If between one tag and another I put a delay of 2 seconds the tags are written, I think because I give to driver time to update the OPC tag.
from time import sleep
if system.gui.confirm (u'Are you sure? ',' Confirm '):
event.source.parent.DVC_Popup.C_Moff = 1
sleep (2)
event.source.parent.DVC_Popup.C_Mon = 0
sleep (2)
Is there any way to avoid inserting this delay? or another way to write derived tags at the same time?
Thanks
Does the Tag Group these tags belong to have "Optimistic Writes" enabled?
That should be enough to make it work. How is that script actually causing a write to the tags? Are those custom properties bound to the derived tag or something?
Also what version of Ignition are you using?
I use version 8.1.3.
This tags is inside popup have custom properties with udt . Button set with script this property…
i think problem isn’t in popup,
I tried to click quickly in less than 1s in the tag browser to set the tags and always the last one gets changed.
I need to restart OPC connection before change “optimistic write”?
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 !!!! 
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.