Someone at my work wants to to try to put some of our Ignition business logic into client tag as handler functions essentially. Someone clicks a Submit type button, a dataset with the necessary info is sent to a dataset client tag, and the client tag is triggered on valueChange, reads the dataset, and inserts/updates the database. I did get this to work but the writes to the database are much slower than if we just had the database python script in the button function itself as we previously did, not to mention we can easily get confirmation from the database using a getKey=1 parameter.
He asked why it was slower and I estimated that it was because the script in the actionPerformed extension function of the button, given that it starts the whole process and the GUI is dependent on it, is the main thread that has priority in terms of ram and getting completed by Ignition, whereas the client tag with the valueChanged is running in the background on another thread, given lower priority/less processing power. But I’m not entirely sure that’s true. I’d also hazard a guess there was more overhead in terms of communicating from the client to the client tag to the gateway etc over just scripting directly.
Can someone explain how Ignition handles this situation? A extension function on a gui component runs, and in that script a client tag is written to that has a valueChanged event that is triggered. How does Ignition do these two processes - cocurrently? Does it finish the GUI extension function first? Lastly he wanted to know if there was a way to, in the middle of the GUI extenstion function, tell Ignition to focus on the client tag valueChange script/make it run faster in some way.
I know this is a not a specific question but we would like to know how Ignition handles this sort of situation under the hood and what if any ability to affect the process a designer has over it.