Towers of Hanoi Mini Game

[Deano91]

Hey all

I am trying to create an 8 block towers of hanoi mini game in labview that communicates with robot studio which will simulate each block moving in the game. I have a pretty basic interface setup in which I am moving around square LED around the screen to visualize each move. i am trying to read the left and top properties of my selected block and depending on the value send a number from 1-8 to Robotstudio so it can determine where the block is to be picked up. Then depending on my selection i am moving the LED bar to its next position.

So my code that i send looks something like this. 15436 - 1(stack 1) 5(position 5) 4(Block4) 3(Go to stack 3) 6(Go to position6).

The problem i am having is that by the time i send the code to RS the LED block changes and updates the sent code so that's its initial position changes to read its new position so instead of sending 15436 i get 36436 at the other end. how do i fix this ?

I am running a sub vi to delete unnecessary zeros out my array so make sure to have that if you run my file.

[James_W]

Hi Dean,

fundamentally it looks like you have a race condition between the FP update and the data being sent to the TCP - this is probably your fundamental issue (due to the UI update lag). Try putting a delay after the Execute case structure before you write the string to the TCP.

Look at your basic architecture.
You should be using a producer consumer loop to pass data.
TCP open and Close take up loads of time, move them outside the while loop and put in a shift register.
Property nodes take a (relatively) long time to execute -  if you know the position of a block, keep it in memory in a shift register instead of working it out.

You have a stack of "rings" of different sizes - this is essentially an array of max size (stack height) and with elements which could correspond to an enum. The moving of the boolean indicators on the FP is really killing your execution speed.
If you have 3 x array of enum (or ring) you can do the grapical display at the end quite quickly (maybe with a picture ring)

There's a lot of that code that could be improved and if you are using more than 1 local variable for a control, you should be asking yourself why? and "can I write this better?"

(I haven't even looked at the subVI)

James

[altenbach]

I agree that the code as it currently stands is not maintainable and really debugable.

You have dozens of cases that only differ in a few references and a few constants. Why can't you use a boolean array for all the round LEDs? 90% less code! Why are these LEDs controls if the code constantly changes them. Do you really want the operator to be able to toggle them at will?

Can't you use CRLF mode for TCP read (assuming you have control over the sender) instead of inspecting one character at a time? It also feels fragile, because your code will lock up forever if a CR is never received. Suffice to say that the internet as we know it would not work if each byte would take 10ms to receive. 😮

I would probably use a simple picture indicator for the towers. drawing filled rectangles is trivial. Moving indicators around on the front panel is like herding cats and aborting the code in the middle leaves your FP in disarray.