Hi, I am having some significant problems with ignition.
I have made a number of other posts regarding database issues etc, none of which have yet been resolved. My latest issue is that I am getting random changes in data in the PLC, which I know are caused by ignition, but are not appearing in the audit trail. In addition to this, I am getting random firing of events, events that change setpoints. This all seems to happen when restarting the primary gateway of the redundant configuration, or sometimes during communications loss.
While nothing is happening ignition-wise, no changes happen in the PLC. However, when a reboot of ignition happens or any sort of comms loss happens, data randomly and throughout the entire PLC memory becomes corrupted.
I have also seen some other events trigger from another client (i am running multiple clients) that I wasn’t even working on get fired during these times also, although this is relatively rare. But definately happening, as I am looking at such an event right now (I have custom events logging).
This is very worrisome, as it is changing setpoints for alarms all over the place, and it seems ignition is not even aware it is happening. I am using the Modbus/TCP driver with 17 connections to the PLC as recommended by inductive support to get the throughput required from an M580.
Without clear evidence that this is happening outside of events or transaction groups, I would be inclined to say this is programmer error. Like not using the initialChange flag, or not checking quality in events, or not using a persistent state to decide when events are appropriate. Or, most especially, structuring your code such that multiple paths can write to common memory or PLC tags.
I would suggest you start by auditing all of your event scripts (and transaction groups, if any) to cross reference every combination of event & written PLC tag.
Thanks for the response, I am still yet to confirm but i did have a think a bit more about the sorts of code i was executing in more detail, and i suspect the issue i might be having is that although I am using initialChange on some variables that are manipulating my data, I am using a value changed event (with no initialChange check) to fire a change on the variable that has an initialchange event. This wouldn’t have caused an issue if the value i had in the data was calculated correctly, but i suspect it might not be. I will check in once i confirm this is the issue.
There seemed to be a combination of things happening, one being what was mentioned above, one was bad mapping to the PLC. Both my error.
However the most interesting problem was when navigating to popups, values would change randomly. I found the cause of this to be that when in designer, I opened the popups in live mode by clicking on my template that opens the popup. This navigated me to the right popup within designer, but it modified the popup by adding a bidirectional binding to the passed parameters (a UDT) so that it was connected to a specific UDT in my tag list. After hitting save, my popup was saved with this binding.
Now for some reason, after doing this, when I opened the popup, all my components which used the passed UDT parameter, started flickering between data in the bound UDT and the passed UDT and data in both UDTs was getting confused with that of each other. As though there were two bindings on the one property. After removing the bidirectional UDT added automatically by ignition, my problem went away with this.
Another, less interesting but also confusing problem, was the fact that on opening my popup, I get a change event on components, as they change from whatever was in their during the designer session to whatever they had to load in from the UDT. This was tricky to overcome because there is no initialChange type property that can be checked, so I had to use a combination of events tied to mouse clicks and loss of focus to store a property to enable/disable event processing for the component. I wanted to check if the component was in focus when the change happened, but in the client the hasFocus() method of the component proved unreliable, even though it worked fine in the designer.