It's impossible for TL, TR, BL, BR motors to be crossed, right?

Troubleshooting
21

there are two problems with skinny frames

  1. the forces involved get high as the angles between adjacent belts get larger
  2. the arms are limited in how close they can get to the posts, and when they
    hit their limits, the arm and belt are no longer inline

if you have a skinny frame, what I would suggest is that you plug the numbers
into the calculator and make sure that you are only doing your calibration
within the green area.

when you are cutting, you can probably go outside the greeen area by a couple of
bands without noticing much in the way of errors, but the calibration is much
more sensitive to problems (either due to angles or to belt stretch, which is
why people express concern about high current limits during calibration)

Dylan Taft wrote:

I think I can do a PID loop that makes magnetic encoders driven pwm DC motors
look like servos for better compatibility

that would be a fantastic step forward, right now, a lot of the maslow specifics
are more hard-coded than they should be. expanding fluidNC to be able to define
a “motor” that is actually a DC + encoder would be a huge long-term win.

when looking at the kinematics, lookup the term ‘cable driven robot’ and you
find the right calculations.

unfortunantly, even chains and steel braided cable have a surprising amount of
stretch in them (and with chains, the weight of the chain becomes significant
and you start having to account for sag that you can get away with ignoring with
lighter material)

…redoing something like a motion planner is way beyond me…

that’s core fluidMC stuff, not something you should have to worry about

but one problem that a PID DC motor setup has is that the response
(acceleration) lags behind what a stepper would do (until the stepper starts
skipping steps), so you may want to see if you can hook in to the output of the
motion planner rather than the output of the stepper driver so that you not only
know the position and speed, but what acceleration is desired and feed that into
the PID loop

It feels like stretch can be modeled by keeping a running number of additional
retraction to keep belt tension. It can be measured diagonally easily at
different points along a hypotenuse…

please try it. I think the biggest problem is that there are so many causes of
unpredictable friction that we don’t really know the forces involved.

From there, ignored..wouldn’t the belts move like normal triangles if kept tightish? Move slow and just do trilateration.

the calculations are actually pretty simple right now, an abc triangle + anchor
and arm lengths (with a multiplier available for people to try and fudge things
for belt stretch, but that’s not doing anything by default)

I might just abandon frame edits and try a port…vastly easier to do things
like restore known belt lengths on powering up

This is a big todo item that keeps getting pushed back as we try to figure out
these calibration issues.

there is code in place to try and save the Z position when the machine pauses
for a few seconds, we need to tie into that to save the belt positions as well
(and then restore them at startup)

This would also be a huge thing to do.

when you don’t have to sync machine state to a web interface…and if
“calibration” is simple math…it can be done on device with custom gcode.

currently this is pushed to the browser as the browser calculations in
javascript are much faster than the calculations on the esp32

it has the side effect that the measurements are available for us to grab and
experiment with other approaches

I think how I want to use the device ultimately is vastly different from how
it is used…

please say more

David Lang

22

This is beyond troubleshooting at this point, so don’t want to waste people’s time - I’ll post when I have something to show in technical details. I have a bunch of ideas that I want to implement.

  • A ring buffer of troubleshooting data that is flushed to disk or wifi dump frequently - think like motor current data, magneto position data, belt data, if I implement PWM motor stepper emulation, then a count of deviations off expected movements measured per the magneto sensor. This could be processed on a PC and overlayed onto a video recording of problems as they occur, showing data, making apparent spool binding, slipping magnets, mismeasurements, etc. imagemagik…I think if I recall..could do this very easy. More unified debugging vs printing out serial console debug messages
  • Something more focused on gcode senders - allowing for multiple ways of gathering frame dimensions and setup - ie measuring 4 corners, calculating hypotenuse. least squares, etc. Like M100 - calculate anchor coordinates off pre-established anchor distance
    M101 - Run and output data for the least squares calibration process
    M102 - Disable\Enable debug ring buffer
    M103 - params to set frame geometry manually, or belt distances manually, including for setting stuff from least squares calibration process
    G Codes to move the motors manually, disregarding cartesian translations, for troubleshooting
  • Lots of error detection code - like if current starts falling for a motor, did the line just go slack? If current rapidly rises, is the spool bound? Add it to debugging ring buffer or alarm

grblhal built right ontop of the ESP SDK instead of platformIO + FluidNC probably provides a good test bed for ideas to prove out or disprove, far fewer moving parts, much simpler. So I am porting it over. It might go quicker than I expected, Maslow’s documentation is VERY good, so are the inline comments,schematics, etc. Modern ESP SDK APIs are also idiot proof, simpler timers etc.

I’d rather do this than continue spending money and time on building frames that don’t work lol…my basement became a graveyard of failed maslow frames.

Restoring the belt positions is very important to me. Like I’d rather just pin the maslow to a pre-drilled hole in the frame, tension the belts, restore belt positions…now the device knows where it is, never have to unmount and remount.

And like if everything is gcode based, it becomes very easy to implement several methods and ideas of calculating frame geometry. There’s no GUI.

A lot of senders…or processors…you can just add pre-machining gcode commands and that’s where this stuff would go, based on your setup.

Plus I am like so curious - friction rises when cutting I am sure. Does that translate to like unexpected motor movement vs just moving the sled around on a spoil board? The PID loop can detect and correct. Does one maintain a cutting value offset vs a non cutting value? But these motors are like super high torque, slow, planetary gear or something, maybe they just slice through wood like butter and current changes barely show. I have no idea.

fluidnc…there’s not a huge separation of concerns, the GUI seems tightly bound to operation of the machine. That can complicate things…

1 Like
23

Not sure if there’s any interest, but looking at the ESP SDK, having to do a deep dive into the schematics and current maslow code…
TL motor ADC current sensor is on ADC channel 2. There’s errata for the WROOM S3 chip you guys are using. There can be unstable adc output for the current sensor as it’s shared with the wifi controller. I wonder if that can cause calibration issues for some. It’s best to use the lower GPIO pins for ADC I guess.

1 Like
24

Dylan Taft wrote:

G Codes to move the motors manually, disregarding cartesian translations, for troubleshooting

I believe this is already in place

look at FluidNC/FluidNC/src/ProcessSettings.cpp

starting around line 1093 are the maslow commands

at about line 1100 you have TLI and TLO type commands that command the belt to
move in or out

we can add additional commands as needed

David Lang

1 Like
25

That is a good catch! We’re really looking for big spikes in the data so a few bits of noise is probably not going to impact the results much, but it’s something to keep an eye on for sure!

1 Like
26

Pretty well underway with the C port to grblhal + ESP SDK 5.4.1.
If you’re still using that Sparkfun TCA9548A driver code for Arduino, there’s a small bug in it, especially as maslow uses TCA9546.

bool QWIICMUX::isConnected()
{
_i2cPort->beginTransmission(_deviceAddress);
if (_i2cPort->endTransmission() != 0)
return (false); //Device did not ACK

//Write to device, expect a return
setPortState(0xA4); //Set port register to a known value
uint8_t response = getPortState();
setPortState(0x00); //Disable all ports
if (response == 0xA4) //Make sure we got back what we expected
return (true); //All good
return (false);
}

They’re not doing a i2c stop between send and receive from what I can tell, the datasheet specifically calls out doing that. A4 could never be returned by the 6 chip, the high nibble will always be 0 as it is a 4 channel chip. However, maslow barely reads from that chip, even if it’s undefined behavior it may or may not trigger much.

When I ported the driver to C, I started getting the right result, 0x04, isolated to a test case, and realized I was comparing to something doing it wrong.

I have control over ADC, belt position sensors, PWM on the motors, the i2C muxer, fan, etc. The magnets do not seem to be slipping, they are potentially ROCKING a bit due to the casting? Ie if I pull the belt and return it several times, it always only goes back to a number close to what it was originally. But it’s not creeping up or down, so I’d say that indicates some rocking. Guessing that would hopefully average out. But…your maslow 4.1 arms…didn’t they put the sensor inside a proper bearing? So that’s a huge step forward for accuracy and a reason to upgrade.

ADC Readings: BL: 0, BR: 0, TR: 0, TL: 0
Belt Positions: AS5600_1: 1, AS5600_2: 0, AS5600_3: 1, AS5600_4: -1
Restarting in 150 seconds…
ADC Readings: BL: 2, BR: 0, TR: 0, TL: 0
Belt Positions: AS5600_1: 1, AS5600_2: 0, AS5600_3: 1, AS5600_4: 0
Restarting in 149 seconds…
ADC Readings: BL: 0, BR: 0, TR: 0, TL: 0
Belt Positions: AS5600_1: 1, AS5600_2: 0, AS5600_3: 0, AS5600_4: 0

After I finish the port…I’ll probably upgrade.

So far I am just finding really minor things going over the schematic, code, datasheets. No indication as to why my belts are loosening other than bad measurements. I am thinking how I am doing calibration in grblhal will be easier with some sanity checks - human measure distances between points, machine measure hypotenuse, sanity check, report back how good the measurement was. Probably measuring the hypotenuse a few times and getting an average is a good idea due to the magnets apparently rocking. I imagine this isn’t helping the calibration you’re doing, and it’s probably specific to the arm castings and normal play. The 4.1 arm is a huge step ahead here.

I still think doing all this extra work is worth it for me…it’ll end up on the latest ESP SDK and also validate what you’ve done…and provide a new way to use the machine prioritizing gcode senders.

I have a sense that this is the primary issue with calibration on both my frames, the magnet play. Because the motor mount also has play, there can be varying pressure on the gear that holds the magnet, and different play for different people on 4.0 I imagine…

I am still learning but I am not getting a feeling that any issues are coming from belt stretch. They should hold tension if frame measurement is good and the magnetic encoders sensor reading issues actually average out.

If they don’t average out the sane solution is Maslow 4.1 arm replacement, but probably also oscillating a small amount of slack to tilt the sensors during movement might force it to average out. That’s easy enough to do. Basically, intentionally adding movement errors and correcting them at a low enough level the quality of cut is not impacted :joy:

1 Like