Showing results for 
Search instead for 
Did you mean: 

DAQ/LabVIEW memory (sorry for the repost)

sorry, misunderstood your statement, disregard my last comment, were you able to run the main vi? RTLTestRunnerV2?  Just want you to see the way it's behaving.  Thanks a million.
0 Kudos
Message 11 of 25

Yes I can run some of it and I get a bunch of file name prompts but that's all related to what I said before with the mis-use of locals and bad wiring. I've attached what one of your first file reads should look like. There is no string control for a path and the first Read Lines passes the selected path to the next. If you have three different files you want to read, then you will get three different prompts unless you fill in the path on the front panel control before you run the VI. There should be absolutely no local variables required for any of these paths.

Message Edited by Dennis Knutson on 05-25-2006 10:45 AM

Message 12 of 25
So the string control is not needed because that related back to a local variable which isn't needed right?  So should all locals be somehow replaced with paths?? And if so what is the best way to do this since throughout the entire program local variables are used extremely frequently.  Also back to the bad dataflow with the Digital writes, should that just be solved using structures?  And beyond data flow, does their wiring seem correct?
0 Kudos
Message 13 of 25

Again thank you for your time and patience.

Message Edited by pdb511 on 05-25-2006 12:25 PM

0 Kudos
Message 14 of 25
Ok I'm sort of thinking out loud i guess, but did you mean I should replace all the string controls in the write functions with paths, and that would do away with the string local variables?  Because I think that wouldn't be too difficult.  Or did you mean that local's throughout the entire program are not necessary? 
0 Kudos
Message 15 of 25
I didn't immediately see a reason for any local variables if the code is re-written correctly
0 Kudos
Message 16 of 25
Wow..if it's not too much trouble, how might that be accomplished?
0 Kudos
Message 17 of 25
For the most part, you just have wires. For example, you have a lot of local variables inside sequence statements which are inside case statements. Get rid of the sequence statements and place the terminal outside the case statement so each case will update the terminal. In other situations, you can use a shift register. It's not going to be easy with the code you have but it's something that I think needs to be done.
0 Kudos
Message 18 of 25
Alright, that makes sense, in your opinion do you think the File I/O portion of this the program could be demoed, ie shown to read a spreadsheet, save/write this data to labview memory, then read this memory and write it to another spread sheet, as well as reading and writing headers to the spreadsheets, using this local variable format? ( I was hoping that was something that could be cleaned up later on)  On another note, on the main VI, the program is not supposed to ask for a file until the respective button "read/write" is pressed, i know this is a data flow problem, loops or structures, didn't know if there was anything obvious that stood out to you.  But even that aside, the program will not accept any file selected, no matter the format or file type, yet the when altered the way you suggested will read a txt file in spreadsheet form, though it does disorganize the data.  Your thoughts have been extremely helpful, and I truely appreciate your help, sorry to hound you so much, just have a tight deadline for this demo, any other help would be invaluable.

Message Edited by pdb511 on 05-25-2006 05:44 PM

0 Kudos
Message 19 of 25
I'm not at a computer with LabVIEW on it right now so I can't post an example, but your demo should be pretty easy. You can create a while loop and put an event structure in it. Create a front panel Boolean called "Read" and create and event for it. Put the Read From Spreadsheet function in that event. Create another front panel Boolean called "Write" and create an event for that with Write to Spreadsheet File in it. Create a shift register on the edge of the while loop and you can pass the data from the Read to the input of the Write.

From what I remember about the existing program, the read functions were not inside any case statement and there were no event structures at all. Event structures are better than while loops with case statements because the while loop does not have to poll the front panel Booleans with every iteration. If you only have the base version of LabVIEW, then you can't use the event structure so a while loop with two separate case statements will work.
0 Kudos
Message 20 of 25