Settings import OK, I go to run the chain calibration process. I’m using “premarked” chain calibration. Once I commit the chain settings and go back to frame the motor distance setting is reverted to -1286.56 and the system behaves abnormally on any movements (likely because of the number).
Thanks for that; I really appreciate you noting the specific point it happens, the settings involved, and the build number. I’ll have a closer look first thing tomorrow morning. Should be easy to find with that information.
Well, a new build (233) is up. I ended up rounding all the settings values. It made the UI a lot cleaner. I’m not 100% confident it’s fixed the problem yet. So if it does happen again, please do the following:
Return to the main screen
Copy the contents from the Console
Send them to me (paste here)
We’re looking for any case where the value gets set to a really long number (like $10=1.000000). This shouldn’t happen any more with build 233, since I’m truncating everything, but just FYI.
Something seems to be off with the calibration routine. I can not advance through the tabs with the “Next Step” button and none of the entered values from the calibration screen are saving. The previous builds had the “updating settings” pop up - that is not appearing. There does not appear to be any activity in the console when entering new values in the calibration modal.
I can update settings directly in the settings modal. I can move the sled using the
Yikes, sorry about that @scottfmosley — I should have run through the Calibration flow after making changes to how settings are saved. Easy fix; the build is working now and should be uploaded in ~30min.
I was just about to post the same issue about calibration. My numbers look better. I cleaned the input file to only have 2 digits after the decimal as well (lots of them were longer). Will test again once the next build is up.
So it seems better though I have still landed in some failure modes where; Y becomes reversed, the sled won’t move (motors just make noise), Z axis moves the sled rather than Z. But the most consistent thing I can make happen (after: full wipe of settings, import, then manual calibration, enter distance from top of stock to sled) is that home is calibrated to about 145mm higher than it should be and as the result much of the rest is off. I’m still trying to figure out if I’m doing something wrong but it seems like I’m following everything up till that point. I’m doing edge calibration now but decided to type this up first.
The only numbers that have more than 2 decimal in settings are chain sag, chain tolerance, and chain stretch, all 4 are all zeros.
A few other notes. One of the steps says “Make sure the sprockets are pointing straight up” How is it possible to set that at this point? You’ve already calibrated equal distance so you can’t get both sprockets in sync if they are out.
When you are doing the edge calibration, if the sled hangs over the edge do you use a negative number to indicate this?
I may be wrong, but AFAIK the only way that’s possible on the Mega is if you have the wires crossed.
edit but there may be a Grbl setting which would do the same thing. I wonder if one of your “invert” settings is somehow negative? I’ve never modified them myself.
Let’s have a look at your settings (paste the export). Also, what is the Y measurement you entered at the end of the “Set Chains” step?
There’s a jog / shuttle control on that screen. You can use it to move the sled up or down (turning the sprockets).
Since they are equal distance, they must be in-sync. The former implies the latter. If they are out of sync, they are not extended the same length.
Oh! One thing just hit me @ltfiend . I think the Holey firmware defaults to the wrong Kinematics mode if you do a full “Wipe.” You want “Triangular” kinematics (2).
It seems to be software related. When some number is out of sync it goes crazy. Right after a wipe I can get it moving but then after the calibration steps something is off. Maybe something with the rotations number I have 3.14 and 7560 for those numbers. I thought 7560 sounded high but I’m looking online and I see 17280 as a number?
Current export (after calibration) below. Y measurement when the “center” button takes it +145 is about 238 (I didn’t note the exact number, I will do so now)
Yep, you were right on this. I just set it to 2. I am going to rerun calibration with that set. We seem to be better on the X/Y but something is up with Z.
facepalm. I’ll add a guard that prevents you from running calibration if you’re not in triangular mode.
I should note, I just built the Z calibration tab, and I realize it may not work with the Mega. I would expect the Mega firmware to work correctly with default settings for Z-axis rotation (I’ve never had to change anything in WebControl AFAIK). That said, the goal is for the Z-axis tab to work well for calibrating any motor gear ratio (instead of just assuming a standard kit).
Sounds good, I’m getting different results based on some random numbers in the Z fields. I need to step away for a few but I’ll retry this in a bit and will report back on any findings.
Alright - just ran the calibration with #234 and the new doug fir top beam. Down to 1.8mm. I think that I am in business.
With #234, I did not notice any of the issues with the workpiece width resetting as @ltfiend and I have noted in previous builds.
I’m with @ltfiend the sprocket adjustment is not the same on the mega. My gears definitely do not move in tandem. It feels like there is a missing step of setting both gears to 0 before you adjust the chains?
I’m setting up to do a cut tomorrow. Will report back.
Ok, I’m now calibrated to 2.3mm after two runs of the precision calibration. However, it was not without some issues. Let me start with the most major.
Something is happening in the bottom right corner of precision cutting that causes Z to behave erratically. It only appears to happen on the bottom right corner. The first time, I started at center, moved directly to the center bottom point and then moved to the bottom right corner. During the move to the bottom right corner Z raised like 30mm even though it didn’t log this (so the hole still only attempted to go 3mm down). A second time (actually I tried the same thing the second time and it happened again), so the third time I did every other hole first (top center, top left, bottom left, bottom center, top right, then bottom right) and on the way to bottom right it dropped the bit about 30mm driving into the board and causing some general panic as I tried to stop the Z movement without breaking the calibration process. I was able to complete that cycle and that’s how I ended at 2.3.
To get this far I had a few issues, I had to load back to web control to get my Z to behave again. Once I did that it seems to have been fine in makerverse (other than the above issue). I have not attempted recalibration of Z in makerverse. My settings for Z are 7560 / -21.5. Also note I had tried multiple full reboots before that to get Z to work again and it was having none of it. I loaded web control mostly to make sure the motor hadn’t gotten fried but it behaved right instantly in web control. I’m not sure what changed but something did. There was another full reboot after this to get back to clean makerverse only (makerverse and webcontrol seem to have issues when trying to stop them, I didn’t dive into that yet)
I have had some difficultly importing settings, I haven’t ironed it out exactly but I think it wasn’t accepting imports with more than a certain number of decimals. Possibly related to the recent work? When I say wouldn’t import, nothing would happen when I click import, not the loading message or the refreshing settings message.
Lastly, after calibration my sled is logged as Width 310 and Height 139.0 even though it’s a round sled at 223 mm.
I think I’ll start attempting some cuts from here and see if I continue to notice Z movement strangeness,
Honestly, I can’t imagine anything other than hardware that would cause this. It’s simply not something which Makerverse could cause to happen, AFAIK. The Gcode is processed 100% on the Arduino side.
I’ve seen these exact symptoms caused by a wire that gets over-extended in the corner, thus flexing the wire and causing a poor connection.
What values are you referring to? These don’t look like things you could enter in the Z-calibration, to my eyes, and there should be no negative values, so this seems suspicious.
This really jumps out at me. Something seems very strange here. Nothing should behave differently in Web Control. The firmware is responsible for 100% of the movement controls, etc. — not WebControl/Makerverse. Could you please dig into this a little and explain in more detail what’s going on? If you issue the same command in each (e.g., jog Z up/down), what are the exact differences that happen?
Don’t worry about that. It’s actually a legacy setting that’s not used at all by the Maslow, it was just never removed from the Mega firmware. It is unrelated to the setting in discussion.
Z steps per revolution and z distance per rotation. The second one needs to be negative for it to move the right direction on mine.
Yeah will do. I’m going to get some cuts under my belt since I don’t enjoy that calibration process to much but I’m fairly confident I can recreate the scenario.
I have a z-axis sled that inverts the motor. (Pic below for reference)
Yeah understood, and it’s not that it’s complicated it’s just that it takes a while to run the edges. I’m not familiar enough with the unit to know what I can do without having to re-calibrate everything. I have started to add larger offsets to the calibration procedure (make the hole at 300mm rather than the default of 25.4.) That keeps my whole sled on the piece and saves a bit of time.