Page 2 of 2

Re: Mach 3 question

Posted: Mon Jul 07, 2014 12:12 am
by Woodworker
Thanks Will, missed that page.

Re: Mach 3 question

Posted: Mon Jul 07, 2014 1:14 am
by WillAdams
WillAdams wrote: That said, I think a great feature for the G-code senders which are oriented towards Grbl would be to accept the entire G-code standard and interpret and instantiate it as G-code which Grbl can understand.
Probably the tool pregrbl is that: https://github.com/chamnit/preGrbl

Perhaps some of the comm/control programs could add this?

Re: Mach 3 question

Posted: Mon Jul 07, 2014 1:39 am
by Woodworker
Looks like it is based on GRBL 0.7 so it needs some updating. This looks like what I am looking for as a start. I want to add the ability to add pre and post commands to the CAM generated GCODE. Now al I have to do is learn python! Seems with all the programmers on this forum, some of them would step forward to update/bug fix some of the existing code like UGS and MakerCAM. I will start on this. I have a friend that hopefully will coach me in the build process.

Re: Mach 3 question

Posted: Mon Jul 07, 2014 12:09 pm
by cvoinescu
fl0yd wrote:GRBL v9 has a new gcode parser that aims to be 100% gcode compliant. It will be interesting to see what pre-processing to remove unsupported statements will be needed.
Even with the new parser, it doesn't support user variables, expressions, and flow control, which are the things used by human-written G-code, but not by CAM-generated G-code. Just to be clear, I'm not saying it's a problem -- it's intentional, documented policy, and I understand, and agree with, the rationale.

Re: Mach 3 question

Posted: Mon Jul 07, 2014 12:26 pm
by Woodworker
So what happens of you send them to GRBL, are they just ignore or does processing stop?

Re: Mach 3 question

Posted: Tue Jul 08, 2014 11:36 am
by stevensloane
cvoinescu wrote:Pretty much.

Your system needs to:
  1. read G-code from a file
  2. interpret the G-code
  3. plan the motions
  4. generate step and direction signals
  5. count step pulses to determine the required current in each motor winding
  6. put that much current through the motor
In all cases, your motor drivers (e.g. Allegro A4988, Texas Instruments DRV8825, Toshiba TB6560...) do the last two steps (step 5 is called "indexing"). Cheap, small drivers do both step 5 and 6 on a single chip; larger and/or more advanced drivers (e.g. Gecko) do them with separate components.

LinuxCNC uses the PC to do all the other steps. It generates the step and direction signals on the PC's parallel port (or a specialized card), which connect to the inputs of the motor drivers.

Mach3 does the same, but it also supports doing step 4 (the actual timing and generation of the pulses) on separate, dedicated hardware connected by USB or Ethernet (e.g. SmoothStepper).

With GRBL, Universal G-Code Sender (or GRBL Controller, etc) runs on the PC, reads the G-code, and sends it over to GRBL via serial-over-USB (so the PC does step 1). GRBL runs on the Arduino Uno and does steps 2, 3 and 4. Your driver shield has the drivers that do steps 5 and 6.

For completeness, I should add that some driver chips do not use the step pulse system; instead, they are given motion commands directly from the planner. Steps 4 and 5 are replaced by a single step, "interpret motion commands to determine the required current waveform in each motor winding". GRBL does not support this type of driver, and I doubt it can be used from LinuxCNC or Mach3 either.

Also, there's great leeway in interpreting what step 2 means. GRBL has an intentionally limited G-code interpreter, with no support for user variables, expressions, flow control, canned cycles, spindle synchronization, and so on. It can handle only three linear axes. GRBL can not be used for lathes, nor for milling machines with more than three axes. Both LinuxCNC and Mach3 have pretty much complete G-code support, with all the features, and they understand rotary axes. They can be -- and are -- used with professional machines of many types. Humans who write G-code directly find the lack of variables and flow control in GRBL very limiting. However, G-code generated by CAM packages doesn't need those features, so GRBL works perfectly for that.
Thanks for the reply, it's starting make sense to me ;)

Re: Mach 3 question

Posted: Tue Mar 19, 2019 6:07 pm
by MIRUIWANG
cvoinescu wrote:Pretty much.

Your system needs to:
  1. read G-code from a file
  2. interpret the G-code
  3. plan the motions
  4. generate step and direction signals
  5. count step pulses to determine the required current in each motor winding
  6. put that much current through the motor
In all cases, your motor drivers (e.g. Allegro A4988, Texas Instruments DRV8825, Toshiba TB6560...) do the last two steps (step 5 is called "indexing"). Cheap, small drivers do both step 5 and 6 on a single chip; larger and/or more advanced drivers (e.g. Gecko) do them with separate components.

LinuxCNC uses the PC to do all the other steps. It generates the step and direction signals on the PC's parallel port (or a specialized card), which connect to the inputs of the motor drivers.

Mach3 does the same, but it also supports doing step 4 (the actual timing and generation of the pulses) on separate, dedicated hardware connected by USB or Ethernet (e.g. SmoothStepper).

With GRBL, Universal G-Code Sender (or GRBL Controller, etc) runs on the PC, reads the G-code, and sends it over to GRBL via serial-over-USB (so the PC does step 1). GRBL runs on the Arduino Uno and does steps 2, 3 and 4. Your driver shield has the drivers that do steps 5 and 6.

For completeness, I should add that some driver chips do not use the step pulse system; instead, they are given motion commands directly from the planner. Steps 4 and 5 are replaced by a single step, "interpret motion commands to determine the required current waveform in each motor winding". GRBL does not support this type of driver, and I doubt it can be used from LinuxCNC or Mach3 either.

Also, there's great leeway in interpreting what step 2 means. GRBL has an intentionally limited G-code interpreter, with no support for user variables, expressions, flow control, canned cycles, spindle synchronization, and so on. It can handle only three linear axes. GRBL can not be used for lathes, nor for milling machines with more than three axes. Both LinuxCNC and Mach3 have pretty much complete G-code support, with all the features, and they understand rotary axes. They can be -- and are -- used with professional machines of many types. Humans who write G-code directly find the lack of variables and flow control in GRBL very limiting. However, G-code generated by CAM packages doesn't need those features, so GRBL works perfectly for that.
At step 4, is this iterpolated, or not?
or does Mach3 and LinuxCNC do interpolation?

Re: Mach 3 question

Posted: Mon Aug 17, 2020 2:52 am
by zezid
But it's expanded a bit.