05-12-2011 12:57 PM
@PaulieQ wrote:
@Mark Yedinak wrote:
@PaulieQ wrote:
As far as I know there is no real multi-threading in LabView.
Paul
I am not sure why you think this but this simply is not true. LabVIEW is multithreaded and can not only take advantage of multiple threads but it can take advantage of multiple cores as well. The compiler is quite sophisticated and breaks the code up into executable nodes which it will execute in parallel in separate threads.
Mark, by "multithread" I mean the same multithread which is available in Visual C for example. Where one can define the priorities, cores and so on. LabView is multitreaded but you have no direct control on individual threads.
The multithreading in LabView means creating parallel loops and letting LabView to deal with them. Correct me if I'm wrong.
LabVIEW does have the ability to control the items you mentioned. If I am not mistaken this capability is available as an add on on a PC. It definitely exists in LabVIEW RT. You can set priorities on subVIs (in all versions) which does give you some control over the execution. LabVIEW actually does a very good job of load balancing thread execution and core usage. The nice thing about LabVIEW is that the programmer doesn't have to worry about parallel execution, multithreading or load balancing across cores. It is native to the language. Granted you might be able to fine tune it but this functionality is built into the language. The programmer must explicitly set up and manage all of this in traditional C/C++ code. If they don't do it they don't get any benefit of parallel execution.
I am sure someone from NI could explain in more detail what happens under the hood but suffice it to say you get MUCH more multithreading and parallel execution in a LabVIEW program than in your traditional languages.
05-12-2011 01:25 PM - edited 05-12-2011 01:26 PM
Some details about threads in LabVIEW can be found here.
@Mark Yedinak wrote:
LabVIEW does have the ability to control the items you mentioned.
An exception are timed loops, where you can assign them to a certain CPU if you like.
Back to the original problem: My current monitor is 2048x1152 and I will not touch your diagram. It is not manageable. Just glancing at it, there are glaring mistakes, really weird code, and many overly complicated constructs. You have empty timeout cases that don't do anything at regular intervals.
For example you need three loops with shift registers for something that can be done almost atomically:
Then you have things like the following:
What was the idea here??? 😮
05-12-2011 03:56 PM
If the problem is solved mark it as solved.
05-15-2011 05:04 AM
Hi,
Problem is solved.
Thanks again for everyone that helped!
I'll try to incorporate all your suggestions!
Greetings
kper
05-15-2011 11:38 AM
kper wrote:Problem is solved.
You should mark the post that was the most helpful as solution, this way later users with similar problems can quickly jump to there. It makes no sense to mark a reminder as solution. Thanks!
(If none of the posts were helpful and you solved the problem yourself, write a small summary and mark it as solution.)
06-02-2014 05:43 AM - edited 06-02-2014 05:44 AM
I had a similar problem ...my program stopped unexpectadly (no error, as if someone pressed the stop button). In my case i had a queue that was increasing in size with every iteration and at some point the program stopped because of that.
Solution: i used a block to flush the queue after each program iteration, to free some space.
Hope this will help someone in the future,
Best regards,
Valentina
06-02-2014 10:36 AM
@valentina.alina wrote:
I had a similar problem ...my program stopped unexpectadly (no error, as if someone pressed the stop button). In my case i had a queue that was increasing in size with every iteration and at some point the program stopped because of that.
Solution: i used a block to flush the queue after each program iteration, to free some space.
What good is a queue if you flush it with every iteration? That seems rather pointless. 😄