Ignition loses connection to OPC UA server and when reconnecting, ignition sends multiple values

Ignition
,
1

Hello Forum,
we have this issue:

we have a script that triggers every 4 seconds (due to a tag change of a timer in an expression tag that goes to true every 4 seconds (getSeconds()%4=0), and when that happens the function gets triggered) (I don't know it's not implemented with timer script, but this is our case anyway).

this script writes to an OPC UA server ( with a function that gets a list of paths, and corresponding values) and the script does writeblocking.

After that we have a function that writes data to our database just after writing to the OPC UA server (a remote database).

What we notice is that when the connection is faulted between the opc ua server and our ignition, the data sent is not sent or gets sent in an unusual periods and after that we get the connection back, Ignition sends multiple datapoints to our database (and it feels like he sent all the missed data when we were not connected to the OPC UA server)

This is how we are triggering the script:


if not initialChange and newValue.getValue(): #can this get triggered multiple times (and not every 4 seconds? when the expression function of the tag change is going from false to true every 4 seconds
	method()

Is this normal? thank you for your help

2

It’s not normal, but one explanation is because you’re using tag change events instead of timer scripts, that subsequent queued executions all eventually run after the connection is restored and script unblocks.

Add logging or change to a timer script and see what happens.

1 Like
3

Sadly, we lost the logs as this happened some hours ago and we were not putting in place good logging database, and I can't for now make changement as it's in prod, so I need to wait to deploy changes, however I want to know how can this happen, can you explain to me more about queued executions and script unblocks and connection restores and how ignition handles that? and how that is not equal to timer script in ignition, thank you for those details, I really appreciate it

4

On any tag, only one instance of the tag event script can be executing at a time. If the execution is slow, or blocked, or whatever - and the tag value changes again but there's currently an execution, that change event just gets queued and executed later when the current execution finishes.

So it's possible that your script is blocking for some reason (server down, database slow, whatever), and subsequent executions get queued, and then they execute all at once because the server is suddenly online and you end up seeing what looks like multiple inserts at the same time.

1 Like
5

Thank you for your response, when you say "server" down, you talk about the OPC UA server right?
we are writing like this to it:

        try:
            results = system.tag.writeBlocking(tags_list, value_list)
        except Exception as e:
            error_message = "An exception occurred: {}\nTraceback:\n{}".format(
                str(e), traceback.format_exc())
            LOGGER.error(
                "Tag.write_values failed, error: {},".format(
                    error_message))

how does writeblocking behaves? can it block for more than 1 minute? (len(tags_list) == 15)

Also for the event timer script, so basically if I change it to event timer script, there will be no more a queue (partially of course) as the scripts can get triggered and running in parallel right?

Really thank you for your responses.

6

Yeah.

I think it's possible writeBlocking could block for a bit while the server is down.

I can't really think of any other explanation for the behavior you saw.

Not exactly. There's no queue, but the timer won't reschedule until after the completion of the current execution. You wouldn't want parallel executions of the timer script.

7

So if I get it correctly, putting it into a timer script will not solve the problem right? (our problem is mostly about sending all the missed data at once to the server also to our database, how do you suggest that we handle that (we actually prefer not sending data rather than sending it late)?

8

There won't be any missed data to send because there is no queueing.

If you're concerned about inserting to the database when the server is offline or the write failed, then you should be checking the results of the write and only doing the insert if the quality is good.

9

now I get it!!

and for this, this is clear for me yes, thank you for your time.
I will try to reproduce this behavior in our dev environment and check if I can do so, and if event tag scripts timers solves this problem.
Have a good day.