I am logged onto the network as the same user on both PCs (not at the same time; i.e. I only run one of the PCs at a time).
So I would think that the network access is just fine.
Also, other LabView apps that run on this PC and access the same mysql database have no problems.
Again, I am not running them at the same time.
It just seems to be this one app.
I don't think that it matters where the app is "stuck". The process window of the task manager shows that it is only getting 2-5% of the CPU.
That would make it run more slowly regardless of my code.
Thanks for that thought, but the slow PC had the hard drive reformatted and everything re-installed yesterday.
It had anti-virus software installed on it prior to being added back to our network.
Also, other LabView apps that use the network have no problem on this PC.
At them moment I am following C.Minnela's advice and trying to isolate what is slow.
It didn't seem that there should be a problem in the code since it is the same, but I am finding that "Case"ing out one VI eliminates the problem. Now, the question is whether that is really the problem, or just a Wild Goose wasting time.
I am working my way through that VI at present.
Compunding the issue is that I am running an exe on the problem PC, but my development PC is quite a hike from that spot.
If I don't solve this soon, I will get remote access running.
I will either post more questions, or the solution.
Thanks for the thoughts. Left field is fine. At present even the parking lot would be good 🙂 Turn off the lights, I'm shooting in the dark.
The difference in timing is not between the development PC and the deployment PC, it is a timing difference between two deployment PCs. Each of which run the exe, but only one is connected to the network for any given test. I swap all cables between the two PCs when I run tests (keyboard, mouse, monitor, serial port, network). They have different network addresses, but are on the same domain.
The issue with the development PC is just how far away it is. I have configured for remote logins and can now run my development PC from the deployment PC. This eliminates about 400 yards of walking and two flights of stairs. Should have done that sooner.
It does seem to be something with the mysql on the problem machine.
The other apps that access mysql that are working on both deployment machines do run considerably slower on the problem machine. However, their timing difference is not as noticeable in "human time". They take three seconds to do an update instead of 500ms. Their human interface is slower normally, so they did not seem to be affected.
I was told by the person that set up the sql links that both PCs are the same. The little bit that I know to check (administrative tools, odbc...) look the same on both PCs.
I do not know about the RAM size and VM configs (I can check later).
Since it is the same app running on both deployment PCs and the host, etc are set up by the app, it has to be the same on both PCs (doesn't it).