Leaderboard

Disclaimer that this is from the perspective of someone who helps people who call in to NI with problems rather than a developer If you have not built an application using RT/FPGA, are very familiar with DAQ, and do not need to use the FPGA for any of the reasons smithd mentioned I would agree with using the cDAQ controller. You'll probably save a lot of development time if you stick to something you're comfortable with. In terms of general use and debugging for your real-time application, it will feel very similar to testing and debugging a windows application. When you click the run arrow on your VI it will deploy code to your target (minimal time) and you will be running your code interactively which means the application is running on the remote target but still gives you access to most of the normal debugging tools. When you are done and want to deploy an executable, you can build an rtexe and set that to run when your target powers on all from your project. You can troubleshoot this the same as you would a debuggable executable running on a separate computer. FPGA is a separate beast and it does add to development time as people have mentioned, especially if it's your first time. I think RT is pretty good once you get past the whole finding the target in MAX part. -Matt J

I was wading through an old SCC repo today, and stumbled upon some of our old tools - the ones that existed before VI Analyzer, execution trace toolkits, complexity metrics, Requirements Gateway, et al. Here's a few screenshots for those that have been in the LabVIEW world long enough to remember the VISTA offerings from V I Engineering, in the days of old - enjoy a trip down memory lane!

LabVIEW can do some funny things, with constant folding, deleting dead code, and caching results from previous calculations. That coupled with the fact that UI elements are updated asynchronously, probes, automatic error handling, and debugging, can cause code that measure execution speed to be some thing that is trickier than initially thought. You may want to post the code you made which calculates this speed test so we can determine if it is calculating a speed properly.

I think you'll find that "affordable industry PC" is a bit of an oxymoron

Delacor is thrilled to announce the release of the DQMH Toolkit 2.0 to the LabVIEW Tools Network (LVTN). This 2.0 release brings a number of new features (they are awesome and worth the download alone) and improvements. These changes were inspired by our desire to give you the best possible experience for rapid LabVIEW application development and by the great feedback we received from you. We have incorporated some of this feedback into our 2.0 release and will continue to do so on future releases. You can read the release notes for a full description of all of the changes. At your convenience head on over to the LabVIEW Tools Network and grab the DQMH Toolkit 2.0 directly or upgrade by refreshing the package list in VI Package Manager. If you are upgrading from an earlier version of the DQMH Toolkit please ensure that you upgrade the Delacor QMH package that will take care of upgrading all the toolkit required packages. All that remains is to launch the DQMH and get to work! Many thanks, Team Delacor

Disclaimer that a lot of my knowledge on this subject is not from hands on, but research. I have lots of experience with cDAQ, and lots from FPGAs, but not so much when it comes to RT or embedded targets other than FPGA. When using a embedded target, you'll program on your normal host (usually Windows) machine and in the project you will add your target. Then you will write VIs for those targets and deploy from within your host. Then some level of debugging is done on that host machine, for the code that is running on the target, this always involves seeing front panels, but also some level of probing for some targets. (for example FPGAs don't allow probes breakpoints etc.) When using a cRIO almost all I/O go through the FPGA. There are exceptions for things like serial ports which I think just show up as a VISA resource. So full cRIO applications may have three targets, the FPGA, the RT, and Windows, all in the same project. But for debug you can temporarily ignore the Windows target, and for the FPGA you might be able to get away with the Scan Engine, which is a FPGA profile that just reads all data and sends it to the RT. So you might be able to get away with just needing to write one program, but then when you need more control you can write code for the FPGA, and then a custom UI might be needed on Windows. All three targets have the familiar LabVIEW IDE, just some have a subset of palette items. I have never used an embedded cDAQ chassis but I believe they are a target in the project and you write code and deploy it like before. But in this case I/O go through DAQmx and not through an FPGA. A lot easier, but less flexible.