Okay, I just did some X jogging. I can easily align the cotter pin in the center of the bar. I actually don’t think the orientation of the sprockets matters just yet.
Here’s my revised proposal:
Attach cotter pin and pull chains taut
Enter measurement for distBetweenMotors
Machine sets current chain lengths to distBetweenMotors/2
Jog in negative Y direction until the bit is just above the top of the stock.
Mark this spot on the spoilboard. It is your home / reset chains location.
Measure the distance from the mark to the top of the workspace.
The Maslow can now compute !!! the motorOffsetY – it’s just how much the sled moved during (4) plus. the offset from top of workspace in (6).
Finally, the chain lengths can be calculated. Assuming the original distBetweenMotors was correct, the motorOffsetY should be perfect. And since the chains are guaranteed to be the same length, the extended chain lengths should also be highly accurate.
I also assume you’d start step (4) by homing. So by the time you get to (6), the Y coordinate shown by the Maslow is exactly the amount moved (negative).
In reading through all the back and forth, I can’t help but be left with the impression that you are simply recreating the original Maslow calibration process. Steps 1-3 are just a variation of extending one chain from the L to R motor and pulling taut - that also gives you the motor spacing, correct? Then when you feed the chain from each motor you are finding the center point because you know both chains have been fed out the same distance.
I agree that the original setup process was tedious, mainly because the risk of chain wrap was high, but I’m not convinced this isn’t equally tedious.
Fair point, but I think we are getting close to something better.
Yes, tho I’d say they’re much faster (you only end up extending 1/3 the distance) and less error-prone (no chain wrapping or snapping with the cotter pin in place).
I’m also wondering can do the following. It’s pretty easy to use the cotter pin to create a perfect triangle. I mean, maybe this isn’t the same as having the sled, but it feels pretty darn precise to me when I actually line it up and press down on it…
… so if I tell you to hit a specific point before attaching the sled, and then you measure the actual location of the sled, I can perform an initial validation. We know how long the chains should be at this point, given the cotter pin. If the actual sled location doesn’t line up, I can actually provide advice and prevent the user from trying to calibrate invalid measurements.
To recap, the steps are now just:
Make cotter pin hit a given point (with equal chain lengths; easy to do with sled off)
Attach sled
Enter sled location measurement, as well as distBetweenMotors and motorOffsetY
If the sled’s location does not match expectations, it could do a single-point calibration process to adjust distBetweenMotors and motorOffsetY into nearby values which satisfy the expectations.
1- marked center with pencil to make a plus in the middle with a 4’ drywall square ( work area is 4’, so easily done)
2. used return to center after calibration
3. used precision calibration with 1/8" bit to drill each location. Will do it again and get back to you.
with length of this thread, should we split it to calibration techniques /accuracy and UI feature / software issues?
How does the user avoid the chains wrapping around the sprockets if they are feeding at the same time? I found I had to be at the motor making sure it didn’t come around and start wrapping until there was sufficient weight on the outfeed side. With both motors feeding chain at the same time, that would be impossible.
Short answer: you never move the motors without the cotter pin in place. You throw the chains over the sprockets, stick the cotter pin in, and move them until they’re taut and the pin is centered. Then you can move in the -Y axis freely to align the pin with the target point.
I just had time to re-run Precision Calibration. I measured and remeasured my work area and did find that what I thought was my center point was off a bit. I started the calibration from true 0,0 and will see if it consistently hits the mark going forward.
One nice to have - my machine is setup with Router On/Off control. The calibration never sends an M4 when starting but does send an M5 when done. It would be nice to have the M4 sent at the beginning so I don’t have to do it manually before starting calibration.
After calibrating, I’m between 0.5 and 1mm off on a 50mm square and 100mm circle. Not bad…
Not bad at all! Definitely still check the corners though.
Yeah, I have this lumped with “probes” in my head. Though, I do have my RPi GPIO turning my router and shopvac on/off automatically (its described earlier in this thread).
I’m working on a new version that improves the visualizer a lot. There were some bugs with mpos vs. wpos. You can now see the bit, the limits of the material… the grid lines look cleaner, and so on.
If the Makerverse build is failing (like now) and I reboot my RPI, will it pull down the bad build? I just rebooted and Makerverse isn’t coming back up. I just checked the Github page and see that the build is failing. If the two things correlate I won’t bother investigating further.
In this case, it was only the Windows build which failed. And I did just pull successfully on my RPi.
I think the confusion comes from the fact it can take many minutes to pull and unpack the updates, during which time Makerverse says its “running” but it’s really running the update step…
When I upload Gcode to Makerverse, I press the “Play” button to start cutting. Sometimes, as I’m learning how Work position works in relation to Machine position, I find that the machine is going to do something I don’t want. I expected that I could press “Pause” or “Stop” to end what it is doing. However, neither of those buttons are enabled when the machine is running. The only way I’ve been able to stop the machine is to click “Reset” which stops it immediately but seems quite extreme.
Is this expected behavior or a bug in the button states for “Pause” and “Stop”?
I just figured this out myself, and did try to make some improvements (I thought these were in that #211 build you have). What you have circled are the “workflow” commands. They specifically control the GCode program. Not the machine, in general.
I think what you’re looking for is formally called Feedhold (and subsequently Cycle Start). These buttons used to be there all the time. Now, I made it so that when the machine is Running (e.g., moving) you should see this:
Pressing the Feedhold halts the shuttling and shows this:
WDYT?
I don’t like the fact that the run/hold badges are not buttons, but feedhold and cycle start are. I think this area generally needs polish…
I would lean toward simpler terminology - Pause instead of Feedhold and Start/Resume instead of Cycle Start. And if those buttons are added, the Gcode button bar has to go away - they appear to the user to be the same function.
Honestly, I don’t really understand what the existing Play/Pause/Stop buttons are intended to do if they don’t control machine function. I think it will be a trap for most users and the possible benefit likely doesn’t rise to the level that it should take up primary screen real estate.
You’re right. I’ve already started going down this code wormhole. Basically, I need to “normalize” the different states of different protocols (Grbl, Marlin, TingG, Smoothie, etc.) into a human-readable status badge. I’ll put the “formal” terms in tooltips, but abstract the whole thing behind a “normalized” version that applies to all machines.
clicking on it does nothing. I want to see the calibrated values. I screen shotted them and it says I’m within 1.8 mm now, but when I go to the calibration sheet, they are hidden, so I can’t save them just in case. How can I find them?
