Welcome to the SeeMeCNC Community

PikachuPorkChops wrote:1. I did a quick check and can confirm my towers are in fact off by 1-2 degrees. The trouble with squaring them is that my bed domes at the centre, but I will try that tomorrow.
2. That was my assumption; it would have been impossible to get my tolerances otherwise.
3. Yes, I do home the printer every time, but there is a discrepancy between your gcode and when I do it through MatterControl.

I did a quick look (as it's quite late) and the square is 1mm higher on the side of the bed close to the X axis, with similar values on the X and Y. I guess it would be impossible to account for the "waviness" caused by this, but only an overall tilt in the bed.

As for the instructions, I think you were right in that writing a comprehensive overview is not of high priority, though maybe a rough set of steps should be created. The comprehensive bit can come, as you mentioned, once issues with the program are solved.

Ikarius wrote: Hey!
Just a quick question.
I used the manual config for my Rostock Max V2 and every time I enter the calculates values my printer starts behaving really weird.
If i run the GCode again it will move to the opposite x,y,z coordinates well above the intended height and move very slowly- the terminal keeps saying invalid delta coordinate.
I have to reset my EEProm via Arduino and re-upload the firmware to get it right again.
I ran this a few times now same result every time!
regards Ika

jason128 wrote: Just wanted to put out a big THANK YOU to RollieRowland and all the other contributors to this calibration software.
I think I now have a rostock max that can print over the entire build surface.
I've just put a few dollars into your donate account- more a token gesture of appreciation, which I think we should all do. I wish I got the same level of support I have had from you for some of the very expensive software we run at work!


Shifting my steps per mm to 80.45 has given me a calculated diagonal rod length of 269.03. (it was coming out at 273mm this means the prints are at scale in the XY, and more importantly the bed is now level in all areas. im getting pretty much +- 0.00 or 0.01 over all points- I'm very happy about that!

I Still have no idea why I was getting such a big error on the diagonal rod length, it just does not make sense.



here's some things I have learnt after chasing an impossible bed to level around for a month

1 The stock arms are just rubbish: - you need rubber bands on them to get kind of good result
Sorry Seeme CNC but these are just not fit for purpose. I ended getting a replacement sent sent out to me as the first set had too much play. They kindly sent a replacement set, and included the white plastic pivots as well, so they could check the play in them.- from their point of view they were 'good'. Unfortunately it turns out they were not. it wasn’t until I tied cable ties & rubber bands around them that I could get the autocalbration programme to work. This shows how the slop was messing with me getting my setup right.
I see the tricklazer arms happening soon… but these should be a upgrade, not a necessary replacement to a new machine- kinda of frustrating

2 I reckon the carrages should be tighter than the instructions say:
I ended up tightening them untill all had a nice firm amount of skidding friction against the track. At this tension the lateral play dissappears, and it seems the motors still have more than enough grunt to deal with the added friction.

3 If your diagional rod number is above about 269.5, there no way you are going to be able to print well over the entire bed.
you need to adjust the steps per mm, as otherwise although reading level, the effector will be changing height over the bed.

4 crashing the effector into the bed when autocalbrating:
I did this twice, it seems that for some machines the autocalbration tries a setting that’s way out, and the 10mm default probing length is not enough to pick it up before it crashes.
I suggest that the default value should be higher, particularly if you are doing The HAI calbration. its better that is rund a little slow than crashes. those who want to get smart can adjust the number down anyway.

The only other two little suggestions I have for the software are:
- it would be nice to have a probe test button before starting the software. Its possible for muppets like me to high/ Low settings reversed in the firmware (which believe me gets very ugly just when you think its all working perfectly, and have moved away for the machine)
- maybe the FSR/ Z probe drop down should not be under advanced settings- as it's something that needs to be set right, even is you don't want to mess with the advanced settings.( I also missed this once, which gets ugly too!)

Cheers and thanks again

Jason

RollieRowland wrote:Since your tower scaling didn't change, what were your end results for the diagonal rod length and horizontal radius? (or SmoothieWare equivalents)

[PK] Current kinematic settings:
[PK]           Arm length: 271.799
[PK]         Delta radius: 134.761
[PK]      Endstop offsets: {-0.511, 0.000, -0.175}
[PK] Radius offsets (ABC): {0.000, 0.022, 0.022}
[PK]  Angle offsets (DEF): {-0.380, 0.023, -0.221}
[PK]     Virtual shimming: {0.126, 0.001, -0.126}, vector={0.001, 0.001, 1.000}, d=-0.016, Enabled
[PK]          Tower scale: {1.000, 1.000, 1.000}
[PK] Depth (Z) correction: Disabled

jason128 wrote: cheers,
by FSR/Z-Probe drop down, i meant the drop down menu where you choose the probe type, which currently defaults to FSR. - maybe this could be up as part of the initial settings
i.e build diameter, baud rate, & probe type?

I had the Z probe set at 30mm when i had the crashes. For some reason, a good way through the calibration, it would try some big tower offsets. obviously these didn't work! As long as the z probe height was 50mm it tested them, realized they were rubbish, and moved on. I'm not sure why it tried these big offsets- it was a long way into the calibration process. This s was before i added rubber bands to the arms, but for whatever reason it was possible get it to crash. (consider me the crash test dummy)

626Pilot wrote:

RollieRowland wrote:Since your tower scaling didn't change, what were your end results for the diagonal rod length and horizontal radius? (or SmoothieWare equivalents)

Code: Select all

[PK] Current kinematic settings:
[PK]           Arm length: 271.799
[PK]         Delta radius: 134.761
[PK]      Endstop offsets: {-0.511, 0.000, -0.175}
[PK] Radius offsets (ABC): {0.000, 0.022, 0.022}
[PK]  Angle offsets (DEF): {-0.380, 0.023, -0.221}
[PK]     Virtual shimming: {0.126, 0.001, -0.126}, vector={0.001, 0.001, 1.000}, d=-0.016, Enabled
[PK]          Tower scale: {1.000, 1.000, 1.000}
[PK] Depth (Z) correction: Disabled

My favorite thing about this is the radius offsets. They've always come in very close to 0 ever since I upgraded to the Trick Laser frame.

RollieRowland wrote: Are you not concerned about the change in the diagonal rod/delta radius? Does your calculation know that the change in tower scaling will give the same results to the change in arm length/horizontal radius? This of course will give your correct values for your diagonal rod and horizontal(delta) radius, while only correcting the tower scaling.

PikachuPorkChops wrote:Okay, so I've squared the towers against the headed bed (sans the glass) and I had a bit more luck. This time I managed to calibrate all six points to +/- 0.005mm, and like last time, I ran into problems when I replaced the calipers with the hotend. I tried printing some calibration circles and was able to successfully do it up to 6.5cm from the center. The outermost ring (13.5cm radius) only ended up being able to print in the areas directly across from each of the towers. The layer thickness in the areas it was able to print was 0.1mm lower than the layer height specified. I'm honestly stumped. Deduction would lead me to believe that something is going wrong when I switch between the calipers and the hotend, though you mentioned there shouldn't be a problem with that. This time I didn't even need to change the Z-height when I switched them.

I'm starting to wonder whether the calipers are reliable or not.

Also: Should the bed heat be on when I'm calibrating? This time I tried it with the bed at 85C as I know the bed warps significantly in the center at higher temperatures. Prior, I did not attempt calibrating with the bed on.

EDIT: The discrepancy I mentioned was that when I compared the heights between when your gcode and MatterControl are used to bring the effector to Z0, I found that your gcode brought it 1-2mm lower than MC.

626Pilot wrote: The algorithm only knows how to arrive at an optimal solution (lowest average Z error across all sampled points), and how to arrive at that solution in seconds. It uses the firmware's own kinematic functions to simulate a virtual printer, and then tries to see what combination of variables would make that printer most closely produce the measured real-world values. The version I'm using now predicted an average deviation of 0.046, and produced a real-world average deviation of 0.054, so it has become fairly good. (That's a smaller difference than the measured repeatability of the probe!) If I tell the algorithm that the arm length is 269.0000, and then tell it to anneal every variable except arm length, it will produce worse results. The left-right freedom in the joints may be some of why this happens.

The other thing is that any left-right tower lean, or differences in arm lengths, will tweak the effector out of tram by a small amount. As many who have tried to use a 2- or 4-nozzle setup can attest, any given nozzle may be too low in one position and too high in another. (That happened to me when I tried to set up my Chimera hot end on my MAX v1 and is why I started using the Cyclops instead.) That only happens when the effector isn't tram with the print surface. When the platform is tweaked like that, the probe will hit in a slightly different position - and elevation - than it should, and that will change according to XY position. My code doesn't know about this, nor how far the probe projects below the effector at the elevation where it triggers. If it did, it might be able to factor those discrepancies out of contaminating the rest of the variables, as they probably are now.

DSteck wrote:I made a Z-probe by bending a thing piece of sheet metal to screw to the effector plate and touch the nozzle. On the underside is a 4mm diameter FSR taped to the sheet metal. I use a pull-down resistor between - and the lead of the FSR connected to S for the z-min endstop, and the other end of the FSR is connected to the + side. I've checked it with G31, and it reads L when not pushed into the glass and H when pushed into the glass.

When I run the calibration program, it reads the EEPROM, sends out a G28, and then stalls out and does nothing. This is on 2.0.4PA.

Is there something I'm missing that would cause this? Before I used the pull-down resistor (and consequently had inverted logic on the FSR), it would just run through the air, but now it won't do anything.

Edit: Nevermind, I forgot to set #define Z_PROBE_WAIT_BEFORE_TEST false (it was still true).

PikachuPorkChops wrote:Rollie,
It's no doubt a problem on my end, thanks for the amazing program and help. I'll post back when I figure out what's going wrong.

DSteck wrote: I made a Z-probe by bending a thing piece of sheet metal to screw to the effector plate and touch the nozzle. On the underside is a 4mm diameter FSR taped to the sheet metal. I use a pull-down resistor between - and the lead of the FSR connected to S for the z-min endstop, and the other end of the FSR is connected to the + side. I've checked it with G31, and it reads L when not pushed into the glass and H when pushed into the glass.

When I run the calibration program, it reads the EEPROM, sends out a G28, and then stalls out and does nothing. This is on 2.0.4PA.

Is there something I'm missing that would cause this? Before I used the pull-down resistor (and consequently had inverted logic on the FSR), it would just run through the air, but now it won't do anything.

Edit: Nevermind, I forgot to set #define Z_PROBE_WAIT_BEFORE_TEST false (it was still true).

DSteck wrote:Thanks! And thanks for this integrated tool. I suspect my machine is out a little as it took 17 iterations on basic to calibrate. I have the Trick Laser 269mm arms which measured to more like 270mm, and the program pushed my length to 272.

I tried running the AI version, and it began to just make wild adjustments to rod length up and down. It would add 2mm, then subtract 3mm, then add 4mm, etc. I had to abort it and reset the values in EEPROM to run again in basic.

DSteck wrote:For now, I'm still printing random crap as I burn through this roll of brown ABS. I've been more concerned with warping due to lack of bed heat which is now solved with my SP-600-24 and a Crydom D1D40 running at half duty cycle. If you want to release another version that edits the steps per mm, I'd be happy to try it. I just checked my rods again, and they're almost exactly 270mm from center to center of the axles they ride on.

DSteck wrote:Got it downloaded and tried to run it, but it crashes when it tries to read the EEPROM.

It said it generated files describing the problem, but the files don't exist where it says they were supposed to be.