Dynamic Data Issues with Multifunction DAQ

[mfitzsimons]

I am having significant issues with a Multifunction DAQ (PCI-6220) and Dynamic Data. I have done many DAQ applications but this one requires a mix of Analog, Digital, adn Counters. See description below and attached code. This is in LabVIEW 7.1 format. Thanks in advance for any help with this issue.

Test Method

- Generate clock (CTR1) out on PFI.13
- Jumper clock to PFI.1
- Use PFI to trigger all acquire VIs: Analog, Digital, and Counter

Issues

- Can't merge 1-D digital Waveform to other Dynamic Data
- Want to merge to write data to file in single LVM file
- All data must have labels before writing to disk in LVM format
- Digital Waveform has no plot labels
- Merged Dynamic Data for multiple analog and encoder count
- Plot label form encoder count did not merge
- Not sure Clock Generation will work to trigger acquires
- I get error -50103 when run in sim mode
- I don't have access to equipment for a few more days
- Encode data is off by a factor of 100, WHY?
- Analog and Count Encoder have same number of samples to take
- Data is the same but dT is off by 100

[Kevin_Price]

I do a lot of DAQ too, and frankly, I go far out of my way to avoid digital waveforms, dynamic data, and any other special datatypes.  The few times I've goofed with them, I've found them difficult to work with.  Part of that is because I'm an old dog that knows enough old tricks that I need some convincing before trying new tricks.  Part of it is that certain aspects are non-intuitive and/or not thoroughly documented, or else much more inefficient than the old-school ways.

Do you need to stick with "Dynamic Data" and "LVM" formats?  If so, I'm curious -- what are their advantages?  I still simply acquire arrays and store either to csv ASCII or custom binary.  I've started looking into and playing with the new (as of LV 8.20) TDMS format (TDM streaming) and am hoping / planning to use it as a new standard format though.

Can't look at code now so can't comment on many specifics.  Admittedly not sure I understand several of them though...

I've done quite a few apps that hardware-sync analog, digital, and counter i/o, so I'd say there ought to be a path forward on those issues at least.  Will try to look at code when I get a chance.

-Kevin P.

Edit: spelling / typo

Message Edited by Kevin Price on 12-07-2006 11:49 AM

[JeffBoettcher]

I do not have all the drivers that are needed to run this installed personally, but you are correct that the Dynamic Data Type (DDT) does not support digital data.  It was designed with analog measurements, with the addition of being able to hold a small variety of simple data types, such as scalar numeric, boolean, etc, and then there are some conversion functions that will allow you to put a waveform, 1D numeric array, etc.

I'm not sure it makes sense to merge them though, as they can't really be displayed on the same graph type.

Also, are you sure the Encoder's plot label is getting lost at the merge?  It looks to me like the Encoder output never has a label, as the graph you've connected directly to the Encoder output also has a default plot legend name.

Those are the only issues that I'd probably be equipped to help with, I'm more knowledgeable about the DDT than I am about the Measurement functions.

[DFGray]

I stopped being competent in DAQ a long time ago, but I have a few suggestions and comments on your storage mechanism.

1. LVM was intended to cover about the 80% use case and be simple to use.  It was never intended to do what you are trying to do.  You can make it work by converting your digital waveforms to some sort of analog (e.g. convert your 2D array of digital waveforms to a 1D array of integers, then convert to DDT) before trying to merge with the other DDT.  This will probably make the LVM file less readable, however.  It will also make several data copies.
   
2. Do you really need to use LVM?  The best file format NI has for this type of storage in LV7.1 is NI-HWS.  HWS was designed for waveforms and will handle all the types you need.  It is the fastest streaming solution we have for few waveforms (TDMS is faster for large numbers of waveforms, but is not available on 7.1).  HWS is also based on HDF5, so is a self-describing file format and can be read by most major analysis packages (Matlab, Mathematica, etc.).  It also has native compression.
3. TDM will also work for you, but will be slower.  You can choose either a text or binary form of TDM, with text being pure XML and binary being blobs embedded in XML.  I would recommend the binary, if you go this route.

Final recommendation - use NI-HWS for your file storage.  It will solve most of these problems.

[Kevin_Price]

Similar thread in the MIO board over here.  I was about to request that followups go there, but there've already been 2 more reponses here addressing issues that do indeed belong here on the LabVIEW board.  So, uh, never mind, unless the followup is specific to the MIO hardware.

-Kevin P.

[mfitzsimons]

Reading many responses and will post soon

 Thanks!

[mfitzsimons]

Thanks for all the responses.  You have convinced me that for this case to ditch the Dynamic Data type and put it into a format I can work with.

I have done some DAQ applications that were all analog signals and the Dynamic Data type worked very well.  I guess it hits a limitation when you try multiple data types and merge them together.

I think I have it under control and will rewrite the application using good old Waveform formatted data.  I thought I was doing something wrong and there was a simple solution.  In this case it was the wrong tool for the job.