Whoever uses Mach3, this strangeful designed VisualBasic program?
A better choice today is using GRBL
embedded into an Arduino board (or simply its ATmega328 microcontroller).
The plugin
A Mach3 plugin skeleton without MFC for outputting wave data to a
suitable (mostly USB) device. It's not tested!
The plugin opens a system wave device expecting three channels
(one for each X, Y, and Z axis) — or more for rotational axes,
and will output data with following characteristics:
At least 3 channels
1 kHz sample rate (possibly even lower, depends on maximum acceleration)
8 bit per sample, zero-centered signed acceleration data, ±126 = maximum acceleration
This requires second-order trajectory planning, which is the minimum de-facto standard for CNC controls
In opposite to the ready-made SmoothStepper
board, no driver installation is needed at all.
How to implement the CNC machine
A microcontroller is obviously necessary.
For it, 8-bit types with built-in USB interface,
like AT90USB162, are sufficient.
For more performance, necessary for
parallel kinematics
like this one,
a 32-bit controller like
AT91SAM7S should be used.
Also, when encoders
and therefore feedback loops (with
PI controller) are used,
a 32-bit controller should be used.
Motor control
All what a CNC constructor has to do is to create a microcontroller firmware
that exposes a suitable USB sound card to the PC,
and interpret the incoming data accordingly.
Despite the relaxed sample rate (incoming data rata is only 3 kByte/s),
the firmware can easily create high-speed,
high-resolution step pulses for the stepper motors, because:
Mach3 (i.e. the built-in Trajectory Planner)
will ensure that speed ramps (i.e. accelerations) are limited.
Mach3 will sum up all the pulses for the correct position, therefore,
there is no need for the microcontroller to deal with (wide-bitness) positions.
Incoming speed data can be easily converted to equally-distanced step pulses
and microsteps, it's not a great task.
Three hardware CTC will ease this,
but one single timer is still sufficient.
For built-in safety, a disrupting waveform data stream will lead to an
emergency stop,
which is mostly intended.
An emergency stop removes power from all motors and activates all
available brakes.
The exception from this rule are motors or solenoids holding a load
that will otherwise fall down and make additional damage.
References are lost, and a synchronization movement is necessary
in front of next positioning.
A normal stop speeds down the motors as fast as possible,
then holding them for some microseconds to ensure braking,
and later reduce or remove power.
References are kept.
Incoming invalid data, such as 80h-centered sound data, must be ignored
by that firmware, to prevent inadvertent movements by a mis-configured
media player.
All switches are relatively low-speed and reported by an HID interface.
This will include all end switches and some human-interface switches,
possibly an extra Emergency Stop contact.
(Of course an Emergency Stop should interrupt the power supply for all drives – in wired hardware!)
This is to be specified!
Construction of controller firmware
The only source for high-speed return data is an encoder.
Such data is fed to Mach3 by another “sound” channel (like a multi-channel microphone)
in the reverse direction. Also, counts and microsteps are transferred.
For stable operation, encoder positions should be processed by the microcontroller,
not by Mach3.
![[ICO]](/icons/blank.gif){kind=icon}
![[IMG]](/icons/image2.gif){kind=icon}
![[ ]](/icons/compressed.gif){kind=icon}