OpenDACT(Delta Automatic Calibration Tool) - For Repetier

[RollieRowland]

I really appreciate your work on this! Does the probing happen at a rate that's slow enough for someone to be able to successfully keep up with the nozzle if using a redneck z-probe? (alligator clip on the nozzle, other wire to a feeler gauge)

tnx!

g.

Just hope that it can help!

The default probing speed is 5mm/s and the default probing height is 10mm, so this gives you about 2 seconds. In the advanced settings panel you can manipulate the speed before pressing calibrate, which you may need to do.

[bvandiepenbos]

thanks for your great work Rollie.

[bvandiepenbos]

I just now got FSR working on one of my printers. It has a smoothie board. So, can I use the manual web page based program you made first?
Or can I use this new exe just letting it calc and save results to a plain text file which I then manually edit smoothie text config.

I am so excited to try this!

[RollieRowland]

I just now got FSR working on one of my printers. It has a smoothie board. So, can I use the manual web page based program you made first?
Or can I use this new exe just letting it calc and save results to a plain text file which I then manually edit smoothie text config.

I am so excited to try this!

I am assuming you are running smoothieware? If you are running Repetier, then this should work. However, if you are using smoothieware, the version that I've previously uploaded will not work, yet. Eventually there will be support for other firmware. What I can do to help you now is modify the html version so that it has the updated calibration code.

HTML Version 1.0.4:
https://drive.google.com/file/d/0B06WCA ... sp=sharing

This now has XY scaling correction, and should correctly set the XYZ offset in a couple of iterations. I just tested the code, and it returned values that seem reasonable. Let me know if you have any issues.

If you are wanting to use your FSRs, then to convert values to a height-map:

Code: Select all

//assuming you are starting at 10mm above the plate (probingHeight)
centerHeight = zMaxLength - probingHeight + probeHeightAtCenter;
X = centerHeight - (zMaxLength - probingHeight + probeHeightAtX);
XOpp = centerHeight - (zMaxLength - probingHeight + probeHeightAtXOpp);
Y = centerHeight - (zMaxLength - probingHeight + probeHeightAtY);
YOpp = centerHeight - (zMaxLength - probingHeight + probeHeightAtYOpp);
Z = centerHeight - (zMaxLength - probingHeight + probeHeightAtZ);
ZOpp = centerHeight - (zMaxLength - probingHeight + probeHeightAtZOpp);

//centerHeight is the z maximum length at the center of the plate

//invert values
X = -X;
XOpp = -XOpp;
Y = -Y;
YOpp = -YOpp;
Z = -Z;
ZOpp = -ZOpp;

Let me know if you need help.

[bvandiepenbos]

cool, thanks. I let you know how it goes. I need to adjust sensitivity of FSR trigger first, right now it takes way to much force to trigger.
yes, smoothie fw.
I am not sure what to do with the height map code for FSR. Though I can probably figure it out.
Yes, I want to use FSR instead of dial indicator.

I just now got FSR working on one of my printers. It has a smoothie board. So, can I use the manual web page based program you made first?
Or can I use this new exe just letting it calc and save results to a plain text file which I then manually edit smoothie text config.

I am so excited to try this!

I am assuming you are running smoothieware? If you are running Repetier, then this should work. However, if you are using smoothieware, the version that I've previously uploaded will not work, yet. Eventually there will be support for other firmware. What I can do to help you now is modify the html version so that it has the updated calibration code.

HTML Version 1.0.4:
https://drive.google.com/file/d/0B06WCA ... sp=sharing

This now has XY scaling correction, and should correctly set the XYZ offset in a couple of iterations. I just tested the code, and it returned values that seem reasonable. Let me know if you have any issues.

If you are wanting to use your FSRs, then to convert values to a height-map:

Code: Select all

//assuming you are starting at 10mm above the plate (probingHeight)
centerHeight = zMaxLength - probingHeight + probeHeightAtCenter;
X = centerHeight - (zMaxLength - probingHeight + probeHeightAtX);
XOpp = centerHeight - (zMaxLength - probingHeight + probeHeightAtXOpp);
Y = centerHeight - (zMaxLength - probingHeight + probeHeightAtY);
YOpp = centerHeight - (zMaxLength - probingHeight + probeHeightAtYOpp);
Z = centerHeight - (zMaxLength - probingHeight + probeHeightAtZ);
ZOpp = centerHeight - (zMaxLength - probingHeight + probeHeightAtZOpp);

//centerHeight is the z maximum length at the center of the plate

//invert values
X = -X;
XOpp = -XOpp;
Y = -Y;
YOpp = -YOpp;
Z = -Z;
ZOpp = -ZOpp;

Let me know if you need help.

[HumanLiberty]

Thanks for html v1.0.4 Rollie! With this I was able to calibrate to max variances of .07mm highest-lowest, .04mm from center, and a combined absolute value of only .12mm for all six points. Though I'm sure this is perfectly functional, I may run it through more iterations later just so see how far it can go - it's kind of addictive actually.
Two questions - 1) I noticed the "Measurement inversion" dropdown is gone - is v1.0.4 set up for calipers?
2) When using longer delta arms (325mm, in my case) should any other default EEPROM fields be changed aside from diagonal rod length?

Thanks!

[dkaustin]

OK, got my FSR's installed and downloaded v2.03 of the calibration tool. When I try to run, though, I'm getting the same hanging after "Request to read EEPROM sent" that others have seen. I'm running Win7 64-bit and Repetier v1.5.5. The calibration exe has full read/write privileges. Any suggestions appreciated.

[teoman]

Did you disconnect and quit other software?

[RollieRowland]

I just noticed that I modified the wrong html file, that was the version 1.0.0. I will update it to take probing values as well. That being said, I will modify v1.0.3 this time to get a few features back.

For the 325mm arms, all you have to change is the diagonal rod length. The delta radii will remain the same.

dkaustin, the problem is most likely arising from windows 7, I will compile a version in Windows 7 today and will test it as far as I can. I will upload that for you to test it but it may not be for a couple hours.

teoman, he wouldn't have been able to connect to the printer through the program if he had been using other software that interfaced with the printer. Since he reached that step, he had to have been connected. This means it is a problem in the software itself.

Edit: I have the updated version of the HTML version. For the probe height ( center height) use the height at the center of your plate - if you are using a probe.
https://drive.google.com/file/d/0B06WCA ... sp=sharing

This version was tested, and returned reasonable values.

[bvandiepenbos]

Rollie,
Would you label above the input boxes in the HTML version with text that describes what variable goes there? It is hard to remember what value goes where. When you hover over input box it just says "get this value from eeprom" uhhhh, what value?
Also the hover pop up text could be more descriptive.
Thanks

Is there a reason your stand alone .exe couldn't take manually gauged heights? Then possibly save to a text file for manual editing eeprom values. That mode would let you use your calib .exe with any firmware.
Also you would not have to maintain both versions, .HTML & .exe

It would be helpful if your .exe could generate simple gcode probe script that you could put on SD card and run to gather your data manually.
Just a thought, it is pretty simple to just type up your own gcode.

[RollieRowland]

Rollie,
Would you label above the input boxes in the HTML version with text that describes what variable goes there? It is hard to remember what value goes where. When you hover over input box it just says "get this value from eeprom" uhhhh, what value?
Also the hover pop up text could be more descriptive.
Thanks

Is there a reason your stand alone .exe couldn't take manually gauged heights? Then possibly save to a text file for manual editing eeprom values. That mode would let you use your calib .exe with any firmware.
Also you would not have to maintain both versions, .HTML & .exe

It would be helpful if your .exe could generate simple gcode probe script that you could put on SD card and run to gather your data manually.
Just a thought, it is pretty simple to just type up your own gcode.

I made the changes - use the same download link that was just previously posted.

The main reason for not including the manual calibration in the .exe is due to a lack of time on my part. It would not be too difficult to implement, so I will add it to my list.

[FRANCO888999]

I am assuming you are running smoothieware? If you are running Repetier, then this should work. However, if you are using smoothieware, the version that I've previously uploaded will not work, yet. Eventually there will be support for other firmware. What I can do to help you now is modify the html version so that it has the updated calibration code.

[/quote]

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

[RollieRowland]

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.

[forrie]

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.

Cool...seems like pilot626 has given up on smoothie board calibration.

[dkaustin]

Rollie--

Since you suspected that Windows 7 might be the culprit in my calibration hanging, I tried running in XP compatibility mode. Good news-- the calibration started normally. Bad news-- the nozzle didn't want to stop when it contacted the build plate, even though the FSR triggered. Confusing news-- when I tried to repeat the run in XP compatibility mode, the program again hangs after "Request to read EEPROM sent". Feels like progress, though.

[crocky]

Rollie,

He may be having problems with the signals from the FSR's... Mine show as H when at rest and go to L when activated...

Where is the easiest place the change it for the Z-probe to be L and the change to H when activated?

[RollieRowland]

Rollie--

Since you suspected that Windows 7 might be the culprit in my calibration hanging, I tried running in XP compatibility mode. Good news-- the calibration started normally. Bad news-- the nozzle didn't want to stop when it contacted the build plate, even though the FSR triggered. Confusing news-- when I tried to repeat the run in XP compatibility mode, the program again hangs after "Request to read EEPROM sent". Feels like progress, though.

Did the printer slow down when it reached the probing height? Also, have you reset your z-height since you have added the fsr mounts?

And to invert the values, you can modify the firmware and re-flash.

[bvandiepenbos]

There is a jumper on FSR board to invert high/low logic

[RollieRowland]

There is a jumper on FSR board to invert high/low logic

Right! Sorry, I had entirely forgot about the pins on the board. Here, this will help - https://github.com/JohnSL/FSR_Endstop

[dkaustin]

The printer DID slow down as it approached the build plate, so I think it's reading the correct Z-height. I inverted the FSR logic in firmware. Now if I could just get the calibration to run again. I've tried a number of compatibility settings, and the exe has administrator rights, but it still hangs after "Request to read EEPROM sent". I can't figure out why it ran that one time in XP compatibility mode but now hangs.

When it hangs, the "Advanced" window displays the following eleven times:

Resend: 17
ok

[RollieRowland]

The printer DID slow down as it approached the build plate, so I think it's reading the correct Z-height. I inverted the FSR logic in firmware. Now if I could just get the calibration to run again. I've tried a number of compatibility settings, and the exe has administrator rights, but it still hangs after "Request to read EEPROM sent". I can't figure out why it ran that one time in XP compatibility mode but now hangs.

When it hangs, the "Advanced" window displays the following eleven times:

Resend: 17
ok

Ok, well when the printer returns Resend it usually means that the data is being sent from the computer too fast.

Try sending M112 in your host to read the EEProm, then G31 to test the FSR controller, then test G30 to see if thr probing operates properly. If M112 works then try changing the COM port wait time from 500 to 1000 or 1500.

[dkaustin]

Success! XP Service Pack 2 compatibility mode is the key for me. With the FSR logic inverted in firmware, the FSR's trigger with the lightest of touches. The calibration ran for 17 iterations and converged to .02-.03mm all around. I was able to print this test pattern in ABS on a bare plate with no glue stick, a first for me. If the calibration isn't absolutely perfect, it's closer than I've ever been able to get before. If I get ambitious, I'll try going out to a larger print diameter, but for now I'm happy.

Rollie-- M112 works with hiccups; it took a couple of resends for the info to come over, so you're probably right about there being a speed issue. Even so, I can get a good calibration, now. Many thanks for all your hard work on this! Well done!

[RollieRowland]

Success! XP Service Pack 2 compatibility mode is the key for me. With the FSR logic inverted in firmware, the FSR's trigger with the lightest of touches. The calibration ran for 17 iterations and converged to .02-.03mm all around. I was able to print this test pattern in ABS on a bare plate with no glue stick, a first for me. If the calibration isn't absolutely perfect, it's closer than I've ever been able to get before. If I get ambitious, I'll try going out to a larger print diameter, but for now I'm happy.

Rollie-- M112 works with hiccups; it took a couple of resends for the info to come over, so you're probably right about there being a speed issue. Even so, I can get a good calibration, now. Many thanks for all your hard work on this! Well done!

I have a couple questions: What was your final height-map? What was your accuracy setting? How many times did you send M112 before it succeeded?

For the speed issue, I find it odd, as there is only one command (M112) sent to the printer - at first. This really should not cause an issue with the communication. I will read up on it, as it may be the serial port communication settings.

[crocky]

Nice to see mine going thru some iterations now, it's up to 20 now.....

EDIT: After twenty or so it started to move to the left, it now thinks the bed is moving to to left and the centre is changing to match it... something is wrong here? I stopped it at 30 iterations! What the best way to get it back....

[crocky]

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