OpenDACT(Delta Automatic Calibration Tool) - For Repetier

[RollieRowland]

Got it all back and the same thing happened around 20 iterations, starts going left again.... I've stopped for a while now

What step was the program on before you stopped it?

[dkaustin]

Rollie--

I was just running the basic calibration, using the default accuracy setting (.001, I think). I didn't think to save my height map; when I have some time, I'll re-run it. I only had to enter M112 G-code once, but Repetier had to do a couple of resends before the requested info came back. I have backed off the speed on the COM port FIFO buffers to see if that makes any difference.

[bvandiepenbos]

Rollie--

I was just running the basic calibration, using the default accuracy setting (.001, I think). I didn't think to save my height map; when I have some time, I'll re-run it. I only had to enter M112 G-code once, but Repetier had to do a couple of resends before the requested info came back. I have backed off the speed on the COM port FIFO buffers to see if that makes any difference.

It would be interesting trying a different host for sending M112...
Sometimes I have trouble with Repetier host connecting to the printer, however Pronterface/Printrun http://www.pronterface.com/ or S3D connects easily EVERY time. They must do communication differently?

[RollieRowland]

Rollie--

I was just running the basic calibration, using the default accuracy setting (.001, I think). I didn't think to save my height map; when I have some time, I'll re-run it. I only had to enter M112 G-code once, but Repetier had to do a couple of resends before the requested info came back. I have backed off the speed on the COM port FIFO buffers to see if that makes any difference.

Ok, I was concerned that the information didn't return at all. This is not as much of a problem. For the program to start, the EEProm values must be returned, then the process is initiated. My main question is what you meant previously about "starts going left"?

It would be interesting trying a different host for sending M112...
Sometimes I have trouble with Repetier host connecting to the printer, however Pronterface/Printrun http://www.pronterface.com/ or S3D connects easily EVERY time. They must do communication differently?

Yes, this could be because of how they have their COM port connection settings set up. It is more than likely that they are different in their communication methods, it is just finding how they differ and then using that information.

[dkaustin]

For me, M112 sent from MatterControl executes perfectly, sent from Repetier it requires multiple resends before it executes. I also had to uninstall Repetier Server; it was playing merry hell with the COM port.

[crocky]

My problems are:

Program starts and seems to work fine until about iteration 20 and then it's home setting begin to change at move a little to the left. When I saw that happening I aborted the run at iteration 30 because there was something wrong.

Then I had to enter the values to put it all back and at that time I thought to go to the normal calibrate and change to 10 iterations, it stopped after it had done ten and told me I need to run the advanced calibration.

So program exited then restart and away we go and when it got to 20 iterations in comes the left settings again, it seems something is putting incorrect setting in the eeprom. G28 then sends the printer home + new offset to where it now thinks home is.

?? Probe goes down to 10mm then speed reduces to go down the rest of the way touches off the probe then goes up 10mm and goes to the next etc....

I'll get it changed back this morning so I can do some more testing!

[RollieRowland]

My problems are:

Program starts and seems to work fine until about iteration 20 and then it's home setting begin to change at move a little to the left. When I saw that happening I aborted the run at iteration 30 because there was something wrong.

Then I had to enter the values to put it all back and at that time I thought to go to the normal calibrate and change to 10 iterations, it stopped after it had done ten and told me I need to run the advanced calibration.

So program exited then restart and away we go and when it got to 20 iterations in comes the left settings again, it seems something is putting incorrect setting in the eeprom. G28 then sends the printer home + new offset to where it now thinks home is.

?? Probe goes down to 10mm then speed reduces to go down the rest of the way touches off the probe then goes up 10mm and goes to the next etc....

I'll get it changed back this morning so I can do some more testing!

By changing home settings what do you mean? If I understand what you are saying you are on the XYZ offset calibration. During and after the calibration the towers will home and then drop a fair bit to offset for the endstops.

In the version you are running, my printer took about 30 iterations to calibrate, sometimes less. The purpose of the iteration limiter is to prevent the printer from running infinitely.

From what I can tell it is running normally, however I am not in front of your printer.

[crocky]

I'll get it changed back this morning, remove the powered hub, and run the printer directly to the TW802 and see if that makes a difference.

the change to the home settings is worry though..

[crocky]

With the TW802 connected directly to the printer it gets to iteration 21-22 before the the home begins changing. Always to the left..

Put everything back to normal and try with pause time COM at 1000, still the same. Get to 21-22 and then starts moving the home position to the left again. Every iteration after this the home gets worse!

This is with Version 3.0.0

Rostock Max V2

TW802 with Windows 10

AMICROE Powered Hub (same with and without)

[RollieRowland]

With the TW802 connected directly to the printer it gets to iteration 21-22 before the the home begins changing. Always to the left..

Put everything back to normal and try with pause time COM at 1000, still the same. Get to 21-22 and then starts moving the home position to the left again. Every iteration after this the home gets worse!

This is with Version 3.0.0

Rostock Max V2

TW802 with Windows 10

AMICROE Powered Hub (same with and without)

Ok, and that version was labeled incorrectly.

When the X tower offset is changed for instance, the printer will home normally, however, after it homes the carriage will lower on the X tower by the specified amount of steps in the EEProm. Usually it is a considerable amount, 300-400 steps, or around 5-6mm(80 steps per mm). When one tower is changed then the hot-end will not be centered in the middle of the plate - it most likely won't if you have successfully printed near the edge of the plate, unless your printer was perfect from the beginning. This being said, it may appear as if the hot-end is moving to the left, it most likely is. But it is correcting for how your current mechanical endstop error. The same displacement would occur if your mechanical endstops were changed.

I am assuming this is the error you are mentioning? If you would want to copy the log from the main console and email or pm it to me, then we can determine what the error actually is.

[crocky]

How can I copy the log... I can't select anything with the mouse. She's frozen, probably because I stopped it...

The program was 203PA....

I ran it again and it started going left again and then at iteration 28 the head ploughed into the bed even with FSR's on, hmmmmmmm!

I have got another windows 8 machine to try this out on, hang on while I get it

[crocky]

Back a version to 2.0.1B and the printer works and advanced calibrated beautifully. Probably took about 6 iterations!

Windows 10 in tablet did not like it with latest software.

Windows 8 in HP did not like it with the latest software.

Windows 8 in HP works well with 2.0.1B.

I'll put the tablet back on now and use it with 2.0.1B and I think I will leave it with that one for a while, sure has been a hard slog today though...

[RollieRowland]

Back a version to 2.0.1B and the printer works and advanced calibrated beautifully. Probably took about 6 iterations!

Windows 10 in tablet did not like it with latest software.

Windows 8 in HP did not like it with the latest software.

Windows 8 in HP works well with 2.0.1B.

I'll put the tablet back on now and use it with 2.0.1B and I think I will leave it with that one for a while, sure has been a hard slog today though...

That version's advanced calibration was very similar to the basic calibration that is about to be reimplemented, I just haven't been able to test it to upload it.

I am still questioning your issue in 2.0.3? By moving left what exactly do you mean?

[geneb]

crocky, if you've got a camera on your phone and can upload a video to youtube, I suspect it would help Rollie a LOT.

g.

[schlrobe]

I just got myself a dial indicator and printed out a simple mount from Thingaverse so I can use it for calibrations.

When trying to calibrate my Orion with the latest HTML version I keep getting a change to my horizontal radius that seems to be absurd. All the other changes seem to be good, but going from 75 to 95.829 is just a tad too much. Is there something that needs to be modified in the code for the smaller diameter of the Orion??? ANd yes, I am using the values from my eeprom and not the ones for the Rostock Max...

Thanks for all the work you all have put into this by the way.

Robert

[RollieRowland]

Yes, as Gene said, a video would be very useful in diagnosing the issue. The log would also help.

And schlrobe, that horizontal radius is absurd... don't use that. It is most likely a complication with the difference in printer size. I am assuming that you have used the expert mode to adjust the program for your printer? If you have, that version of the code doesn't learn from its mistakes, it would continue to return odd values. I will look into it, but it may be difficult due to not having a smaller/larger delta to test with.

I am almost done with testing the current changes. I have added a new mode of calibration; the first is the basic calibration which will work best with the RMax v2, the second is the basic calibration which learns each EEProm setting and adjusts specifically for your printer (now labeled advanced calibration), and then there is the heuristic calibration which learns your printer from scratch (except the EEProm, height, etc.) I am optimizing, and adding a couple methods of damage prevention for situations where the program decides it wants to send ridiculous values - mostly with the XYZ offset calibration.

[crocky]

PM sent with the log...

The home shift to the the left happens from about 21-22 iterations on, it is weird...

[RollieRowland]

PM sent with the log...

The home shift to the the left happens from about 21-22 iterations on, it is weird...

Found the issue:
XYZ offset percentages: -2.53571428571446, -1.11290322580644, and -0.615999999999985

Now I understand what you mean by moving to the left. It was the XYZ offset, however, the program was definitely not operating as it should have been. Let me explain why:

First of all, the XYZ offset percentages should be positive values, in which I have fixed via making them an absolute value(this is why your X offset was increasing exponentially, it was fixing the issue except in the wrong direction). Second of all I shouldn't have called them percentages, as they were no longer percentages and were actually 1/percentage. I actually was having issues with this specific part of the calibration on my machine - the value that is 1/percentage was returning infinity. I am rechecking the code to find out how this is happening - the input was 1/(0 - 0.7) and the return was infinity, when it should have been -1.43. Third, the equations needs to be fixed for that part of the advanced calibration.

The reason that the previous version is working is that it is most likely the version that I completely bypassed the offset percentage calibration and used the default values instead.

On a side note, I have implemented the error prevention that I recently mentioned, i.e. if the value is outside of a certain tolerance then it will not send it to the EEProm. This will mean that no values that are: infinity, 5.4*10^-43, or 2.5*10^31, get sent to the printer.

[crocky]

Thank you

I was not dreaming after all. I'm quite happy with the previous version for the time being.

[FRANCO888999]

Hi to all..sorry for my english..
I'm also using smoothieware and I'm very gald for your work....so if you want traslate your software to became compatible with smoothie, I'm will be very happy to became a beta tester for you!

Andrea

Fantastic, I'll keep that in mind! I am probably going to start looking into adding support for Smoothieware tonight, if I find time.

Hi,
Thankyou for your interest in smoothie,
currently I'm running the last iteration of the great firmware of 626pilot, that for me with his work has opened the doors to a new way to think about calibration of delta printer.
I have realy good result with his work, but I think that an external tool it's better for at least two reason:

1- no git problem...no synch with the main branch is needed because all the thing are made externaly (the tool) and the only interaction with the firmware is made with "standard" gcode ..for what does it means;-)
2- we have eyes and for this reason a graphical tool that not only correct the error but where you can see the error it better that only numbers...strange numbers that came from the screen.

So I hope in some news from you...thank you very much.

[RollieRowland]

Ok so good news and bad news for those who are running Smoothieboards...

Good news first, it is possible to calibrate printers with Smoothieboards.
Bad news, it is difficult to make software for something that I do not have to test with. So this most likely won't be completed until I get one - shouldn't be too long. I do want to make sure this version is stabile first as I won't be able to test with Repetier then...

Also, I am still trying to solve the puzzle as to why these values are returning oddly. Should be done soon - if not then I will just disable part of the calculation and use defaults for now. Will update soon.

Edit: The issue is now fixed, it was due to the temporary initial height never being saved for a comparison. I have a couple more changes I want to make and then I will upload what I have.

[crocky]

Thanks Rollie..

We don't mind if you test it first and make sure there is no problems, mine is really working nicely now with the old version.

[626Pilot]

Good news first, it is possible to calibrate printers with Smoothieboards.

If anyone with a Smoothieboard can't get your calibration running, they can run my fork and have that capability natively.

[bvandiepenbos]

Here is a gcode file I created to gather the data points with a dial indicator for Rollies html calibration script.
I put in on my sd card and run it from printer.
If you look at the gcode in a text editor the comments explain what it does.
Basically it homes then moves down to Z0 at center of bed, pauses for you to zero out your dial.
Then proceeds to probe the 3 tower locations and 3 opposite tower locations pausing to let you write down the number.
The spots are on a 130mm radius.

[stonewater]

contemplating FSR versus the switch method (feeler gauge and nozzle and a set of wires to the z min endstop) at some point we are swatting at gnats. is it worth the 50 bucks for FSR ?

Tom C