12-31-2009 10:19 AM
Sorry for the delay I've been out on Christmas break, it sounds like it might be time to engage our technical support team. Several of your symptoms do sound like the main thread is starved of CPU resources; the RT Get CPU Loads.VI will give you a better idea of what the CPU load is like during operation. Do you have access to NI support?
01-07-2010 10:18 AM
I've been out too. I decided to try re-downloading the reference application and rebuilding my program. I noticed that the program I downloaded last week had some small differences from the one I downloaded a couple months ago. The major difference in the file I downloaded recently is that it indicates the DMA buffer (usually) runs at less than 0.1%. The older version of the file had it usually at 10%. Along with this there are a lot fewer buffer overflows. These differences seem to have helped and with a little tinkering the cRIO is running reliably now.
Here are some changes that I made on top of downloading the reference application. They seem to have helped it run more smoothly.
- I increased the block size from 1 second to 2 seconds of data
- I changed the free space required in drive cleanup from 30% to 40%
- The drive cleanup program was set up in a way that would cause a crash if data files were deleted manually (ie via ftp) without then restarting the cRIO. I changed it to recreate the list of files in the directory each iteration.
- I had an overly sensetive trigger on the RMS vibration levels which was causing files to be saved more frequently than useful. Removing this seems to have helped also.
To respond to your comment about CPU resources, even when using my old program the CPU load was never over 60%. As it is running now the CPU load is around 20 or 30%. I don't know if the higher load in my old program would have caused the slow behavior. Another thought is that the version running now does a better job of handling the DMA buffering and/or hard drive space.
Anyway it has been working great over the past several days and I apreciate your help and feedback. Hopefully my difficulties have not all been from being new to LabView. If you would like me to send the version of the program that is working for me just let me know.
05-04-2012 01:50 PM
We were using your code for our bridge: http://sine.ni.com/cs/app/doc/p/id/cs-13804. The system we used to have had two module 9234 and one 9211. It was working all fine. Recently We added 8 more sensors and we need to reprpgram the cRIO for the new sensors or new two 9234 modules. I change the code we have, which was midified version of yours, based on steps mentiond in the walkthrough PDF file of project 1: getting started SHM page 5.
I also changed the cfg file (text file on cRIO) and added the extra 8 channels. However, the code is not working and the cRIO is not saving any data! I think the trigger is not working anymore. It is supposed to save 5 minutes data every hour.
I need technical help on this. It is the first time I am using Labview. It would be highly apprecuiated.
05-13-2012 06:08 PM
I am using the code. I modifyed the code for the extra modules we recently put on the cRio. Now, when I run th FPGA vi, the DMA FIFO FULL light of the front page will be turned on simuntaniously with FINISHED light. Do you know why and how I can avoid this to happen.
02-21-2013 02:09 AM
i used until now a crio 9012, in the Module rwfm ConfiTiming as in the picture you can see a 40M. could someone explain why we have to use this 40M? does this mean 40M = 40Mhz?
now when i use a crio 9024 which has 800Mhz what do i write 80M or 800M or always 40M?
thank you for ur help
02-21-2013 09:26 AM
That 40M represents the 40 MHz clock of the FPGA. That little math is calculating the number of ticks in your sample period. You would only need to change that number if the FPGA clock was something other than 40 MHz.
S&V Systems Engineer