tdms not recording all samples

[McMurray]

Hello!

I'm attempting  to record somedata from my USB-6120 to a TDMS file.  The data is sampled at 1kHz, for a total of 1k samples.  My output array is of the appropriate size (1000 entries), but the TDMS file is only recording 40 samples.  For the life of me, I just cannot figure out why it's not working.  If anyone has any ideas, I'd greatly appreciate them.  I've attached the vi, but the forum won't let me upload a sample TDMS output file.  It's definitely possible that I've misunderstood how to use TDMS files, so if you see something blatently wrong, don't be surprised.  Thanks ahead of time for the help.

Matt

[Christian Mergl]

Matt,

There are definitely TOO MUCH VARIABLES used!

Christian

[McMurray]

But that wouldn't cause my issue... Clearly I'm not a professional LabView programmer, I'm just trying to get the vi to work.  Can you offer any suggestions regarding this aspect of the program?  Thanks!

[Christian Mergl]

Maybe it's causing your issue, but it will definitely causing other issues - race condition.

I'm sorry, but I don't have that much time right now to try understanding this really poor readable code.

I would highly recommend to first change your design and use wires with shift registers instead of variables.

Christian

[AndrewMc]

Hey Matt,

First of all, your VI is actually well-written.  Your use of the state machine architecture made the code really easy to read.  I was able to transition from one state to the next on a single screen (no scrolling or opening subVIs) and it all made perfect sense what was happening.  You are using local variables a lot, but I don't see any places where you could run into a race condition.  All of the variables are rather static in nature (file reference is opened only once and is read-only after that point, whether to include a particular chamber or not is again determined once and read-only after that point).  Like I said, it was really easy to read the code, and the use of local variables didn't seem bad.

Secondly, I've reviewed your VI and found something to try and pin down the problem but as well improve the application.  I notice that you're reading from the DAQ Assistant, converting to a 2-D array, and then individually finding each channel with Index Array.  This seems like it could be a likely source of error in getting the indices right.  Additionally, the timing information is lost in this conversion (t0/dt) that might be beneficial in looking at your data.  What I would recommend is to actually use four of the "Convert from Dynamic Data" functions instead of just the one.  Then, in the dialog for each node, you can select either "1D array of scalars - single channel" (if you really don't care about timing information) or "Single waveform".  Finally, select the appropriate channel number in this dialog for each instance of the node (0-3).  This seems like it could be a potential problem area in the current implementation, but as well this solution would just be a little safer.

Please let me know if this still does not resolve the problem, and I can look into it further.

[Norbert_B]

Matt,

i spent about an hour trying to pinpoint the behavior you are seeing. Without success. So i assume that you posted a different version of the VI than you are describing (in the VI, you acquire 6000 samples per channel for instance, not 1000!)....

Since there is some kind of discussion going on about your code, i will provide my personal thinking as well:

First of all, the code is not "well-written". It lacks of many important features which distinguishes "good code" from "bad code". Taking a close look into the code it is quite obvious to me that you are used to program in procedural languages, i would say primarily in C.

Sadly, this leads to "non-LabVIEWish code" which will result in reduced performance and most often in reduced readability and scalability. Nevertheless, i have to concur with Andy that the design of the code (the graphical layout) looks quite good, at least much better than most of the code posted in the forums. So this is definelty not the point here and i hope that you take my post as constructive feedback and  keep the cleanlayout of the blockdiagram.

But now to the list of things you should change:

1. Remove ALL local variables. Andy is correct that there is no "real race condition" in the code, but variables have several disadvantages which might strike when reworking/extending the software.

2. You have two "race conditions" in your software already. Locals are involved but not the reason though. The locations are: Taking the timestamps for the elapsed time. You include the "Ready to Start?"-Dialog (unknown time until the user presses OK) and on the other hand you exclude the data acquisition of the current iteration (to an unknown amount since it is multithreaded). I doubt that this is really desired behavior (but possibly it is....).

3. There is no real error handling which helps during debugging. Hiding the error out without any display of an error dialog is no good.

Additionally, the software does not recover from any "intentional errors" (e.g. if the name of a "chamber subject" is identical to one from a previous execution). This is always a bad idea.

4. There is no way to interrupt/pause the execution once the chambers are "working". Running an application for about an hour without the chance to stop it gently in between is a no-go for software development!

5. The user does not get any useful information about the progress of the software. This does not match the heuristics for an user interface. Please consider to rework your application to match the suggested usability.

6. You have several unneeded coercions. This might not be an issue in this software, but if talking about good programming style, this is definetly a point to mention. Please change "iterations" to be an I32. Another location of coercions are the connections to the graph indicator.

7. Working with paths does not require strings. Change the "Root" to be a path control and use "Build Path" in the "Make Directories" and "Initialize Files" State instead of the Concatenate Strings .

8. Remove redundancies. You have four chambers, therefore you now do the same stuff four times (create directories/files, write and read tdms files). This is not scalable. What if in the future the software should handle 20 chambers simultateously? 50? 100? 

Ok, i think those are the most obvious and important issues in your software which do not create the issue why you were posting.... Nevertheless, you should know about them and i ask you to improve those.

Now the reason for the issue why you were posting:

I am quite sure (at least to my tests) that the "Transpose 2D Array) is creating your issue and has to be removed. That's it.

hope this helps,

Norbert