From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
04-30-2010 03:12 PM
Hi all,
I searched around, but I couldn't find any posts with my exact situation. Here it goes:
I have an AMD Phenom 64 multi-core processor and I'm running Windows 7 64 and I'm running an application in LabVIEW 8.6.1 in compatibility mode. (I know, not such a good idea) I have a rather complex application with several timed loops and various means of talking to FieldPoint (FieldPoint 6.0.6 and experimentation with Modbus talking to cFP-180x). You might be wondering why I'm using timed loops. This is an RT application that can also run on Windows using conditional disable structures, etc.
I had encountered sporadic crashing earlier on in my executables over a year ago and used a patched version of lvalarms.dll in only my executables. This was on a completely different processor and we were running Vista at the time. Now I'm noticing very similar behavior on 8.6.1, except now the whole development environment crashes or my compiled executable crashes as well.
I found this KB, but it was in reference to issues observed on LabVIEW 8.5, and the OS utility is only for Windows XP. As recommended in the KB, I used BCDEdit to set the onecpu flag and now everything appears to be working normally. My PC is now noticably slower, however, and I'm wondering if there is another workaround that I might be able to try.
If you've read this far and have followed my description you already have my gratitude. Has anyone else encountered this? Does anyone have any ideas?
Many thanks,
Jim
Solved! Go to Solution.
05-02-2010 07:00 PM
I've had all sorts of problems trying to use timed loops in LabVIEW 8.6.1 on non-real-time Windows (only tried 32bit OSs).
The only way we could achieve stability and performance was to replace ALL timed loops with while loops.
You just have to get more creative with how you control you're timing.
When I mentioned the problems I was having at an NI seminar, I was told that timed loops were designed for RT.
They can be used in windows but it's not really what they were designed for.
05-03-2010 08:54 AM
Troy K wrote:I've had all sorts of problems trying to use timed loops in LabVIEW 8.6.1 on non-real-time Windows (only tried 32bit OSs).
The only way we could achieve stability and performance was to replace ALL timed loops with while loops.
You just have to get more creative with how you control you're timing.
When I mentioned the problems I was having at an NI seminar, I was told that timed loops were designed for RT.
They can be used in windows but it's not really what they were designed for.
Hi Troy - thanks for getting back to me. I guess you've confirmed what I've suspected for a while - that they really are designed for RT. It's funny because 95% of the time they're okay on Windows - it's just that 5% that really makes things difficult. I suppose what I can do is implement some fancy conditional disable structure logic and perhaps some home-brewed timing algorithms. Turning off the additional cores (completely) has definitely worked, as LabVIEW ran just fine over the weekend. Before I start experimenting with changes, however, I'm going to see if there's a way to disable multiple cores on a single Windows application.
Have you noticed differences in how LabVIEW 2009 behaves in this regard? I'm running myriad other applications on 2009, but I've been procrastinating the upgrade this one due to its complexity and critical application.
Thanks again,
Jim
05-03-2010 10:58 AM
Alright. In the event that someone else runs into this apparently obscure scenario, here are some workarounds I've found:
1. See if the problem goes away by setting processor affinity using Task Manager. Open Task Manager, look under the "Processes" tab, and right click the process. (e.g. LabVIEW.exe or your executable) Under the resulting context menu select "Set Affinity..." and select only CPU 0. In my case, I have a quad-core processor, so I have up to four logical processors that show up on the resulting dialog.
Run your application code or its executable for a while, and if all appears to be stable, it would seem that you've successfully isolated the problem.
2. One option is to disable additional logical processors for the entire OS, though there may be adverse implications on performance. In that case, try the instructions listed toward the bottom of this KB. I have Windows 7, so I used the bcdedit command line utility without any issues.
3. Finally, a really attractive option that's worked well for me is to automatically set processor affinity for each individual process. There is at least one utility available to accomplish this. I've now modified my LabVIEW 8.6 shortcut to call RunFirst, which sets the processor affinity for LabVIEW to use the first logical processor automatically. This way I can still use my quad core processor for all it's worth except in applications that have issues with it.
I hope this helps someone else out someday.
Jim
05-03-2010 06:09 PM
I only just switched to LabVIEW 2009 last week because of a memory leak in 8.6.1.
We've ran into problems with timed loops a couple of times so I'm hesitant to try them again.
For timed structures you can set the processor assignment manually. Maybe that will work similar to setting the assignment with the utility you found?
05-04-2010 08:26 AM
Troy K wrote:For timed structures you can set the processor assignment manually. Maybe that will work similar to setting the assignment with the utility you found?
Well, sort of - at least you would think so. I had experimented with setting the processor assignment on the timed loops early on, but it actually seemed like I was seeing crashes more frequently when selecting a processor manually as opposed to using the -2/Automatic setting. At first glance it might seem like it accomplishes the same end result, but my experience has been that allowing LabVIEW 8.x access to all cores/logical processors and using timed loops in any form within Windows (regardless of manual processor selection on the loop) can cause the unpredictable crashing behavior. It's hit or miss on processor architectures, though. Most of the time it works perfectly, but since I've moved to a quad-core Phenom workstation I've started observing this behavior.
I should stress that I certainly don't see it as much of a shortcoming on the part of NI's development effort; there are so many processor architectures out there that it has to be difficult to account for all of them.
05-18-2010 04:11 AM
Hi,
Just for reference, the Timed loops also have issues when working with DAQmx functions. DAQmx acquisition running in continuous mode on more than 5 channels will crash if placed inside a timed loop. Also note that if you are running a continuous acquisition on a multi core machine in one VI and attempt to start a timed loop (even if it is in a completely separate VI) will cause the DAQmx to return error -200279: buffer overflow. Manually assigning the processor on the timed loop sometimes allows it to start but it seems to be dependant on which processor the other threads are running on. NI are aware of the problem and currently recommending (to me at least) not to use timed loops on windows systems at all. The problem now is getting decent timing control on a while loop execution rate...
05-18-2010 02:36 PM
We suffered through similar problems in DSC 7.0, and learned to use the micosorft imagecfg.exe utility to permanently set processor affinity for particular NI processes.
http://www.robpol86.com/index.php/ImageCFG
It's a very simple approach, and absolutely got the job done when we needed a persistent fix. Sadly, we now see reason to use it with DSC 8.6, these pesky multi-core CPUs seem to be a real bear for developers.
05-18-2010 03:09 PM
Thanks, Andrew. That's a great option, even though it appears that imagecfg hasn't been supported "officially" for some time. (For reasons unknown) It looks to be a bit more permanent as a solution than the one I'm using now, in addition to being user friendlier in the long term.
Being a Windows 7 user, of course I had to see if there's some kind of recent, "officially" supported solution, and it appears that I'm in luck. I haven't tried any of these, but I definitely plan to when Ihave a free moment:
start /affinity 1 mspaint
The best part is that it leverages a command already native to the OS. (At least in my case)
In an effort to avoid thinly veiled plagiarism, here is the link where I found most of these solutions:PsExec.exe -a 0 c:\Windows\notepad.exe
Jim
03-31-2011 01:11 PM
I have run into similar problems with Timed Loops. I am not seeing crashes, but my system will hang for 5sec intervals, sometimes 10sec or even 20, but multiples of about 5sec. I only see this when using multiple Timed Loops on a multicore system whether internally or DAQ timed.
My workaround has been to use a single Timed Loop to set notifiers and while loops with WaitForNotifiers in them for all other tasks. I implemented a custom high resolution timer to monitor jitter. The jitter stacks up if you use an internally-timed (1kHz) Timed Loop and the Notifiers. If you use a DAQ-clock-timed Timed Loop, the jitter is basically just that of the notifiers and very small.
If you use the attached vi's you may have to copy the folder to c: for the high res timer dll paths to work.
(Anyone know how to programatically alter the path in a dll call node? It always seems to find the files, but I still wory)
I have also attached screen shots of the VI for those with LV versions earlier than 2010.
Hope this helps,
-Eric