It seems there is a bug using system.util.retarget on a remote vision client. I have two projects on the same gateway and a menu bar script that reads system.util.retarget(‘project name’). This works as long as the client is running on the same machine the gateway is located on. If I open a remote client and click the same button the retarget process begins, but stops on the initializing portion of opening the client and I have to close the client in task manager. I also tried adding the gateway address even though according to the documentation that should be unnecessary as it should default to the current gateway. The designers window on the gateway web server shows the client as open. This was using b2019032102 and todays build b2019032708.
Also a second point, I don’t know if this has been reported, but when using multiple monitors menu bar dropdowns in my vision client consistently open on the monitor that is incremented one less than the monitor the client is open on. So if the client is open on monitor 2 the drop down opens on monitor 1 and when the client is open on monitor 3 the drop down opens on monitor 2. They drop down opens in its proper place provided the client is on monitor 1. This is using Windows 10.
Part one:
Several team-members here have tried to help me replicate this locally across different operating systems, and we were unable to. There are a variety of reasons why this could be occurring, but with the information at hand we’re not able to move any further. So…
Does the second project have any sort of startup scripts? In theory, if the second project has something that would only work on a local environment (hard-coded localhost references for instance), it might fail to launch on a remote machine. Have you tried opening the second project on this remote machine WITHOUT retargeting? Please try to open the second project on the remote machine without going through the first project.
Part two:
I have someone looking into this, but I wasn’t able to replicate the issue on macOS.
1 Like
Part Two:
The Menu Bar issue is apparently a side-effect of manipulating the monitor count of your environment. If you attach/detach monitors from your environment, Java Swing is apparently unable to track which window it is located in.
This would be exacerbated by having it open on a transient display (attached monitor), unplugging the display, interacting with the Client/Designer, then reattaching the display.
Is it possible that this is what you are encountering?
Part 1: There is no startup script on the second project, and important to note that this works both ways. I can open both clients using the client launcher on my machine with no issues. But retargetting does not work going from project 1 to 2 or project 2 to 1. Important to note that the startup screen goes through none of the normal motions. It does not seem to download the project, extract scripts, or do anything other than load the screen that reads initializing and then the performance on my task manager goes to 0%. Indeed while that screen is sitting there I can go to my client launcher and load the project from there with no issues.
Part 2: Double checking this only seems to happen on the left most tab and when the window is full screen. Dropdowns in any other position open fine and if I take the window out of full screen the left most tab opens in the correct location.
I remember the issue of changing monitors being an issue in 7.9, but I am not changing monitors currently. My configuration has been static since turning on my pc this morning.
Could you look in C:\Users\your_profile.ignition\clientlauncher-data\ and locate the visionclientlauncher log file, then post it here or send it privately?
Sure, here you go. Looks like there are a bunch of IOExceptions for socket timeouts.
visionclientlauncher.log (25.1 KB)
On watching task manager during the opening of the clients I noticed some different behavior between retargetting and loading through the client launcher. When I load the project through the client launcher there is an entry under Zulu Platform x64 Architecture which reads ‘Launching’ and then changes to the project name once the project is launched. When retargetting the entry goes straight from one project name to another. Is it possible it is not running the launcher as it should?
The “Launching” is preparing resources (like Java). Once they’re loaded there is no need to re-load them as they are the same across projects. Initialization refers to more project-specific loading (Windows, Permissions, Client Tags). I’ll open a ticket to track this, but I’m not able to replicate the issue, so I’m not able to provide a workaround for you other than “open each project manually for now”.
One last thing which 100% should not matter if you’re able to open even one project from the remote machine: are the relevant port(s) (8088) open on the Gateway machine? That would explain why you are getting a timeout error, but the fact that you’re able to open even one client should preclude this issue. If the port is not open and opening the port does resolve the issue, then there is a different bug I would need to research.
yeah, the 8088 port is open on the server hosting the gateway.
Working with one of my other guys here. It works for him as long as he is connected over ethernet to our server, but when he tries to do it over wifi he gets the same response and I am connected over wifi as well.
That actually helps a little bit.
In a Command Prompt while on wifi, run ipconfig /all and look for the “DNS Servers” entry. Record this listing (all lines fr DNS Servers).
Now connect with ethernet and wait for the machine to recognize the ethernet configuration.
Execute the ipconfig /all command again and examine the DNS Servers entry. Is there any difference?
There doesn’t seem to be a difference between the DNS servers whether connected over wifi or ethernet. In the client launcher json there is a timeout setting of 30, what is the time unit of that setting?
I would expect the units to be seconds.
ok, I’m not sure if this is related since the problem we’re having seems to be related to the network somehow, but we have another section of the project where we retarget and include parameters. When we do that I get the below error once the new client opens, and this is only on the local machine, as I’m still unable to retarget with my remote client.
If I click abort, the client attempts to reload unsuccessfully, same with retry, exit simply closes the client. When the client tries to reload the message changes to this.
So, we just noticed that if we launch the client on a remote desktop using the designer tools/launch project/launch (windowed) and then try to redirect we are able to redirect successfully regardless of our network connection. Only when we launch through the client launcher does it seem to matter how we are connected to the network.
Regarding the validation and file lock exception errors, I checked my user/.ignition folder and saw a number of launch error text files. Below are a couple of them with different errors.
launch_error_2019-03-29_15-23-49.log (7.7 KB)
launch_error_2019-03-29_15-58-44.log (7.7 KB)
Hi Chad, we haven’t had much success replicating this internally; so far the behavior looks to be more environmental. Could you email support@inductiveautomation.com and reference this post? Thanks.
Yeah, no problem. It is definitely strange as we are able to successfully retarget for existing projects in 7.9.10. The other bugs I have been able to track down as user error, it is now just the remote client retargetting that remains an issue.
