Herbert

QUOTE(PJM_labview @ Apr 30 2007, 08:21 PM)

1) Attempting to read properties that do not exist from a TDMS file return whatever was last read from the TDMS get property primitive (from whatever was the last TDMS file the TDMS get Property was invoked on). This is VERY confusing.

Yep, that's a known issue. The door on 8.2.1 closed too early to get the fix in.

http://forums.ni.com/ni/board/message?boar...uireLogin=False

QUOTE(PJM_labview @ Apr 30 2007, 08:21 PM)

Thanks for catching that. I had never seen that one. It seems to crash only if the output is a variant. CAR# 4909S6WJ.

Thanks,

Herbert

QUOTE(torekp @ Apr 24 2007, 01:13 PM)

Then I can decimate my data in-place as needed.

I see the point of decimating a large file, but why would you want to do that in-place rather than into a new file? How would a reading application know which parts of the file are decimated and by which degree?

If what you want to achieve is some kind of ring buffer, you can do that with either LabVIEW File I/O (reset pointer to beginning of file) or you could use TDMS. In case of TDMS you would simply use 2 files and switch between them every time one of them reaches the "critical" size. The only downside of TDMS here is that you need twice the disc space. Reading data back from a file that you partly overwrote in-place is just as complicated (or simple) as reading data back from two different TDMS files, so the solutions are really similar.

Just some thoughts,

Herbert

I'm picking up the discussion from here, because we obviously agree that this is the thread to talk about it.

QUOTE(Ben @ Apr 23 2007, 07:27 AM)

If the data is stored as "native datatype (dbl, u32, etc) " DIAdem can do its magic without any help, correct?

Correct. It doesn't really matter if you just display properties in a report. But if you use the values to calculate something (e.g. scale a channel), or you require a particular number format, using numeric properties saves you some conversions.

Storing properties to their native data type is generally a good practice, even if you work in LabVIEW only. For the cluster use case it is obviously less important, because we already know which data type to expect.

Herbert

QUOTE(PJM_labview @ Apr 20 2007, 10:51 AM)

If there are unsupported data type, may be the help for "TDMS Get Property" should be updated to reflect that.

Is there any other unsupported types?

PJM

I agree. The help for "Set Properties" actually lists the allowed data types, unfortunately the list is wrong. I've filed documentation CARs accordingly. The following data types are allowed as TDMS properties:

• U8, U16, U32, U64
  
• I8, I16, I32, I64
  
• SGL, DBL, EXT
  
• String (alphanumeric, cannot contain null terminator(s))
  
• Timestamp
  
• Boolean (supported, but there's a bug with booleans in "Get Properties")
  
• Variants that contain any of the above types
  

Any other data type should either break the wire or return a runtime error.

Herbert

This is another occurrence of data types that are available in LabVIEW, but not in other TDMS clients like DIAdem or CVI. We are gradually implementing these data types, but for each of them, we have to find ways of making it work for the rest of our platform, which is sometimes not as easy as it sounds. I cannot currently give you a timeframe for when complex numbers will be supported.

The bug here is that there seems to be a way of wiring up a complex number and undoing stuff so the wire isn't broken.

Herbert

QUOTE(bbean @ Apr 20 2007, 08:46 AM)

Seems like the boolean data type is not supported directly by TDMS.

This is a bug. Booleans are supported, but that's not working correctly. CAR# 48B7CBWJ.

Herbert

QUOTE(chrisdavis @ Apr 18 2007, 04:51 PM)

Another issue I found when I started using these API funtions was the inability of C's fwrite function to write a file bigger than 4 GB.

fwrite, iostreams etc. are just planted on top of the native Windows file I/O for compatibility with standard C/C++. The lowest-level and fastest API is the one centered around CreateFile etc. That's where all the good stuff is accessible. The fastest thing in Windows is asynchronous ("overlapped"), non-buffered I/O. That keeps your hard drive going at maximum speed while the processor(s) are free to do other things.

Herbert

The issue appears to be caused by an incompatibility between the TDMS functions in the LabVIEW 8.2 and 8.2.1 runtime engines. Unfortunately, we do not have a workaround for this problem. I'm not sure how well uninstalling DAQmx versions / runtime engines and replacing them with older versions works. That sounds like the kind of thing that might not work as smoothly as it maybe could (uninstalling DAQmx might leave the installed runtime engines untouched / reinstalling 8.2 runtime might not do anything if 8.2.1 is present / runtime engines for recent LabVIEW versions cannot be uninstalled in the Windows Control Panel etc.).

Details on this particular issue:

• An application that uses TDMS and is compiled with 8.2 will only run with the 8.2 runtime engine. It will not work with DAQmx 8.5 (or higher) installed, since this updates the runtime engine to 8.2.1. The runtime engines for 8.2 and 8.2.1 cannot coexist on one machine.
  
• If your application requires DAQmx 8.5 to be installed, the only way of getting things running is to compile your application with LabVIEW 8.2.1.
  
• For the same reasons, an application compiled with 8.2.1 will not run with the LabVIEW 8.2 runtime engine.
  

The issue can result in several different errors coming from any one of these functions: TDMS Write, TDMS Read, TDMS Set Properties.

Probably the worst birthday present ever.

Sorry George!

Herbert

According to MS documentation, using the Windows file functions without buffering requires you to allocate memory at certain offsets and in certain chunk sizes (both should be multiples of your hd sector size). It works for the vast majority of hard discs without that. I do not know which hard discs are exceptions to that. LabVIEW does not allocate memory that way. I'm not aware of any other limitations of that technology.

The performance gain with a single hard disc should be easy enough to measure, but it is not going to be huge. Performance gains are very impressive though if you're using a RAID array. A RAID array with 4 hard drives will speed up traditional LabVIEW file I/O by roughly 20%. Without buffering, writing speed will almost quadruple.

Writing speed obviously varies with the number of drives connected, but it also strongly depends on which controller you use. Some controllers are as much as 20% faster than others, and different controllers have different "sweet spots" for the size of the data chunks you write to disc. If you want to get the best out of that technology, you will need to figure out these things for your actual equipment.

Herbert

This is one of the most basic areas of the Win32 API and it has been like that forever (including FILE_FLAG_NO_BUFFERING). Of course you never know for sure what MS is doing next, but with this, you are as safe as you can get.

Herbert

Kevin,

the cool thing about the OpenG-based solution is that it is ready for cluster structures of arbitrary complexity. If your cluster isn't too complex, you might get away with something more straightforward. Of course, none of these solutions is as straightforward as the U8 array. I'm adding this more for further reference than in order to talk you out of the U8 solution.

Examples:

If your cluster contains no arrays, clusters or containers of any sort, simply loop over the "controls" array. Passing a variant into "TDMS Set Properties" will create a property of the same data type that the control has (if supported).

http://forums.lavag.org/index.php?act=attach&type=post&id=5515

If you are using nested clusters, you can use the example VI "Queue Control Reference Info" as boilerplate code, so you end up with something like this:

http://forums.lavag.org/index.php?act=attach&type=post&id=5516 http://forums.lavag.org/index.php?act=attach&type=post&id=5517

For arrays, you would need to add a case similar to the above "30" case. And you might need a reading VI. Plus, the error handling could use some improvements .

Herbert

QUOTE(PJM_labview @ Apr 13 2007, 04:42 PM)

Modifying the OpenG Variant Configuration Tools works like a charm. I quickly made a writer based on the write ini cluster.

Very cool. :thumbup:

Herbert

QUOTE(Kevin P @ Apr 13 2007, 02:58 PM)

1. Please tell me if the following is correct: When using TDMS properties, each Write operations *overwrites* old data related to that named property. When using TDMS channels, each Write operation *appends* to old data related to that named channel.

[...]

It would appear that if I need to use TDMS channels for this data, I'd better use standard functional globals and then be sure to perform one and only one TDMS write at test completion.

That is correct. We do not yet have a way of deleting objects or overwriting channel values in TDMS files. Using a variable sounds like a good solution.

QUOTE(Kevin P @ Apr 13 2007, 02:58 PM)

You're perfectly right. The idea here is to store a piece of information to the file that can tell you which version of your cluster the file contains. I guess I went a little overboard with this when I stored the complete type descriptor to a channel. You can instead store a version number for your cluster to the file (e.g. as a property of the channel that contains the flattened cluster data). When you read the file, you can then use a case structure that has a case for all cluster versions you have used over time. In each of the cases you unflatten using the appropriate cluster type and convert to the newest version.

A crude, but working solution is to always try unflattening with the newest version of your cluster, then trying the next older version if "unflatten" returns an error, and so forth, until you succeed. That way, you don't even need a version info in the file.

Herbert

More details on ni.com.

Herbert

Kevin,

TDMS properties are reserved for "human-readable" strings. The reason is that they need to play well with other software accessing them, in particular DIAdem and the NI DataFinder.

If you want to store cluster information, I recommend flattening it into a U8 array and storing it as a channel. You can also store the data type as an array of I16 to a separate channel in order to handle changes in your cluster data type. See the attached screen shots for how to do that.

Hope that helps,

Herbert

Write cluster type and value to TDMS channels:

http://forums.lavag.org/index.php?act=attach&type=post&id=5503

Read cluster type and value from TDMS channels:

http://forums.lavag.org/index.php?act=attach&type=post&id=5504

QUOTE(george seifert @ Apr 11 2007, 06:28 AM)

I was taking the AI.CustomScaleName from the DAQmx Channel node and feeding it directly to the Set Attributes VI.

I see. I thought you had taken the whole waveform from a DAQmx VI, in which case it should have been a string. We normally coerce tags to strings in most LabVIEW functions, but if they are "hiding" in variant/waveform attributes, that doesn't happen automatically. Need to add that in TDMS Write.

Thanks,

Herbert

QUOTE(JasonKing @ Apr 10 2007, 03:42 PM)

I feel sorry for the ferarri driver who pulls up beside this New Beetle at a stoplight:

http://hpamotorsports.com/projects_finished_cannonbeetle.htm

http://www.motortrend.com/features/perform...kswagen_beetle/

Not to mention this one:

http://www.techeblog.com/index.php/tech-ga...wered-vw-beetle

Herbert

George,

I have tried your VI and I can reproduce the problem. The root cause is that the data type of the "NI_ChannelName" property on some of your waveforms is "tag" instead of "string". My first thought would be that the change in data types was introduced by a new driver version. Did you recently update your drivers?

The issue is filed as CAR# 489IR4WJ. There is a workaround, which is converting the property type from tag to string (that's a perfectly valid conversion). It's not nice, but at least it is simple.

http://forums.lavag.org/index.php?act=attach&type=post&id=5459

Sorry for the inconvenience,

Herbert

Herbert

QUOTE(Rick @ Mar 7 2007, 02:05 PM)

Is this a known fundamental limit of the "Get TDMS Properties" primitive?

No, that's a rather embarrassing bug in the TDMS File Viewer. The good news is that you can fix it really easily. It's in a subVI called loadAndFormatValues.vi. This subVI contains a loop that first gets the NI_DataType, correctly as a U16. I think I must have copy-pasted this in order to read the NI_ChannelLength right after that, without changing the data type to U64.

All you need to do is go into this subVI, right-click the integer constant that determines the data type for "Get Properties" (the one that gets NI_ChannelLength) and switch the representation to U64. Obviously, this will be fixed in the next LabVIEW release.

The reason it works on the "Properties" tab is that we get the properties for this tab as variants. These are then converted properly. The "Get Properties" we use for the dialog that configures how many values you can see in table and graph have the correct U64 constant wired.

Hope that helps,

Herbert

- This is being cross-posted to death right now.

- The print preview in LabVIEW is in File->Print->Next->Preview.

- See this thread on ni.com for more.

Herbert

To see the dialog in LabVIEW, go to File->Print->Next->Preview.

I gave some recommendations for programming a similar dialog in LabVIEW in this thread on ni.com. It basically involves the LabVIEW Picture Control and some VI Server methods that do most of the legwork for you.

Herbert

Right-click the Express VI and select "Open Front Panel", then select "Convert" in the following dialog box. That'll bring up the VI that will be executed at runtime. The VI you see there is a special flavour of reentrant VI called instance VI. It is embedded in the VI you dropped it on and you shouldn't modify it for various reasons. It's main purpose is to contain the settings you make in the configuration page.

The actual functionality of the Express VI is contained in a subVI of the instance VI. That subVI is just a regular VI that you can copy, modify or whatever. For the DIAdem Report Generation Express VI, the VI you're looking for is .\vi.lib\Platform\express\DIAdem Report.llb\Execute.vi.

Hope that helps,

Herbert

I guess that reminds me of that we sometimes abuse the timestamp type for things it wasn't originally designed for.

I spare you the details

Herbert

While I generally agree that we could potentially shoot for an even better user experience , there are some little helpers available in .\vi.lib\Waveform\TSOps.llb that can ease the pain of adding and subtracting time stamps.

Hope that helps,

Herbert