Yup went through the academy twice. However when I'm up against bugs in the software and video tutorials using older versions, it tends to get a bit frustrating. But the meta visibility works to hide the date when the cycle isn't running and I got the date to at least trigger off a plc tag so that's as good as it's going to get for now. I feel vision is a much better front end for a more typical scada as it was much more straight forward to do typical automation. But since the sales guy only wants to sell me perspective and for our testing purposes to we had to go with perspective, we'll make due.
This applies to both Perspective and Vision. Gateway events and tags are isolated from user interfaces of either kind.
This topic only leaned into Perspective after many comments--it isn't tagged for either and the OP isn't specific to either. Throwing stones at the different UIs can be fun, but has been beat to death in other topics. Consider participating in one of those...
Regarding the visibility saga, there are differences between the different containers. For the most common:
- Flex containers: you can use either
position.displayormeta.visible.position.displaywill remove the item from the DOM entirely, and effectively collapse the space the component took up -- you would use this 99.9% of the timemeta.visiblewill keep the component in the DOM and effectively make the component transparent; it will not collapse the space the component takes up -- useful in very limited circumstances
- Coordinate containers: you can only use
meta.visible
Regarding Perspective vs Vision, Perspective is far better at creating standardised projects, however it's definitely a steep learning curve when you're used to traditional raster platforms like Vision. The biggest piece of advice for Perspective is to get familiar with CSS as it will help you immensely. That, and knowing that all scripts run on the gateway, not the client, so they have no access to local client resources.
Note: DOM refers to the Document Object Model; think of it as all of the components that make up the HTML page which includes your labels, embedded views, containers, etc. which map into various HTML elements in the DOM
And lastly, regarding the tag change script.. I would be adding this into the trigger tag's value change script, not into a gateway tag change script.
Waffle
In general, it's best to keep scripts that run inside tag change events to execute very quickly, ~10ms or less, since these scripts run in a limited number of threads (3 by default) for the entire tag system, with up to 5 queued events per tag. If there are many tags configured with tag change events that hold up execution, it's possible for the tag event queues to fill up and then drop future events until the current ones are processed. In practice, it really depends how many tags you have that have tag events configured, and that 10ms figure is more or less a best practice guide to allow for substantial project scaling.
Into the trigger tag's value change event, I would add below. Note the use of writeAsync instead of writeBlocking so the tag event script isn't blocked while the tag writes, to ensure it runs quickly
# Catch rising edge of transition from false to true, and when there is no previousValue
if currentValue.value and (not previousValue or not previousValue.value):
system.tag.writeAsync(['Path/To/Storage/Tag'], [system.date.now()])
Note: previousValue is None when there is no previous value, so previousValue.value produces an exception in this case which these conditions handle, since Python short circuits conditions
This may be a potayto, potahto thing, but why wouldn't we use currentValue.timestamp?
- Won't filter out true ⇒ false transitions, and
- Would be OPC server's timestamp, not gateway timestamp, for other than built-in drivers.
Not required for writes to memory tags. (They are the only writes that don't actually block.)
I was rather just meaning instead of system.date.now(). 
Oh, I missed it was into a mem tag (datetime type is pretty obviously a mem tag though...) , good practice to get into regardless however, if the result is dropped anyway 
Yes. You don't need an IF just to copy the current time. If you want to capture the time when a PLC bit turns ON, simply do:
IF Trigger_Bit THEN
Time_Stamp := NOW();
END_IF;
Make sure Time_Stamp is a DATE_AND_TIME/DT type supported by your PLC. If NOW() isn't accepted directly, check the tag's data type first.
I've used a similar approach in IOTMATRIX's energy monitoring setup, where timestamps are stored with machine and energy data to track exactly when an event or change occurred.
You seem confused about the environment discussed here. The topic is not about PLC code, but code in Ignition SCADA.
Of course, you might be an LLM-driven bot planning to post a marketing link shortly, since your final paragraph is spammy, and totally disconnected from the topic.
I'm waiting patiently
We seem to have gotten quite off-topic. This is pretty trivial (or should be, for someone who apparently went through IA University twice).
- Open the designer
- Add a PLC tag to your provider
- Add a memory tag to your provider to hold the date
- Open
Project>Gateway Events - Select
Tag Change - Click the
+to add a tag change event (give it a name) - Add the tag path to your tag from step 2 using the tag selector dialog
- Add the script to write to the memory tag
# Catch rising edge of transition from false to true
if not previousValue.value and newValue.value:
system.tag.writeBlocking(['Path/To/Storage/Tag'], [system.date.now()])
I just wrote a simple script on the tag itself within my project using a combination of everything from everyone above. No gateway script needed. Wish things like this were simpler and spelled out better but it is what it is. Is there a way to mark this as closed? Interesting at the amount of spam coming from the leaders on here. Makes the little guys like me not want to contribute or ask questions. Maybe I'll keep my questions to chat gpt?
Yes, a tag change script on a PLC tag would work as well.
Interesting to note after spending considerable of my own time to put together at least one significantly longer (than normal) reply here, presumably with useful info in it. Its sad that one fun post would taint the rest
Let's just say this thread has run it's course. @dfox37 I'd encourage you to post any future questions you have in new threads; we really do like to help.