Hi Spencer,
I'll tell you a little more about the application and hopefully things will become somewhat clearer.
We are measuring road characteristics on a mobile system (a van fitted with a number of sensors, which are sampled on a distance-base. There a two sample distances: 1 mm for a laser-based system (16 or 32 bits), and 1cm or 10 cm (for a maximum of 8 analog channels). The maximum measuring speed will be around 110 km/h.
The sensors are mounted on different positions on the vehicle. Some at the front, and some on a trailer behind the vehicle. This means that a point on the road is not measured by all sensors at the same moment. The maximum distance between sensors can be almost 18 meters. Our data format corrects for these distances, but we therefore need/use a buffer which contains all the data for say 20 meters. The software picks the correct blocks of data (so that the data all correspond to the same 5-meter section of road, 5 meter being our standard processed block of data) and saves them to disk. As we have a lot of software that uses this data format, we do not want to deviate from this approach/format.
Now, If we used the LabView VI's for this, we would have the data-acquisition buffer in memory, PLUS an extra buffer to hold the required 20 meters of data. We would use double-buffering of course, so in case of the lasers, the acquisition buffer would be at least 10m of 1mm sampled 32 bits data, which is 40 kilobytes. This data would them simply be copied to another piece of memory - into another cirular buffer (the 20-meter buffer, so to say). Every 5 meters a DLL would be started which picks the right segments of data (of the laser, but also from the analog channels and a few counters) and save them to disk.
Why create our own circular buffer (which takes memory and processor time to make sure everything is copied correctly, remember write and read positions, etc.) when LabView already has done this: the acquisition buffer. If we make the acquisition buffer the right size (20 meters) and if we know the location in memory of this buffer, we can directly access the data. If we create the data-acquistion using the NIDAQ commands, we have the pointer to the array/buffer. No copying data, no self created and controlled buffers, no unneccesary CPU overhead.
- bare with me, I'm almost there -
The data-acquisition is hardware controlled. We have a mm pulse and a cm-puls which we use to trigger the laser and the analog channels respectively. Every 5 meters, we need to start the DLL which accesses the data and saves the correct results (with some calculations). The samplepulses are also fed to counters, so we can keep track on how many samples are acquired an also as an odometer. With an analog sampledistance of say 10 cm, I use a third counter counting down from 50 (5 meters), and at TC I wish to start the DLL. This is the basis for my original question in this thread.
Thats it! (pant, pant)
If things are still unclear, please let me know.
Thanks
Walter
