Guest
Show Posts
1
Feature Requests / Fix CV by pre-processing the g-code
« on: May 05, 2012, 01:12:27 AM »
After having worked thru many different bugs with CV and living with the ones that are still in there, it seems to me that fixing the core purpose of mach3 (generate clean pulse trains from g-code) should be priority 1.
Here is a thought on how to both possibly help produce better tracking, give the user more info, and provide a much easier way to find and report bugs in path generation back to the programmers: have Mach3 go thru a pre-processing step after loading g-code where it does a pre-processing step and takes the motor tuning data, cv settings, backlash settings, etc and generates new intermediate toolpath points for all the spots where it is going to modify the base g-code path. It could be color coded and inserted right in the g-code window. For instance, you have a max x and y speed of 50 but your g-code is a square with a feed of 60 and CV is enabled. The feedrate would show red and be overridden to 50, then near each corner new g-code lines in green would be displayed which would be arcs showing the corner rounding. The original corner would be greyed out because it was replaced by the end of the arc g-code line. Etc. One funky item would be that it would be really useful to add a new code word to the language that would be a decel value. Then could have lines that the preprocessor added that basically show both the initial feed rate and then a decel rate from there to the next point.
Not only would then it be clear to the user what Mach is going to command, it would be easier to see bugs or issues, AND the code would run better because the PC no longer is calculating CV on the fly, it would just have a simpler command interpreter and run straight thru the 'updated' g-code.
A similar and much simpler tool that would be very useful for checking code quality would be to have a test mode where MACH 3 runs thru the code and the driver produces fake pulses that get displayed on a graph of frequency. You could have a sort of oscilloscope displaying the frequency of all axis and also the derivative (the accel). Then you could watch the graph and see if all looks good or if there are bad spikes or stalls where the pc can't keep up with the needed block rate.
Here is a thought on how to both possibly help produce better tracking, give the user more info, and provide a much easier way to find and report bugs in path generation back to the programmers: have Mach3 go thru a pre-processing step after loading g-code where it does a pre-processing step and takes the motor tuning data, cv settings, backlash settings, etc and generates new intermediate toolpath points for all the spots where it is going to modify the base g-code path. It could be color coded and inserted right in the g-code window. For instance, you have a max x and y speed of 50 but your g-code is a square with a feed of 60 and CV is enabled. The feedrate would show red and be overridden to 50, then near each corner new g-code lines in green would be displayed which would be arcs showing the corner rounding. The original corner would be greyed out because it was replaced by the end of the arc g-code line. Etc. One funky item would be that it would be really useful to add a new code word to the language that would be a decel value. Then could have lines that the preprocessor added that basically show both the initial feed rate and then a decel rate from there to the next point.
Not only would then it be clear to the user what Mach is going to command, it would be easier to see bugs or issues, AND the code would run better because the PC no longer is calculating CV on the fly, it would just have a simpler command interpreter and run straight thru the 'updated' g-code.
A similar and much simpler tool that would be very useful for checking code quality would be to have a test mode where MACH 3 runs thru the code and the driver produces fake pulses that get displayed on a graph of frequency. You could have a sort of oscilloscope displaying the frequency of all axis and also the derivative (the accel). Then you could watch the graph and see if all looks good or if there are bad spikes or stalls where the pc can't keep up with the needed block rate.