LabVIEW
Help - Invalid reference error when closing file
Solved!
Hello,
I am developing a VI that measures some current values and saving them in *.xls files. I am using 9 analog input channels and i have 9 case structures that manage file saving. ( creates a new file when acquiring 40,000 samples so i get i.e IA1,IA2 ......IAn or IB1, IB2 ..... IBn files and so on for every channel).
The problem is that straight away after I start the VI, I get error 1 , pin pointing all the close file funtions I am using in the VI
'' Possible reason(s):
LabVIEW: An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @. ''
I have checked all the file names, input clusters and paths i am using and i dont see anything wrong.
Could you please gimme some advice on this??
Please find attached screenshots of the VI.
Cheers,
Panos
Since you are going with a newer version of LabVIEW now, and it is a huge jump from LV6 to LV 2009, it is time to start cleaning up some code and replace some of the ancient functions. The white icon Close+.VI is one of them.
I think there is a good logical reason why the new Close File icon (yellow) doesn't have a duplicate refnum coming out. Since you close the file in the function, the refnum becomes invalid. There is way you could ever use it again after the function. The old white icon has a duplicate refnum because looking at the context help, it looks like it doesn't necessarily always close the file depending on what boolean value is wired into the bottom.
I think there is a lot of thinks you could do to clean up the code. There are 9 sections of case structures on the right hand side that all appear to do the same thing (perhaps on different data). They are prime places where a subVI should be created so that you don't duplicate code unnecessarily. It would probably cut your screen real estate to 1/10th to 1/20th of its current size.
Those case structures are stacked 3 layers deep, so there could be some logic flaw going on there you can't see. If possible, rethink the logic going into the case structures so that the depth of the structures can be reduced. I think this might be the source of your problem as many of the cases involve a Close File. Sometimes the new function, sometimes the old function. There are a lot of logic paths and it seems like many of them could close the file and make the refnum invalid. Yet the refnum gets stored into a cluster saved in a shift register. Unless your logic is flawlessly executed, there is a good possibility there is a logic path that causes a file to be written to with an invalid refnum.
I think there are 3 architectures that could help. One would be based on a state machine that would remember the current state of each of those file paths to determine whether they need to be opened, closed, written to, or read from.
The second is a producer/consumer architecture. The data that is to be written to should be passed off to a consumer loop by way of a queue. Let the consumer loop handle the file operations.
The third would be an Action Engine or a functional global variable. It could store the array or cluster of file renums. Perhaps also a status for each one that tells whether the refnum is valid or not. Let the action engine handle the storage of the refnums so you don't have to string refnum wires through the whole VI and bundle them all up into a cluster at the end.
PS. On your front panel, "Incline Plain" should be spelled "Inclined Plane"
Ravens Fan wrote:Since you are going with a newer version of LabVIEW now, and it is a huge jump from LV6 to LV 2009, it is time to start cleaning up some code and replace some of the ancient functions. The white icon Close+.VI is one of them.
I think there is a good logical reason why the new Close File icon (yellow) doesn't have a duplicate refnum coming out. Since you close the file in the function, the refnum becomes invalid. There is way you could ever use it again after the function. The old white icon has a duplicate refnum because looking at the context help, it looks like it doesn't necessarily always close the file depending on what boolean value is wired into the bottom.
I think there is a lot of thinks you could do to clean up the code. There are 9 sections of case structures on the right hand side that all appear to do the same thing (perhaps on different data). They are prime places where a subVI should be created so that you don't duplicate code unnecessarily. It would probably cut your screen real estate to 1/10th to 1/20th of its current size.
Those case structures are stacked 3 layers deep, so there could be some logic flaw going on there you can't see. If possible, rethink the logic going into the case structures so that the depth of the structures can be reduced. I think this might be the source of your problem as many of the cases involve a Close File. Sometimes the new function, sometimes the old function. There are a lot of logic paths and it seems like many of them could close the file and make the refnum invalid. Yet the refnum gets stored into a cluster saved in a shift register. Unless your logic is flawlessly executed, there is a good possibility there is a logic path that causes a file to be written to with an invalid refnum.
I think there are 3 architectures that could help. One would be based on a state machine that would remember the current state of each of those file paths to determine whether they need to be opened, closed, written to, or read from.
The second is a producer/consumer architecture. The data that is to be written to should be passed off to a consumer loop by way of a queue. Let the consumer loop handle the file operations.
The third would be an Action Engine or a functional global variable. It could store the array or cluster of file renums. Perhaps also a status for each one that tells whether the refnum is valid or not. Let the action engine handle the storage of the refnums so you don't have to string refnum wires through the whole VI and bundle them all up into a cluster at the end.
PS. On your front panel, "Incline Plain" should be spelled "Inclined Plane"
Hi Ravens Fan,
thank you very much for the detailed answer, really appreciate it.
About having one common subVI in order to replace the 9 case structures, i am not quite sure how I can define in that subVI the file name and path in the unbudle cluster in the 3rd level of the case structure where actually forms the new filename and path for every single new file created (i.e IA1, IA2, IA3 .... IAn). I can define inputs on such a subVI for everything else but dont know about that thing.(actually that unbundle by name is the only thing that makes these 9 cases different).
Regarding the use of refnums after the close function, if I replace the old close file functions with the new ones, I dont have to feeedback a path or a refnum to the output cluster on the right?
About programming techniques, I am not so experienced the time being but I would be really happy if you could please suggest knowledge database in NI site so I can have a look.
And yeah, you are definitely right! I am not a native speaker of english and sometimes i do these kinda silly mistakes! 
Thank you!
Panos
