821
VB and the development of wizards / Re: OEM/User/otherwise knowledge
« on: August 12, 2015, 08:51:47 AM »
Here is the scoop on While Ismoving() as I remember it. In the beginning the WIM() did not have a built in sleep AND it hogged teh CPU during the wait. THen Brian added in an auto sleep to the mix BUT this caused other problems and it was later removed. So that is why I still add in the sleep() to the WIM() and it works well here.
Also I find that IF you have a group of Gcode moves you can group them together with a WIM() at the end of the group.
Slower PCs work better than faster PCs when handling Macros it is a timing issue with macros. That is WHY one script will run perfect on ONE PC but not another without some tuning.
Sleep() allows the PC to wait with out hogging the CPU.
After anything that has to update or get a values add in a sleep(100) minimum to give it time to do it or create a semiphor to control the flow.
Never call another macro from inside a macro There IS a CALL for that in later versions that make it work.
The G4P# call is for use in the Gcode side. It stops the Que fill at that line call and then restarts the que fill from that point. YES it does create a wait BUT WIM() and sleep() are the better choice in the macro side as they do NOT effect the Que fill.
The Gcode side and the Macro side are 2 seperate control functions that are merged together when you use Gcode in a Macro script. REMEMBER that (;-) Not all things will work as you assume they would/should (;-).
Just a few thoughts, Your Mileage may vary. (;-) TP
Also I find that IF you have a group of Gcode moves you can group them together with a WIM() at the end of the group.
Slower PCs work better than faster PCs when handling Macros it is a timing issue with macros. That is WHY one script will run perfect on ONE PC but not another without some tuning.
Sleep() allows the PC to wait with out hogging the CPU.
After anything that has to update or get a values add in a sleep(100) minimum to give it time to do it or create a semiphor to control the flow.
Never call another macro from inside a macro There IS a CALL for that in later versions that make it work.
The G4P# call is for use in the Gcode side. It stops the Que fill at that line call and then restarts the que fill from that point. YES it does create a wait BUT WIM() and sleep() are the better choice in the macro side as they do NOT effect the Que fill.
The Gcode side and the Macro side are 2 seperate control functions that are merged together when you use Gcode in a Macro script. REMEMBER that (;-) Not all things will work as you assume they would/should (;-).
Just a few thoughts, Your Mileage may vary. (;-) TP