Script's odd behavior

Hi everyone,

I’d like to share something that just happened to me to see if anyone has experienced it before and if there’s any history about it.

Application developed on one of the early ignition 8.0.x versions (sorry, but my access was revoked at the end of the job, so i don’t have the exact version; i can provide it in a few weeks if necessary, and upgrading is not an option, at least at the moment).

This production plant has been running for 4-5 years, the client called me because the machine was stopped.
When I connected to ignition gateway everything seemed fine.

The production line was stopped because the plc was waiting for feedback data from a barcode read. The script handling this procedure was being executed correctly, as the script’s completion flag was set to true on the plc as long with other data, except for a string.

This script read a row from the database and wrote four values to the plc, including the problematic string that, however, wasn’t actually written to the plc.

I commented out the line retriving data from a dataset returned from the query and wrote a static value instead, which was written correctly.

At this point, i removed the static value, uncommented the old line, and everything started working as it had for years.

Any idea what might have happened?

This is not a great way of confirming that Ignition actually wrote the tag value. When you do a system.tag.writeBlocking you get a list of results back - that is what you should be checking to see if the tag actually wrote. If you are not checking these, it's very feasible system.tag.writeBlocking tried to write, failed, and the rest of your script went on, ending with the true, making it seem like thing went fine when you never wrote to the PLC tag, perhaps a comm issue at a crucial time.

1 Like

Hello,
although i completely agree with you, this script, written years ago by a former colleague, does not check the result of the writeSynchronous calls.

That said, the strange thing is that the script behaved consistently in the same way providing same input parameter.

Repeating its execution five times in a row, four tags were written correctly, the string tag was blank.

Executing the script with the line commented out, then removing the comment and re-executing it, made the problem disappear.

I agree that different strategies could be applied to ensure reliable writes, but it seams to me that there was something else going on.

You'll have to check the return values to rule out some transient write error.

2 Likes

Ok, thank you for the advice.

Unfortunately, the project is not within my scope, so i cannot make any changes.

I just found it strange that a script, executed thousands of times a day for 5 years with the same input data, would suddenly exhibit this behavior, only to start working correctly again after simply saving the project in the designer without making any changes.

Thank you for your time and for the advice, which will certainly be helpful in my future projects.

If all else, I have seen and known of PLCs have some type of unexplained internal failure that it either needs a reboot, reconfiguration, or replacement.

The internal failure we had once still allowed the PLC to communicate and read values from it, but the values stopped changing. Everything flatlined, a power reboot didn't work and had to be reconfigured.

Fortunately, this wasn’t our case today.
All the other stations on the production line were working correctly, along with all the other ignition scripts.
However, thank you for sharing your experience; i’ll keep it in mind for the future.