Thanks for pointing out all that I have not understood. I'll spend the evening studying what you have created. Chris
Outstanding. It was clear that this was new to you. I am pleased that you are committed to learning from the supplied help resources. Also, that PNG you see in my post... That is actually a snippet. Drag it to your desktop and then to a new blank block diagram in 2016. Poof you have a running vi. If you need a copy for an older version of LabVIEW, it can be arranged by anyone using the LAVA CCT tool.
Spent the morning studying your example program. I choose to create it myself instead of copying. Thats my way of learning. I think I need to explain a little more what my intentions are with this VI. It is a data collection VI triggered by a proximity switch. With each trigger of the switch I want to sample the sensors. Once the for loop executes 4 times, a file is created. I attached an xlsx file to show you what is happening. With each trigger, more columns are created. I expected the rows to increase(that is desired). Would the reason for that behavior be because the tunnel is set to concatenating? When it is set to indexing there are issues with data types.
I did create the file as you did but the trigger wasn't recognized and errors appeared(200278). So I went back to my VI which I have attached. Chris
OK the express vi is just not going to handle appending to file with gaps in the times between the end of one triggered sample and start of the next. There are no really drop-dead simple ways around this. Appending wafeforms ignores the T0 of the appendant waveform, Enabling logging in the DAQmx task would help but, graphs would look funky (adding an undesired line segment between triggered reads) and DAQmx logging only supports TDMS format (Although- TDMS is another subject you might want to read up on) . "Waveform to XY pairs" and "Get Time array from waveform" don't give outputs that play nice with dynamic data (Besides we hate the DDtype anyway right?)
SO! for your investigative pleasure!
Note: I added a new loop to append a "NaN" value at the end of each channels triggered acquisition. NaN is not a number. It has some unusual effects on graphs since it isn't a number it cannot be plotted on a scale that is numeric! (Hey, that puts the gaps in the graphs between the end of one acquisition and the next trigger!)
Also, I unloaded the express vi in favor of an approach that might be a little more helpful to us in building the desired file.
Enjoy the tour through the help file
Note: I added a new loop to append a "NaN" value at the end of each channels triggered acquisition.
It would be sufficient to unbundle/bundle the Y component since the dt does not change. Even better, use the in place element structure in the loop as in my example.
Thanks for your continued suupport!!. Ran into some trouble. I could not find the functions you used to save the array to file. I thought it should it be in the File I/O palette. Could you explain the process there? The feedback loop part, the two components of the feedback loop. I'll tour some help files/examples as you suggested. I am using LabView 2015. Chris
I was able to move forward with your idea. Watched a few tutorials that helped. Understanding the terminalogy is my weakness at the moment. I like the way the data is presented in the file. I few issues to resolve though. I have a path for the data file, but would like to be prompted to enter a file name after the run button is pressed on the front panel. Could you provide some ideas on that? Chris
Learning Labview....what a way to spend your mornings while on leave from work.
Wiring a blank file path constant to the Feedback node initializer terminal will pause the vi and prompt the user for a file name. Not exactly desired behavior! you may miss triggers So we need a prompt before the loop. Right click the feedback node and select "Replace with Shift Register." Initiallize the Shift Register with the output of a "File Dialog" express vi.
File Dialog is actually one of the "Good" express vis. Many are not so great. It comes down to scope. Write to file- is a "Bad guy" because the scope of storing data is vast, selecting a file name and path is much more limited so that express vi is closer to bulletproof. Of course, since I persoally don't like some of the core vis under the file dialod express vi AND I don't normally support localization (changing the language of displayed text elements) I use this baby:
Honestly I chose the FBN (Feedback Node) instead of the SR(Shift Register) simply because it fit in the screen where the SR loop terminals would have been out of view.