Real-Time Measurement and Control
TDMS Read Returns Different Data If On RT
@nanocyte wrote:
Here is my work around. It should have quite good write performance.
Yeah I thought about that kind of approach. But one thing I wanted was to flatten an array of clusters, into an array of strings. The reason was that when looking at it in a TDMS viewer it would be easy and obvious to make the comparison with other samples of other channels in that data. Say I have an array of time stamps to go along with it. Now I know that each cluster (which is a scalar sting) has a corresponding time stamp at the same index just in another channel within the same group. I also did worry a bit that flattening data to an array of bytes would make for very large number of samples when writing because now each element in the array is many samples in the channel.
I did eventually have an option for multiple cluster samples within a single channel sample, and that was through a compression. Then I obviously needed another channel to track how many cluster samples were in each channel sample. But again this is pretty easy to do if the number of channel samples are the same and indexes match. It is a trade off in performance, readability, and file size.
But all of this really shouldn't be needed. If I am writing a string, it shouldn't matter if it is extended or not, LabVIEW should interpret it as an array of bytes. Stopping at a null byte is understandable, but changing the bytes read because of the platform seems weird.
Did anyone ever open a support request for this and get a CAR number? This just bit me on some analysis I was trying to offload to a different computer.
I've never heard NI respond to this issue. I posted this information in the hopes that NI can make LabVIEW better. Until they do all I can do is work around the issue, which I think we have.
