06-06-2014 01:48 PM
I do not like the sounds of "resource intensive and slow" lol so ima look into that...
im also running into some issues embedding this within my FPGA circuit...
at the time during my testing its just way easier for me to create it on the desktop and run and test it there cause i have to wait for it to compile when I want to run and test it for the FPGA =P
anyways thanks for the tips!
06-06-2014 02:05 PM
so i made a quick change...
Now it will only open or create>write file>and then close file durring a true event...
am i understanding this?
06-06-2014 03:55 PM
That looks good. The next step up in performance would be to move the open file and close file references outside of the while loop for maximum performance.
06-06-2014 06:59 PM
i tried putting the open and close file references outside of the while loop but it was doing something weird...
so i am keeping it the same way for now...
i did however make a few changes:
i added headers for the recorded data
also i added a flat sequence to first create the file if there is none, so during a true event, im only opening the file to write to it?
do you think this flat sequence is necessary?
or am i trying to get too complicated?
Thanks for all the help, i feel i made some progress on this this week 😃
06-09-2014 04:12 PM
We generally prefer to use error wires to force dataflow as it keeps the diagram a bit cleaner.
06-10-2014 02:24 PM
So i can clearly see what you did here with the pic you posted...
I did try it this way by putting the "open/create" and "close" file outside of the while loop...
If you compare my file (open/create>write>close all within the true box) VS. yours (open/create & close outside the while loop) the 2 different programs save the file differently, and i think i know why
My version: (open/create>write>close all within the true box)
During a true event, the txt file is created or opened, written to, and closed
Now if i understand this correctly even though my code may add a new line at every button press the way it is actually being written to the file is different
During a true event it was taking the new Concatenate Strings which would have +1 more line then the previous and writing over the last file, making the illusion that it is adding another line, but really it is just rewriting over the old data with the new Concatenate Strings of data.
Your version: (open/create & close outside the while loop)
by moving the open/create outside the while loop it is executed first and remains open during the loop run time.
now because the file is always open, i think is why it saves the data differently, its adding the new Concatenate Strings to a new line instead of writing over the existing data...
So my next question is why is it a good practice to place the open/create & close functions outside of a while loop?
is it because the while loop with cause it to execute at ever iteration?
also if this circuit was part of a bigger circuit with multiple while loops, would i still use the same practice putting the open/create & close outside of the outer most while loop and just tunnel through?
i hope i was clear with my explanations and questions, cause im even starting to confuse myself now...
in the meantime im going to redesign this so that it will save the way i want it to using your suggestion of moving the open/create & close outside of the while loop
06-11-2014 12:36 PM
The main reason for moving the open and close operations out of the loop is because they are the most expensive in terms of execution speed. By moving them out of the loop they only have to be performed once because that is all we need. We only repeatedly perform the file access tasks that must be repeatedly performed.
Note that depending on the application, the improvement in execution speed may not outweigh the effort required to implement this architecture. For example, if you are not writing to file very often and passing references deep into nested structures will be complicated, performing the open-write-close all inside the same case would be an appropriate trade off.
As writing streaming data of any type involves many file writes, this architecture is much more common.
06-11-2014 01:39 PM
ya even though he data is always changing ( measuring time elapsed) i would only want to be able to save once a condition is met, or in this case when run time = set time...
and im talking 30, 45, 60, and/or not more then 90 miniutes that will pass before a session is complete, the only time it will be wayy shorter is if something went wrong... like safty circuit tripped or the session was manually interupted... then i still want it to save that it ran for only 15 seconds out of 90 minuites when it was interupted...
although this is a small part of a biger picture, i might be able to run it in its own loop and used a shared variable for the data so i dont have to worry about passing references thorugh other structures?
06-11-2014 05:59 PM - edited 06-11-2014 06:11 PM
I bring good news... i toook into consideration your advise on the file creation being only executed 1 time outside of the while loop
I also made it so that is adds the headers at that time as well
then when the while loop is executed the data that is meant to be logged durrign a certain condition is only writted to the file on a new line durring a true event
I had to get rid of the shift register on the data string when it saved to the file...
that is what was causeing it to save the data in a funky way...
So turns out im still a noob, but i am making forward progress with understand LabView 😃
Now that i feel i got it working the way as intended i believe i can just copy and paste and pug in the wires as needed, im sure because this is going to be running on an FPGA ill need to make a few minor changes in order to have it run but ill keep you posted... and let you know if i run into any brick walls
non-the-less im super excited to test this in its intended circuit 😃
Tanks For all the Help!
06-12-2014 01:10 PM
This looks good. One thing you need to know up front is that this will not run on the FPGA. It will run on the Real-Time side of a cRIO but not on the FPGA. The FPGA is programable hardware and does not have access to a file system. Additionally, the FPGA is generally only used for tasks that require timing greater than 1 KHz.