Slow Navigation on VXL V200 thin client

Ignition
1

Hello,

I’m currently implementing a project that will have 20 production lines, each with their own VXL V200 thin client running Ignition and communicating PCoIP to the gateway on a VMware horizon view server.

Upon opening an Ignition client on one of the V200s, I’m seeing very slow navigation, sometimes up to 5 minutes in switching pages. This project includes quite a bit of indirection based upon a client tag as the current production line number of the client, as well as a few screens utilizing a template repeater.

Based upon these diagnostics, it seems like the CPU is getting hit pretty hard. the two long plateaus are two different attempts to switch screens. the longer one took about 5 minutes:

Thin Client CPU usage when opening.jpg1024×768 323 KB

I have no issue on my machine or regular PCs within the plant loading up screens quickly. This only seems to affect the clients accessed through the V200s.

Also, an older project without indirection/templating was loaded up on a V200, and we had no navigation issues.

Has anyone had experience with this type of architecture before, or could point me to a solution?

Thanks

2

Running the Ignition client diagnostics was also unhelpful…

Client Diagnostics.jpg789×575 139 KB

Just a giant gap in the time it takes to navigate tothe next screen

3

Hi,

I had similar problem (Slow swapTo navigation). I solved it by using below code instead of swapTo function:

system.nav.closeWindow(system.nav.getCurrentWindow())
system.nav.openWindow('yourNewWindowPath')

Then I had to write also my own navigation functions like goBack() goForward().

So if you’re using swapTo you can try my solution.

4

I know, this is 6 years later, but in my last project with Ignition v8.1.7 (Vision), I have the same “problem”…
I have a fairly complex window with a complete production line layout with a lot of templates for conveyors, barcode readers, motors, … and swapping from that window to any other (complex or not) window, takes a lot of time (around 20 sec).
And the only “solution” is to use (like @Vita said) .closeWindow and .openWindow.
But then you lose goBack() and goForward() functionality and you need to write it yourself…

5

Have you watched the client’s memory usage during this slow swaptTo ? Is the thin client’s physical memory large enough for the client memory setting chosen? (Plus some leeway for the OS…)

6

Ha… a good point. But no, I haven’t.
I didn’t even think about that… because my clients are almost always Intel NUCs with I5, 4 cores, and 8 threads with 8GB of memory and Windows 10 Enterprise LTSB (2016) v1607 without any (MS) bloatware. And in my project properties, I always set min/max memory for a client at 512/1024 MB.

But, I’ll check this ASAP…

7

Consider also setting Min=Max for dedicated thin clients. There’s no benefit to waiting to allocate all of the permitted memory.

1 Like