LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Is this bug in File I/O

Access Write only

Performed Read only but not displayed the data

not throwing any error (error 😎

 

When I wire Indicator on read out it throws an error 8.

 

why such things?

 

Please help me to get clear out of this.

 

 File Chosen during RuntimeFile Chosen during Runtime

0 Kudos
Message 1 of 9
(2,809 Views)

If you are not using the output, then is it likely that the read portion was not actually done.  This is common in many other LabVIEW primitives that parts of a primitive are not performed because the output is not used.

 

But a bug?  I would say so.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 9
(2,777 Views)

The LabVIEW compiler does a lot of optimization in the background nowadays. It's very likely for your first picture that the read-vi is completely removed since no output is used thus not throwing an error at all.

 

Bug? Yes, kind of

 

Regards, Jens

 

Kudos are welcome...
0 Kudos
Message 3 of 9
(2,773 Views)

If the Read VI is completely removed then how ref number if passed to close file?

I have checked by highlight execution.

It passes data and follows data flow...

0 Kudos
Message 4 of 9
(2,760 Views)

Did you read the whitepaper about the compiler? Of course in the background, the file refnum will be reconnected betweeen file open and file close. On the other hand it might even be that even the file open and file close is removed before the compilation. It's difficult to predict what's going in the background. This will also not reflect the dataflow you see in highlight execution mode.

 

Just to make it clear: I'm speculating, I'm not 100% sure that the read-vi is really removed by DFIR optimazition but it does at least explain the difference between your two code snippets.

 

Regards, Jens

Kudos are welcome...
0 Kudos
Message 5 of 9
(2,753 Views)

LOL it's like you caught the compiler with its pants down.  😄

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.
Message 6 of 9
(2,730 Views)

@billko wrote:

LOL it's like you caught the compiler with its pants down.  😄


Smiley LOLSmiley LOLSmiley LOL

Kudos are welcome...
0 Kudos
Message 7 of 9
(2,713 Views)

Yeah

I understood that u are the only one genious in LabVIEW.

But Remember I am a learner towards certification.

So i need to taken care about all the points.

by time passes everything will change. let see...

 

Thanks for your genious comment

0 Kudos
Message 8 of 9
(2,707 Views)

@GURU_PANDIAN wrote:

Yeah

I understood that u are the only one genious in LabVIEW.

But Remember I am a learner towards certification.

So i need to taken care about all the points.

by time passes everything will change. let see...

 

Thanks for your genious comment


Thanks for not quoting who you were responding to, so no one knows who should be the honorable recipient of your genius comment.  If you were actually responding to me, I was just trying to show that nowadays, it's pretty hard to catch LabVIEW doing something inconsistent like that, because there are decades of people like yourself catching all the little oddities like this.  I thought it was pretty cool, actually.

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 9 of 9
(2,700 Views)