Hello all, I am a graduate student will little programming experience trying to modify our lab's code to use a new detector which interfaces to the computer with a NI PCI-6534 card. The code is written in Borland C++ builder 6 and uses the ANSI C library support provided with the NIDAQmx drivers.
I have been able to get data, but have run into problems when trying to run experiments and retrieve many scans. After taking so many scans, the computer will freeze up completely, as in you must hold down the power button for a hard reset. How many scans before this occurs is tied to how many accumulations are requested, higher accumulations will freeze the computer in fewer measurements. It seems to be somehow related to the NIDAQmx ReadDigital32 function writing outside of the allocated bounds of the buffer array, as the computer only freezes when I include this step while executing the program, and purposefully making the buffer much larger, say 100x, only delays the freezing. I
This is the our code that reads the data, I only copied enough of the GetScanData() function to show where it puts the data from the GetRawData() function:
There are a couple of debugging tools that I think will help narrow down what is happening:
1) Can you enable the Resource Tracking Window? This will allow you to see the memory allocated by your variables as your programs run and lets you look for memory leaks. You go to options -> build options -> Configuration Options and set the "Debugging Level" to extended.
2) Can you monitor the memory being used by CVI inside of the windows task manager? If you are experiencing a memory leak the amount of memory being used by CVI should slowly be increasing over time.
Hi, thanks for the response. I'm actually just using the NIDAQmx api in an application built in Borland C++ Builder 6, so I dont have those options. what I have done is use NI Trace to capture all of the api function calls until the program crashes, and it seems to crash in the midst of a DAQmxReadDigitalU32 command. I'm attaching the end of the captured nitrace file, its the last data collection cycle the code runs and then crashes partway through the buffer.
I'd be curious to see if we are writing to memory that is never released. What does the memory indicator in your Windows task manager do while this code runs? A steady increase might mean that the program eventually begins to overwrite memory not allocated to LabVIEW, causing a system halt.