What's wrong with this VI?

[jpdrolet]

I've found this remarkable counter intuitive piece of code today...

What's wrong with it :question:

Thanks for the lightbulb mode

[Michael Aivaliotis]

Well that's a neat trick! :worship:

This normally generates an error in LV (broken wire). You can't have the output of the array feeding into the equal function. Object is member of a cycle.

"These wires form a cycle, making two parts of the diagram interdependent, so each must wait for an input from the other and neither can execute."

I assume there is something else you're not showing us...

[Jim Kring]

Well that's a neat trick! :worship:

This normally generates an error in LV (broken wire). You can't have the output of the array feeding into the equal function. Object is member of a cycle.

"These wires form a cycle, making two parts of the diagram interdependent, so each must wait for an input from the other and neither can execute."

I assume there is something else you're not showing us...

1811[/snapback]

I see the same thing!?

[Michael Aivaliotis]

I see the same thing!?

1814[/snapback]

Jim, your VI makes sense because you're not taking the outputs of the math functions and passing them along. It's more like the attached image:

[jpdrolet]

I assume there is something else you're not showing us...

1811[/snapback]

Look closely, there is nothing hidden. Check for data sources and wire directions. I found the trick with the lightbulb, I was sure LabVIEW would choke trying to run that.... Since the VI was converted from LV4, I thought there was some error, but it's legit code.

[PJM_labview]

Look closely, there is nothing hidden.  Check for data sources and wire directions.  I found the trick with the lightbulb, I was sure LabVIEW would choke trying to run that.... Since the VI was converted from LV4, I thought there was some error, but it's legit code.

1816[/snapback]

Ok I think I got it

The way I understand it, it does the following:

In any "case", whether the control boolean is true or false, an array is build and wired to the shift register.

So, initially, my guess is that the boolean control is set to true, and the array is build independantly form the subvi. Also my other guess is that once the boolean control become set to false, it will be reset to true quickly after.

Then when the boolean control is false and if previous value from the shift register is not equal to the one generated when the boolean control was true, then call the subvi with 2048 as input then again (and here lies another problem) if the boolean control is still false collect all the values from the subvi and display then to the following locals (Barrier A, Barrier B, Dipper, Spare A, Spare B and Relay) then rebuild the array with this value and wire it to the shift register.

This seem indeed to be legit code...

It a nightmare to understand that what's wrong with it!

PJM

Note: Now that I am re reading this, I am not so sure that I understand what's going on ...

[pmaj]

HELLO Everyone

I checked it in my LabVIEW v.7.1 and this is what I got:

As I see the new version solve the problem automatically.

Regards

[Jim Kring]

I've found this remarkable counter intuitive piece of code today...

What's wrong with it :question:

Thanks for the lightbulb mode

1810[/snapback]

After thinking about it, I thought that you had hidden a feedback node:

But, after reading your hint about data sources, I realized that the code "makes sense":

[jpdrolet]

But, after reading your hint about data sources, I realized that the code "makes sense":

1820[/snapback]

Bravo! But which sense!!! :laugh:

[Michael Aivaliotis]

But, after reading your hint about data sources, I realized that the code "makes sense":

1820[/snapback]

Ah, yes. It reminds me of those visual optical tricks you read in puzzle books. The optical illusion here is the idea that data always exits a VI on the right-hand side. This forces your eye to follow the data from left to right. What you don't notice is that the constant "2048" is wired to ALL locals...

I hope you shot the programmer...

[Barrie]

If that's not the worst piece of code I've seen, it's gotta be close :thumbdown:

[JackHamilton]

Too many wires!

that's whats wrong with that code...

I can do that code with 5 wires!

[crichter]

I thought I was pretty clever in overcoming the "wire is a member of a cycle" error. I had the desired continued count with sucessive presses of the run and stop buttons. Please see attached VI. Trouble is, after building in strings and arrays to try to make it into something useful, (see second attachment) the count is skipped occasionally. I assumed I had a timing error so I played with "wait until next mS multiple" without success. I also put a condtional loop on the stop button with "wait X mS" and experimented by varying X. To date, my problem persists. Comments and suggestions are welcomed.

continued count A.vi

Log File misses a count .vi

[MikaelH]

The Control & Simulation Loop, has a solution for this:

Last post for me this year, happy holidays everyone :-)