LabVIEW
Computer processing power used during EXE build??
Hey guys,
I am working on a VI that programmatically builds and deploys an executable from the cmputer to an RT target. When you use the build vi function in labview, there is no native pop up box that comes up and shows you the build progress so I decided to add a loading animation that would start when the Build VI is executed and stop when the VI is finished (that is, start when it begins building and stop when it completes). What U have found is that when LabVIEW is building the executable, the animation freezes and gets stuck on a single frame. I am fairly sure the program is written correctly as when you remove the build function and replace with a wait timer, it functions correctly. But when it is building, the animation freezes.
Does anyone know if this is just processing power related? As in, when the program is building, LabVIEW doesnt have enough juice to service both the build and the animation display? I have attached part of the VI here. The first one with the RT build freezes the animation. The second picture wait function works fine with the animation. Thanks!
My thought is it is related to the "root loop" being used by the builder, which ends up blocking a lot of processing in your code.
Assuming it is the root loop, there is no way around it. But maybe somebody from NI will be able to give more insight into the issue. I am just guessing based on issues I have been exposed to.
@Muri777 wrote:
Is there any way around this
Create an animation subVI which you call dynamically before starting the build/deploy action. Then your builder main VI could msg the animation VI to stop and exit when the build/deploy action finished (use Queue/Channel/User Event, etc. for the stop msg).
But if you only want to indicate to the user that she/he needs to wait for the application to finish the actual action, then I would just use the "busy" functions:
@crossrulz wrote:
My thought is it is related to the "root loop" being used by the builder, which ends up blocking a lot of processing in your code.
It's related to the root loop but technically simply because that is also the UI thread. Your front panel is updated always in the UI thread since it is a shared resource and that is technically the most simple solution to guarantee that no two independent code paths try to fight over who controls the UI at any given time.
The VI Server interface which is at the base of all the scripting interface to do the things like building an application etc. has various operations that also go through the UI thread, not so much because it is controlling the UI but because the UI execution system is the only execution system that is guaranteed to always be single threaded. Opening a VI reference for instance accesses many different global resources in LabVIEW such as tables that manage what VIs are loaded in memory and many more such things. In order to guarantee that those global tables are not modified concurrently by two different threads at the same time you can either protect them with mutexes or force them to only be ever accessed from a single specific thread.
Mutexes cost extra resources and if you use multiple mutexes to protect different global resources it is very easy to create a situation where you create a complete lock through mutual exclusion where two different code parts hold a lock to one of these resources and want to also get a lock to the other resource held by the other code part. That are the typical CTRL-ALT-DEL situations because such an application can only be terminated with a kill at that point. Guaranteeing that such global resources are always accessed from the same thread is a much easier solution. Guaranteeing that you don't create a mutual exclusion situation with multiple mutexes is a much harder and sometimes almost impossible thing. The only way to easily guarantee that you don't create a mutual exclusion that way is to never ever hold more than one mutex by any specific code hierarchy at any time, which is almost unworkable. And it's potentially much slower as you may have to grab and release the mutexes many many times during a specific operation like opening a VI reference and while the mutex grab and release itself is not really expensive, the possible delay when waiting for a much fought about resource mutex can be pretty enormous.
Back in the early 90ies of last century when the LabVIEW developers introduced concurrent multithreading in LabVIEW they had already a pretty enormous code base that was build partly on the assumption that there were never ever two concurrent code sections running in parallel. They had two choices: Rewrite LabVIEW from scratch and wait with a new release for 5 to 10 years or find something that could be made to work even with multithreading. The choice in such a situation is pretty obvious. The drawback that UI updates won't happen during such protected operations is a relatively small annoyance compared to the option to not have a new release for many years.
I'm not really sure if the busy cursor would work. Most likely it is controlled by the OS on a lower level before the messages are dispatched to the application, in that case it will work since LabVIEW is still serving the message loop in its root loop. Windows does a lot of things in that part including some of the marshaling of OLE/COM data and it is crucial for any application to keep serving that message loop or many things will simply start to misbehave.
The idea alone to have to work in that part of the Windows code gives me the cold shivers.
