My CAR is missing

[Cat]

Does anyone know how to find out the status of an orphan CAR?  I have one from a few years ago (313508) and the same issue is biting me in the backside, again.  So it looks like it wasn't fixed.

 

Cat

[Jordan Kuehn]

I think your best bet is to call NI.  AFAIK that information is not public.

[crossrulz]

Ask in the NI forums.  You are likely to get an AE to track it that way.

[JackDunaway]

Does anyone know how to find out the status of an orphan CAR?  I have one from a few years ago (313508) and the same issue is biting me in the backside, again.  So it looks like it wasn't fixed.

 

Cat

 

 

Searching `site:ni.com 313508` leads to: https://forums.ni.com/t5/LabVIEW/Process-freezes-for-a-few-seconds/td-p/2309090

 

Does your application have a similar number of parallel "actors"? (the original post in the thread above mentions 52 parallel "actors) What does CPU usage do during this pause?

 

If you have a lot of parallel loops, and if CPU drops to near-zero during these "pauses", you might be exhausting the thread pool per execution system in LabVIEW.

 

If this sounds like the case, try bumping the thread count higher than 20 (the default). To do this, use `threadconfig.vi` which will then create 25 or so entries in your `LabVIEW.ini` file, then manually edit those numbers using a text editor to be higher (e.g., 50).

[ShaunR]

If this sounds like the case, try bumping the thread count higher than 20 (the default). To do this, use `threadconfig.vi` which will then create 25 or so entries in your `LabVIEW.ini` file, then manually edit those numbers using a text editor to be higher (e.g., 50).

 

Are you saying that the # threads can be increased past 8 per execution system and create more execution systems by editing the ini file? i.e you can surpass the absolute maximum number of allocatable threads of 200 that can be achieved if you maximise all in the threadconfig.vi, Can you clarify what you mean here?

 

Another solution that I've used quite often for comms is to use other 1 and other 2 execution systems for read and write respectively. That effectively doubles the number of available threads and removes them from the usual thread pools used by everything else.

 

What was CAR 313508 for anyway?

Edited June 11, 2015 by ShaunR

[Cat]

What was CAR 313508 for anyway?

 

CAR 313508

 

I was attempting to do something similar last week, didn't work, couldn't figure out why, was going to post here, and then realized I was probably running into the same problem I had 4 years ago.  Which I had completely forgotten about.  It's hell getting old. :-)

 

(cross-posted to NI)

Edited June 14, 2015 by Cat

[Neil Pate]

Searching `site:ni.com 313508` leads to: https://forums.ni.com/t5/LabVIEW/Process-freezes-for-a-few-seconds/td-p/2309090

 

Does your application have a similar number of parallel "actors"? (the original post in the thread above mentions 52 parallel "actors) What does CPU usage do during this pause?

 

If you have a lot of parallel loops, and if CPU drops to near-zero during these "pauses", you might be exhausting the thread pool per execution system in LabVIEW.

 

If this sounds like the case, try bumping the thread count higher than 20 (the default). To do this, use `threadconfig.vi` which will then create 25 or so entries in your `LabVIEW.ini` file, then manually edit those numbers using a text editor to be higher (e.g., 50).

 

<possible thread hijack>

 

Jack, I had tried to do something similar with the threads just yesterday.

 

Do you know how to achieve this in a built executable? Unfortunately threadconfig.vi is a GUI type VI, so not really able to be embedded into another application. I was able to get the contents of this VI and remove the GUI aspect and then inserted it into my code. However I am not really sure this will do what I want as I do not know if it is possible to modify the thread configuration from a running application?

 

Perhaps I need to modify the LV IDE settings before building?

 

</possible thread hijack>

[ShaunR]

CAR 313508

 

I was attempting to do something similar last week, didn't work, couldn't figure out why, was going to post here, and then realized I was probably running into the same problem I had 4 years ago.  Which I had completely forgotten about.  It's hell getting old. :-)

IC. Never found where it was left after you parked it (see what I did there? )

 

Reading back over it; seems we covered most bases so hopefully NI didn't put the brakes on it. (oh dear, I need some coffee)

[smithd]

Do you know how to achieve this in a built executable? Unfortunately threadconfig.vi is a GUI type VI, so not really able to be embedded into another application. I was able to get the contents of this VI and remove the GUI aspect and then inserted it into my code. However I am not really sure this will do what I want as I do not know if it is possible to modify the thread configuration from a running application?

I remember someone having issues with DAQ threads at some point and fixed it in an exe. I believe all you have to do is copy the appropriate INI keys from labview.ini into your exe's ini file and the runtime will allocate the right number of threads on launch.

[JackDunaway]

copy the appropriate INI keys from labview.ini into your exe's ini file and the runtime will allocate the right number of threads on launch.

 

True.

 

 

Are you saying that the # threads can be increased past 8 per execution system

 

 

Yes. Quick battle story. I was dismayed on a project mid-2014 to realize the root of an inexplicable bug was due to thread exhaustion, which would have been costly to refactor (as in, "let's move this big chunk of the application from LabVIEW to another language"). The failure mode was terrible to debug -- any part of the system could arbitrarily fail at any time! I was delighted to find that manually editing `LabVIEW.ini` to increase values beyond the arbitrary limit of 20 threads per executionsystem/priority imposed by `threadconfig.vi` actually worked! Said another way: "As a LabVIEW developer, you don't have to worry about threads*... until you do... and you will, given sufficient non-trivial applications."

 

* `threads` is interchangeable with `memory allocation` here

create more execution systems

 

False... to my knowledge and testing.

[drjdpowell]

Is there a list somewhere of the operations that block a thread?   In other words, when do I have to start worrying about threads or execution systems?

[ShaunR]

NB t/pe/pp = threads per priority, per execution system
 

True.

 
 
TIL.
1. They have bumped up the max to 20 t/pe/pp (2014) from 8 (2009) although the default seems still to be 8.
2. You can indeed set more than 20 t/pe/pp

TIWL (Things I will Learn)

1. How high can it go before nasty things happen.
2. When setting executables' ini files. Does labview cumulatively allocate threads as more executables are run?
3. Is there a more up-to-date document that describes LabVIEW threading?
 

"As a LabVIEW developer, you don't have to worry about threads*... until you do... and you will, given sufficient non-trivial applications."

and you will, given sufficient non-trivial applications. bloatware"

 

FTFY

[JKSH]

"As a LabVIEW developer, you don't have to worry about threads*... until you do... and you will, given sufficient non-trivial applications."

 

This is just another case of the Law of Leaky Abstractions: http://www.joelonsoftware.com/articles/LeakyAbstractions.html

 

LabVIEW abstracts away our need to manage every thread manually. However, every so often, we find ourselves in a position where we need to understand how threads work and how LabVIEW hides these details from us.

[Cat]

Ask in the NI forums.  You are likely to get an AE to track it that way.

 

Thanks. I've cross-posted.

[Neil Pate]

I remember someone having issues with DAQ threads at some point and fixed it in an exe. I believe all you have to do is copy the appropriate INI keys from labview.ini into your exe's ini file and the runtime will allocate the right number of threads on launch.

Thanks for this tip.

 

I have made the change and now I just have to wait for my application to fall over (or not fall over, hopefully!).

[hooovahh]

This is just another case of the Law of Leaky Abstractions: http://www.joelonsoftware.com/articles/LeakyAbstractions.html

Interesting read, and LabVIEW definitely falls into this category, and not just with threads.  Ever allocate memory for a variable in LabVIEW?  Maybe you initialized an array and used replace instead of build, but this is not the same kind of memory allocation other languages think about.  What about parallel tasks?  Memory cleanup?  Obviously being a higher level language many things are hidden away, and with a really advanced compiler even more things are hidden from the developer.

 

I was talking to a friend yesterday and he made the statement about how easy software programming is, compared to previous decades.  And while I agree I think the challenge has shifted.  You no longer need to worry about the things that are abstracted away (until you do), but you do need to worry about much larger systems, with a much smaller team.  We need to have more architect skills, and be thinking about how the pieces plumb together, and worry less about the low level, and assume they are water tight.  When they aren't, we struggle. 

[Mark Smith]

Is there a list somewhere of the operations that block a thread?   In other words, when do I have to start worrying about threads or execution systems?

The only time I've had to worry about thread exhaustion is when making interop calls to .NET/DLL/COM. LabVIEW will grab a thread for the interop call and not release it until the call returns. If you make simultaneous calls to DLLs (assuming they are thread-safe and not called in the UI thread), LabVIEW will allocate a thread and not return that thread until the DLL call is complete. This can lead to thread starvation and blocking if the DLL call takes a non-trivial amount of time to complete and you reach the thread limit for a given execution system. DAQmx is susceptible because it's all calls to the DAQmx DLL under the hood.

 

Mark

[Stormshadow]

Dude, Where's My Car?

[hooovahh]