2026-11-02

Last modified: 2026-11-03 12:07:50

FluidNC

I have been talking in the FluidNC discord about how to support jog feed override.

Also I embarrassed myself by slagging off UGS directly to a UGS developer.

Generally I would say there is not much enthusiasm for improving jogging, I think this is because they haven't seen it working. So the plan is to film a demo video before/after of showing how the latency of shift-for-rapid-jog changes with the old version vs the new version.

But first still need to fix the X belt grippers.

OK, belt grippers done, and I was messing about with figuring out the velocity and acceleration limits, and then FluidNC kept disconnecting, unsure what is wrong. I moved the laptop closer and opened the lid on the cabinet to see if it was just a WiFi problem but it persisted.

I ran ping in a terminal and watched it while doing nothing, and it seems to be working for 30 seconds and then down for 30 seconds, I wonder what could be causing that.

Unsure what was wrong and can't reproduce now. Will try to pay more attention to what I was doing just before it broke if it happens again.

New problem is the belt keeps falling off the bearings on the omega drive:

Belts are such a hassle. I guess put some flanges on them.

While the flanges were printing I was trying to find the acceleration/velocity limits on the Y axis, I got as far as 50 m/min and 2500 mm/sec^2 and found that this was much faster than I was comfortable with so I don't see any benefit to increasing it further. Making the machine move any more rapidly than this is not going to be helpful in cutting, is not going to save any time in jogging, and is just going to allow me to crash it with less warning. So this is more than adequate.

I may even want to slow it down.

Flanges finished printing and installed, seems good.

I've slowed it to 10 m/min and 1000 mm/sec^2.

I then ran a program that makes the same movements over and over again, and found that the X axis seems to be losing steps.

It will consistently "drift" in one particular direction, until it hits the end of the axis and trips the servo drive alarm.

I'm pretty sure the belt is not slipping, and the servo drive ought to notice if steps are genuinely being lost, so what could be wrong here?

My steps/mm value is non-integer, could that be the problem?

ChatGPT says that FluidNC supports non-integer steps/mm, suggests the problem might be to do with timing of the DIR signal?

FluidNC has a "dir_delay_us" parameter that I can use, supports values up to 10.

So plan is:

• run the same pattern in reverse and see if it drifts the other way
• run the same program but slower and see if it still drifts
• set "dir_delay_us" to 10 and see if it goes away

It always drifts the same way. It drifts even with low speed and low acceleration. "dir_delay_us" set to 10 didn't help.

I am kind of suspecting that the problem is running the servo drive on 12v, which is below the minimum of 18v or whatever. I tried adjusting the trim on the power supply as high as it would go and got 14.5v, but didn't help with missing steps.

Other candidates include that the 74HCT245 is not quite reliably powering the opto inputs on the servo drive. I could connect the oscilloscope to have a look at the actual pulses.

I connected the oscilloscope across PUL+/PUL- of the X servo drive and it looks like a perfect 5v square wave to me, I don't think anything wrong with the buffer. I think the leading hypothesis is the low supply voltage to the servo drives, but that is inconvenient to resolve without spending money. Actually it's not! I can temporarily run one of the servo drives on the adjustable bench power supply.

While this was going on the random disconnection problem came back, so this time I left a ping -D running and copied its output into ChatGPT.

It suggested run sudo iw event -t to see if it's actually getting disconnected from WiFi.

I ran the X servo drive on 24v from the bench power supply and the problem persisted! Unbelievable.

Weirdly it seems to be fine if I just get it to move 100mm back and forth, always ends at the same place it started as far as I can tell, but if I go 200mm it drifts a bit and if I go 300mm it drifts a lot. Much more than 1.5x the drift for 200mm, and much more than 3x as much as the 100mm movement plausibly drifts.

So this suggests there is something going wrong either with long movements themselves, or when traversing some region of the linear axis or the belt.

Let's try moving 100mm back and forth but from different starting positions.

OK I found out what is wrong, it is riding over the flange on the pulley:

This changes the effective diameter so changes the distance it travels per revolution of the motor.

Currently I just have one bearing for each idler, but really wants 2 to stop it rocking. So I think redesign the idler to have 2 bearings, and redesign the motor pulley to be longer and maybe have a larger diameter flange.

Belts are such a hassle.

Have this in CAD now, green parts new:

So the pulley gets longer, flanges get longer and take 2 bearings, and there's a bar tying them together to try to stop them from being able to bend apart.