Hi everybody, i'm quite new to Ignition. In a project with igntion 8.3.4 we're trying to write a list of tags with writeBlocking. The last tag of the list is significant since it will trigger a process with all values. We saw that sometimes this trigger before all tags are written. How does writeBlocking works internally ? Does it write tags in the same order given in parameters or is the order not guarranteed ?
To solve this for now i will split the write operation in 2 writeBlocking, first with values and second with the trigger.
I think you have a fundamental misunderstanding of what is happening here.
writeBlocking() does move through the list of tag paths sequentially. That writes the values to the Ignition tag server sequentially. Those values do not necissarily arive at the device in that same order.
Even splitting the write into two sepearte calls does not make this a sure thing.
Esentially what you have here is a race condition, this is a common problem though often it is from the other direction.
Probably the best way to get around this is to use system.opc.writeValues() which will write the values directly to the device.
Thank you for your answer ! I did forget to mention it is on memory tags with the system.tags.writeBlocking method (not OPC). So i was expecting to have more-or-less no delay except for the write-time since it writes in the gateway tags.
Not sure if i'm clear. Nontheless thank you for your answer
I can't imagine there being a sequencing issue with memory tags. Obviously I don't know all the in's and outs of the programming behind the function, but I would find it hard to beleive that there is any parallelism inside that function.
However, depending on how you are reacting to the trigger's value change, it could have something to do with scan classes.
Do your tags have tag change events on them which then run in response to your writeBlocking? Might be confounding things.
I believe I saw that memory tags don't need / wait for polling.
If all these are really memory tags I would think this should work right. Though you should also show all your logic - how are you writing, and what is the mechanmism you are using for your trigger tag?
I do have a script on the trigger tag value changes. If the trigger is true then it notifies another gateway that will read all these tags. When the other gateway is notified and read, some tags are not yet updated with their new value. This is why i suspected that the order is not guaranteed.
Once the gateway is ok it will send me a response and i will reset all my tags and set my trigger to False and wait for another writeBlocking sequence.
Ok so for future reference architiectural decisions like this are worth noting in your original post, the fact you have two gateways. I believe that is probably your issue here. If this was all executing on the same gateway it woudl be fine, but Gateway 2 looking at your tags on Gateway 1 is on a polling basis and so that tidbit about memory tags not needing to wait for the poll cycle doesn't apply here. That is my best guess what is going on based on what you've told us.
To avoid the issue I would, on gateway 1 upon the trigger being set to true, I would in that script grab all revelant tag values and include that in the payload to that you are sending to gateway 2 so that it has everything it needs in one message. Now gateway 2 poll cycle is immaterial as gateway 2's message handler has everything it needs in the message from gateway1, which should be the right values at time of sending the message over.
To avoid the possibility of races, since the implementation is opaque, is to use two calls to system.tag.writeBlocking(). One to write all the new data, and the second to write the new trigger. It is vital to examine the return value of the first call (a list of quality codes) to make sure they are all "Good" before writing the trigger.
