Can not see memory tag in Audit Log script overwriting

Is that normal behavior? History is enabled.

I found a script overwriting tag, but it was hard to find cause there no trace in the audit log. And the script was done by someone who is no longer here

Thank you!

I think you’ll need to provide some more detail here. Specifically, I am not sure what you mean by "Audit Log script overwriting’. What are you seeing and what are you expecting?

@obober The was a script overwriting to the tags. But I could not see any tag changes in the audit log as I would expect.

I assume by “overwriting” you just mean you have a script that is writing to your memory tag values? (“Overwriting” is a term I associate with the configuration of a tag e.g. overwriting the tag’s configuration with new configuration. Writing to a tag implies writing to the value of a tag for example with system.tag.writeBlocking(...))

You don’t specify what version you’re using or what visualisation module, but assuming Perspective, prior to version 8.1.16 calls to system.tag.write* would not add these writes into the audit log. You will either need to upgrade or in the meantime provide your own wrapper functions to perform these writes and also inserts into the audit log (e.g. using system.util.audit)

History has nothing to do with auditing.

It’s tagged as 7.8 ?

Oh, so it is… I must be getting old…
In that case, I would recommend upgrading to this century :slight_smile:
7.8.x versions are over 5.5 years old, or an eternity in software terms.

1 Like

@nminchin its a work in progress. But currently I’m stuck debugging it.

All the “Validated Systems”/Part 11 compliant systems I work on - I have never had IT let me upgrade the Ignition Gateway. Part of Part 11 criteria is the system be validated.

Validated how, and by what criteria, the world may never know. The definition and terms are vague enough for interpretation.

But it seems like upgrading invalidates things in IT’s eyes. I don’t know. I still have to work on projects with 7.7 due to this.

TBF, anytime I end up making a stack overflow question and tag it as python 2.7 (or 2.5 for these systems) I get told the same thing - Upgrade to python 3.X!

1 Like

In ITs eyes it works now, so why upgrade. Honestly @nminchin my only decent argument is it makes it easier for me. I’ve been through the feature least, and IT says well… yeah but you can still program a work around. Truth be told a week of me pulling out my hair is less expensive to them then a 20-30k upgrade. Its not cheap to upgrade as much as everyone likes to point it out all the time.

1 Like

Next time they want to Upgrade your desktop OS, ask them why, this one still works.

Reasons to upgrade:

1.) Security
2.) New Tools, Improvements, and bug fixes
3.) Support

No upgrading isn’t “cheap”, but the longer you wait the less “cheap” it will get. The further away from that version that you get the more difficult the process of upgrading it will be. This is the sole purpose that we maintain a maintenance agreement with IA. Then minor version upgrades are free, and Major version upgrades are discounted.

“If it ain’t broke don’t fix it” is a fallacy that anyone in Industrial Automation \ OT \ IT should avoid at all costs.

1 Like

@lrose

  1. IT thinks they have it locked down
  2. system is already working in place what new tool, bug fix or improvement could we need if the system already works?
  3. You can figure it out.

Unfortunately I’m not high enough on the totem poll to challenge anything

:rofl: I agree with all your points. We maintain basic support for free upgrades and aim to keep things relatively current. Ignition is generally painless to upgrade, with 7->8 being a bit of an exception. Thankfully we don’t have the “validated systems” issue to worry about.