LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error 1 at Write to Text File within For Loop

Solved!
Go to solution

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. 

0 Kudos
Message 11 of 27
(835 Views)

Time to stick some probes around it to see where stuff is going bad.  😞

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 12 of 27
(822 Views)

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?

0 Kudos
Message 13 of 27
(820 Views)

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.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 14 of 27
(817 Views)

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).

Simple Test File.png

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

0 Kudos
Message 15 of 27
(807 Views)

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?

0 Kudos
Message 16 of 27
(804 Views)

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?

0 Kudos
Message 17 of 27
(802 Views)

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.

0 Kudos
Message 18 of 27
(797 Views)

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

0 Kudos
Message 19 of 27
(793 Views)

@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.

Message 20 of 27
(785 Views)