09-12-2017 10:03 AM
We use EPOS motor controllers for a rotating motor. During the homing (takes maybe 10s) and also normal operation /2-4s) operation the EPOS Homing3.vi and normal roation VI's lock the whole labview program completely. Screen of main program is not responsive (shows moving circle icon) , control loop stops. All until the EPOS procedure is finished.
Some suggestions on how to solve this?
Some details:
Windows 7.
Slow touch screen pc. 2 CPU core.
EPOS via USB (since we could not connect it to the cRIO).
CPU load 15-25% with the program running. Hardly visibile increase when homing starts.
Main control loop is 1000ms cycle.
Main control loop has both logic and screen update mixed.
A heartbeat loop that fast (few Hz) update a shared variable (no screen update) works normal during homing.
If run the same exe-file on faster laptop the problem is seldom seen.
Part of block diagram
Solved! Go to Solution.
09-12-2017 03:36 PM
I wouldn't venture a guess unless I could see (and inspect, with LabVIEW) the actual code, not a miniscule picture of part of one Block Diagram. If your code is organized in a LabVIEW Project, compress the folder that holds your VIs and attach the resulting .zip file.
Bob Schor
09-13-2017 02:28 AM
It's not my own project, and it's too internal to share as a whole. But I will try to get permission to share a test project, with just enough to show the problem!
09-13-2017 08:54 AM
An excellent idea (creating a small Test program to more closely isolate and examine a problem). It may well be that the STP (small test program) runs just fine, in which case you can start "corrupting" it by adding more stuff until it breaks. Another trick is to take the STP and encapsulate it in a sub-VI (or several sub-VIs) -- now you know "This code works!", so you can concentrate on the other functions and wires when things go awry.
Bob Schor
09-15-2017 08:07 AM - edited 09-15-2017 08:20 AM
Here are the files from a small test project I made. I am not really familiar with how I install EPOS vi's, I just added a llb I found.
I also added a rather crappy movie I took when running. although none of loops are halted due do homing in this test it still shows that Labview front panel becomes unresponsive during homing. In the real program all loops with front panel updates are halted during this freeze of the front panel.
One idea was that the USB from EPOS motor controller was interferring with USB (?) from touch screen. But
It is only the Labview program that is "locked", so that seems unlikely.
09-15-2017 08:33 AM - edited 09-15-2017 08:34 AM
Hi Ola,
although none of loops are halted due do homing in this test it still shows that Labview front panel becomes unresponsive during homing.
All those EPOS subVIs just contain a single CLFN, the "hard work" is done inside that DLL.
As this DLL is run in the UI thread this thread will be blocked for the time the function call is executed. When the UI thread is blocked you will not get any UI updates…
What else should LabVIEW do?
09-15-2017 08:58 AM
Hello GerdW!
Although the details about execution threads etc. is above my head I feel your explanation is correct.
That the user interface thread is blocked by the DLL suits my experience. In the full program everything is stopped exept a loop with no user interface at all.
A good solution should then be to redesign the whole program so no user interface updates takes place in the control loops, but in practice we don't have the time to do this. A lesson for next project
Is there any way we can influence that the EPOS DLL is run in the UI thread?
09-15-2017 10:02 AM
09-18-2017 07:48 AM - edited 09-18-2017 07:50 AM
GerdW, for the fun of it I tried to change the Thread of the Call Library Functions to "Run in any thread". And it works!
Firstly it runs without errors. And secondly the user interface continues to update during the homing
Details of what I did: For the Epos homing3.vi I changed Execution to "other 1" (and Priority to "background priority"). I then changed all EPOS DLL call function exept the init vi to "Run in any thread". Execution of all sub vi's was left at "same as caller". Probably it should be enough to just do this for the " VCS Wait for homing attained.vi". I cannot guarantee it will not crash of course, but seems to work!