I need to launch the vision client program on a remote server （which IP address is not in the same LAN of Ignition gateway）
The loading of program with vision client on the gateway server is less than10 seconds.
The loading of program is very slow (more than 20 seconds), and the window page switch is also slow. (I use the system.nav.openWindow(） instead of swap function in the program. It has 4 windows. There are about 40 function groups in these windows, each function group will read the OPC UDT data with 1 second time interval ( each data length is about 1000 bytes)
Both the gatway server and remote client host installed Win10 OS and more than 8GB memory.
So is there any way that can speedup the loading of vision client on remote server?
For the slow loading, which threads shown in the diagnostic window will have the most impact on it?
BTW, from the diagnostic window of vision client, the average ping resposne time from gateway is about 300ms…
I could only use the Shift+Ctrl+F7 to show the vision client when the loading is finished.
How could we monitor the diagnostic window from the time when vision client program is loading?
I’m sorry, but you won’t make startup dramatically faster. There’s just too many small pieces of information that have to make the round trip from client to gateway.
With that long of a ping time, you will need to make sure the project’s poll interval is significantly greater. The default is 250ms. Being smaller than your ping time is probably contributing to the slow startup. I’d recommend a poll time of no less than 500ms.
To make the client run as fast as practical after startup, I recommend two things:
Set each of the four windows in your project to use Cache Policy = Always. That will keep the windows’ design information in the client after they are opened the first time.
Create a Client Tag Event Script that does nothing (just use the “pass” statement on line 1) but subscribes to all of the tags that you use in this project’s windows. Starting and stopping subscriptions to tags requires a gateway handshake. Having this event script will cause these tags to be kept current in client memory no matter what windows are open, so switching windows will be quick.
@pturmel
Thanks for your detail comments.
I will update the project’s polling interval.
For suggestion 1) The window Cache policy is already set to “Always”. With this Cache policy, it have some side effect for popup window content display.
In my program, when clicking the buttons, it will pop out a popup window to show some strings, The shown string in popup window is read from database. When I click button 1, it shows “content 1 for button 1” in popup window , when I click button 2(it shall show “content 2 for button 2”), but in fact it still shows “content 1 for button 1” for about 1 seconds and then the content will be updated to “content 2 for button 2” in popup window …
For suggestion 2) I will follow it to see if it has some improvement.
Yeah, you’ll want to eliminate DB query bindings wherever you can, too. One technique to consider would be to use a single query at startup (perhaps a DB binding in a client tag) and then use a filtering binding (like my view() expression function) in your popup to pick the correct row(s) from that persistent dataset.
Another possibility is to define the dataset needed by the labels on the root container of the popup, and pass the correct information in the openWindow() call – no DB at all.
Many typical, simple techniques for user interfaces fall apart in high-latency environments.
As the content in database is updated by data from OPC tag. How about passing OPC tag’s UDT as parameters (documentation data) to popup windows directly?
As the OPC tag data are updated realtimly and ignition use subscribe way to get the data with 1 second time interval.
BTW, how did ignition handle the OPC tag UDT as a paramters in popup window? consider them as a string instance or just a pointer address like in C language?
Blegh. While UDTs are extraordinarily valuable, UDT parameters are on my /expletive/ list. If you are using UDT parameters, get rid of them. Use indirect bindings based on string tagpaths everywhere. Make sure all of your combinations are accounted for in your Client Tag Change Event.
UDT parameters are serialized and deserialized as a whole, it seems. (Java has no pointers, just object references.)
The UDT is not defined in the tag directory of Ignition.
I just drag the OPC tags（with its UDT content) for the OPCUA server.
In fact, the OPC tag’s UDT is a nested UDT, it contents more than 30 different parameters. I don’t want define 30 tags for each parameters and mapped them one by one in the tag directory of Ignition, so I just drag the whole OPC UDT tag and pass the OPC tag’s UDT content as one parameter to a popup window.
In the popup window, I will parse the UDT content to fill each widgets with jsonGet() function to decode the UDT content.
Is this an efficient way ?
For your suggestion of using indirect tag bind,
do you mean that I use the OPC tag path instead of the OPC tag’s content(the document type data)? And then parse the content of OPC tag with the system.tag.read() function to read the whole structure data and decode it with jsonGet() function?
I would do all of the jsonGet() operations in expression tags. I would pass a folder tag path to your popup window. In the popup window I’d use indirect binding to retrieve individual tag values from within that folder.
