Advanced Search

200N = ~20.3KG ???
450LBS = over 200KG = ~2000N

Hi all, I’m planning to use a Compulab Fitlet3 as the controller PC for a LinuxCNC setup (Mesa 7i94T over Ethernet). My goal is a quiet, compact, low-latency machine with dual LAN and enough performance for a Qt UI (e.g., QtDragon or ProbeBasic), without excessive overhead. Here’s the configuration I’m considering:  

Fitlet3 configuration: 

• CPU: Intel Atom x6425E (4 cores @ 2.0 GHz base, 3.0 GHz burst, 12 W TDP)
• RAM: 8 GB DDR4 SODIMM
• Storage: 256 GB NVMe (M.2 Key-M)
• No SATA drive, no WiFi or modem
• Audio: Analog audio codec module
• I/O: Terminal block with RS-232/RS-485/GPIO
• Enclosure: Standard finned top cover (rated for 18 W)
• Thermal spec: Extended range –20°C to +70°C
• TPM: Not installed
• FACET card: FC3-LAN (adds 2× Intel i210/i225 Gbit LAN)

I plan to run the official LinuxCNC ISO with Preempt-RT, not a custom kernel or patched distro. Hence, I’m relying on the FC3-LAN FACET card for known-good Intel NICs, as the onboard Marvell NICs require kernel 5.15+ and I’d prefer to avoid that complexity.  

My questions: 

1. Has anyone here run LinuxCNC with a Fitlet3 (or similar Elkhart Lake system)?
2. Is the x6425E predictable and stable under Preempt-RT with Mesa boards over Ethernet?
3. Can anyone confirm that the following BIOS options are present and can be disabled in a AMI Inc. BIOS? 
   • Intel Turbo Boost
   • CPU C-states
   • SpeedStep (EIST)
   • CPU power management (set to Performance)

I’d also appreciate any pointers on edge cases I might be overlooking, or real-world latency results on this hardware (if available). 

Thanks in advance — I’d love to avoid going down a rabbit hole if this platform has hidden caveats. 

aeth wrote:

... I want to make a truly badass solution with Raspberry Pi...

That statement ... has issues!
Use a NUC or any small PC, not a RPI.
You should check the export regulations before jumping in, the biggest market for DIY is USA, then India, Europe is pretty far down that list. I checked for the same thing, it was not pretty. BTW, my country has the lowest tarifs for USA at 10% only! Does not fix much when sending anything there costs over 300$ for a small box.
This is not to discourage you, absolutely do try, just make sure you get informed beforehand.

Hello everyone.

I'm quite new to the topic of Mesa cards and LinuxCNC. For the past few days, I've been trying to get my Mesa 7i95T up and running. Some things are working well, I’ve loaded the firmware and configuration, and now I can communicate with my card. Encoders can also be observed on the LinuxCNC interface. Now I wanted to try running my motor for the first time, but unfortunately, I’ve been unsuccessful for a few days. When I reference all my axes and click Jog, I get the error message:
Motor 0 position error
emc/task/taskintf.cc 976: Error on joint 0, command number 108


.hal
# kinematics
loadrt [KINS](KINEMATICS)
# motion controller
loadrt [EMCMOT](EMCMOT) servo_period_nsec=[EMCMOT](SERVO_PERIOD) num_joints=[KINS](JOINTS) num_dio=8
# hostmot2 driver
loadrt hostmot2
loadrt hm2_eth board_ip=192.168.1.121 config="num_encoders=6 num_stepgens=6 sserial_port_0=00000000"
#Stepgen
loadrt stepgen step_type=0,0,0
setp hm2_7i95.0.stepgen.00.enable TRUE
# THREADS
addf [MESA](CARD0).read servo-thread
addf [MESA](CARD0).write servo-thread
addf motion-command-handler servo-thread
addf motion-controller servo-thread
# Encoder X
setp hm2_7i95.0.encoder.00.filter 1
setp hm2_7i95.0.encoder.01.filter 1
setp hm2_7i95.0.encoder.02.filter 1
# Encoder 0 -> Joint 0 (X)
net x-pos-fb hm2_7i95.0.encoder.00.position => joint.0.motor-pos-fb
#E-Stop
net estop-loop iocontrol.0.user-enable-out => iocontrol.0.emc-enable-in
# DPLL
setp hm2_7i95.0.dpll.01.timer-us 100
# joint-0 enable chain
net joint-0-index-enable <=> joint.0.index-enable
#net joint-0-index-enable <=> [MESA](CARD0).encoder.00.index-enable
net joint-0-index-enable <=> [MESA](CARD0).stepgen.00.index-enable

# Joint 0 Step Generator Settings
setp [MESA](CARD0).stepgen.00.dirsetup [JOINT_0](DIRSETUP)
setp [MESA](CARD0).stepgen.00.dirhold [JOINT_0](DIRHOLD)
setp [MESA](CARD0).stepgen.00.steplen [JOINT_0](STEPLEN)
setp [MESA](CARD0).stepgen.00.stepspace [JOINT_0](STEPSPACE)
setp [MESA](CARD0).stepgen.00.position-scale [JOINT_0](SCALE)
setp [MESA](CARD0).stepgen.00.maxvel [JOINT_0](STEPGEN_MAX_VEL)
setp [MESA](CARD0).stepgen.00.maxaccel [JOINT_0](STEPGEN_MAX_ACC)
setp [MESA](CARD0).stepgen.00.step_type 0
setp [MESA](CARD0).stepgen.00.control-type 0
setp [MESA](CARD0).stepgen.00.direction.invert_output true
# position command and feedback
net joint-0-pos-cmd <= joint.0.motor-pos-cmd
net joint-0-pos-cmd <= [MESA](CARD0).stepgen.00.position-cmd
net joint-0-pos-fb <= [MESA](CARD0).stepgen.00.position-fb
#net joint-0-pos-fb <= [MESA](CARD0).encoder.00.position
net joint.0.output => [MESA](CARD0).stepgen.00.velocity-cmd
net joint.0.output <= joint.0.vel-cmd

.ini
[EMC]
MACHINE = Mesa 7i95T XYZ
DEBUG = 0
VERSION = 1.1
[HAL]
HALFILE = /home/kacper/linuxcnc/configs/Mesa_Mini/01_main.hal
[HMOT]
CARD0=hm2_eth
[HOSTMOT2]
ETH0=192.168.1.121
[EMCMOT]
EMCMOT = motmod
COMM_TIMEOUT = 1.0
COMM_WAIT = 0.010
SERVO_PERIOD = 1000000
[MESA]
VERSION = 2.0.6
FIRMWARE = 7i95t_sdid.bin
CARD0 = hm2_7i95.0
[DISPLAY]
DISPLAY = axis
POSITION_OFFSET = RELATIVE
POSITION_FEEDBACK = ACTUAL
[TASK]
TASK = milltask
CYCLE_TIME = 0.010
[EMCIO]
EMCIO = iov2
CYCLE_TIME = 0.1
TOOL_TABLE = tool.tbl
[RS274NGC]
PARAMETER_FILE = linuxcnc.var
[KINS]
KINEMATICS = trivkins coordinates=XYZ
JOINTS = 1
[TRAJ]
AXES = 1
COORDINATES = X
LINEAR_UNITS = mm
ANGULAR_UNITS = degree
MAX_LINEAR_VELOCITY = 200

[AXIS_X]
TYPE = LINEAR
MAX_VELOCITY = 50
MAX_ACCELERATION = 100
MIN_LIMIT = -200
MAX_LIMIT = 200
[JOINT_0]
TYPE = LINEAR
HOME = 0
FERROR = 5
MIN_FERROR = 0.5
MAX_VELOCITY = 100
MAX_ACCELERATION = 200
STEPGEN_MAX_VEL = 60
STEPGEN_MAX_ACC = 120
P = 1000
I = 0
D = 0
FF0 = 0
FF1 = 1
FF2 = 0
DEADBAND = 0
BIAS = 0
MAX_OUTPUT = 10
MIN_LIMIT = -200
MAX_LIMIT = 200
STEPLEN = 1000     
STEPSPACE = 1000   
DIRSETUP = 1000    
DIRHOLD = 1000     
SCALE = 640  
start

 From a hardware perspective, everything seems to be correctly connected. Below, I’m attaching my .ini, .hal, and stepgen pins. Do you maybe have an idea where the issue could be?

Right now, my main goal is just to get the motor running. Thanks in advance for your tips and support.

I noticed when looking at encoderS0.position I'm getting no valves. Also no valves when looking at spindle.0.revs in halshow. Could this be causing the issue ? EncoderS0.phase-Z is getting the signal from one of the remora input pins(my encoder index) which both are blinking in halshow when triggered. Should I be seeing the spindle.0.revs displaying a valve in halshow?

I was recently wondering if there's a company or someone who builds 3 or 4 axis mill control boxes pre-configured with LinuxCNC. Most hobby and semi-professional machines rely on a very similar configuration with one, maybe 2 steppers per axis and it would be awesome if a properly built control box with Linux CNC was available pre-configured and off the shelf. Is anyone aware of a product like this? I know that CNC drive sells their control boxes with UCCNC and stuff like VFD, fuses, relays and stepper drivers preinstalled.
Ever since Ethercat was integrated into LinuxCNC, I want to make a truly badass solution with Raspberry Pi, hardware control panel (there's a Shenzen company producign Ethercat panels with feed/speed knobs and macro buttons!) and Leadshine CS3E closed loop stepper drivers and Delta MS300 VFD. A complete Linux CNC solution like this will cost around 2500 USD which is the price for just the Centroid Hicory mainboard + software that offers similar capabilities.
If there's nothing like this on the market and enough people are interested, I could partner with my friend in China who could help me get this stuff assembled there.

That dkms error is an error in the debian distribution, they included a raspberry package. Just delete it.Well I thought the secure boot would be an explanation but now I don't know.
Happy you can use it, anyway.

Changing the latch velocity is worth a try _but_ having the same sign on search velocity as latch velocity is valid.

In this case, The homing logic is supposed to move towards the home switch at the search velocity, and when the
home switch is detected, reverse and back off until the home switch deactivates, and then move towards the home
switch again at the latch velocity for the final home switch detection.

Hi everyone, I've already done that. I've reinstalled the PC three times and always encountered the same problems. I included Mok Management during the second installation. I've done that again this time.

and yet something seems to have gone wrong:

With the workaround everything works so far (I hope) and thanks again

Hi rodw, thanks for the response. I think you are missing the problem so please allow me to clarify.

On my Tormach, this process makes perfect sense. I touch off with a probe or tool or edge finder or whatever, and then hit the zero buttons in the GUI. This sets the DRO readout to zero, puts the work offset origin symbol in the workspace viewer at the current position, and populates the offsets table with the position of the work offset in absolute coordinates. No problems here.

But on my new LinuxCNC mill, this process isn't working. When I hit the zero buttons in the gui, the DRO readout gets set to zero, the work offset symbol in the workspace viewer (3 colored axis arrows) gets put at my present position, but the offsets table doesn't update. It remains unchanged. You can see this in the images I attached to my previous post. More so, if I try to manually enter values in the offsets table, I get an error. I also included this info in my previous post.

Please let me know if there's anything else I can clarify. I understand that this is a bit of a subtle issue and I haven't done the best job of explaining it so far, so I hope this is a little better.

Edit: The mill is already homed in both situations described above. When run in what I call Bridgeport mode, moving the tool around manually and using the readout as a simple DRO, everything functions normally. The gui buttons zero the G54 work offset in the DRO correctly, it's just that the offsets table isn't updating along with this. When I load a G-code file, it appears to be respecting the offsets table G54 offset rather than the DRO-shown G54 offset, so the tool paths are not where I want them to be.

add loaded forces to the mix and i just learned something else this weekend. always something with this project, it seems. 450lbs of force is no joke or 2000N for everyone over on the other side of the pond.

Video links:

Hi guys ! Long time no see !
Back to this project after a long pause, a new mesa 7i77 board and some wiring mess cleaning. We managed to do some successful test cuts. The machine did even cut some 12mm sheets last Friday. But we still have issues with height control as the torch gets too close to the materiel and this messes up the cut and the torch tip. I'm uploading some test cut videos and will upload some more in order to have your feedback on height control and correct voltage values. Big Thanks for Tommy for his great help with this project. @Tommy, hope you're doing well and enjoying your projects !
Will update with youtube links soon.

Please note the update regarding tool-spindle orientation in the post above.

Also note that there is a sim config for fanuc style tool change and tool-wear, which you may find interesting:
github.com/LinuxCNC/linuxcnc/tree/master...im/axis/lathe-fanucy

Take a look at:

www.linuxcnc.org/docs/html//gui/gmoccapy...l#_tool_related_pins

It seems that you are missing the iocontrol connections. Putting these into the postgui file is correct.