Leaderboard

Hi everyone, Just want to share our open source project "Labview Python Bridge". Connect labview apps with python apps in realtime with multi-processing data queues. https://github.com/jmor2000/labview_python_bridge If anyone has any questions or suggestions for new developments / features, let me know. Cheers Jeff

Available in the new ECL version 4.6.0

Hi All, I'm looking for a good resource that explains LabVIEW's Execution System / Thread Allocation / Thread Priority system. As a background to the reason for my request: I have an application with over 50 parallel loops running at fixed but configurable times. Twenty of these loops are calling a .net Dll and are thus not in a Timed Loop (there is a known issue according to NI support with calling a .net dll in a timed loop where the call time is large ie. upwards of a second). The remaining loops are performing other data acquisition. Each loop is what I call a Task Controller - it looks after a specific piece of hardware, taking requests for data (via queues), performing data acquisition and then pumping the result back to the requester. In order to seperate the timing of the functionality (and allow multiple requesters access to the same data), this process is not sequential but occurs in parallel loops. So there is a lot of parallel activity going on. I notice that as more of these loops fire up, the slower the remaining loops are. The CPU usage tends to stay around 7-8% during this time irrespective of how many loops are executing. Note that the .net dll calls (up to 20) are reasonably slow calls and each could take up to 6 seconds to execute. The .net dll has been written to handle multi-threading. The PC is a hyper-threaded quad core (ie 8 logical cores) @ 3.3GHz. Kinda a meaty machine. I should also mention that the majority of the VIs are re-entrant. The only non-rentrant VIs are some FGVs and a few User Interface VIs that reference the data in these FGVs. And before you ask the FGVs are simply Get/Set for a handful of cluster points. So I figure it's a simple case of thread starvation. Every VI is currently set to the Standard Execution System (via Same as Caller) with Normal Priority. I figure that adjusting these settings on the top level Task Controller vis may assist in spreading the load to the remaining available, but not executing, threads. The SubVIs under each Task Controller will continue to use the Same As Caller setting, allowing me to seperate logically each Task into appropriate Execution Systems. Any thoughts?

The configuration is contained in the *.ini file for the built application along with other properties such as vi server configuration. Here's an example of the content that updates the Other1 and Other2 execution systems maximum thread count for each priority. You can generate this programmatically as part of the application build spec with a Post-Built Action : ESys.other1.Normal = 20 ESys.other1.High = 20 ESys.other1.VHigh = 20 ESys.other1.TCritical = 20 ESys.other2.Normal = 20 ESys.other2.High = 20 ESys.other2.VHigh = 20 ESys.other2.TCritical = 20 Note that you could also just use the same property settings in your LabVIEW.ini file for the same effect in the development environment. I believe this is all threadconfig.vi actually does however it doesn't touch any application build specs (not that sophisticated I'm afraid). Here is a quick post build vi I cobbled together to generate the entries on every application build:

Start with NI's article "How Many Threads Does LabVIEW Allocate?" Also see the LabVIEW help for "Multitasking, Multithreading, and Multiprocessing." If you divide your code across execution systems instead of leaving them all at "Same as Caller" you should see the work distributed across more threads, and probably better performance and higher CPU use.