04-26-2015 03:51 AM
Hint - look at the broken wire in the while loop. Hover mouse over it for more information. If you don't understand why you get this error, look at where it is coming from - the '=' node. Look up the help on that - it can be configured in different ways.
What data types are going into the '=' node? (hover mouse over wires to see)
What data type have you got coming out?
What data type do you need coming out?
Speaking of data types - your 65536 has coercion dots (probably - hard to see) - fix that.
Speaking of hard to see - tidy your diagram up, reduce its size, easier to read for you and for me if you post it.
Speaking of diagrams - Use VI Snippet to Store and Share Reusable Code Sections (you can do this with the code I pasted earlier - just right click the image and 'save as' then drag the file into a blank block diagram.
04-26-2015 05:39 AM
LV 13
04-26-2015 06:44 AM - edited 04-26-2015 06:48 AM
For 3 diferit number work
For more number don't work 😞
This is VI :
04-26-2015 11:07 AM - edited 04-26-2015 11:11 AM
My guess is that there is a flaw in the logic. When it gets to a CD already in the position where it is supposed to be, it doesn't know how to skip over it.
More specifically, when the 2nd CD is in the first slot, and it gets swapped into the 2nd because that is where the 1st CD actually is.
I'm guessing something about the logic happening in that very first swap before the while loop starts is failing it. I think all swap logic belongs in the while loop including the first swap.
04-27-2015 06:47 AM
Yes - this was a very quick knock-together with minimal testing - defintiely flawed!
Can't run the code at the moment, but if you just work through it manually you'll see that, with your values, it does the first swap ('9' from 0 to 5 - fine), then enters the loop.
First iteration - '3' from 1 to 0
2nd iteration - '9' from 5 to 1
At this point it hangs up. The next thing it does is look to see what should be in slot 5 (empty) and slot 5 is now empty, so nothing gets moved, and it just goes round and round moving nothing until... There needs to be a check in the loop for this condition and go back and find the next one that needs moving (could use the initial method of finding the first one out of place to find the next that needs moving).
Can you add that? Or maybe the whole algorithm needs a minor re-think.