Connected hardware
Rip-It: connecting a touchscreen to a moving saw fence
The software between a requested cutting width and a motor: units, commands, feedback, and remembered positions.
By Curtis Tech Solutions3 min read
Rip-It is a motorized table saw fence controlled from a touchscreen. A woodworker enters a cutting width, and the system moves the fence. Making that interaction work requires software that connects human measurements, application state, and motor commands.
Curtis Tech Solutions contributed to the core Electron software behind that connection. The work included measurement conversion, movement and stop commands, home-zero controls, saved presets, and position tracking across restarts. It sits at the point where a familiar interface starts controlling physical movement.
Translate measurements into movement
The interface needs to work with measurements people recognize, including metric units and decimal or fractional inches. The motor operates in steps. Converting between those representations is part of the core control path.
Our contributions included a unit-conversion layer connecting those input formats to motor microsteps, along with corrections to rounding for absolute moves. Keeping those calculations in a defined layer gives the rest of the application a consistent way to express a position.
An absolute move asks for a target position. A relative move asks for a change from the current position. The software needs to preserve that distinction when turning an interface action into a command, even when both actions look like simple buttons on screen.
Connect the interface to the motor
In the Electron application, controls in the React interface communicate through Electron’s process messaging to the motor-control layer. Work on the WebSocket connection covered movement messages, reported position, and reconnection behavior.
That division creates a useful separation of responsibilities. The interface expresses what the operator requested. The control layer translates and sends the command. Position information coming back from the motor helps the application represent what is happening.
A requested position and a reported position are different pieces of information. Treating them separately is a general lesson from connected hardware: updating a number on a screen does not by itself establish that a device reached it.
Support the controls around a move
The contribution history also includes home-zero controls and a stop command carried from the interface through the Electron and WebSocket layers. Those interactions need a complete path through the application, with feedback that reflects the action being handled.
Saved measurement presets support returning to commonly used settings. They introduce another kind of state: a remembered target that should remain available between sessions. That state has a different purpose from the motor’s current position, even though both are displayed as measurements.
Handle state beyond the current session
Position tracking across restarts was another part of the work. Restarting the software can interrupt the relationship between the application’s saved state and the position reported by the motor. The implementation needed to account for that transition rather than assume every session starts with the same context.
Rip-It shows how connected hardware software extends beyond a control panel. Unit handling, communication, operator actions, and persistence all meet in one interaction. Our contribution focused on that software connection, helping the frontend and motor controls work together as parts of the same product.