Documentation Reference
Sender software with the Twinwright controller
This page is for people who want to drive the MC-1 from a G-code sender of their own (bCNC, gSender or Universal G-code Sender) instead of from Studio. The MC-1's controller is the Twinwright controller (kernel), compatible with the Grbl 1.1 serial protocol and the extensions current senders use, so these senders work with it, with the few settings and caveats below.
Everything here was tested on the MC-1 digital twin, which runs the same controller code as the machine. Checking it on a real machine is still to come. Tested versions: bCNC 0.9.16, gSender 1.6.4, UGS Platform 2.1.27.
Connect
| Where | How |
|---|---|
| The twin in Studio's window | Studio takes one sender at a time on localhost:2323 (this computer only; start Studio with --bind any to reach it from the network). bCNC: port socket://localhost:2323. gSender: Ethernet, address 127.0.0.1, port 2323. UGS: tcp://localhost:2323. |
| The MC-1 itself | Native USB: the controller shows up as a serial port (COM*n* on Windows). Pick that port. The baud rate does not matter on native USB, but some senders want one: 115200 works. |
What the controller says about itself:
- Its welcome line is
Grbl 1.1f ['$' or '$HELP' for help], like a classic Grbl controller. Senders look for a welcome line that starts with "Grbl" to notice that the controller restarted (see section 3). - Its name is in the answer to
$I:[VER:Twinwright 1.1f.…]and[FIRMWARE:Twinwright]. Senders that show the firmware show "Twinwright".
Pick the firmware in the sender
| Sender | Setting | Why |
|---|---|---|
| bCNC 0.9.16 | Controller: GRBL1 | bCNC does not read the firmware's name. Tested with GRBL1. |
| gSender 1.6.4 | Default firmware: the choice other than Grbl | gSender recognises a firmware by its name in $I. Our controller gives its own name, so gSender uses the firmware you set as the default. Tested with that choice. |
| UGS 2.1.27 | Firmware: GRBL | Tested: settings, programs, alarms and homing after a reset, with no extra Soft Reset (section 3). UGS's other firmware choice works as well, but needs one more Soft Reset after a reset; jogging was tested with that choice only. |
After an alarm or a reset
- E-stop. The MC-1's E-stop opens the power contactor. Release it, press the machine's Start button, then reset in the sender and home. Until Start is pressed the alarm (ALARM:10) does not clear.
- ALARM:11 (homing required). Home (
$H). Unlocking with$Xis refused (error:46). - ALARM:2 (soft limit). The program asked for a move outside the travel. Homing leaves Z at the top of its travel (machine Z 0), so any move above it, such as
G53 G0 Z5, raises ALARM:2. Reset, then home or unlock. - bCNC recovers after any reset: it sees the "Grbl" welcome line and forgets the lines that were still on their way, so
$Hgoes out. - bCNC after Stop. bCNC's Stop is a feed hold, then a reset. Afterwards bCNC sends the modes it had before (coordinate system, units, tool length offset) back to the controller in a line or two, and in a few cases the controller refuses them, as other Grbl controllers do: with a tool length offset (
G43.1) in effect the line gets error:24 (bCNC sends aG43.1Z...of its own after its first Stop, so from the second Stop on it always happens); underG80,G43.1Z...gets error:31; with scaling (G51) in effect,G51:Xgets error:1. After an error every G-code line that follows gets the same error until an empty line, a$command or a reset. So after a Stop, check the coordinate system, the units and the tool length offset with$Gand$#before you jog or carry on. If they are wrong, set the zero again and measure the tool length again (tested on the twin, 2026-10-06). - UGS with its other firmware choice. After a reset that UGS did not send itself, for example one from Studio's window or the controller restarting by itself, press Soft Reset once more in UGS before Home. Until then Home does nothing. With that choice UGS treats only another welcome line as a restart. A reset from UGS's own Soft Reset button is fine. On the MC-1 itself such resets are rare: it has no reset input and one USB host. With the firmware set to "GRBL" this does not happen: after such a reset UGS shows CONNECTING, and Home works at once (tested on the twin, 2026-10-06).
Tool changes (M6)
None of the three senders, with their default settings, lets the MC-1 change the tool and measure the new one:
| Sender | Default | What to do |
|---|---|---|
| bCNC | Skips every M6 line: the next tool's cuts are made with the tool still in the spindle. | Set its tool change to Manual tool change (TLO) and measure on the MC-1's tool setter (section 5). |
| gSender | Tool change "Ignore": M6 is sent as a comment and the program does not stop. | Set its tool change to Fixed Tool Sensor at the MC-1's tool setter (section 5). |
| UGS | Handles M6 itself: it retracts, stops the spindle and asks you to change the tool, but it never measures it. A longer tool then cuts too deep, and on a real machine it can crash into the part. | Run one tool per program and set the tool's length or work zero before each, or use Studio for programs with tool changes. |
More about UGS and M6:
- It also stops at an "M6" inside a comment, such as FreeCAD's
( M6 T1 ). - A second M6 that comes right after a tool change can slip past it to the controller. The controller then waits in the Tool state for a confirmation that UGS never sends, and no button in UGS's window works any more. On the MC-1 only the E-stop ends it: press it, release it, press Start, then Soft Reset and Home in UGS.
- If the controller is reset during a UGS job before UGS has reached an M6, UGS may report the job as complete, but its tool-change dialog still comes. Dismissing it can start the whole program again from the beginning. After a reset in the middle of a job, close the file in UGS before you go on.
Measuring tool length on the MC-1's tool setter
The tool setter is at the back left of the table; G59.3 is stored right above it.
- bCNC, Manual tool change (TLO). Tool change position above the tool setter. Probe position
G59.3. Probing distance 50 mm, seek 200 mm/min, slow 25 mm/min (the MC-1's$342–$344), command G38.2. Measure the first tool with "Calibrate" before running the program. bCNC then setsG43.1for each new tool. - gSender, Fixed Tool Sensor. Sensor location
G59.3. Measure the initial tool in the wizard. gSender then shifts the work Z for each new tool (G10 L20) instead of using a tool length offset. It takes the length from where the axis stopped after the touch, not from the trigger point the controller reports, so each change can be a little off. In the twin, run tool changes at 1× speed: gSender reads that position after a fixed short pause, and a twin running faster can give it one from before the stop. - Start at least 0.1 mm below the top of Z (machine Z −0.1 or lower) when the tool change begins. Both senders return to that height after measuring. Starting right at the top, the small scatter of a measurement can put that return above the soft limit, and the job stops with ALARM:2 before it cuts.
Setting work zero with a touch probe
- UGS (its probe module) works out the zero from the trigger points the controller reports (
[PRB:]). This is the right way. - gSender (3D probe) and bCNC (its probe page, then its Z=0 / X / Y buttons) set the zero where the axes stopped after the touch. The machine always runs on a little past the trigger before it stops, and the faster the final touch, the further. Use a slow final touch, or set the zero with Studio's probe cycles, which use the trigger points.
- UGS's hole centre (its probe module's Hole Center): from where you leave the probe it probes -X, +X, -Y and +Y, each by half the hole diameter you type in, and sets the centre midway between the slow touches' trigger points. How far it reaches depends on that diameter: the start may be at most (typed diameter - actual bore) / 2 + the ball's radius from the centre. With the bore's own diameter typed in, that is only the ball's radius (1 mm for a 2 mm ball); type it a few mm larger (24 to 26 for a 20 mm bore) to allow for placing the probe by eye.
- When UGS's hole centre does not reach the wall (finding 192, UGS's own behaviour): that probe ends in ALARM:5 and UGS stops. But it set G54's X0 Y0 at the start point before probing, and as the cycle did not finish, G54 stays there. After unlocking, set the zero again before cutting. Its probe cycle also stays half-way: disconnect and connect again before probing again. It also takes a point the controller reports as not touched (
[PRB:...:0]) for a touch. - Calibrate the probe first (Studio's probe cycles: a ring gauge). An uncalibrated probe reads every bore larger and every boss smaller by twice its pretravel.
Other things to know
- bCNC over the network. On Windows, bCNC reads a TCP connection only about every 2 seconds, so its display can be 2 seconds old. "Idle" in bCNC does not mean the machine has stopped. A USB connection does not have this delay.
- gSender, M0. An M0 within the first 10 lines of a program does not pause (gSender turns it into a comment). M1 always pauses.
- gSender, continuous jog. Holding a jog button is refused on the MC-1 (error:15): gSender asks for a long jog beyond the travel. Jog in steps. On some Grbl controllers,
$40=1(limit jog commands) ends long jogs at the soft limits instead of refusing them; the MC-1's controller does not act on that setting yet and still refuses them (tried with gSender on the twin, 2026-10-06). - UGS, long lines. UGS never sends a line longer than 127 characters: the job stops without a message. Keep lines shorter (UGS removes comments first).
- UGS, M30. UGS removes M30. A program that relies on M30 to stop the spindle and coolant leaves them running: end programs with M5 and M9 before M30.
- UGS, comments. If a line has two comments, UGS also removes the code between them.
- Disconnecting during a job. The controller keeps running the lines it already has. gSender and UGS send no stop when you disconnect, so the machine runs on, with the spindle turning. Stop the job before you disconnect. bCNC holds and resets before it closes the connection.
- Comments with non-ASCII characters (such as Chinese, "Ø", "–"): all three senders remove comments before they send, so these characters never reach the controller. The controller itself reads UTF-8 text in comments and in
(MSG,...)as text, never as a real-time command.