07-10-2018 08:43 AM
Additionally, if you do want to find the I/O code manually, and not just use the find terminal option from the front panel. It is actually in the 6th stacked sequence (5), all the way on the left side (of the stacked sequence) and about 40% of the way down.
07-10-2018 10:17 AM
Time to stick some probes around it to see where stuff is going bad. 😞
07-10-2018 10:28 AM
Yeah I've been playing with that, when probing the create path functions appended path reads 'not executed', as well as the refnum from the create incrementing suffix file function, and the refnum from the write to file function. Then where it enters the for loop from the starting shift register it reads 0. Is the path somehow not being created being located in this position?
07-10-2018 10:51 AM
This is daunting code, but you need to find out why that code isn't executing. But at least now you know it isn't executing. Stacked Sequences will be the bane of your existence while you do this, unfortunately.
07-10-2018 01:21 PM
Thanks for pointing out the code. Why is there a Feedback Node on the input to the While Loop with no feedback to be seen? [Feedback nodes I find confusing, anyway, but this one really takes the cake].
Here's a suggestion -- pull just the File I/O part of your code out into another VI. I did this here, replacing the Build Array with lots of inputs into a simpler 2-column affair of Index Number and Random Variable. I also removed the Feedback Node (as I didn't understand it).
To no surprise, this runs fine, without errors, essentially the same code (again, simplified, no feedback node) that you had in your Very Large VI. [Much easier to test tiny code ...]. Could it be the Feedback Node? Or something else Unrelated?
Bob Schor
07-10-2018 01:32 PM - edited 07-10-2018 01:35 PM
So every time I connect a refnum or error wire from the I/O code to a tunnel or shift register into the for loop it automatically creates a feedback node, any ideas why this might be?
07-10-2018 01:56 PM
Interestingly enough, wiring the error wire through the I/O code, despite having a feedback node, allowed for the program to take measurements, and then I get the same error closing the file. This results in an output file with just the header and no data, so the problem must lie after the write to file function which adds the header I presume?
07-10-2018 02:20 PM
Because there must be some other dependency going on causes the item you want to be later on the wire to actually have occurred earlier due to data flow.
Go to Tools > Options > Block Diagram.
There is a setting for "Auto-insert Feedback Node in Cycles". NI has this checked off as default, which I feel is a poor choice. It is what is causing you to have that automatic feedback node.
My opinion is that if you want a feedback node, it is a conscious decision that you should add it explicitly. But when checked, LabVIEW is trying to be "helpful" and prevent you from having broken wires. But in this case, you do want a broken wire as an indication things aren't wiring up the way you want them to.
07-10-2018 02:54 PM - edited 07-10-2018 02:54 PM
That makes sense. I'll try disabling it on Thursday and working on the code some more. I just moved the system to a different location and have instrument time all day tomorrow, so I'll be integrating a known version of this code which works with temperature controls. I'll keep you guys updated.
Cheers
07-10-2018 03:32 PM - edited 07-10-2018 03:32 PM
@RavensFan wrote:
Because there must be some other dependency going on causes the item you want to be later on the wire to actually have occurred earlier due to data flow.
Go to Tools > Options > Block Diagram.
There is a setting for "Auto-insert Feedback Node in Cycles". NI has this checked off as default, which I feel is a poor choice. It is what is causing you to have that automatic feedback node.
My opinion is that if you want a feedback node, it is a conscious decision that you should add it explicitly. But when checked, LabVIEW is trying to be "helpful" and prevent you from having broken wires. But in this case, you do want a broken wire as an indication things aren't wiring up the way you want them to.
Rereading my original post, my wording may be confusing. I said "checked off" in the way that if you were going down a list and you "check off" something that you are putting a check mark next to it. But on second reading, it sounds like it could also mean the check box is "off".
What I mean to say is that NI's default on that check box is to that it is set to ON or TRUE. My preference is that they DO NOT auto-insert feedback notes. That check box should not be checked.