Leaderboard

Draw a while loop around this one, and voilà! (Source: Associated Press)

If the DLL call and ActiveX call are both UI threaded (ActiveX as said is most likely, DLL depends on the Call Library node configuration but if it is a driver you haven't written yourself I would be vary to change a possible UI thread setting to re-entrant as that could cause all kinds of weird problems in the DLL if its functions aren't explicitly written to be re-entrant) you get most likely following scenario: Since the ActiveX call takes a certain amount of time, LabVIEW can't interrupt it midway to switch to the DLL call and let it take over the same UI thread. Once LabVIEW hands over control to an external code (ActiveX or DLL) it can only wait for that code to return code back to LabVIEW before doing anything else in that same thread. There is not a single way around it. I can give you a solution that will work. Create two LabVIEW executables, one calling into the ActiveX component and the other into the DLL, and let them communicate through Inter-application Communication together. That solves the problem since both components now reside in separate processes and will be simply multitasked by Windows itself. Changing the Call Library Nodes to run re-entrant might be a solution, but without knowing the underlying DLL code I would never make such a change myself. If it is not set re-entrant this has most likely a reason. It could be just an omission from the actual programmer but the chance that the DLL uses global variables and resources between functions without protecting them explicitly is very high and in that case changing the VIs to allow re-entrant calls could in the best case lead to crashes in the worst case to strange and almost impossible to debug effects. One other option is to change the Call Library Node to be re-entrant and assign all Driver VIs to a specific execution system. Now you go into vi.lib/utility/sysinfo.llb/thread config.vi and run it. In that VI set the execution system you have chosen to assign to all driver VIs to only have one thread. This will likely work fine but has the disadvantage that the thread configuration is not part of the VI but of the LabVIEW runtime setup. So you will have to make sure to add the according lines in labview.ini, that this change will create, into any executable ini file as well as any other LabVIEW development system ini file that you may use, such as other LabVIEW development versions you may use or other LabVIEW installations on any other machine that wants to make use of that library.

Hello, Your issue might be similar to the one exposed in this discussion. First thing to try is to close LabVIEW, re-open and see if it works. If it doesn't you can try to temporarily remove parts of your code to find out which VI causes this problem. Have you been able to build an exe from this source code earlier or is it the first time you try to build?