I think the loosing moves is a VB problem. Each time you press the button for a move a new VB instance is called. It generates the Gcode, then exits. If you press the button again, another Vb session is called. Mach and VB dont get along all that well- they barely tolerate each other. Look at some of the issues of a macropump that tries to run 10 times a second.
I probably should have added a While IsMoving loop to each command so that Vb does not return until the move is finished. Then you could not get ahead of VB.
I suggest you do NOT try to get several moves ahead of the machine.
Mike, you can do that kind of surfacing with the power feed wizard, but you do have to keep pressing the buttons for each feed and step over. It is for surfacing that I added the step over buttons in the lower right corner of the screen. To do a surface you would set up the limit values then press <feed> <Rapid return> <step over Y> then repeat the loop as many times as it takes to finish.
I realize thats not as nice as a wizard that simply generates one block of code then runs unattended.
This is kind of a fundamental distinction of my view of conversational. As its implemented here it means generating a block of gcode, then running a program. In my view of the world, one I was calling 'Interactive milling' instead of conversational you would actually run the code under the screen where it was generated. as you do in the PowerFeed wizard.
A long time ago I did a program like this, but I was never able to get a motor driver module I could call from VB. When Art started Master5 there was supposed to be a callable ocx to do moves, but it never really worked. I eventually quit working on my code. If you are interested in what I was doing its at
http://plsntcov.8m.com/CNH.htm Someday I may revive that idea.