Most standard CNC controllers limit your capabilities by offering a fixed number of stepper driver channels, making it difficult or expensive to expand your machine. If you want to add secondary rotational or indexing axes to build a 4-axis or 5-axis setup, you are typically forced to completely upgrade your motion controller hardware.

Our new Axis Swapper solves this elegantly at the hardware level. Powered by a high-speed 74AHCT125 tri-state buffer IC, this board allows a single master controller axis to safely share its stepping logic between two separate physical motor drivers (such as alternating between an A-axis tilt head and a B-axis rotary platter).

Because it uses hardware-locked active buffering, it is physically impossible to drive both axes at the same time—safeguarding your machine from accidental dual-movement and mechanical crashes.

Here is exactly how to wire, configure, and automate this board using your Buildbotics CNC Controller.

🔌 Step 1: Physical Terminal Wiring

Because the Buildbotics Controller cleanly isolates external motor logic from secondary tool I/O, your selector board acts as the meeting bridge. External motor step/direction logic lives on the DB15 Breakout Box, while the programmable digital output lines live on the DB25 Breakout Box.

For the cleanest control panel routing, we recommend bundling the 4 logic lines from the DB15 block and your single toggle line from the DB25 block into a single clean cable run using zip-ties or braided sleeving.

Connect the wires to the J1 Input Terminal on the Selector Board as follows:

Output Motor Driver Wiring

Once your input signals are wired, you must route the isolated outputs from your selector board over to your external stepper motor drivers.

• Output A (J2) connects to Motor Driver 0 (e.g., Tilt Axis)
• Output B (J3) connects to Motor Driver 1 (e.g., Turn Axis)

Use the following terminal wiring map to connect the pins on either output block (J2 or J3) directly to the matching control terminals on its respective motor driver:

⚙️ Step 2: Controller I/O Configuration

Before creating your macro buttons, you must tell the Buildbotics Controller software which physical pin is acting as your A/B toggle switch.

1. Open the Buildbotics web interface and navigate to SETTINGS -> I/O.
2. Locate the digital output pin selected in step 1 and change the function to output-0, output-1, output-2, or output-3. In this example, we chose pin 1 and output-0.
3. Set the Mode to 'lo-hi'.
4. Click Save to apply the configuration.

⚙️ Step 3: Creating the Macro Buttons

To seamlessly switch between your two multi-axis modes (e.g., Tilting vs. Turning) without losing your machine coordinates, you can set up two custom Macro buttons in your Buildbotics web interface.

These macros automatically back up your absolute machine position (#5423) for the inactive motor, reload the last saved position for the incoming motor using G28.3 (without physical movement), and flip the electronic hardware gate via G-code commands (M64/M65).

🔵 Macro 1: "Tilt" (Select Output A / Motor Driver 0)

Go to your Buildbotics Macro settings, create a button named Tilt, and paste the following code:

o110 if [#<_rotary_mode> NE 1]
    #<_bloc> = #5423      (Save the active Turn position to memory)
    G28.3 A#<_aloc>       (Restore the last saved Tilt position to the DRO)
o110 endif

M65 P0                    (Turn off Digital Output 0 -> Select Hardware Output A)
#<_rotary_mode> = 1       (Set system state to Mode 1)
(msg, Machine switched to Tilting Mode)

🟡 Macro 2: "Turn" (Select Output B / Motor Driver 1)

Create a second macro button named Turn, and paste the following code:

o110 if [#<_rotary_mode> NE 2]
    #<_aloc> = #5423      (Save the active Tilt position to memory)
    G28.3 A#<_bloc>       (Restore the last saved Turn position to the DRO)
o110 endif

M64 P0                    (Turn on Digital Output 0 -> Select Hardware Output B)
#<_rotary_mode> = 2       (Set system state to Mode 2)
(msg, Machine switched to Turning Mode)

🚀 Step 4: How to Operate

Once wired and configured, operation is entirely automated:

1. When you boot up, home your machine as normal.
2. Click the Tilt button to work on your primary axis.
3. When you are ready to switch, simply click the Turn button. The controller will instantly store where your Tilt axis was resting, swap the hardware signal line to your Turn axis, and update your screen coordinates perfectly.

You can also embed M64 P0 and M65 P0 directly into your post-processed G-code program files if you want your machine to automatically swap axes mid-job!

Ready to upgrade your machine? I only manufactured an incredibly limited run of 18 boards, and they are available on our store right now for less than $35.

👉 Click Here to Grab One of the 18 A/B Step/Dir Multi-Axis Selector Boards Before They Sell Out!

1. Introduction: Moving Beyond the "Slap a Bead on It" Advice

If you scroll through hobby CNC forums long enough looking for solutions to random mid-carve disconnects, computer dropouts, or mysterious emergency stop events, you will encounter a universal chorus of advice: “Slap some ferrite beads on your motor cables,” or “You need fully shielded cables.”

While adding beads and shielding can absolutely be valid fixes for a machine suffering from genuine electromagnetic interference (EMI), this advice is often handed out as a generic, reactive band-aid without any real diagnostic proof. If radio frequency (RF) energy or inductive cross-talk is actively causing false tripping on your machine, blindly stacking magnets on your wires won't tell you why it happened, where it's coming from, or how to truly prevent it.

I decided I didn’t want to just guess. I wanted to see the invisible electrical noise floating around my shop, track its behavior, and map exactly what it does to my machine.

But here is the twist: I have run my CNC machine for several years with absolutely no ferrite beads or cable shielding, and it has never suffered from a single false trip or connection drop.

So why execute a rigorous, data-driven electromagnetic audit on a machine that already runs flawlessly?

Because I wanted to understand the science behind that stability. My machine relies on a Buildbotics CNC Controller, a unit built with exceptional industrial hardware engineering. Many entry-level or budget control boards on the market are far less capable, featuring bare processor lines that collapse the second a nearby spindle kicks on.

I deployed a tinySA Ultra spectrum analyzer running completely on its internal battery to sniff out airborne RF,

and a Rigol DS1054Z digital oscilloscope to measure the real-world voltage lines inside my controller,

This audit does two things: it exposes the brilliant engineering secrets that keep the Buildbotics platform immune to noise, and it provides a clear, proven diagnostic roadmap for hobbyists struggling to cure persistent EMI headaches on their own machines.

2. The Suspect Lineup: Where Does CNC Noise Come From?

To execute a proper electromagnetic audit, we first have to identify the potential rogue transmitters inside a typical CNC workspace. Any piece of active electronics operating in your shop can generate electromagnetic noise, but they fall into a few primary categories:

• The Power Supply Ecosystem: Many entry-level CNC setups rely on open-frame component power supplies that are only certified to lenient Class A (Industrial) limits, allowing raw RF noise to bleed freely from their ventilated metal mesh into an open room. To establish a clean, residential-ready standard for this audit, I upgraded the main supply feed to a MEAN WELL GST280A48-C6P desktop adapter. Because this fully sealed 48V brick is explicitly certified to strict FCC Part 15 Class B (Consumer/Residential) emission limits, it ensures that the raw power feeding our electronics is baseline quiet out of the gate.
• The CNC Controller: The internal microprocessor clocks, fast-switching FETs, and step-direction signal lines inside a mainboard are constantly humming with digital state changes.
• The Variable Frequency Drive (VFD): This is the ultimate heavy hitter. A VFD controls spindle speed by rapidly chopping high-voltage AC electricity down into aggressive pulse-width modulation (PWM) square waves, creating immense harmonic ringing.
• Computers and External Monitors: A shop laptop, its internal charging circuits, or a nearby desktop monitor can inject high-amplitude RF noise directly backward down data lines and power links.
• Peripherals & Accessories: USB cameras, digital gamepads, unshielded wireless dongles, and even cooling fans add their own microscopic noise profiles to the shared electrical ground.

The Real Enemy: Wires as Antennas

Here is a foundational truth of EMC engineering: While the active electronics listed above generate the high-frequency noise, the components themselves are usually too small to broadcast it very far into the room.

Instead, the noise rides out of the electronics housing and hitches a ride down your interconnecting cables.

Your 10-foot stepper motor lines and spindle power cords function exactly like perfectly tuned, long-wire transmitting antennas. When you pack these high-power cables tightly into the narrow plastic track of a drag chain right alongside low-voltage, highly sensitive digital limit switches or Z-probe wires, you create an ideal environment for inductive and capacitive cross-talk.

The high-power lines broadcast a localized blanket of electromagnetic energy, and the neighboring digital lines act as receiving antennas, catching the voltage ripples and feeding them directly back into the microprocessor. This is precisely why our near-field testing strategy focuses on sniffing the air directly inside the drag chain. We aren't just testing the components; we are testing the efficiency of the cables functioning as a rogue radio network right alongside our machine's nervous system.

3. The Physics of Interference: Near-Field vs. Far-Field Noise

To execute a meaningful electromagnetic audit, we must separate our measurements into two distinct physical zones. Electromagnetic energy behaves completely differently depending on how far it has traveled from its source wire. Understanding these two domains dictates exactly how we use our test equipment to isolate problems:

Near-Field Noise (The Self-Interference Zone)

The near-field is the region of space immediately surrounding your wires and electronics chassis—typically within one wavelength of the operating frequency. In this zone, energy does not travel through space as an organized, airborne electromagnetic wave. Instead, it exists as raw, localized magnetic (inductive) and electric (capacitive) field cross-talk.

• How we use it: If your CNC machine is experiencing physical stability problems—such as random mid-carve emergency stops or computer disconnects—near-field measurements are the only ones that matter. By taping our 1-foot whip antenna directly to the drag chain, we are intentionally sampling this chaotic cross-talk environment. This test tracks the exact energy profile that is trying to leap across the wire insulation from your high-power motor lines straight into your sensitive digital inputs.

Far-Field Noise (The Regulatory Compliance Zone)

As electromagnetic energy moves further away from the machine, the electric and magnetic fields couple together permanently. They form a true plane wave that breaks away from the wiring completely, radiating out into the open room and traveling through walls. This is the zone where federal regulators care about your shop.

• How we use it: To check for legal FCC compliance, we move our spectrum analyzer 10 feet (3 meters) away from the machine. At this distance, the localized drag-chain cross-talk disappears from the airwaves, leaving only the pure radiated signals that have successfully escaped the machine's wiring network. This test tells us whether our shop is actively broadcasting illegal radio interference that could disrupt a neighbor's Wi-Fi, television, or cellular reception.

The Regulatory Catch-22: Who is Responsible?

It is a common misconception that every individual component you buy for a hobby CNC project must carry an FCC compliance sticker. Under FCC Part 15 regulations, standalone sub-assemblies—such as bare stepper motors, developer microcontrollers, and control modules like the Buildbotics Controller—are generally exempt from independent certification because they cannot function on their own out of the box.

However, the regulations feature a massive catch: the final system integrator—which means you, the person wiring all these parts together onto a structural frame—is legally responsible for the compliance of the total machine.

4. Raw Near-Field Auditing & The Voltage Reality

To get an accurate measure of the noise that the digital inputs experience, I taped the tinySA directly to the drag chain carrying the power cable from the Huanyang VFD, the motor cables connected to the X and Z axis motors, and the input signals for the X and Z axis limit switches.

Recall that these initial tests were done with the machine set up as it has been running for years, that is, with no beads on the motor cables and no toroid protecting VFD power cable.

By sweeping a window from 100 kHz to 40 MHz, I captured a detailed six-part chronological map of the electromagnetic noise inside the chain as each component powered up. Running the tinySA purely on battery power completely isolated the test environment, exposing the raw, unpolluted truth:

Decoding the Six-Pane Scan Matrix

• 1. Everything Off (-88.0 dBm @ 6.41 MHz): This is our baseline environmental control scan with the entire shop powered down. The spectrum is beautifully flat and sitting deep in the static floor at -88 dBm, proving that there is no external ambient RF contamination leaking into our drag chain from the outside world.
• 2. Power Supply On (-87.0 dBm @ 17.40 MHz): Next, I flipped on our new MEAN WELL GST280A48-C6P desktop power brick. The spectrum barely budged, showing a tiny blip at 17.4 MHz but keeping the rest of the noise floor completely flat. This confirms that this Class B certified residential supply successfully traps its internal switching oscillation inside its sealed housing.
• 3. Buildbotics Controller On (-90 dBm @ 5.41 MHz): Turning on the Buildbotics Controller did not introduce any discernable noise.
• 4. VFD & Buildbotics Controller On (-68 dBm at 5 MHz and -75dBm at 30MHz): Flipping the power switch on the Huanyang VFD introduces our very first sign of real electromagnetic activity. Even with the spindle at a dead stop, a jagged, broadband "noise mountain" begins swelling upward between 5 MHz and 15 MHz and between 25 MHz and 35MHz. Because this budget VFD uses a plastic enclosure rather than a cast-metal grounded chassis, its internal idling power electronics actively radiate RF energy straight through the plastic housing and into the adjacent antenna.
• 5. X Motor Running (-60 dBm @ 13 MHz): The moment the X-axis motor begins stepping back and forth, a prominent harmonic spike punches through the noise floor, jumping up by about 30 dB to hit -60 dBm near 13 MHz. This represents the fast pulse-width modulation (PWM) chopping frequency of the internal Texas Instruments stepper drivers radiating straight off the unshielded 10-foot motor lines.
• 6. Huanyang VFD & Spindle Running (-60 dBm @ 110KHz): The instant the VFD fires up and spins the spindle motor, a violent, high-amplitude energy surge floods the lower end of our spectrum, peaking at -60 dBm down at 0.11 MHz.

On a spectrum analyzer screen, an airborne spike climbing all the way to -60 dBm inside your drag chain looks incredibly intimidating. This is exactly the kind of graph that causes hobbyists to panic and assume their machine is on the verge of a catastrophic crash. But what does that airborne radio signal actually do to a physical copper wire sitting right next to it?

Hooking Up the Oscilloscope: Volts vs. Logic Thresholds

To move past radio frequency theory and measure the actual electrical impact on our physical wire lines, I fired up my Rigol DS1054Z digital oscilloscope. I placed a probe directly across the input signal pin and ground of an active limit switch right at the terminal block of the Buildbotics Controller.

If the airborne radio waves captured by the tinySA were truly threatening our machine's stability, we would see violent voltage transients completely overwhelming our digital circuit. Instead, the scope traces revealed a masterclass in real-world circuit behavior.

• Top Pane: Buildbotics Controller ON (Baseline): With the controller fully powered up but all motors idle, the 3.3V DC digital input line is an absolute straight line. The signal is incredibly clean, showing a completely stable digital "HIGH" state with no stray voltage fluctuations or ripples present at 1.00 Volt per division.
• Center Pane: X Motor Running at 500mm/min: When the stepper motor is activated, the unshielded wires begin transmitting the high-frequency PWM switching profile of the stepper drivers. Because our long limit switch wires are unshielded, they behave like an open antenna, capacitively picking up that energy. At 1.00 Volt per division, this noise band actively measures a substantial 1.5 Volts peak-to-peak, swinging the line up toward 4.0V and pulling it down to roughly 2.5V.
• Bottom Pane: VFD Running at 10,000 RPM: The final trace captures a staggering electrical reality when the spindle is actively spinning. Because the VFD uses high-voltage, high-power switching pulses, the capacitive coupling inside the drag chain scales up exponentially. Look closely at the vertical scale on the left edge of the screen: the scope has stepped up from 1V/div to 5.00 Volts per division. At this scale, the periodic switching spikes and voltage settling waves are ringing across more than a full grid square, revealing an induced noise profile measuring a massive noise voltage ranging from +15V to -1V!.

The Real Reason the Machine Doesn't Trip

Seeing a 1.5V noise band from the steppers—and a massive 16V ringing waveform from the spindle—riding on top of a 3.3V logic circuit would make any textbook engineer predict an instant system crash. In normal circumstances, a 15V spike would effortlessly overdrive the microprocessor input entirely via overvoltage and the negative swings would certainly trip the input limit switch. Yet, my machine has run flawlessly for years without a single false trip.

How is this possible?

First, we have to look at the ATxmega processor's input thresholds. To register a digital logic change from a HIGH state to an active LOW state (triggering an E-stop), the voltage must drop below ~0.9 Volts. On the stepper motor trace, our 1.5V peak-to-peak swing only pulls the line down to about 2.5 Volts, meaning the signal safely floats well above the danger zone.

But what about that massive 15V spindle transient? Left unmanaged, that spike would pull the input into negative volts and blast it past +15V, possibly destroying the chip. It doesn't crash because of the exceptional hardware protection built directly into the Buildbotics CNC Controller.

The digital inputs on the Buildbotics mainboard feature ultra-fast Schottky protection diodes pointing outward with a 100V reverse breakdown. The instant the unshielded spindle line induces a high-voltage spike inside the drag chain, these diodes become reverse biased and block the high voltage before it can cross into the microprocessor.

The spikes that go below the .9V threshold are neutralized by the controller's programmable software debounce timing. Because RF noise oscillates rapidly millions of times per second, the firmware demands that an input signal remain continuously and solidly held down for a steady 5 millisecond window before recognizing it as a real switch closure. The massive 15V spike is chopped down by the hardware and ignored by the software, proving that intelligent circuit design will easily defeat brutal near-field noise environments.

5. Taming the Near-Field: Do Ferrites Actually Work?

Even though our raw baseline testing proved that the Buildbotics Controller remains perfectly stable under fire, leaving large voltage swings bouncing around input lines goes against standard shop advice. To see if the common internet remedies actually hold weight, I re-installed our two hardware countermeasures: a linear stack of five clip-on ferrite beads on the stepper motor wires, and a heavy toroid choke core on the main VFD output lines feeding the spindle.

The side-by-side oscilloscope captures revealed a fascinating disconnect between internet forum lore and real bench physics:

The Stepper Motor: A Noticeable Win for the Beads

When we check the scope traces for the running X-axis stepper motor (1.00 Volt per division), the five clip-on ferrites deliver a clear, measurable improvement:

• Left Pane (No Beads): The raw PWM motor-chopping frequency couples into our unshielded limit switch line, creating a thick, fuzzy band of noise measuring a substantial 1.5 Volts peak-to-peak around our 3.3V rail.
• Right Pane (With 5 Beads): The moment the five ferrite beads are snapped over the line, they act as a high-frequency choke. On the scope, the thick, fuzzy voltage envelope noticeably compresses. While it doesn't flatten the signal completely, it takes a clean bite out of the peak-to-peak ripple, visibly thinning out the fuzzy noise band.

The VFD Spindle: The Toroid Myth Exploded

The story completely changes when we look at the high-power spindle lines running at full 10,000 RPM. When we look at the scope traces at 5.00 Volts per division, we see a reality check that goes entirely against common blog advice:

• Left Pane (No Toroid): The raw, unshielded VFD lines induce a heavy, erratic ringing pattern onto our limit switch line that surges across the screen, reaching 15 Volts peak-to-peak.
• Right Pane (With Toroid): After wrapping the heavy UVW spindle lines through the magnetic toroid core, the result on the scope is a bit of a letdown. The toroid has almost no noticeable effect on the voltage swing. The chaotic spikes and multi-volt surges remain practically identical to the unshielded run, showing only a microscopic reduction in peak height.

Simply wrapping your spindle lines through a toroid does practically nothing to solve near-field cross-talk inside a drag chain. The raw current and capacitive coupling running parallel over 10 feet completely overwhelms what a single magnetic ring can filter out at these lower frequencies.

The Buildbotics Advantage: Silicon over Ferrites

This test exposes exactly why so many hobbyists get stuck in an endless loop of buying filters. If you are running an entry-level controller with bare microprocessor pins, relying on a VFD toroid to fix your false trips is a losing battle—the noise is still hitting your board at full strength.

The only reason my machine has carved flawlessly for years without a single false trip comes down entirely to the internal architecture of the Buildbotics CNC Controller:

These tests demonstrate that traditional, forum-vouched hardware fixes like clip-on ferrite beads and magnetic toroid chokes offer mixed results against intense near-field electromagnetic noise. While five snap-on ferrite beads provide a clear, measurable reduction in peak-to-peak ripple on unshielded stepper motor lines, a heavy magnetic toroid core wrapped around VFD spindle power lines fails to produce any noticeable impact on massive 15V-to-1V ringing transients. Ultimately, the test reveals that external filters cannot match the protection of robust, onboard hardware architecture—proving that the Buildbotics Controller’s internal Schottky protection diodes and programmable software debouncing are what truly shield sensitive microprocessor logic circuits from catastrophic cross-talk and false limit-switch trips.

6. Turning to the Airwaves: The Far-Field Subtraction Protocol

With our near-field drag chain environment thoroughly understood, it was time to step back 10 feet (3 meters) and analyze our integrated machine from a regulatory standpoint across the official FCC radiated emissions spectrum: 30 MHz to 1000 MHz (1 GHz).

However, open-air EMI testing outside of a million-dollar shielded anechoic chamber presents a massive challenge: the airwaves are already flooded with external radio signals. While it is not possible to do testing comparable to an FCC certified test lab in my garage, the tinySA has a great feature that attempts to subtract background noise. (Quite impressive for a device that you can get on Amazon for less than $100. Oh, and I should mention that its an open source project!)

The graph on the left is the noise spectrum with my CNC machine completely turned off. As you can see there multiple spikes of massive amounts of RF signal across this spectrum. A live view reveals that these signals are constantly changing, especially around 630, 750, and 880MHz. These are all cell phone bands and cannot be completely subtracted by the tinySA because they are constantly changing with network traffic.

Even still, the middle graph shows the RF signals present with the CNC machine completely off minus the baseline on the left. While the first graph measures the actual signal power in dBm, the middle and right graphs show the deviation from the baseline in dB. Since the cell traffic is constantly changing the subtraction still shows significant RF signal around those frequencies.

The graph on the right shows the RF signal captured with the CNC machine on and the X motor running at 500mm/minute and the spindle running at 10000 RPM.

This test suggests that my CNC Machine which is powered by the Mean Well GST280A48-C6P power adapter, the Buildbotics Controller, and the Huanyang VFD would easily pass an FCC certification.

Introduction

The user interface for the Buildbotics CNC Controller is really nice. It's easy to use and flexible. But, every user and application is different and the interface may not be optimal for every case.

Maybe you want to run it from your smart phone, but find the web interface to be too busy to all fit on a smart phone. Maybe you want more macro buttons. Maybe you want to limit the things a user can do. You get the picture, there always things that could be done differently or more efficiently for each unique user and application.

That's where the Buildbotics Applications Programming Interface (API) comes in. We recently published a full description of the API and quietly announced it. This describes how to use it.

Also, check out my blog post titled Creating a CNC Jogging App for an Android Phone to see a real life example.

API Overview

Applications that use the API will connect to the Buildbotics Controller via the hardwired Ethernet port or through the WiFi interface.

The API exposes WebSocket and HttpRequest interfaces.

The WebSocket interface initially receives many state variables from the controller when the websocket is first opened and then subsequently receives those variables again whenever they change.

The WebSocket interface can also be used to run Manual Data Input (MDI) commands.

The HttpRequest interface is used to send specific commands and send or receive information or files.

WebSocket Interface

Most applications need to monitor the state of the machine. That single interface will send back the state variables and their values and then send each variable again if it changes.

Here's some javascript code that will open a WebSocket with my Buildbotics CNC Controller and then handle the state messages as they arrive.

is_object(o) {return o !== null && typeof o == 'object'},

update_state(state, update) {
  for (const [key, value] of Object.entries(update))
    if (is_object(value) && is_object(state[key]))
      update_state(state[key], value)
    else state[key] = value
}

let state
let ws = new WebSocket('ws://192.168.12.243/websocket')

ws.onmessage(event) {
  let msg = JSON.parse(event.data)
  if (state == undefined) state = msg  // First message
  else update_state(state, msg)        // Update messages
}

The 'let state' line initializes a variable called state, which will ultimately maintain a list of all variables and their current value.

This piece of code opens a WebSocket with the Buildbotics Controller and puts it in 'ws'. The argument to WebSocket is a Uniform Resource Locator (URL). Replace '192.168.12.243' with the IP address for your controller.

Then, whenever a message arrives, the code in ws.onmessage is called with the message contained in the 'event' argument. 'msg' is then gleaned from the event. For the first message, the variable state is set to msg. Subsequent messages are passed to update_state.

update_state then finds all the variables and their values in 'msg' and updates state.

Now that you have the variables, you can monitor them and take whatever action desired based on their valued. For instance, you could add a line to update_state that raises an alert if the machine is estopped.

update_state(state, update) {
  for (const [key, value] of Object.entries(update))
    if (is_object(value) && is_object(state[key]))
      update_state(state[key], value)
    else state[key] = value
    if (key === 'es' && value == 0) alert('Machine Estopped!')
}

The variables and their definitions are documented in bbctrl-vars-schema.

You can also send messages to the Buildbotics Controller via this same WebSocket. Any command that can be sent through the MDI interface on the Buildbotics Control page can also be sent through this WebSocket interface. For instance, if I want motor 0 to set to homed, I could use a command like this.

ws.send('0homed=1')

HttpRequest Interface

The HttpRequest interface is used for sending and receiving files, loading and setting the configuration, telling the machine to run, stop, start, pause, jog, reboot, estop, and lots of other things. The Applications Programming Interface (API) document provides a detailed list of the commands that the Buildbotics Controller accepts.

These commands use 'GET', 'PUT', and 'DEL' HttpRequests as described in the API. The API also specifies the URL for each command. The API provides nice examples of how to send and receive each command in various technologies such as unix Shell, javascript, java, python and others.

In javascript, it's best to use fetch commands.

Here's an example of how to read the hostname in javascript.

try {
  const response = await fetch('http://192.168.12.243/api/hostname);
  if (response.ok) {
    const data = await response.json();
    console.log('got response', data);
   }
} catch (e) {
  console.log('error:', e);
}

Note that the javascript fetch command automatically assumes a 'GET' request if the request method is not specified.

Here's an example of using the controller to start jogging on the X axis at full speed.

try {
  const response = await fetch('http://192.168.12.243/api/jog', {
                        method: 'PUT',
                        body: JSON.stringify({'X': 1,'ts':Date.now()}),
                        headers: {
                        'Content-Type' : 'application/json',
                    },
  });
  if (response.ok) {
    return;
  }
} catch (e) {
}

Here's an example of how to write a file to the Buildbotics Controller.

async writeRemoteFile(data, path, fileName) {    
  let fd = new FormData();
  let blob = new Blob([data], {type: 'text/plain'});
  let file = new File([blob], fileName);
  fd.append('file', file);
  let url = path + fileName;
  await fetch(url,{method :'PUT', body: fd})
}

writeRemoteFile('this is some file content',
                'http://192.168.12.243/api/fs/Home/',
                'newfile.txt')

Conclusion

The Buildbotics API can be used by developers to do pretty much anything you want. Remember, freedom comes with responsibility. It's certainly possible to mess things up on your Buildbotics CNC Controller royally using this interface. I recommend making a backup of your MicroSD card before you start.

If you are planning to do applications development on the Buildbotics CNC Controller, please consider joining our Applications Development forum.

Introduction

This is a step-by-step procedure for creating an application for jogging your Buildbotics CNC with an Android Phone. My development system is a desktop computer running debian linux and my phone is a Pixel 8. This procedure utilizes the React Native applications development framework. Other combinations of development systems and android phones will be very similar.

Besides the phone and development system, all you'll need is a USB cable to connect your phone to your development computer.

Note - The development process for IOS phones should be similar, but I haven't tried that.

Check out my blog posting titled Introduction to the Buildbotics CNC Controller API to learn about the Buildbotics API.

Step 1 - Set up your computer for developing react-native applications.

1. Open a terminal in the folder where you want the root folder for the app to reside.
2. Ensure that node.js and npm are installed on your system

sudo apt update
sudo apt install node.js
sudo apt install npm

3. Tell npm to put commands in ~/.global/bin. This only needs to be done once for your system. Then add the .npm-global/bin to your path.

npm config set prefix '~/.npm-global'
export PATH=$PATH:~/.npm-global/bin

Then, add the following line to your .bashrc file.

export PATH=$PATH:~/.npm-global/bin

4. Download and install the command-line-tools from Android Developer Studio. In my case, I downloaded the file called android-studio-2024.2.2.15-linux.tar.gz. Then, extract the files to the Android/Sdk directory under your home directory. Then add these lines to your .bashrc file.

    export ANDROID_HOME=$HOME/Android/Sdk
    export PATH=$PATH:$ANDROID_HOME/tools:$ANDROID_HOME/tools/bin:$ANDROID_HOME/platform-tools

5. Then reload your .bashrc file to ensure your current paths are correct.

source ~/.bashrc

Step 2 - Prepare your phone

Enable developer options on your phone. In my case, I have a 'pixel 8' phone and the developer options can be enabled by going to Settings->About. Then tapping 'Build number' several times. Then, go to Settings->Developer options. I did not find a link directly to 'Developer options', but I did find it by searching for the word 'developer' in Settings. Then enable 'USB debugging'.

Step 3 - Connect your phone to your development computer.

In my case, this required a USB C to A cable. I didn't have one, so I had to go to a local store and buy one.

You may be prompted by your phone to confirm that you want to allow USB debugging.

Step 4 - Make sure the ADB server is running and sees your phone.

The Android Debugging Bridge (ADB) handles communications between your development computer and your android phone. Enter these commands from your terminal.

    adb kill-server
    adb start-server

Verify that your development computer sees your phone by running the following command from your terminal. You may be prompted by your phone to accept the request.

    adb devices

You should get a response like: '4A072DEJH001A2 device'.

If it says your device is 'unauthorized', check the phone for a prompt to authorize the connection, allow it, and run the command again.

Step 5 - Create an new project.

From the directory where you want your new project directory to reside, enter the following commands.

    npx @react-native-community/cli init Buildbotics
    cd Buildbotics

This will create a project in a directory called Buildbotics and then move into that directory.

Add the following section to the "dependencies" section in package.json file in the Buildbotics project root directory.

  "devDependencies": {
    "@react-native-community/cli": "latest"
  },

Now you have a default project built. To actually run it:

• Open a separate terminal and start the 'Metro' server.

    npx react-native start

Then, in the original terminal run this command.

    npx react-native run-android

After this command completes, the default app should appear on your phone.
The next few steps will replace the default app with the Buildbotics app.

Step 6 - Get the files for this project from github.

The files that you will need for this project can be downloaded from my Android-CNC-jogger github repository.

Step 7 - Move the files into your project directory.

1. Copy buildbotics.ts from the github directory to the Buildbotics project root directory.
2. Copy the layout.tsx file from the github directory to the Buildbotics project root directory.
3. Copy the App.tsx file from the github directory to the Buildbotics project root directory, overwriting the existing App.tsx file.
4. Copy the assets folder from the github directory to the Buildbotics project root directory.
5. Copy the AndroidManifest.xml from the github directory to the Buildbotics project root at android/app/src/main/AndroidManifest.xml overwriting the existing AndroidManifest.xml. This step tells your phone to allow cleartext communications.

Step 8 - Install a library from react-native

Run the following command to install the react-native-paper library. This library is needed to run the radio buttons at the bottom of the screen.

    npm install react-native-paper

Step 9 - Replace the app icon

It is recommended to use an icon that is 1024x1024. An image that meets this recommendation can now be found in the assets/images/icon.png directory.

You actually have to make several copies of this and place them in different folders. This is because the icon size depends on the size and model of the android phone.

I happen to have ImageMagick installed on my debian trixie and it comes with a command-line command called convert. With this, I created the following script:

convert $1 -resize 48x48 ./android/app/src/main/res/mipmap-mdpi/ic_launcher.png 
convert $1 -resize 48x48 ./android/app/src/main/res/mipmap-mdpi/ic_launcher_round.png
convert $1 -resize 72x72 ./android/app/src/main/res/mipmap-hdpi/ic_launcher.png 
convert $1 -resize 72x72 ./android/app/src/main/res/mipmap-hdpi/ic_launcher_round.png
convert $1 -resize 96x96 ./android/app/src/main/res/mipmap-xhdpi/ic_launcher.png 
convert $1 -resize 96x96 ./android/app/src/main/res/mipmap-xhdpi/ic_launcher_round.png
convert $1 -resize 144x144 ./android/app/src/main/res/mipmap-xxhdpi/ic_launcher.png 
convert $1 -resize 144x144 ./android/app/src/main/res/mipmap-xxhdpi/ic_launcher_round.png
convert $1 -resize 192x192 ./android/app/src/main/res/mipmap-xxxhdpi/ic_launcher.png 
convert $1 -resize 192x192 ./android/app/src/main/res/mipmap-xxxhdpi/ic_launcher_round.png    

Then, I saved the script as 'make_icons' in my ~/.local/bin folder which s part of my path.

Then, I ran the command from my project root dirctory like this:

    make_icons ./assets/images/icon.png

Step 10 - Start the Metro server.

The Metro server provides the web server interface for development and communicates with the app on the android phone. If it's already running, kill it and run the following command. Note, this command does not return until you kill it (^C on from the linux command line), so it's best to run it from a separate terminal window.

    npx react-native start

Step 11 - Build the app for the android.

The following command builds the app specifically for the android.

    npx react-native run-android

Step 12 - Test the app in development mode

At this point the app should be displayed on the screen of your phone. It should look like this.

Now is a good time to try it out. Just enter the IP address for your Buildbotics CNC Controller in the input field at the top of the page and press the 'Connect' button. The host name should appear and the machine state (hopefully "READY") should also appear. If so, click the big triangle buttons to jog your machine. Select the axis from the X, Y, and Z buttons at the bottom of the screen. Adjust the jogging speed with the up arrow and down arrow buttons near the top of the screen.

Step 13 - Build the app for production and disconnect from the development machine.

Run the following commands to build the production app for the android phone.

    cd android
    ./gradlew assembleRelease

Now, move back up to the Buildbotics project root directory and install the production app on your phone with the following command.

    cd ..
    adb install android/app/build/outputs/apk/release/app-release.apk

That's it! Disconnect the phone from the USB cable. There should be a new icon on your screen that has the Buildbotics logo in it. Just touch that icon when you want to run the app.

Conclusion

As you know by now, we started from a default project, added a couple of source code files, replaced an existing file, and added a few images.

The source code files are written in TypeScript which is Javascript with extensions for type checking. Check out this tutorial if you want to learn more about TypeScript.

The source files are:

• buildbotics.ts - This file contains the code for interfacing with the Buildbotics Controller. Check out my blog post titled Introduction to the Buildbotics CNC Controller API to learn more about the Buildbotics Applications Programming Interface.
• _layout.tsx - This file manages the layout and widgets that appear on the screen of the android phone.
• app.tsx - This is the main app and manages communications between buildbotics.ts and _layout.tsx

Please consider joining the buildbotics forum and contributing to the Applications Development board.

Introduction

The good people over at PwnCNC are now offering a nice Automatic Tool Changing (ATC) System, and one of my customers asked if it was compatible with the Buildbotics CNC Controller. I didn't know for sure, so I sent an e-mail to PwnCNC and they readily agreed to loan me a system so I could try it out with the Buildbotics CNC Controller.

It works great with our latest hardware (V17) and latest software (V2.0.4). This table summarizes what you can expect with earlier versions of our hardware and software.

This article describes how to integrate the PwnCNC ATC system with a Buildbotics CNC Controller that has V17 or later hardware and V2.0.4 or later software.

Overview

The Buildbotics Controller connects to the PwnCNC Pneumatic Enclosure(PE) and the PwnCNC Variable Frequency Drive(VFD) through a DB25 breakout box that is connected to the back of the Controller.

I recommend getting the ATC System running in manual mode first. Then, connect and configure the Buildbotics CNC Controller. The major steps are:

• Install the PwnCNC ATC System on your machine for manual operation.
• Connect the Buildbotics CNC Controller to the PwnCNC ATC System.
• Install the tool holders.
• Configure the Buildbotics CNC Controller.

Installing the ATC System for manual operation

Manual operation means that you can control the pneumatic chuck in the ATC spindle with a button. This makes tool changes much easier and faster, but still requires human intervention.

The PwnCNC ATC system comes with quite a few parts, and they describe them here.

PwnCNC describes how to get the system running in manual mode here.

Connect the Buildbotics CNC Controller to the PwnCNC ATC System

Both the VFD and PE connect to the BB Controller through a DB25 breakout box.
The BB Controller communicates with the VFD using a Modbus/RS-485 connection. The connector on the VFD is compatible with a 2-pin GX12 aviation plug.

Plug the modbus cable into the Modbus connector on the VFD.

Connect pin 13 (rs485a) on the DB25 breakout box to pin 1 on the VFD Modbus connector and connect pin 14 (rs485b) to pin 2 on the VFD modbus connector.

Note, it is recommended that the two RS485 wires be twisted at about 1 turn per inch to reduce noise interference.

PwnCNC provided this control cable for connecting to the PE.

They also provided this cable for extending the control cable to a another controller.

Plug the control cable into the Ctrl port on the PE and connect the extension cable to the control cable.

Connect the black wire (labeled Ground) from the extension to any of the ground wires on the DB25 breakout box. I chose pin 25.

The green wire (labeled Relay 1/Output 7) opens the air supply to the tool and dust outputs on the PE so a tool can be inserted. Connect the green wire to any unused digital output on the DB25 breakout box. I chose pin 15.

The red wire (labeled Relay 2/Output 8) opens the air supply to the addl output and can be used for other purposes. Connect the red wire to any unused digital output on the DB25 breakout box. I connected the red wire to pin 16 but am not using it in my system.

The extension has a yellow wire (labeled Drawbar/Input 7) that is connected to a red wire (labeled Power) This connection to power is not needed and you should cut the connection to the red (Power) wire, leaving the yellow wire intact.

Similarly, The extension has a white (labeled Tool Preset/Input 7) that is connected to a red wire (labeled power) This connection to power is not needed and you should cut the connection to the red (Power) wire, leaving the white wire intact.

Important! - The yellow and white wires from the PE present 24Volts DC when inactive and ground when active. If your Buildbotics Controller uses a board that is older than Version 15, a diode is required to protect the internal circuitry from the 24 Volt connection.

These connections are not absolutely required to make the ATC system and I recommend leaving them off for older Buildbotics Controllers. However, if you insist on connecting them, then connect low drop shottkey diodes (e.g. 1N4001) in line with the yellow and white wires to protect the circuits. The diode cathodes should point toward the PE.

If you don't know what version of main board your controller utilizes, you can contact Buildbotics at 707-559-8539 for that information.

You should also be aware that connecting the yellow or white wire to any pin other than a digital input will damage the Buildbotics Controller even if you have Version 15, or later, main boards.

Assuming your controller utilizes a Version 15 or later main board, then choose any unused digital input pin on the DB25 breakout board and connect the yellow wire to that pin. I chose pin 11 for the yellow wire.

Similarly, assuming your controller utilizes a Version 15 or later main board, then choose any unused digital input pin on the DB25 breakout board and connect the white wire to that pin. I chose pin 12 for the white wire.

Installing the tool holder

PwnCNC included four 3D printed tool holders with the system. I didn't want to drill holes in my table for this temporary installation, so I built this stand and screwed the 3D printed tool holders to the stand.

Then, I used workpiece hold-down clamps to hold it in place.

Configuring the Buildbotics Controller

With the system working in manual mode and all the connections intact, now is a good time to configure the Buildbotics Controller. To do this, we have to select the correct VFD, assign the digital I/O points, and tell the controller how to change tools, and how to park the last tool used at the end of a gcode program.

Selecting the VFD.

Use the following steps to select the PwnCNC VFD.

1. Go to the SETTINGS->Tool page on the Buildbotics Controller.
2. If the 'Login' button is green, click it and log in.
3. Select 'EM60' from the 'tool-type' drop-down menu.
4. Click the green 'Save' button.

If everything is working correctly, the Status field should say 'Ok' and the Failures field should not be increasing.

If the status field does not say OK or the Failures field is increasing try the following things.

1. Verify that the VFD is turned on.
2. Verify that the VFD is switched to 'Auto'.
3. Verify that the connections to the 'Modbus' connector on VFD is properly seated.
4. Verify that the pins 13 and 14 on the DB25 connector are securely connected.
5. Verify that the DB25 breakout box is plugged into the back of the Buldbotics Controller and properly seated.
6. Try reversing the connections between pin 13 and 14 on the DB25 breakout box.
7. Call Buildbotics at 707-559-8539.

After the "Status' field says 'Ok' and the Failures field has stopped increasing, you can test the interface. Here's how:

1. Navigate to the CONTROL page on the Buildbotics user interface.
2. Select the 'MDI' tab.
3. Enter M3S10000 and click play to turn the spindle clockwise at 10000 RPM.
4. Enter M4 and click play to cause the spindle to stop and go in reverse at 10000 rpm
5. Enter M5 to stop the spindle.

Configuring the digital I/O points

Follow these steps to configure the digital inputs:

1. Navigate to the SETTINGS->I/O page.
2. Find the pin that you connected to the yellow wire from the Ctrl extension cable. In my case, that is pin 11. Change the drop-down menu selection in the 'Function' column to 'input-0' and change the drop-down menu selection in the "Mode' column to 'normally-open'.
3. Find the pin that you connected to the white wire from the Ctrl extension cable. In my case, that is pin 12. Change the drop-down menu selection in the 'Function' column to 'input-1' and change the drop-down menu selection in the "Mode' column to 'normally-open'.
4. Click the green 'Save' button.

You can test this connection by using the manual tool change button to insert and remove a tool from the spindle chuck.

The icons next the the digital input pins will reflect the state of the input.

Input0 should momentarily flash from red to green when you insert or remove a tool from the spindle chuck.

Input1 should be green when a tool is in the chuck and red otherwise.

If the manual changes are working but the icons are not reflecting the correct state, check the wiring between the Buildbotics Controller and the PE.

Follow these steps to configure the digital output ports.

1. Find the pin that you connected to the green wire from the PE Ctrl cable extension. Pin 15 in my case. Then,select 'output-0' from the drop-down menu in the 'Function' column and select 'lo-hi' from the drop-down menu in the 'Mode' field.
2. Similarly, Find the pin that you connected to the red wire from the PE Ctrl cable extension. Pin 16 in my case. Then,select 'output-1' from the drop-down menu in the 'Function' column and select 'lo-hi' from the drop-down menu in the 'Mode' field.
3. Click 'Save'

Use the following steps to test the digital outputs:

1. Navigate to the CONTROL Page.
2. Select the MDI tab.
3. Enter 'M64 P0' and click play.
4. You should now get non-zero readings on the tool and dust guages on the PE and air should be blowing in the spindle.
5. Enter 'M65 P0' and click play.
6. The tool and dust guages should go to zero.
7. Enter 'M64 P1' and click play.
8. The 'addl' guage should be non-zero.
9. Enter 'M65 P1' guage should read zero again.

If the guages don't respond properly, try the following things:

1. Verify that the PE is turned on.
2. Verify that the air compressor is turned on and air is getting to the PE.
3. Look at the icons next to pins 15 and 16 on the SETTINGS->I/O page to make sure they are changing state. If not, check the configuration.
4. Check the wiring between the DB25 breakout box and the PE.

Telling the Buildbotics Controller how to change a tool

In order for the Buildbotics Controller to automatically change tools, it needs to know where each tool is located, how long the tools are, what to do when a tool change is requested, and how to park the last tool at the end of the program.

Locating your tool holders

Use the following procedure to locate your tools.

1. Clear all offsets.
2. Home your machine and do not set any offsets.
3. Use the gamepad to jog your spingle to a height where it can move to any place on the table without running into anything. For me that height, which I'll call 'zSafe', is 200mm. Record the 'absolute' position of the Z axis.
4. Use the gamepad to jog the spindle into a position directly above the tool location for your reference tool. You should center it perfectly over your tool holder. My reference tool is tool 1 and it is simply one of the ISO20 ER20 tool holders that was provided by PwnCNC with no tool. Since there is no tool, its length will be zero.
5. Jog the Z axis to a position where it can safely drop the tool into the holder using the MTC button. Record the 'absolute' position of the Z axis. For me, that height is 43mm, which I'll call 'zDrop'.
6. Jog the Z axis to a position where the you can pick up the tool from the tool holder using the MTC button. Record the 'absolute' position of the Z axis. For me, that height is 11mm, which I'll call 'zPick''.
7. For each tool, find and record the 'absolute' positions for the X and Y axes.

Measuring the length of your tools

Use this program to measure the length of each tool:

%
M70
G21
M0 (MSG, insert the reference tool and attach the probe)
F100
G91
G38.2 Z-100
#31 = #5422
G0 Z50
M0 (MSG, insert tool to be measured)
G38.2 Z-100
#32 = [#5422 - #31]
G0 Z50
M0 (DEBUG, tool length is #32 mm)
M72
%

I recommend copying this code into a text file named something like 'measure_tool.ngc', uploading that file to the BB Controller and assigning it to a Macro button.

Run the program using the following steps:

1. Put a reference tool in the chuck. (I use one of the ISO20 ER20 tool holders with no tool as a reference.)
2. Connect your height probe and place it on the CNC work surface.
3. Jog the spindle into a place above your height probe.
4. Click the tool measurement macro button.
5. Connect the ground clip on the height probe to the reference tool.
6. Wait for the controller to touch the probe and prompt you to put the tool to be measured in the chuck.
7. Put the tool to be measured into the chuck.
8. Click 'Continue'.
9. Wait for the BB Controller to probe with the tool and display the length.

The length displayed will be the difference between the reference tool and the tool to be measured, which is the information needed for each tool.

You can see this in action on my Youtube video that demonstrates the use of this tool measurement program.

Also, check out my blog article titled CNC Macro Buttons to see how to create a macro button.

Telling the controller what to do when a tool change is requested

This program will reside in the 'tool-change' box on the SETTINGS->General page, and will be executed every time an 'M6TX' gcode command is encountered.

g4 p1
(Runs on M6, tool change) 
M70
G21
#<_zSafe> = 200
#<_zDrop> = 43
#<_zPick> = 11

#<_zDust> = [#<_zPick> + 10]
#<_tool_table> = 2000 (store x location, y location, an tool length for each tool)

o<_make_tool> sub
  #[#<_tool_table> + [#1 * 3]] = #2 (x location)
  #[#<_tool_table> + [#1 * 3] + 1] = #3 (y location)
  #[#<_tool_table> + [#1 * 3] + 2] = #4 (z location)
o<_make_tool> endsub  

(tool table is arguments to _make_tool call, arguments are:)
(tool number, x park position, y park position, tool length)
o<_make_tool> call [1] [-390] [-525] [0]
o<_make_tool> call [2] [-390] [-465] [46.2]
o<_make_tool> call [3] [-390] [-405] [32.8]
o<_make_tool> call [4] [-390] [-345] [27]

M66 P1 L0
o100 if [#<_x_homed> NE 1 or #<_y_homed> NE 1 or #<_z_homed> NE 1]
	(MSG, Error: System must be homed for ATC Operation)
	M2
o100 elseif [#5399 EQ 1 AND #5400 EQ -1]
    (DEBUG, Error: Unidentified tool is in the chuck #5400)
o100 elseif [#5400 NE #<_selected_tool>]
    #<xret> = #5420
    #<yret> = #5421
    M5 (stop the tool and wait five seconds)
    G4 P5
    o101 if [#5400 NE -1]
        (park the old tool)
        G53 G0 Z#<_zSafe>
        G53 G0 X#[#<_tool_table> + [3 * #5400]]Y#[#<_tool_table> + [3 * #5400] + 1] 
        G53 G0 Z#<_zDrop>
        M64 P0
        G4 P2
        M65 P0
        G53 G0 Z#<_zSafe>
        #<new_offset> = [#5213 - #[#<_tool_table> + [3 * #5400] + 2]]
        G92 z[#<_zSafe> - #<new_offset>]
    o101 endif
    (get the new tool)
    #<t> = #<_selected_tool>
    G53 G0 Z#<_zSafe>
    G53 G0 X#[#<_tool_table> + [3 * #<t>]]Y#[#<_tool_table> + [3 * #<t>] + 1]
    G53 G0 Z#<_zDust>
    M64 P0
    F300
    G53 G1 Z#<_zPick>
    M65 P0
    G4 P2
    G53 G0 Z#<_zSafe>
    #<new_offset> = [#5213 + #[#<_tool_table> + [3 * #<_selected_tool>] + 2]]
    G92 z[#<_zSafe> - #<new_offset>]
    G0 X#<xret> Y#<yret>
o100 endif    

M6
M72

Use the following steps to modify this file with the values, tool numbers, tool locations, and tool lengths from previous steps.

1. Copy the program into a text editor so you can easily edit it.
2. Change the value for zSafe on line 5 to the value you recorded for zSafe.
3. Change the value for zDrop on line 6 to the value you recorded for zDrop.
4. Change the value for zPick on line 7 to the value you recorded for zPick.
5. For each tool starting at line 20, modify the arguments with the tool number, x location, y location and tool length. For instance the second line (line 21 in the program) for my system shows that tool 2 is located at -390mm on the X axis, -465mm on the Y axis, and has a relative length of 46.2mm.
6. Copy all the contents of the file and paste them into the 'tool-change' textbox on the SETTINGS->General page and then click 'Save'.

Parking the tool at the end of the program

I like to park the tool and move the spindle to a convenient place at the end of a gcode program because:

1. The last tool used by a program is retained by the system. However, if the controller is turned off, it loses this information. Then, if you try to run a program after turning the controller back on and the previous tool is still in the chuck, it could cause a crash. Parking the last tool at the end of the program and setting the tool to '0' avoids this problem.
2. I like to move the spindle to a position near my limit switches. This way, when I turn the controller off and back on, homing is much faster because the spindle is already close to it's home position. For me that position is Z=175, X=380, Y= -550.

The following program drops the last tool used by the program into its tool holder and parks the spindle near the homing limit switches.

(Runs on M2, program end)
M70
G21
o200 if [#5400 GT 0]
    M5 (stop the spindle and wait 5 seconds)
    G4 P5
    (park the old tool)
    G53 G0 Z#<_zSafe>
    G53 G0 X#[#<_tool_table> + [3 * #5400]]Y#[#<_tool_table> + [3 * #5400] + 1] 
    G53 G0 Z#<_zDrop>
    M64 P0
    G4 P2
    M65 P0
    G53 G0 Z#<_zSafe>
    #<new_offset> = [#5213 - #[#<_tool_table> + [3 * #5400] + 2]]
    G92 z[#<_zSafe> - #<new_offset>]
o200 endif
M6T0
#5400 = -1
(park near the limit switches)
G53 G0 Z175
G53 G0 X380 Y-550
M72
M2

Use the following steps to modify this program with your preferred park position and load it into your Buildbotics Controller.

1. Copy the program into a text editor so you can easily edit it.
2. Change the Z value on line 20 to your preferred Z axis park position.
3. Change the X and Y values on line 21 to your preferred X axis and Y axis park positions.
4. Copy and paste it into the 'program-end' textbox on the SETTINGS->General page and then click 'Save'.

Relavant links

Check out my video titled Integrating the PwnCNC Automatic Tool Changer with the Buildbotics Controller to see the system actually doing a cut.

Also check out my video titled Measuring tools for an Automatic Tool Changer using a macro button on a Buildbotics Controller to see the tool measurement macro in action.

Finally, check out my blog article titled CNC Macro Buttons to see how to create a macro button.

Read the Buildbotics Controller's API documentation on GitHub.

Macro Buttons are one of many features that set the Buildbotics CNC Controller apart from other controllers.

In a 'nutshell', you can assign any GCode program to a button that appears on the Control page. Then, the associated program will execute each time you click the button.

Assigning Macros

Click the 'Macros' button on the CONTROL Page to add, delete or modify Macro buttons.

Click the 'trash' button to remove an existing Macro button.

To add a new Macro button:

• Click the '+ Add' button.
• Select the color using the color selector.
• Assign a name in the field next to the color selector.
• Click the folder icon to select an existing GCode program.
• Click the green 'Save' button to save your work.

The new button will appear on the CONTROL page. Now each time that button is clicked, the associated program will execute.

Example

A program was created to execute 3D probing in my Probing article. Watch my probing video to see a macro button in use.

I saved that program as 3DProbeRick.gc on my local desktop computer and then uploaded it to the Buildbotics Controller via the web interface.

Then, I assigned the program to the pink Macro button shown above.

Homing allows your CNC Controller to learn about the boundaries of your CNC machine. In this article, I'll explain why it helps and how to set it up with a Buildbotics CNC Controller.

Why bother?

Honestly, homing with a Buildbotics Controller is not absolutely necessary. But it does provide two important advantages.

First, it lets the controller know the boundaries of the physical machine. This prevents running into an endstop, which can be pretty hard on your machine.

Second, once a machine is homed, you can tell it to move to some specific absolute position and that absolute position will always be at the same place on the machine. For instance, you may have a jig on your table where you like to lay down a workpiece. If the machine is homed, that location will always be at the same absolute position. Check out my article on 'Macro Buttons' to see how to make things even easier.

You may have noticed that I am using the phrase 'absolute position'. The absolute position is the position relative to the machine boundaries. The cutting position or just 'position' can be different from the absolute position if the position offsets have been adjusted. Check out my article titled 'CNC Offsets (absolute position vs cutting position)' to learn more about position offsets.

What hardware is needed for homing?

Homing relies on the ability to trigger an event when an axis reaches a known position. On the Buildbotics Controller, that event is either opening or closing a switch. These switches are known as limit switches. There are several kinds of limit switches including magnetic reed switches, optical switches, proximity switches, and mechanical lever switches. The one thing that they have in common is that they provide a state change on a pair of wires that can be detected by the controller.

I usually use magnetic reed switches like the ones shown below because:

• They are easy to install.
• They have no mechanical parts that can fail.
• They're cheap.
• They do not require power.
• The activation position seems to be very consistent.
• They never make physical contact. I can install them in a way that the magnet slides past the reed rather than running into it.

The one drawback is that they don't work very well when cutting ferrous materials.

The reed switches change state when the magnet comes into close proximity with the reed relay.

How do you connect the switch to the Buildbotics Controller?

Each limit switch gets connected to one of the digital inputs on the DB25 Breakout box. Simply pick any unused digital input pin. We'll configure the controller later.

If the limit switch is passive (non-powered), simply connect one of the wires to digital input pin and the other wire to a ground pin.

If limit switch is powered, connect the positive wire to a digital input and the ground wire to one of the ground pins.

Then plug the DB25 breakout box into the back of the Buldbotics Controller.

How to configure limit switches in the Buildbotics Controller

Limit switches are configured on the SETTINGS->I/O page on the Buildbotics Controller.

Do the following things for the digital input pin that you selected:

• Select the function from the pull-down menu in the Function column. For instance, if the switch is positioned at the maximum end of the axis served by motor port 0, then the function would be 'input-motor-0-max'
• Select the mode from the pull-down menu in the Mode column. This will be 'normally-open' if the switch is open or presents a high signal when it is not active. It will be 'normally-closed' if the switch presents a low signal or is closed when it is not active.

The icons in the State column report the current state of the switch and are really handy for troubleshooting your switch and connection.

• If the icon is green, the switch is active.
• If the icon is red, the switch is not active.
• If there is a '+' in the icon, the input is high or open.
• If there is a '-' in the icon, the input is low or closed.

You can operate the switch manually while watching the icon to make sure it's doing what you expect.

How to configure homing

Homing is configured on the SETTINGS->Motor pages.

Here's how to configure an axis for homing on the Buildbotics Controller:

1. Go to the SETTINGS->Motor page for the motor port serving the axis and login.
2. Set the absolute position of the minimum and maximum soft limits for the axis. The image above is the configuration for my X axis. It has 830 mm of available travel and I like to set the absolute position right in the middle. As a result, I have set the lower soft limit to -415mm and the upper soft limit to +415mm.
3. If you mounted your limit switch at the maximum end of the axis, set the homing-mode to 'switch-max'. Or, if you mounted the limit switch at the minimum end of your axis, set it to 'switch-min'. My switch is at the maximum end, so it is set to 'switch-max'.
4. Set the 'search-velocity' to the speed at which the machine will search for the switch. If it's too fast, it may may not be able to stop in time and damage your machine. If it's too slow, it will take a long time to find the switch. I have my X-axis set to search at 2 meters per minute.
5. Once the switch changes state, the machine will back off by the distance assigned in the 'latch-backoff' field. My X-axis is set to back off my 15mm once the switch is found. This allows the switch to change back to it's inactive state before approaching again.
6. The 'latch-velocity' sets the speed at which the axis will approach the switch again. This slower speed will provide a more repeatable position where the switch activates. My X-axis is set to .5 meters per minute.
7. Set 'zero-backoff' to the distance that the axis backs away from the switch after the homing sequence is complete.

When the homing sequence is complete, it will set the absolute position to the position defined in the soft limit. If the 'homing-mode' is 'switch-max', the absolute position will be set to the 'max-soft-limit' value. If the 'homing-mode' is 'switch-min', the absolute position will be set to the 'min-soft-limit' value. My X-axis is set to 'switch-max', so it comes to rest at the right end of my axis at an absolute position of +415mm.

How to home the machine

The homing buttons are located on the CONTROL page at the right side of the 'axis table'. Each axis can be homed individually by clicking the 'Home' button for that axis. Clicking the 'Home All' button initiates the homing sequence on all axes.

Summary

Homing teaches the Controller where the boundaries of the physical machine are located. This provides the following advantages:

• Since the controller knows where the boundaries are located, it can prevent crashing into the endstops.
• Commonly used locations on your machine will always be located in the same absolute position. This allows you to return to that exact position from any location after homing, even if the contoller is rebooted. Check out my article on 'Macro Buttons' to see how to make things even easier.

CNC machines 'probe' to find the workpiece and then set the Offsets accordingly. Probing is controlled using G-Code commands on the Buildbotics CNC Controller.

The most common use of probing is to adjust the offset for the z-axis after a bit is changed. This allows changing bits during the execution of a single GCode program.

This article describes how to use probing on a Buildbotics CNC Controller but the concepts are also applicable to most other controllers.

Also, check out my video on 3D Probing.

What is a CNC probe?

A probe is a simple device that provides a state change on a pair of wires when it comes in contact with the bit on your CNC machine. All you really need is a metal plate with a known height that has two wires connected. I use one like the one shown below, but it wouldn't be hard to make your own. These probes are readily available for just a few dollars.

How to connect the probe to your controller

Simply connect the wire that attaches to the metal plate to one of the digital inputs on the Buildbotics Controller and connect the other wire to one of the ground leads on the Buildbotics Controller. Both connections are made through the DB25 breakout box that comes with the controller.

How to configure the probe.

Go to the SETTINGS->I/O page to configure the input pin that you selected for the probe. Pin 22 is used in the image below. Set the function for the pin to 'input-probe'. Then, set the Mode to 'normally-open'. Click the green 'Save' button to save your work.

The icons in the State column report the current state of the input and are really handy for troubleshooting your probe and connections.

• If the icon is green with a '-' sign, the probe plate is touching the ground connection.
• If the icon is red with a '+' sign, probe plate is not touching the ground connection.

How to use it

The probe provides a known height that allows you to determine height of the tip of the bit. For instance, my probe plate is 3/4" (19.05mm) tall. If the bit is just touching the probe plate then it is 19.05 mm above the top surface of the workpiece. I always set up my GCode designs so that the top surface of the workpiece is set to 0. So, all I have to do is set the height to 19.05mm when the probe touches the workpiece.

Start by connecting the probe to the controller, placing the probe plate on the top surface of the workpiece, and moving the tool to a place just above the probe plate.

Issue the following GCode commands to use metric units and set the speed at which the tool will approach the probe.

G21 (use metric units)
F100 (sets the feed rate to 100 mm/minute)

Then, issue the following command to tell the controller to move down towards the probe and stop when contact is made or fail if it moves down by 100mm without making contact.

G38.2 Z-100 

Then, use the following command to set the Z-axis position to 19.05mm.

G92 Z19.05

You can do these commands manually with from the MDI interface on the CONTROL page on the Buildbotics Controller, or you could put these commands into a Macro button.

Automating the process

Lumping the GCode commands into a macro provides some convenience, but it still does not allow you to change bits while running a GCode program. You could issue the commands from within the GCode program, but the Buildbotics Controller provides a better way.

You can configure the Buildbotics Controller to automatically issue a block of commands every time a tool change is encountered. Simply enter the required commands into the 'tool-change' text box on the SETTINGS->General page.

M70 (save the current machine state. (e.g. feed rate and units)
G21 (metric units)
G90 (set the machine to "absolute distance mode")
G0Z50 (raise the spindle to a height that makes it easy to change the bit)
G0 X-50Y-50 (make a rapid move to a good place to sit the probe plate)
M0 (MSG, Change bit and attach probe) (prompt the user to change the bit and attach the probe)
G91 (put the machine in "incremental distance mode")
F100 (set the feed rate to a slow speed for probing)
G38.2 Z-100 (probe down until the plate is touched or until Z has moved by -100mm)
G92 Z19.05 (set the Z axis to the height of the probe plate)
G90 (set the machine to "absolute distance mode")
G0 Z50 (raise the Z axis to a safe height where it is easy to remove the probe.)
M0 (MSG, Remove the probe) (prompt the user to remove the probe)
M72 (recover the original machine state(e.g. feed rate, distance mode, and units))

(to use this program, simple place the probe plate on the front, left corner of the workpiece)
( and move the bit over the circle at about 1" above the plate, then run the program)

(All dimensions should be entered in millimeters)

#<_x_outer_dim> = 63.18 (Change to the outer size of the probe plate in the x direction)
#<_x_inner_dim> = 53.92 (Change to the size of the inset part probe plate in the x direction)
#<_y_outer_dim> = 63.28 (Change to the outer size of the probe plate in the y direction)
#<_y_inner_dim> = 54.34 (Change to the size of the inset part probe plate in the y direction)
#<_height> = 18.88 (change to the overall height of the probe plate)
#<_inset_height> = 14.9 (change to the height of the inset part of the probe plate)
#<_circle_x> = 10 (change to the approximate circle x position on the probe plate)
#<_circle_y> = 10 (change to the approximate circle y position on the probe plate)

M70 (push state)
G21 (Change to metric units)
M5 (stop the spindle)

(prompt the user to attach probe and confirm that it is over the circle)
M0 (MSG, Attach probe and confirm that the center of the bit is over the circle)

G92 X0Y0Z0 (set all offset positions to 0)
F100 (set the feed rate to 100 mm/min)

(the next set of commands determine z height)
G38.2 G91 Z-100 (probe z by as much as 100 mm)
G92 Z[#<_inset_height>] (set z-axis to the height of the probe)

(the next set of commands determine the radius of the bit)
G0 G90 Z[#<_inset_height> + 10] (raise z to 10 mm above the top of the probe plate)
G0 G91 X[#<_x_outer_dim> - #<_circle_x> + 20] (rapid x to approximately 20mm past the right side of the probe)
G1 G90 Z[#<_inset_height> - 5] (move to 5mm below the top surface of the probe plate)
M0 (MSG, align flute for x probe)
G38.2 G91 X-25 (probe by up to 25mm to the left to find the right edge of the probe plate)
#<_right_side> = [#<_x>]
G0 G91 X1 (back off by one mm)
G0 G90 Z[#<_inset_height> + 10] (rapid to safe height)
G0 G91 X[-1 - #<_x_outer_dim> - 20] (rapid to the 20 mm past the left edge of the probe plate)
G1 G90 Z[#<_inset_height> - 5] (move to 5mm below the top surface of the probe plate)
M0 (MSG, align flutes for x probe)
G38.2 G91 X25 (probe by up to 25mm to the right to find the for left edge of the probe plate)
#<_left_side> = [#<_x>]
#<_diameter> = [#<_right_side> - #<_left_side> - #<_x_outer_dim>]
#<_radius> = [#<_diameter> / 2]

(now set the x postion to be 0 - 'x outer dimension - x inner dimension' - radius)
G92 X[0 - #<_x_outer_dim> + #<_x_inner_dim> - #<_radius>]

(next set of commands probe y and set y position)
G0 G91 X-1 (back away by one mm)
G0 G90 Z[#<_inset_height> + 10] (rapid to safe height)
G0 G91 X[1 + #<_radius> + #<_circle_x>] Y[-#<_circle_y> - 20] (rapid to the circle x pos and 20 mm below the lower y edge)
G1 G90 Z[#<_inset_height> - 5] (move to 5mm below the top surface of the probe plate)
M0 (MSG, align flutes on [#<_radius>] bit for y probe)
G38.2 G91 Y25 (probe by up to 25mm to back to find the front edge of the probe plate)

(now set the y postion to be 0 - 'y outer dimension - y inner dimension' - radius)
G92 Y[0 - #<_y_outer_dim> + #<_y_inner_dim> - #<_radius>]
G0 G91 Y-1 ( back away by one mm)
G0 G90 Z[#<_inset_height> + 10] (rapid to safe height)
G0 X0 Y0(move to the front left corner of the workpiece)
M0 (MSG, Remove probe)
M72

After the Buildbotics CNC Controller is booted, it simply assumes that the cutting head is located at the origin (all axis positions are set to zero). Homing the machine leaves the axes near their limit switches at known positions. Check out my article titled 'Homing your CNC machine' to learn all about homing the Buildbotics Controller.

This is all great, but the CAD programs typically define the origin as a location on the workpiece. It's pretty safe to say that the GCode origin is different from the machine origin. That's where offsets come into play.

After homing, my machine thinks the origin is in the center of the table. The picture below shows that the machine origin is in the center of the machine but I laid the workpiece down near the front right side of the machine.

The GCode program expects the origin to be at the top, left, front corner of my workpiece.

The goal is to adjust the offsets such that the machine origin is in the same place as the GCode origin.

One way is to jog the machine into position with the game pad and then set the offsets.

As you jog the tool around, you will notice that the 'Position' and 'Absolute' fields remain equal to each other and the Offset fields remain at zero. The next picture shows my display after jogging to the gcode origin.

Now, click the top Zero offset button to set the current positions to zero. The picture below shows that the offsets have been set. Notice 'Absolute' remains the same but Position is now all zeros and Offset shows the difference between the two.

Summary

This article shows a brute force method of setting the offsets. It works pretty well until you need to change bits in the middle of a program.

This method requires that you take control of the machine to set the offsets. Many GCode programs require tool changes in the middle of the program and unless you have an automatic tool changer, the bit position is likely to be different each time you change it. In the method shown, you would have to run individual programs each time you want to use a different bit.

This problem is solved by initiating a probing sequence after each tool change. Check out my article titled 'Probing to set CNC offsets' and my 3D probing video.

Introduction

This article describes how I set up a rotary axis on my homemade CNC machine. This article describes the setup using my Buildbotics CNC Controller, but the concepts should be applicable to most other CNC controllers.

Check out my youtube video that shows my first cut with this rotary axis.

Setting up the hardware

When I built my CNC Machine, I set up the Z axis with 10 inches of movement. I eventually wanted to add a rotary axis and figured I needed this extra space so I could place the rotary hardware on the table and raise Z high enough to get the spindle over the work piece.

Then, I bought this rotary axis set off of Amazon. It came with a 100 mm, 4-jaw chuck.

I finally got around to setting it up on my machine, and here's the result.

The hardware set up was pretty easy. I rewired the Y-axis motors in parallel and connected them to the Motor port 1. This freed up Motor port 3 so I could assign it to the A axis for rotary motion. I had to reduce the top speed on my Y axis a bit to prevent stalling, but rapid moves are still 300 inches per minute.

Configuring the rotary axis

Configuring the rotary axis was a bit more difficult. The axis had to be configured for linear movement in either millimeters or inches, but the axis actually turned. I figured that I needed to calibrate such that a move given in millimeters would actually travel that far in degrees.

The rotary hardware actually turns the chuck one revolution for every six revolutions of the motor. So, I reasoned that if I set the travel-per-revolution to 60 mm, it would work. And it did! Now, I could give it a command like "G0A90" and the chuck would turn by 90 degrees.

Unfortunately, this setup had two major problems:

1. Switching to Imperial units caused the turning distances to be off by a factor of 25.4. For instance, a command like "G0A360" would cause the chuck to turn by 25.4 revolutions. This meant that I would have to reconfigure the axis everytime I switched between Metric and Imperial units.
2. The feed rates are based on linear travel distance, but the rotary axis traveled in degrees. As a result, the feed rates were incorrect unless the cutting point was exactly 57.3 mm from the center of rotation

A better solution is to treat the axis as if it were a linear axis and set a 'sensible' travel distance for one revolution of the motor. This method provides the correct cutting distance as long as the cutting point is at a specific distance from the center of rotation. Here's how I did it:

1. I decided that the travel distance for one rotation of the chuck would be 10 inches.
2. Since the motor rotates six times for each rotation of the chuck, the travel-per-revoltion would be 10 / 6 = 1.667 inches.
3. I like to configure my machine in metric units so I converted 1.667 inches to 42.33 mm and entered that value into the travel-per-rev field on the Settings->Motor page for my rotary axis.

This distance is correct as long as the cutting point is 1.59 inches from the center of rotation. If the cutting point moves in or out significantly from 1.59 inches, the cutting speed may be off far enough to negatively impact the quality of the cut.

You may want to change the feed rate in your gcode program to compensate for this problem, but be careful because changing the feed rate changes the cutting speed along both axes while the distances are only changing along the rotary axis.

If your CAD software is sophisticated enough, it may be able to calculate and adjust the feed rate for each line segment so that a constant cutting speed is maintained.

In the worst case, you may need to break your project into separate cuts and adjust the travel-per-revolution of the rotary axis between those cuts.

Setting up the origin

In reality, I could move the rotary axis around on my machine, but it is kind of a pain to set it up and move it around. Once I found a good spot, I made some adjustments in the configuration that allow me to set offsets for my cutting origin and then go there at the beginning of each cut.

This works great as long as the machine is homed before you start your program.

On the Buildbotics Controller, this is done in the "program-start" textbox on the "SETTINGS->General" page.

The "G53G0Z100" command tells the machine to ignore existing offsets and move in machine coordinates while raising the Z axis to 100 mm.

The "G53G0X-200A-491" tells the machine to use machine coordinates and move to X=-200mm and A=-491.7 mm. Note that A is actually my linear axis that moves the gantry forward and backward on my machine. The rotary axis is Y. This move puts the tool directly above the center and near the left end of the work piece.

The "G92X0Y0A0" command tells the machine that the current location is the origin for the X, Y, and A axes.

Setting up Z-Axis probing

If you want to change tools during a cut, you will need the ability to probe to adjust the Z-axis offset for each tool that you use.

Probing is set up in the "tool-change" textbox on the "SETTINGS->General" page.

This picture shows the part of the tool change procedure that is automatically inserted into the gcode program every time a tool change is encountered.

The "G0Z100" command tells the Z-axis to move to 100mm to ensure a safe move to the probing location.

The "G0X-140A0" moves the tool to a place directly above the tail-stock housing.

The "G38.2 Z-54" command tells the controller to move down along the Z axis until the probe is tripped or it reaches the minimum soft limit at -54mm.

After the probe is tripped, the "G92 Z47.05" sets the Z axis to 47.05mm.

The Z axis is set to 47.05 mm because the top of the tail-stock housing is 28 mm above the center of rotation and the probe is 19.05 mm (.75 inches) high. 28 + 19.05 = 47.05 mm.

Check out this thread on the Buldbotics Forum for more information on probing.

Be sure to check out my youtube video that shows my first cut using the rotary axis.

These are unpaid independent reviews of the Buildbotics controller.

• July 2021 - Mellow Pine
• November 2021 - Mellow Pine
• August 2017 - Hackster.io

When you first get started with your CNC you will probably try cutting a few preexisting GCodes but soon you will want to make your own.  The first step in that process is to create a drawing using a CAD or drawing software such as LibreCAD (2D) or Inkscape (2D).  There are many guides online explaining how to install and use these programs.

Once you have a drawing saved in DXF format you will need to convert it to GCode using CAM software.  You can use commercial programs such as Fusion360 or MasterCAM but there are also free and Open-Source solutions such as CAMotics, Inkscape's gcodetools plugin and pyCAM.  In this guide, we will focus on using CAMotics and TPL.  A quick Internet search will yield guides on using other software.

Using CAMotics and TPL

CAMotics is a free and Open-Source CNC simulation software. It supports a CNC programming system called TPL (Tool Path Language) that makes it much easier to create GCode.

If have experience with JavaScript or similar programing languages then TPL will be very easy to learn. If you have no programming experience, then you can use this guide to cut-and-paste the simple TPL program presented here and make small changes to convert your own DXF files.

Once you've installed CAMotics, try out some of the examples by selecting them from the File menu. The "CAMotics" and "Buildbotics" examples both use DXF files and TPL. Try changing the tool or workpiece options and rerunning the simulation to see how it changes.

Here we will look at the "Buildbotics" example in detail. Double click on buildbotics_logo.tpl from the left hand side of CAMotics to view the program. The complete program looks something like this:

var dxf = require('dxf');
var layers = dxf.open('buildbotics_logo.dxf');

var zSafe = 3;
var cutDepth = -1.5;

units(METRIC); // This must match the units of the DXF file
feed(1600);
speed(10000);
tool(2);

rapid({z: zSafe});

dxf.cut_layer_offset(layers.Inside,  -0.5, zSafe, cutDepth);
dxf.cut_layer_offset(layers.Tools,    0.5, zSafe, cutDepth);
dxf.cut_layer_offset(layers.Head,     0.5, zSafe, cutDepth);
dxf.cut_layer_offset(layers.Ears,    -0.5, zSafe, cutDepth);
dxf.cut_layer_offset(layers.Eyes,    -0.5, zSafe, cutDepth * 0.66);
dxf.cut_layer_offset(layers.Pupils,  -1.2, zSafe, cutDepth * 0.66);
dxf.cut_layer_offset(layers.Outline,    0, zSafe, cutDepth);

rapid({z: zSafe});
speed(0);
rapid(40, 75);

Let's break it down.

var dxf = require('dxf');
var layers = dxf.open('buildbotics_logo.dxf');

The first two lines load in the DXF library and read in the DXF file. Change the filename to read in a different file. The DXF file should be in the same directory as the TPL file. The variable layers now holds the DXF data.

var zSafe = 3;
var cutDepth = -1.5;

Next we set a couple more variables that will be used below. zSafe is the height above the workpiece where the tool can safely make rapid moves. cutDepth is how deep we will be cutting into the material.

units(METRIC); // This must match the units of the DXF file
feed(1600);
speed(10000);
tool(2);

Now we set the units mode to metric. You could also set it to IMPERIAL to use inches instead of millimeters. The feed rate is set to 1600 mm/min, the spindle speed to 10k RPM and tool 2 is selected. These are just examples, you must choose appropriate values for your machine, material and tool.

rapid({z: zSafe});

Move the tool up to the safe height specified above.

dxf.cut_layer_offset(layers.Inside,  -0.5, zSafe, cutDepth);
dxf.cut_layer_offset(layers.Tools,    0.5, zSafe, cutDepth);
dxf.cut_layer_offset(layers.Head,     0.5, zSafe, cutDepth);
dxf.cut_layer_offset(layers.Ears,    -0.5, zSafe, cutDepth);
dxf.cut_layer_offset(layers.Eyes,    -0.5, zSafe, cutDepth * 0.66);
dxf.cut_layer_offset(layers.Pupils,  -1.2, zSafe, cutDepth * 0.66);
dxf.cut_layer_offset(layers.Outline,    0, zSafe, cutDepth);

Here we cut each of the DXF layers using dxf.cut_layer_offset(). The three paramters passed to dxf.cut_layer_offset() are layer, offset, z-safe and cut depth.

The layer is the DXF layer. DXF layers can be selected by name or by number. DXF layers are named in the CAD software. Your DXF may only have one layer. In that case, it is easer to cut the single layer like this:

dxf.cut_layer_offset(layers[0], 0, zSafe, cutDepth);

The offset offsets the tool position from the DXF path. A positive offset will cut outside of the path. For example, you might want to offset by half the tool diameter. A negative value will cut inside the path and zero will cut exactly on the path.

rapid({z: zSafe});
speed(0);
rapid(40, 75);

Finally, we move back up to the safe height, turn off the spindle and move to a position out of the way.

One of the first things you will want to do with your Buildbotics CNC controller is connect it to your network.  For many people, this means connecting to WiFi.  To do so you must configure the controller's WiFi settings.

There are two ways to access the controller's WiFi settings.  Either temporarily connect the controller to a wired network or boot the controller with a monitor, mouse and keyboard connected.  Each of these methods is described in detail below.

Method 1: Using a wired network

If you plug the Buildbotics controller directly into a wired network, the network should automatically assign the controller an IP address.  You can then use that IP address to access the controller from another computer on the same network.  Here's how:

1. Plug in the controller's power supply.
2. Plug an Ethernet cable in to the back of the controller
3. Plug the other end of the Ethernet cable in to your router or network wall socket.
4. Plug the Gamepad into one of the controller's USB ports.
5. Switch the controller on.
6. Wait for it to boot.
7. Press the right arrow on the Gamepad until you see the network page on the LCD screen.

8. On another computer navigate to http:// followed by the IP address shown on the LCD screen.

For example, you might enter http://192.168.0.2 in your browser.  Once you've reached the Buildbotics controller's Web interface, you can move on to configuring the WiFi.

Method 2: Connect a Monitor, Mouse and Keyboard

The Buildbotics controller has a built-in computer which you can use to control your CNC directly.  You will need the following:

1. A monitor with HDMI cable.
2. A USB mouse.
3. A USB keyboard.

If your monitor is a touch screen you may be able to forgo the mouse and keyboard.

Connect the monitor, mouse, keyboard and the controller's power supply.  Turn the controller on and wait for it to boot.  As it starts up you should see the Buildbotics logo.  Once it is fully booted you can move on to configuring the WiFi.

Configuring the WiFi

Once you've gained access to the controller's Web interface using one of the methods described above you are ready to configure the WiFi settings.

To setup the WiFi:

1. Click on the ADMIN -> General tab from the menu on the left.
2. Set the WiFi mode to Client.
3. Set your WiFi network's SSID or name.
4. Set your WiFi network's password.
5. Click the blue Set button.
6. Click the green Ok button to reboot the controller.
7. Wait for it to fully reboot.

Accessing the Buildbotics controller over WiFi

Once you've saved the controller's WiFi settings and allowed it to reboot you should be able to access the controller over WiFi.  If you used a wired network to configure the controller, you should unplug the Ethernet cable now.

As described in method 1 above, use the Gamepad to locate the new IP address on the LCD screen.  It will be different from the wired network IP.  Enter http:// followed by the IP in another computer on the network to access the controller remotely.

Troubleshooting

Here are some common problems and their solutions.  Please feel free to contact us if you cannot resolve your problem.

Problem: Network connects and disconnects.

The Buildbotics controller's built-in WiFi is not particularly strong.  If your WiFi network's signal is weak or there are a lot of other wireless devices in the area it may be difficult to keep the controller connected.  A wired network connection will be more reliable but if you must use WiFi you can add a USB WiFi dongle with an antenna to boost your signal strength.  There are many good inexpensive WiFi adapters available online.

Problem: No IP address on the LCD screen.

First make sure you are on the LCD screens network page by pressing the right arrow on the Gamepad.  If the screen does not change, make sure the Gamepad is plugged in and you are pressing the right button.

If there is no IP address on the Buildbotics LCD screen on its network page, then it is either not connected to a network or the network is not assigning the controller an IP address.  Check the network connections or the WiFi settings.  It that fails, check your local network's configuration.

Problem: The IP address will not load in the browser

Make sure you type a full address such as http://192.168.0.2  If it still does not work, then the computer you are using may not be on the same network as the Buildbotics controller.  The remote computer must be on the same network.

Problem: The controller shows more than one IP address

Your controller may get assigned more than one IP address if it is connected both to the WiFi and to a wired network.  This may also occur if you are using a WiFi dongle to boost your signal.  You can disconnect the other networks and restart the controller or try each IP address until one works.

A VFD or Variable Frequency Drive is a type of motor driver often used to control high speed CNC spindles. The VFD converts AC line voltage to higher voltages and frequencies.  The VFD varies the output frequency to control motor speed.  Using a VFD smart controller, like the Buildbotics CNC controller, you can control spindle speed and direction using GCode and get feedback indicating actual speed in real-time.

You may also be interested in PWM spindle control.

RS485 VFD Control

Most VFDs support remote control using the two wire RS485 digital interface. This allows a smart CNC controller to command the VFD's speed and direction and read back actual speed and status information while the VFD is running.  Most also use a protocol called Modbus when communicating over RS485.  Unfortunately, compatibility ends here because each VFD vendor uses a different set of Modbus commands.

Fortunately, the Buildbotics CNC controller has built-in configurations to handle many common VFDs and makes it possible to create custom configurations to support new ones.

Supported VFDs

Any VFD that supports Modbus can be used with the Buildbotics controller. However, some VFDs have out-of-the-box support and others require custom programming. At the time of this writing the following VFDs are supported out-of-the-box:

• Huanyang
• AC-Tech
• Nowforever
• Delta VFD015M21A (Beta)
• YL600, YL620, YL620-A (Beta)
• FR-D700 (Beta)

VFDs marked as beta have had limited testing.  If you need help with one of these VFDs or would like to create a custom configuration for a new VFD, don't hesitate to contact us.  We will be glad to help decipher the VFD's manual and are eager to add support for more VFDs.

RS485 Wiring

Only two wires are needed to make the RS485 connection. To reduce electrical noise it is best to keep the wires short and to use a shielded twisted pair such as one of the pairs found in a CAT5  network cable.

First, disconnect all power.  Then, make the following connections on the Buildbotics controller I/O breakout box.

You can connect either wire to RS485 A or B; the Buildbotics controller will automatically discover which is which. Consult the VFD's manual for the correct connection points on the VFD.  Be sure not to connect the RS485 wires to any of the high voltage lines with in the VFD.

Buildbotics Controller Configuration

To configure the Buildbotics controller to talk to the VFD go to the TOOL page on the Web interface and configure the following sections:

Tool Configuration

tool-type

Select one of the built-in VFD configurations or "Custom Modbus VFD" to design your own VFD control commands.

tool-reversed

Check this box if your spindle turns the wrong direction.  Most tools require clockwise rotation. That is clockwise if you are looking down from above the spindle towards the workpiece.  Spinning the tool in the wrong direction can cause major problems so double check it before you cut anything.

max-spin & min-spin

Maximum and minimum spindle speed in RPM (Revolutions per Minute).  Check your VFD's manual to determine the correct values for your spindle.  A typical maximum RPM is 10k to 24k.

tool-enable-mode & tool-direction-mode

These options are not normally needed for RS485 VFD control.  Set them disabled.

Modbus Configuration

There are a number of configuration options on the Buildbotics controller that are common to all VFDs.  These options must match the settings applied in the VFD's configuration.

bus-id

This is the Modbus ID.  It is used to identify multiple Modbus devices on the same RS485 network.  Typically there is only one device so bus ID 1 is a good choice.  It just has to match the setting in the VFD.

baud

This is the speed of the RS485 communication in bits per second.  It is tempting to use higher baud rates but this only increases the likelihood of errors due electrical noise.  The spindle control signals are very brief and even at 9600 baud it is already very fast.  For example, a typical command and response consists of 176 bits of data. At 9600 baud that takes about 1/50th of a second.

parity

The parity bit is an extra bit that is used to help detect communication errors. The Modbus protocol already has it's own error checking so parity is generally set to none. However, it must match the setting in the VFD.

Configuring the VFD

You must configure the VFD for your spindle and enable Modbus communication. If you select one of the preconfigured VFDs, a "Notes" section will appear at the bottom of the page showing the necessary VFD settings.

The configuration process varies for each VFD so consult its manual for details.  It usually consists of using the arrow and enter keys on the VFD's front panel to select an address and then set its value.  This is repeated for each setting until all the necessary settings are configured.

Here are the most common VFD settings needed for Modbus communication:

• Enable RS485 Modbus communication in RTU mode.
• Select 9600 baud.
• Select no parity, 8 data bits and 2 stop bits.
• Set the Modbus slave ID to 1 or whatever you set bus-id to.
• Select Modbus as the start/stop controller and remote frequency source.

You will also need to set the correct frequency, output voltage and min and max RPM for your spindle in the VFD's configuration.

Testing the Connection

With the RS485 wiring complete and the Buildbotics controller and VFD configured, it's time to test the connection.  Test with the spindle disconnected from the VFD until you're sure the VFD is operating correctly.

To start the VFD in the clockwise direction go to the CONTROL page on the Buildbotics controller, select the "MDI" tab, then run the following GCode command:

M3 S1000

Return the the TOOL page to check the Modbus status.  The VFD's front panel may also indicate if it is operating.

Increase the speed with:

S5000

Reverse the direction with:

M4

Stop the VFD by clicking the stop button or with:

M5

Once everything appears to be working correctly, disconnect the power, connect the spindle, power it up and try it again for real. Be sure to check that the spindle turns in the correct direction.

Troubleshooting

VFD fails to operate

Check the following:

• Both RS485 wires are solidly connected to both the Buildbotics controller and the correct connection points on the VFD.
• The following settings match on both the Buildbotics controller and VFD:
  • Modbus ID
  • RS485 baud rate
  • RS485 data bits, parity and stop bits
• The VFD is in Modbus RTU mode. Not ASCII mode.
• RS485 Modbus is the source for start/stop and frequency control on the VFD.
• The VFD can be operated manually through its front panel.

Spindle runs in reverse

If an M3 causes the spindle to turn counter-clockwise you can either correct the configuration in the VFD or set the tool-reversed option on the Buildbotics controller.

Spindle runs at wrong speed

Check that:

• max-spin is correct on the Buildbotics controller.
• The maximum frequency is set correctly on the VFD.
• The VFD program uses either max-freq-read or max-freq-fixed to get the VFD maximum frequency.
• Make sure the VFD output frequency is correct for your spindle motor.

Spindle does not turn a low speeds

Many VFDs will not turn or have very weak torque below a certain speed.

Creating a Custom VFD Program

If there are no preexisting configurations for your VFD but you have the VFD's manual or datasheet, it's time to create a custom VFD control program.  For testing a new VFD program, the VFD must be powered on but you should not connect the spindle until the program appears to be correct.  Incorrect programming could permanently damage your VFD or spindle. Read the VFD manual carefully!

On the TOOL configuration page set tool-type to "Custom Modbus VFD". Then scroll down and begin adding VFD commands.  To add a new VFD command:

• Select the command type using the drop down menu.
• Set the address specified in the VFD's manual.
• For write operations, set the value according the the manual.

Modbus Addresses

The manual may show the addresses or values in hexadecimal so be sure to convert to decimal.

Sometimes the Modbus addresses appear in two parts.  For example: P01.05. Usually, this corresponds to a high and low byte.  In this case the address in decimal is computed as:

address = high_byte x 256 + low_byte

So for P01.05 we have:

1 x 256 + 5 = 261

Modbus Control Flow

Modbus commands are executed according to the above state diagram.  Repeated commands are executed in the order they appear. Click the green "Save" button for the commands to take affect.

Monitor the Modbus status and Active Modbus Configuration failures to see how the program progresses.  If you see failures counting up on a command that means it is failing.  The Modbus control flow is restarted after any failure.  If the very first command fails it may indicate that the communication settings don't match the VFD or the RS485 connection is wired incorrectly.

Modbus Commands

The following table defines all of the Modbus commands used to create VFD configurations with the Buildbotics controller:

Write commands write their value to the specified address.  Read commands read from the specified address and do not require a value.  Constant commands do not require an address but do require a value.

connect-write

These commands are executed once whenever the Buildbotics controller connects to the VFD.  connect-write commands are used to perform any necessary initialization.  You can enter more than one connect-write command or none at all.  They will be executed in order.

max-freq-read & max-freq-fixed

Get the maximum frequency used by the VFD. Rather than report speed, VFDs usually report the current frequency.  The Buildbotics controller needs the maximum frequency to calculate the speed.

max-freq-read reads the maximum frequency from a register in the VFD as an unsigned 16-bit integer.  max-freq-fixed does not actually query the VFD but sets a fixed value for the maximum frequency. It must match the value programmed in the VFD.

freq-set & freq-signed-set

Set the VFD's target frequency and indirectly the spindle speed. Use freq-set for VFDs that used an unsigned frequency and a separate direction setting. freq-signed-set is for VFDs which equate negative frequencies with reverse spin.

stop-write, forward-write & reverse-write

Stop the spindle or command it to spin forward or in reverse. These commands are not always required. Some VFDs use a frequency of zero for stop, positive frequency for forward and negative for reverse.

freq-read, freq-signed-read & freq-actech-read

While the VFD is running the Buildbotics controller will repeatedly read the VFD's output frequency to determine the actual spindle speed. Most VFDs use freq-read to read an unsigned 16-bit integer value, a few use freq-signed-read to read a signed 16-bit integer and ACTech VFDs use freq-actech-read to do a special multi-read.

In order to compute the spindle's actual speed, max-rpm must be set correctly and either max-freq-read or max-freq-fixed must be used to get or set the maximum frequency.  Spindle speed is calculated as:

speed = frequency / max-frequency * max-rpm

status-read

Some VFDs require regular communication to keep the connection from timing out and the VFD from automatically turning itself off.  The status-read command can be used as a heartbeat signal.  The returned value is recorded and reported on the TOOL page and in the "indicators" tab on the CONTROL page but is otherwise unused.

disconnect-write

It is not usually necessary but if there are any commands that need to be run before the VFD is disabled they can be entered as disconnect-write commands.

Sharing A New Custom VFD Program

If you have successfully created a new VFD program or need help with one you're working on, email us your controller configuration file using the following procedure:

• Click the "Save" button in the Buildbotics controller's Web interface.
• On the ADMIN page click "Backup" under the "Configuration" heading.
• Download the configuration file to your computer.
• Attach the configuration file to an email.