This happens if you use tool 0. The wizards try to be clever and not do needless commands. They check to see if the last tool used is the same as the current one, if so it skips the M3 and M6 stuff.
I fixed this in most places, and have a couple more fixes in 2.83. I got stalled in testing it and have not finished. I will try to get it checked out and post it in a day or two. Most of the changes have to do with the new comp code.
Thats a hard one to fix- there are probably 100 or more DROS, and changing them all would mess up every screen.
The program saves the same size number in all cases, so you can enter more digits than show in the DRO. I know that would be an ugly way to do it, but it should work OK. The code generated will have the full numer.
Yes, it will only update when you press the calculate buttons. VB has no way to know that a DRO value was changed. I re-arranged that whole screen a while ago to try to make it more obvious that you need to go through it step by step.
The % override values however actually get used on later screens, so they will be used in generating the code.
Yes, I know about that problem. Its one of the new rules for the comp code, there has to be a straight line exit from comp and that wizard did an arc. I have fixed the code and started testing it, but got sidetracked. I will finish it and get 2.83 out in the next day or two.
I tried Centrecam but it has a major flaw- it wont stay on top of the mach window and while its on top it grabs the keyboard focus so you cannot control mach. If you click on the mach window the video window drops under so you cannot see moves. The only way around this would be 2 screens, or to really shrink the mach window which is unworkable.
I really like the software centering feature of CentreCam. I guess we need to lobby Brian to add that tothe mach video window.