Hi
I have these two udts. They are pointing to the same PLC tag/udt.
I using the same faceplate.
The first udt is made like these:
the bottom udt are using "document" and the each tag is Derived from the document tag :
When I press start/pause ect. button the function from to document udt, using the play/pause/stop button, that are sending a number into the the HMI cmd tag, nothing is happening.
Except when the stop button is pushed, witch is a oneshot button, then I get this message:
It works fin when I'm using the first udt.
Are there any restriction when using a document tag or I'm doing something wrong
Hi @Michael_Johannsen, are all tag in your db in TIA set to OPC UA Writable?
Be aware that due that with document tag it read and write the UDT in one big structure you can have override of data if between the start of the write by ignition and the end the plc change a tag value. It's matter of milliseconds but it happen more that you know. We have seen it in our last project.
Regards
1 Like
Yes all tag in the udt and also in the DB are writable from OPC UA.
This looks correct at the surface level. What's the UDT definition look like?
edit: make sure you are using a Tag Group with "Optimistic Writes" enabled for the UDT containing the source Document and derived tags.
In th HW config under OPC UA, we have the following option activated
Hi
I made an new tag group with Optimistic Writes and it didn't make any difference.
I have other udt (for items) made with document and it works,
But in these case I send the value to the PLC and then plc set the value to 0 when is have seen the value from ignition. In the Item udt the PLC doesn't reset the tag.
The other tags in this udt like "step", "Time left" ect. is only receiving from the PLC and it there is no problem.
Can it be that reason why I have trouble with this udt?
I have the same config in the PLC as @Arnaud_Declerck
Can you maybe share your DB or at list a picture of the structure?
I turns out that not all tags in the udt in the PLC was writable from OPC UA.
All tags in the the udt must be writable from OPC UA for this to work.
That's is what i though with my first message.
Don't forget to mark a solution for the people reading this post later.
regards
You are going to have race conditions if the PLC is updating other elements of that same UDT while you are trying to write. (Ignition will smash the other data, because it must write the entire UDT with the values it has at the moment.)
Really, don't do this. If you need the capacity of UDTs, use two. One that only Ignition writes to, and the other only the PLC writes to. For command signals, use an echo in the other direction, so the source can see it and turn the command back off. (Do not have the PLC turn off a signal that Ignition turned on. Not safe.)
1 Like
Hi Phil
Thank you for your comments, I have one question.
If it's not a god idea to have the PLC turnoff/reset a tag that ignition has turned on, why is the one-shot button made?
I like the one-shot button because it have the confirm request built-in.
And the second question.
If understand you correct, it is not enough to make 2 udts in ignition like this,
where you have a status udt and a cmd udt, because the document writes to the entire udt, no mater if the cmd udt has only to one tag in it?
So something else in Ignition can handle the rest. Like a gateway tag event script that monitors an acknowledge bit for a command.
Keep in mind that the advice to write in only one direction varies by situation: if a single boolean tag fired occasionally, and not used to style a UI, not much of a problem. As part of a larger tag that can only be written as a whole--a really big problem.
Correct, the tags must be separate "on the wire" when writing.
