i looked in the forum to see if anybody had a similar problem but looks like not. I would love to put a cross on the final maslow frame design, but I’m getting stuck after doing the calibration phase now for the 7th time. Testing now on three computers with different OS - windows and linux. Always the same pattern: I start the calibration procedure, get quite at the end of it and if we are able to complete all steps and start to cut a piece, at the certain point the procedure breaks. This wouldn´t be the major problem, but after there is no way to go back to the center with the ´return to home´ button. At this point the home is moved somewhere out of the surface. And all calibration done so far is lost.
To be sure i´m not going crazy my colleague and me repeated the procedure once again, with the same result. Firmware and ground control updated. Other strange thing, if at the beginning the cuts for calibrating in step 8 were moving along the plate with a regular increase, this time after a quite equal horizontal-vertical value, instead of improving they get worse and begin to be scattered along the plate.
We tried everything to be sure itßs not an operating system or computer problem, we are using the short given cable with no extension. Any ideas out there? Thanks
SledNewGCode was the last - we used Makercam - and because of BufferOverflow we were also thinking that there could be a problem with the files (too long decimal or something but this is what Makercam exports) - and there was also the connection lost problem
the errors are not the big thing, it’s a learning process but the lost of the calibration again and again gets now really frustrating - how to save the calibration in a specific file for the controller? or is there a kind of reset - like: put the chains in a specific position, load some parameters and make a manual reset!?
The fastest way to get back is: Once the chain lengths are calibrated, mark the chain links the are at the 12 o’clock positions on the sprockets. That way you only need to turn the sprockets to 12 o’clock, put the chains back in place and use the >Advanced>Calibrate Chain length manual and you are back in the game.
Edit: Thanks for the files. I stumbled over isolated G91 commands in the log file you uploaded, but was likley on the wrong path there. Nothing in the cut files. However, CAMotics complains a few thousand times: ->Sled.nc:4056:Arc radiuses differ by 0.00218518, SledNewGcode.nc:7228:Arc radiuses differ by 0.00266835. Perhaps something to dig deeper.
As soon as I get a chance I will take those files to my Maslow and see what it does with them.
Second Edit: I can confirm a buffer overflow in the office with no motors connected. @BadaboomBerlin Did you try to switch the Truncate Floating Point Numbers to on in the Advanced Settings?
rather than moving incrementally forward through the commits, look at git
bisect, it does a binary search through the commits, so it narrows things down fast
Hi guys, thank you for the reply. Unfortunately we can’t dedicate to Maslow the time we would like, so we are most likely to test your suggestions in the next days. @Gero thanks for the tip on how to quickly save and manually re-adjust the chains - and for the offline makercam. About the Truncate floating point i until now never entered the Advanced Settings section. @dlang i didn’t hear any chain slipping in the test cut procedure. Loss of power? At the moment the power is plugged into a 10 meter extension, I will try to plug it nearer to the source.
About the g-code maybe in general would be better start just with just cuts and no engraves, and see if this works with no problems. @krkeegan we were having the same problems also with previous version of gc and firmware.
We’ll update you as soon as we have news - and hopefully improvements.
THANKS
I believe that I’ve tracked down the issue that was causing this
The issue was that if the machine tried to load it’s position from memory before it had been told the specs for the motors it would load an incorrect position, then save incorrect chain lengths to memory. The next time the position was loaded from memory it would be wrong and the machine would try to compute a new position from the incorrect chain lengths and fail.
The fix is currently on the master branch of both the firmware and Ground Control.
Is anyone available to give it a test before I publish the release? I’d love to know that we got this one in the release.
I can see the B12 and B03 messages passing and the ‘Kinematics Settings Loaded’ message in the log.
I put myself into ‘broken’ again and did a manual re-cal and it seems OK.
Something funny, though. I’ve ‘returned to Cednter’ and 'Home’ed the machine and quit. When I start up the X: and Y: position values start at 0mm, then after the connection is established I see odd values for X: and Y: for a moment then X: goes to 0 and Y: goes to 0.02 or 0.01. ‘Home’ runs the motor and Y: goes to 0. Every time I restart this happens, repeatedly. Y: moves 0.01 or 0.02 every time.
So, - where are the odd values coming from, and why is Y: off every startup?
But my machine isn’t moving when I press the home button.
The position loaded at not being exactly zero makes sense seems normal to me. Mine was off by ~.5mm after a big move to home (which seems normal) then on subsequent loads it was pretty much spot on zero:
by the way, it’s important to realize exactly what the ‘lost calibration’ error
really means.
It doesn’t mean that the chains are in the wrong place or have anything to do
with the actual physical location of the sled.
All it means is that given the dimensions that it’s been told, and the length of
the chains that it’s been told have been played out, the firmware cannot figure
out where the bit is.
It’s a math problem
now, the most common cause of this is that the firmware doesn’t have the right
dimensions entered into it, and the ones that have been entered don’t actually
have a solution (if you have 11 ft between the motors and 4 ft of chain on each
side, you cannot find any location to match because the chains won’t reach the
sled for example)
That being said, just before the simulation was integrated into Ground Control,
I did a pass over the entire work area with a 1mm grid and found that there were
two spots where the math still failed, I’ve never had a chance to go back and
work on narrowing things more (I had local tweaks to write the data to stdout
instead of plotting it, as plotting it ate up too much ram, trying to make these
changes integrated with Ground Control was more effort than I wanted to do)
Hi,
I, too, have been experiencing similar issues.
Being a newbie, I’ve just thought I had been doing stuff wrong.
So I’ve spent days starting from scratch, but getting same issues occurring.
Was tearing my hair out trying all sorts of ideas gleaned from forum posts…
Plus, when I calibrated the z-axis, left motor pays out as well!]
Hoping 0.85 will sort thing out; next thing to try.
