I have a Modbus device connected to Ignition. This device uses two int registers for storing values: base value and scale factor, such are also my device tags. Then I have another tag, an expression one, whe I calculate the exact value: (base value) * 10^(scale factor). I have used the default settings for tags. Sometimes it hapens that scale factor is changed before the base value (or vice versa) and therefore my expression tag jumps to the wrong value.
What would be the best approach in situation like this?
Do you mean both tags should get updates at roughly the same time, but they're not exactly synchronized so there a time gap in which the value is wrong, while waiting for the second tag to update, after which the correct value is calculated ?
I'm not sure I can help with that, this is really not my field, but if both registers are contiguous, you could try to have a tag read both at the same time (read 64 bits once instead of 32 twice), then use an derived tag to process the value, with a read expression like ({source} >> 32) * 10^({source} & 0xffffffff)
That's a bit hackish, I admit, but it's also simple.
1 Like
Yes, that is the case: value is wrong between the updates of the first and second tag. This is visible as a spike on history charts.
I have now changed execution mode on my calculated tag from "Event Driven" to "Fixed rate". Another solution that I wanted to try was the tag history sample mode, which is currently set to "On Change".
This is probably not a good solution, as you can still be unlucky to be inbetween updates.
I dont know the correct answer though.
I'm never really busy with those things, I find it really weird why you would receive two seperate values that you have to combine again, unless there are different things you can do with them...
Perfect use of a derived tag I would think?
Condier using a gateway timer script using system.opc.readValues(), as this will read directly from the device and not the tags.
Won't solve the problem of tag value arrival order.
This is the only solution presented so far that will actually work.
(Assuming both registers are updated atomically in the device. it solves it on the Ignition/driver side though.)
1 Like
Hah! Just fast enough to preempt that caveat from me. (:
1 Like
There's not much you can do from ignition if they're not, is there ?
No, that's out of our control.
Changing execution mode from "Event Driven" to "Fixed rate" solved the problem. It makes sense. Event driven mode updates the expression tag every time one of the base values change. When scaling factor is changed (not very often), the base value also has to be adjusted. Calculated value is updated two times. Although these two updates follow each other very fast, there is an incorect value recorded in between.
Why there are two separate values: because it is a Modbus device which can only expose integer values.
Is it actually an issue that there's an intermediate value for a tiny amount of time ?
I mean, if you're worried about incorrect values, having a fixed rate will also make you have an 'incorrect' while waiting for the next read.
If it's an historian issue, I'm willing to bet there are ways to deal with that.
Also, I'll repeat my suggestion of reading both values as one 64 bits value if the registers are contiguous.
2 Likes