Writing real time data to binary files using USB connected Delsys Trigno EMG system.

[NA7]

I'm using a VI written specifically for viewing real time data from a Delsys Trigno system.  I'm trying to save the data for each of the 16 channels in a single or individual binary files.  The end goal is to process the data in Matlab, but I cannot open the files in Labview successfully.  The data is incorrect or the files are empty depending on the waveform source.  I've gone through the forum and everything I've found for real time data is with a DAQ.  I've tested my writing and reading method with a waveform generated in Labview, but when I try with real time data, the method doesn't work.

[Dennis_Knutson]

I don't believe you are using the term real time correctly. Continuously acquired data can be saved in a variety of ways and there are numerous examples for file I/O. You have not mentioned which method you are using and you did not attach your code. Simply too many unknowns.

[NA7]

So the code I'm using is a VI that came with the Delsys system. (I've attached it)  I have been adding things to it to try and save the data.  I use the term Real Time because the data is visible while I have the VI running and the sensor data is being transmitted to the computer, but once I hit stop, I can't see anything more than the last half second or so of data.

I will also attached my edited version of the VI.  My main focus right now is channel 4, i have everything wired together from a previous attempt.

*The Delsys VI is the Trigno Output Custom VI, the other 3 are sub VIs

[NA7]

These are the other files

[Dennis_Knutson]

All of that converting back and forth with the evil dynamic data type is not only unnecessary, it is the cause of your problems because you are discarding data. Simply wire the 2D array to the Write to Binary File. Do not use any dynamic data at all.

p.s. You really only need a single Index array function if you want to display data in multiple charts. Just drag it down and you will have multiple input/outputs. It will  automatically start at index 0 so you don't even need to wire values to the row input. You did not provide an indicator or actual data received from the instrument so I have no idea whether indexing rows is correct or whether you need to index by column. Create an indicator, run the VI, and then go to Edit>Make Current Values Default. Save the VI and attach it.

[NA7]

Ok, I had suspected some issue with the dynamic data type simply because I was not sure why the condensing block forced me to use that data type.

With regards to the second statement; Are you saying I can use the index array function (retaining the dbl data type) in place of the condensing block?

If so, I think you have solved my problem with saving all of the signals to a single file.

[Dennis_Knutson]

There is no 'condensing" block. There is a merge signals function and, no you do not need but it has nothing to do with what I said about the Index Array function. You already have a 2D array. There are 16 separate Index Array functions and each one is only used to get a particular row for display on a chart. Those 16 separte Index Array functions can be replaced with a single Index Array that indexes all 16 rows at once. Just click and drag on the bottom of the function. If you got this code from the vendor, it was written by an inexperienced programmer.

[turtl]

I have been doing a lot of data collection with delsys system. If using the TCP/IP method, be careful because it can get backlogged and therefore if you are trying to save 30s worth of data, it might not be 30s worth. I am attaching a program I used to collect data, where it stops recording when the array hits a specific size. I am in the process of trying to bypass their system and read straight form the USB, however I am no programming expert, so if anybody knows what to do that would be awesome. So far I have created a driver for the device in VISA, and that is about it. Sorry for jacking your thread.

[johnsold]

turtl,

Most likely your program does not get the full amount of data because of the way you are collecting it and writing to file.  A Producer/Consumer Design Pattern separates the collection of the data from analysis/display/save to file with buffering so that things can happen at different rates.

The use of hidden indicators just to support the creation of local variables shows that you may not understand LabVIEW's dataflow paradigm. Wires are the variables and are the prefered way of connecting data to the places where it will be used.

The file attached as .2.vi is your program cleaned up somewhat. You should probably use Strip Path and Build Path rather than the String Subset. It will not be dependent on knowing exactly how many characters are in the pathname.

The file .3.vi is a start toward a Producer/Consumer design.  It probably will not work as submitted. I do not have the Delsys VIs or equipment so I cannot test it.  Also I did this very quickly and the conditions to stop the loops and release the queues may not be correct.

Lynn

[turtl]

Hi,

Thanks for that, however I do not see any attached files to your post. Did you mean to post files? I only started learning labview in November, and this program was my second one. I have no training at all using labview and I am a sports physiologist, so its be a lot of self teaching. I am still trying to figure out the producer/consumer set up. All I know is that for the delsys, it receives its data via TCP/IP and if I set it to collect for 30s, I would usually not get all the data (data collection is 2khz). This could easily be because I don't have a clue, however I got it to work by stopping collection when array size hit the size I needed ie: collection time x 2000. Thanks again for your help and taking the time to teach me. I hope this can also be of benefit to the OP. Also the hidden indicators were just used to make sure I was getting the correct data, however I should of deleted them, but the person that was sort of teaching me just hid them to make it easier.