Data Flow not working in LabView !!!!!!!

[hulaj]

Dataflow is the main feature of LabView. All sequential code execution
is driven by dataflow, i.e. the code is executed when the data
arrives. That is very good feature. But I found a bug in that.
If you use For loop with zero iterations, the data on wires, which are
wired through that loop sometimes pass and sometimes not. If the input
is control, data does not pass, if it is a constant, data goes
throught.

See example: http://labview.jirihula.com/Wrong_ForLoop_DataFlow.zip

Jiri Hula

[Nadav_Chernin]

Good point, don't know answer.

[Ben]

"Flame suit on!"

Hi Jiri,

Data Flow is working!

What I think you are seeing is a combination of two factors.

1) What do you get from a FOR loop that does not iterate?

and
2) Code optimization.

re:1
Asking this question is like asking "Where do I end up if I sit in my car but don't drive any where?" Answer: The same place you started!

re:2
This is where optimization kicks in. LV has gotten pretty smart about optimizing code. If it can detect something is going to be the same at run time as it is at edit time, it just puts the answer where it should eventually end up. In the case of the constants, LV can see that no matter how many times the loop iterates, the final result will always be the constant. You can prove this to yourself by modifying y
our example to an even more bizarre form. Break the wire inside your FOR loop that caries the Strinf control data. Drop a constant inside the FOR loop and wire it to the output tunnel. Run your VI and you will find that even though the FOR loop does not iterate, the output tunnel returns you contant! This is agian because LV recognizes (at compile time) that the output tunnel can only have one value.

I have read postings from Rolf Kalbermatter re:passing data through FOR loops. If my memory serves me he suggests;
1) Never wire data through a FOR loop that is not used. Wire around the loop.
2) Outputs from a for loop should come from a shift register that is initialized with the default value before the loop iterates, to handle the possibility the loop never iterates.

That is my rad on this Q. I will watch for other opinions.

I hope this helps,

Ben

"Flame suit off!"

[wiebe@CARYA]

Hi,

+ This is *not a bug*. Nor is it a 'new' one.

+ It is even documented. See "For Loops: unexpected data" in the contents
help.

+ It is unavoidable.

Read more about it in the thread called "LabVIEW 6.1 If For Loop count
terminal is zero then value going
through the loop is not passed on to the output of the loop".

Regards,

Wiebe.




"Jiri Hula" wrote in message
news:34ed7a71.0210302325.46a2790c@posting.google.com...
> Dataflow is the main feature of LabView. All sequential code execution
> is driven by dataflow, i.e. the code is executed when the data
> arrives. That is very good feature. But I found a bug in that.
> If you use For loop with zero iterations, the data on wires, which are
> wired through that loop sometimes pass and so
metimes not. If the input
> is control, data does not pass, if it is a constant, data goes
> throught.
>
> See example: http://labview.jirihula.com/Wrong_ForLoop_DataFlow.zip
>
> Jiri Hula

[JeanPierre]

See the LabVIEW FAQ. The zero iteration for loop is the only node where you can have a wire with no source. Since the loop doesn't execute, the non-indexing wires coming from it have no defined data to be assigned to. Use shift registers to pass data through a for loop.

[timpy]

Hi

It's one of those things that catches out the inexperienced or unwary. There are a number of soutions, for all the reasons previously posted. I tend to just case it out for cases where it is going to see a zero number of values on a indexing input.

Remember that an empty array on any of the indexing inputs to the For loop will cause it not to iterate. It's definately a circumstance that you need to allow for. Using a case allows you to use properly defined default values for the instance, rather than the ones that LV thinks are appropriate to pass through, or not.

Hope that helps

timpy

[Greg_McKaskle2]

> Dataflow is the main feature of LabView. All sequential code execution
> is driven by dataflow, i.e. the code is executed when the data
> arrives. That is very good feature. But I found a bug in that.
> If you use For loop with zero iterations, the data on wires, which are
> wired through that loop sometimes pass and sometimes not. If the input
> is control, data does not pass, if it is a constant, data goes
> throught.
>

There have been plenty of posts about this already, but just to be
clear, the nodes do execute in order. The dataflow rules for execution
order were never the problem. The problem was defining what the output
should be when a node does NOT execute. You don't mention which version
you were using, but earlier versions of LV were incon
sistent in what
they returned. With Version 6.1, the otuputs were more consistently
defined to be the default for the datatype.

As noted earlier, if it is possible for a For loop to execute zero
times, then the value should be wired around or through a shift register.

Greg McKaskle

[hulaj]

Dear timpy,
really "inexperienced or unwary" ?????

OK, if you think that the winner of NI Week 2001 Best Application in
Maintenance/Field (http://www.ni.com/niweek/niweek2001/best.htm#maintenance)
or finalist on NI Week 2002 (http://www.ni.com/niweek/best.htm#7) is
really "inexperienced", I would like to see your projects. The VI
which I posted is EXAMPLE.

The VI where I found this strange behavior was for deleting directory
- at first I delete all files in that dir and after that the
directory. But it do not work when the directory is empty. See:
http://labview.jirihula.com/Example2.zip

Another strange thing:
As someone wrote in this discussion - the code inside loop is not
executed when you use 0 iterations. Try to add to constant any number
in that loop
, and it is executed !!! See:
http://labview.jirihula.com/Example3.zip

We tested in in LabView 6.1, 6.0, 5.1, 4.1 and in every version the
behavior is different.




timpy wrote in message news:<5065000000050000004DAF0000-1031838699000@exchange.ni.com>...
> Hi
>
> It's one of those things that catches out the inexperienced or unwary.
> There are a number of soutions, for all the reasons previously posted.
> I tend to just case it out for cases where it is going to see a zero
> number of values on a indexing input.
>
> Remember that an empty array on any of the indexing inputs to the For
> loop will cause it not to iterate. It's definately a circumstance
> that you need to allow for. Using a case allows you to use properly
> defined default values for the instance, rather than the ones that LV
> thinks are appropriate to pass through, or not.
>
> Hope that helps
>
> timpy

[wiebe@CARYA]

Hi,

"Inexperienced or unwary" ????? We can't tell because we haven't seen any of
your work.

The first think to check if you think you've found a bug, is the LabVIEW
help. It's there under "For Loops: unexpected data". The output is
"unexpected", if a for loop runs zero time.

If you start mailing that you've found a bug, while it's right there in the
LabVIEW help, you can't blame people for thinking you're "inexperienced or
unwary", even if you're not.

(BTW: I've been there. You think you found a bug, and you start telling in
excitement. Then you get reactions like this...

Guess you can call this 'overexperienced'. Any beginner would consult the
manual first.)

Regards,

Wiebe.



"Jiri Hula" wrote in message
news:34ed7a71.0211010018.16d026aa@posting.google.com...
> Dear timpy,
> really "inexperienced or unwary" ?????
>
> OK, if you think that the winner of NI Week 2001 Best Application in
> Maintenance/Field
(http://www.ni.com/niweek/niweek2001/best.htm#maintenance)
> or finalist on NI Week 2002 (http://www.ni.com/niweek/best.htm#7) is
> really "inexperienced", I would like to see your projects. The VI
> which I posted is EXAMPLE.
>
> The VI where I found this strange behavior was for deleting directory
> - at first I delete all files in that dir and after that the
> directory. But it do not work when the directory is empty. See:
> http://labview.jirihula.com/Example2.zip
>
> Another strange thing:
> As someone wrote in this discussion - the code inside loop is not
> executed when you use 0 iterations. Try to add to constant any number
> in that loop, and it is executed !!! See:
> http://labview.jirihula.com/Example3.zip
>
> We tested in in LabView 6.1, 6.0, 5.1, 4.1 and in every version the
> behavior is different.
>
>
>
>
> timpy wrote in message
news:<5065000000050000004DAF0000-1031838699000@exchange.ni.com>...
> > Hi
> >
> > It's one of those things that catches out the inexperienced or unwary.
> > There are a number of soutions, for all the reasons previously posted.
> > I tend to just case it out for cases where it is going to see a zero
> > number of values on a indexing input.
> >
> > Remember that an empty array on any of the indexing inputs to the For
> > loop will cause it not to iterate. It's definately a circumstance
> > that you need to allow for. Using a case allows you to use properly
> > defined default values for the instance, rather than the ones that LV
> > thinks are appropriate to pass through, or not.
> >
> > Hope that helps
> >
> > timpy

[JeanPierre]

>We tested in in LabView 6.1, 6.0, 5.1, 4.1 and in every version the
behavior is different.

Well that it what it is meant by "undefined". Output value is as "undefined" in a version as in others. The actual output is not generated by any code so it is a value that comes from compiler attempts to optimize code in the loop or any garbage left the by previous memory usage or a default value or whatever. Let state it otherwise: the output is UNRELIABLE. Look at the following C code:

int myvalue;
for (;0;)
myvalue=1;

What value do you expect in the variable myvalue? It has never been assigned. Is that a bug? Yes it is yours.