A few final questions

Troubleshooting
1

I can get through calibration, the fitness usually hovers around .70, but I notice a bunch of bizarre things.

  • When the device gets to the edge, it starts moving strange from the webui. Like a jog to the left it moves left and then up in two motions. Some of the belts begin to get loose. It works fine in the middle area.
  • When I was moving the Z axis up and down through the webui, the belts were not releasing or tightening to accommodate…eventually one of the belts seemingly loosened, the web ui hung up and it said then that the belts needed to be retracted and extracted. Is this normal? The WebUI freezing is really common.
  • Lastly, is it possible to manually set the 4 belt positions? Say the belts get weird or something.
    Or like, why can’t you just drill a hole in the center of the spoil board, and use a pin in the router, that is machine home? Hold the device down, tension all the lines, restore prior measured line positions.

I am thinking of maybe using a gcode sender and staying out of the web ui…it could be something in my environment making it crash, not sure.

What I really want to do is calibrate, get the router centered through the process, and then like manually home it after that by hand. Can I do this manually through any GRBL commands? Like manually retract all 4 motors via gcode commands, and then set their line positions manually based off a prior known good state where the lines were measured and tensioned - like initial calibration.

The last thing is really important to me…is it doable? I saw some stuff in maslow’s firmware control about manual motor control and dangers but not documentation.

I started looking at my own calibration process and porting to grblhal but it’s a nightmare.
I did figure out if I WAS going to do it, a rough outline of a calibration process that was working on paper, solving for some frame geometry more geometrically with only manually measuring anchor point distance… the benefit to that would be not having to do least squares and could do stuff on device via a custom M gcode.

I haven’t even gotten to thinking about kinematics yet…I’m just afraid to put a piece of wood under this, I feel like it might work but it could ruin the board too.

Manually being able to home it, even physically and with gcode, would be a massive boost of confidence. I can test stuff with a marker attachment first…

grblhal’s esp32 driver also only supports espressif’s SDK up to version 4.4 which is like pretty deprecated by now. And they changed stuff with the MCU timer APIs…it compiles with that older version but that’s just another deterrent to continuing that. Quickly getting in over my head there. I should stop trying to re-invent the wheel over some hopefully small issues…

2

Dylan Taft wrote:

I can get through calibration, the fitness usually hovers around .70, but I notice a bunch of bizarre things.

that is a decent fitness

  • When the device gets to the edge, it starts moving strange from the webui. Like a jog to the left it moves left and then up in two motions. Some of the belts begin to get loose. It works fine in the middle area.
  • When I was moving the Z axis up and down through the webui, the belts were not releasing or tightening to accommodate…eventually one of the belts seemingly loosened, the web ui hung up and it said then that the belts needed to be retracted and extracted. Is this normal? The WebUI freezing is really common.

that sounds like a problem

  • Lastly, is it possible to manually set the 4 belt positions? Say the belts get weird or something.
    Or like, why can’t you just drill a hole in the center of the spoil board, and use a pin in the router, that is machine home? Hold the device down, tension all the lines, restore prior measured line positions.

there is currently no documentation of the individual belt commands, they exist
in the source code, but no documenation has been written

I am thinking of maybe using a gcode sender and staying out of the web ui…it could be something in my environment making it crash, not sure.

I don’t think this is possible (it may be, but you are launching into untested
territory

What I really want to do is calibrate, get the router centered through the
process, and then like manually home it after that by hand. Can I do this
manually through any GRBL commands? Like manually retract all 4 motors via
gcode commands, and then set their line positions manually based off a prior
known good state where the lines were measured and tensioned - like initial
calibration.

I would have to dig into the source to see if you can set the belt length to an
arbitrary value, or if you can only set it to zero (full retraction)

The last thing is really important to me…is it doable? I saw some stuff in
maslow’s firmware control about manual motor control and dangers but not
documentation.

yep, no documentation. Even if the current code doesn’t let you set the length
to an arbitrary value, I don’t see why a patch to support that would not be
accepted.

I started looking at my own calibration process and porting to grblhal but it’s a nightmare.

I did figure out if I WAS going to do it, a rough outline of a calibration
process that was working on paper, solving for some frame geometry more
geometrically with only manually measuring anchor point distance… the
benefit to that would be not having to do least squares and could do stuff on
device via a custom M gcode.

if you manually measure the anchor point distances, just use those values, the
purpose of the calibration is to avoid manual measurements.

I have a onshape doc I’ve posted that lets you enter the 6 anchor-anchor
measurements and outputs the coordinates. I haven’t bothered to reduce this to
equasions and put it into code. It uses 5 measurements to make the calculation
and then the final diagonal as a check for how close it is (what’s the
difference between the measured and calculated diagional)

I haven’t even gotten to thinking about kinematics yet…

that’s a completely different problem, don’t worry about that yet.

I’m just afraid to
put a piece of wood under this, I feel like it might work but it could ruin
the board too.

put a board under it and run it without any bit in the router. get comfortable
with moving it around.

then get some cheap wood/foam and cut on that for a bit until you are
comfortable.

Manually being able to home it, even physically and with gcode, would be a
massive boost of confidence. I can test stuff with a marker attachment
first…

after you calibrate, homing is disconnect anchors/retract all belts/extend all
belts/ attach anchors/apply tension

on large CNC machines, it’s not a matter of homing and operating from there,
it’s a matter of putting your material in the machine and setting home based on
the material, then cutting based on that frame of reference rather than on the
frame of refrence of the machine itself

grblhal’s esp32 driver also only supports espressif’s SDK up to version 4.4 which is like pretty deprecated by now. And they changed stuff with the MCU timer APIs…it compiles with that older version but that’s just another deterrent to continuing that. Quickly getting in over my head there.

platformio works with this code (I ebelieve that’s what it’s designed for)

David Lang

3

Thanks! Next time I dig at this I’ll look at if it looks doable at all to set a belt extraction point manually. It’s going to have to also tell the web side that it finished the retractation\release process. I started looking at the code and it almost looked like the web side scrapes some text output from the text console. Absolutely better than trying to reinvent the wheel, thanks.