OpenDACT(Delta Automatic Calibration Tool) - For Repetier

mhackney · Post by **mhackney** » Sat Aug 15, 2015 3:17 pm

Spoke too soon, it crashed after a minute or so after completion. I was not doing anything as I was on the phone and when I looked over, it was crashed.

RollieRowland · Post by **RollieRowland** » Sat Aug 15, 2015 3:26 pm

mhackney wrote:Ok, after issuing the M206 command above in RH and then re-running v2.0.0, it hangs immediately every time I click Calibrate. I rebooted the printer and tried several times.

There seems to be an issue with the handler, I can't figure it out though. I will need to try a bunch of tests and debug. I'll need to be in front of my printer to try to fix this.

So the program said calibration complete? Since your printer returns the zprobe value differently it may have reported the actual heights as zero. Why it crashed afterwards, I couldn't tell you. I'll do some more digging through the code.

mhackney · Post by **mhackney** » Sat Aug 15, 2015 3:27 pm

No, it did not say calibration complete. I assumed it completed but am probably wrong.

RollieRowland · Post by **RollieRowland** » Sat Aug 15, 2015 3:55 pm

mhackney wrote:No, it did not say calibration complete. I assumed it completed but am probably wrong.

Ahh ok, so it just sent the gcode to your printer, then when it went to process that information it failed because it didn't have your EEProm data. So you are in the same stance as I am, except V2.0.0 cannot parse your eeprom. You could try to copy the event handler from 2.0.0 and copy it to the 2.0.1, then see what happens!

Edit: My computer keeps getting a bsod, I'm going to fix it then will be back to looking through the code.

mhackney · Post by **mhackney** » Sat Aug 15, 2015 7:26 pm

Ok, I don't have a dev environment on a Windows 8.1 machine - the laptop is my son's college laptop and they use Python for the work he does. I don't want to mess with it before he goes back. But now that I have it building in Mono and it seemed that there were some issues in various versions, I can go back and check Windows 7 again.

I recompiled the 2.0.0 sources on OS X Mono and I can connect and issue a G28 and the machine homes! That means we have a connection. But M206 just returns. I can now debug this though and see exactly what the Mac RH is returning and look at your new parser code and go from there.

RollieRowland · Post by **RollieRowland** » Sat Aug 15, 2015 7:28 pm

mhackney wrote:Ok, I don't have a dev environment on a Windows 8.1 machine - the laptop is my son's college laptop and they use Python for the work he does. I don't want to mess with it before he goes back. But now that I have it building in Mono and it seemed that there were some issues in various versions, I can go back and check Windows 7 again.

I recompiled the 2.0.0 sources on OS X Mono and I can connect and issue a G28 and the machine homes! That means we have a connection. But M206 just returns. I can now debug this though and see exactly what the Mac RH is returning and look at your new parser code and go from there.

Ok, let me know what you figure out!

mhackney · Post by **mhackney** » Sat Aug 15, 2015 7:32 pm

Will do. Dealing with USB is a PIA. Now I can't connect from RH or your exe - can't find the device. Every time I develop cross platform code for USB I run into this stuff. Just a PIA.

mhackney · Post by **mhackney** » Sun Aug 16, 2015 10:18 am

The serial connection handling has some issues and after spending a lot of time trying to sort through them I decided to write a simple test program to make sure the connection stuff works (and cross platform too). With the 2.0.0 code I could connect on Mac and Windows and issue gcode commands and calibrate (but I actually only did this on Windows since I don't want to mess with my Rostock calibration yet). I would crash every time on all systems, apparently during the calibration. This forced me to reboot as my USB system was totally hosed (i.e. other SD cards would dismount and could not be found, apps would hang, nasty stuff!). I discovered that even if I just let the app sit after connecting, it would crash in a few minutes, indicating a buffer overflow or memory management issue.

To isolate and simplify I started with some sample source and modified it to talk bidirectionally with our printers. Basically, it is a command line tool that connects and reads on a thread and sends messages from the main thread. I have it wired to send 2 messages, a G28 and an M205, so I can test a simple command and a command that returns data. It works perfectly, no crashes even running over night, and it works on Mono on Mac and native Windows 8.1. I'll try Windows 7 later but I don't expect there to be an issue.

RollieRowland, here is the output from an M205. As you can see, there are not time stamps so maybe that was something Repetier Host was adding and this is the actual data coming from the printer:

Code: Select all

M205

ok 0
EPR:2 75 250000 Baudrate
EPR:3 129 93582.731 Filament printed [m]
EPR:2 125 2672672 Printer active [s]
EPR:2 79 1800000 Max. inactive time [ms,0=off]
EPR:2 83 360000 Stop stepper after inactivity [ms,0=off]
EPR:3 11 213.3333 Steps per mm
EPR:3 23 300.000 Max. feedrate [mm/s]
EPR:3 35 80.000 Homing feedrate [mm/s]
EPR:3 39 36.000 Max. jerk [mm/s]
EPR:3 133 0.000 X home pos [mm]
EPR:3 137 0.000 Y home pos [mm]
EPR:3 141 0.000 Z home pos [mm]
EPR:3 145 280.000 X max length [mm]
EPR:3 149 280.000 Y max length [mm]
EPR:3 153 340.370 Z max length [mm]
EPR:3 59 9000.000 Acceleration [mm/s^2]
EPR:3 71 3000.000 Travel acceleration [mm/s^2]
EPR:3 881 269.000 Diagonal rod length [mm]
EPR:3 885 133.550 Horizontal rod radius at 0,0 [mm]
EPR:3 925 200.000 Max printable radius [mm]
EPR:1 891 70 Segments/s for travel
EPR:1 889 180 Segments/s for printing
EPR:1 893 0 Tower X endstop offset [steps]
EPR:1 895 0 Tower Y endstop offset [steps]
EPR:1 897 0 Tower Z endstop offset [steps]
EPR:3 901 210.000 Alpha A(210):
EPR:3 905 330.000 Alpha B(330):
EPR:3 909 90.000 Alpha C(90):
EPR:3 913 0.000 Delta Radius A(0):
EPR:3 917 0.000 Delta Radius B(0):
EPR:3 921 0.000 Delta Radius C(0):
EPR:3 933 0.000 Corr. diagonal A [mm]
EPR:3 937 0.000 Corr. diagonal B [mm]
EPR:3 941 0.000 Corr. diagonal C [mm]
EPR:3 808 0.000 Z-probe height [mm]
EPR:3 929 5.000 Max. z-probe - bed dist. [mm]
EPR:3 812 60.000 Z-probe speed [mm/s]
EPR:3 840 10.000 Z-probe x-y-speed [mm/s]
EPR:3 800 0.000 Z-probe offset x [mm]
EPR:3 804 0.000 Z-probe offset y [mm]
EPR:3 816 -77.000 Z-probe X1
EPR:3 820 -45.000 Z-probe Y1
EPR:3 824 77.000 Z-probe X2
EPR:3 828 -45.000 Z-probe Y2
EPR:3 832 0.000 Z-probe X3
EPR:3 836 90.000 Z-probe Y3
EPR:0 880 1 Autolevel active (1/0)
EPR:3 976 0.000 tanXY Axis Compensation
EPR:3 980 0.000 tanYZ Axis Compensation
EPR:3 984 0.000 tanXZ Axis Compensation
EPR:0 106 0 Bed Heat Manager [0-3]
EPR:0 107 255 Bed PID drive max
EPR:0 124 80 Bed PID drive min
EPR:3 108 196.000 Bed PID P-gain
EPR:3 112 33.000 Bed PID I-gain
EPR:3 116 290.000 Bed PID D-gain
EPR:0 120 255 Bed PID max value [0-255]
EPR:0 1020 0 Enable retraction conversion [0/1]
EPR:3 992 3.000 Retraction length [mm]
EPR:3 1000 40.000 Retraction speed [mm/s]
EPR:3 1004 0.000 Retraction z-lift [mm]
EPR:3 1008 0.000 Extra extrusion on undo retract [mm]
EPR:3 1016 20.000 Retraction undo speed
EPR:3 200 957.260 Extr.1 steps per mm
EPR:3 204 100.000 Extr.1 max. feedrate [mm/s]
EPR:3 208 25.000 Extr.1 start feedrate [mm/s]
EPR:3 212 6500.000 Extr.1 acceleration [mm/s^2]
EPR:0 216 1 Extr.1 heat manager [0-3]
EPR:0 217 205 Extr.1 PID drive max
EPR:0 245 60 Extr.1 PID drive min
EPR:3 218 14.9100 Extr.1 PID P-gain/dead-time
EPR:3 222 0.5900 Extr.1 PID I-gain
EPR:3 226 93.8500 Extr.1 PID D-gain
EPR:0 230 255 Extr.1 PID max value [0-255]
EPR:2 231 0 Extr.1 X-offset [steps]
EPR:2 235 0 Extr.1 Y-offset [steps]
EPR:1 239 1 Extr.1 temp. stabilize time [s]
EPR:1 250 150 Extr.1 temp. for retraction when heating [C]
EPR:1 252 0 Extr.1 distance to retract when heating [mm]
EPR:0 254 255 Extr.1 extruder cooler speed [0-255]

I also see the continual stream of "waits" the printer is sending. I'll filter those out to make the utility more friendly. What I'm going to do next is merge your 2.0.1 advanced calibration code into this incrementally and validate everything works as we go along. I have a family function today (dinner before all the kids go of to college later this week, you must be in the same boat!).

I'll email you the test code now so you can take a look at it.

RollieRowland · Post by **RollieRowland** » Sun Aug 16, 2015 12:54 pm

mhackney wrote:The serial connection handling has some issues and after spending a lot of time trying to sort through them I decided to write a simple test program to make sure the connection stuff works (and cross platform too). With the 2.0.0 code I could connect on Mac and Windows and issue gcode commands and calibrate (but I actually only did this on Windows since I don't want to mess with my Rostock calibration yet). I would crash every time on all systems, apparently during the calibration. This forced me to reboot as my USB system was totally hosed (i.e. other SD cards would dismount and could not be found, apps would hang, nasty stuff!). I discovered that even if I just let the app sit after connecting, it would crash in a few minutes, indicating a buffer overflow or memory management issue.

To isolate and simplify I started with some sample source and modified it to talk bidirectionally with our printers. Basically, it is a command line tool that connects and reads on a thread and sends messages from the main thread. I have it wired to send 2 messages, a G28 and an M205, so I can test a simple command and a command that returns data. It works perfectly, no crashes even running over night, and it works on Mono on Mac and native Windows 8.1. I'll try Windows 7 later but I don't expect there to be an issue.

RollieRowland, here is the output from an M205. As you can see, there are not time stamps so maybe that was something Repetier Host was adding and this is the actual data coming from the printer:
Code: Select all
M205

ok 0
EPR:2 75 250000 Baudrate
EPR:3 129 93582.731 Filament printed [m]
EPR:2 125 2672672 Printer active [s]
EPR:2 79 1800000 Max. inactive time [ms,0=off]
EPR:2 83 360000 Stop stepper after inactivity [ms,0=off]
EPR:3 11 213.3333 Steps per mm
EPR:3 23 300.000 Max. feedrate [mm/s]
EPR:3 35 80.000 Homing feedrate [mm/s]
EPR:3 39 36.000 Max. jerk [mm/s]
EPR:3 133 0.000 X home pos [mm]
EPR:3 137 0.000 Y home pos [mm]
EPR:3 141 0.000 Z home pos [mm]
EPR:3 145 280.000 X max length [mm]
EPR:3 149 280.000 Y max length [mm]
EPR:3 153 340.370 Z max length [mm]
EPR:3 59 9000.000 Acceleration [mm/s^2]
EPR:3 71 3000.000 Travel acceleration [mm/s^2]
EPR:3 881 269.000 Diagonal rod length [mm]
EPR:3 885 133.550 Horizontal rod radius at 0,0 [mm]
EPR:3 925 200.000 Max printable radius [mm]
EPR:1 891 70 Segments/s for travel
EPR:1 889 180 Segments/s for printing
EPR:1 893 0 Tower X endstop offset [steps]
EPR:1 895 0 Tower Y endstop offset [steps]
EPR:1 897 0 Tower Z endstop offset [steps]
EPR:3 901 210.000 Alpha A(210):
EPR:3 905 330.000 Alpha B(330):
EPR:3 909 90.000 Alpha C(90):
EPR:3 913 0.000 Delta Radius A(0):
EPR:3 917 0.000 Delta Radius B(0):
EPR:3 921 0.000 Delta Radius C(0):
EPR:3 933 0.000 Corr. diagonal A [mm]
EPR:3 937 0.000 Corr. diagonal B [mm]
EPR:3 941 0.000 Corr. diagonal C [mm]
EPR:3 808 0.000 Z-probe height [mm]
EPR:3 929 5.000 Max. z-probe - bed dist. [mm]
EPR:3 812 60.000 Z-probe speed [mm/s]
EPR:3 840 10.000 Z-probe x-y-speed [mm/s]
EPR:3 800 0.000 Z-probe offset x [mm]
EPR:3 804 0.000 Z-probe offset y [mm]
EPR:3 816 -77.000 Z-probe X1
EPR:3 820 -45.000 Z-probe Y1
EPR:3 824 77.000 Z-probe X2
EPR:3 828 -45.000 Z-probe Y2
EPR:3 832 0.000 Z-probe X3
EPR:3 836 90.000 Z-probe Y3
EPR:0 880 1 Autolevel active (1/0)
EPR:3 976 0.000 tanXY Axis Compensation
EPR:3 980 0.000 tanYZ Axis Compensation
EPR:3 984 0.000 tanXZ Axis Compensation
EPR:0 106 0 Bed Heat Manager [0-3]
EPR:0 107 255 Bed PID drive max
EPR:0 124 80 Bed PID drive min
EPR:3 108 196.000 Bed PID P-gain
EPR:3 112 33.000 Bed PID I-gain
EPR:3 116 290.000 Bed PID D-gain
EPR:0 120 255 Bed PID max value [0-255]
EPR:0 1020 0 Enable retraction conversion [0/1]
EPR:3 992 3.000 Retraction length [mm]
EPR:3 1000 40.000 Retraction speed [mm/s]
EPR:3 1004 0.000 Retraction z-lift [mm]
EPR:3 1008 0.000 Extra extrusion on undo retract [mm]
EPR:3 1016 20.000 Retraction undo speed
EPR:3 200 957.260 Extr.1 steps per mm
EPR:3 204 100.000 Extr.1 max. feedrate [mm/s]
EPR:3 208 25.000 Extr.1 start feedrate [mm/s]
EPR:3 212 6500.000 Extr.1 acceleration [mm/s^2]
EPR:0 216 1 Extr.1 heat manager [0-3]
EPR:0 217 205 Extr.1 PID drive max
EPR:0 245 60 Extr.1 PID drive min
EPR:3 218 14.9100 Extr.1 PID P-gain/dead-time
EPR:3 222 0.5900 Extr.1 PID I-gain
EPR:3 226 93.8500 Extr.1 PID D-gain
EPR:0 230 255 Extr.1 PID max value [0-255]
EPR:2 231 0 Extr.1 X-offset [steps]
EPR:2 235 0 Extr.1 Y-offset [steps]
EPR:1 239 1 Extr.1 temp. stabilize time [s]
EPR:1 250 150 Extr.1 temp. for retraction when heating [C]
EPR:1 252 0 Extr.1 distance to retract when heating [mm]
EPR:0 254 255 Extr.1 extruder cooler speed [0-255]
I also see the continual stream of "waits" the printer is sending. I'll filter those out to make the utility more friendly. What I'm going to do next is merge your 2.0.1 advanced calibration code into this incrementally and validate everything works as we go along. I have a family function today (dinner before all the kids go of to college later this week, you must be in the same boat!).

I'll email you the test code now so you can take a look at it.

That is fantastic! I'm going to see what you came up with and see if I can merge some code over to test. If I come up with anything I'll send it to you to test again!

Let me know if you find anything else out too! Also, yes I know what you mean, I'm going to be heading back to college soon. Hopefully, I'll be able to take my printer with me...

Anyway, I'm going to start digging through the code.

mhackney · Post by **mhackney** » Sun Aug 16, 2015 1:07 pm

I just emailed you the latest with a description. I've retrofitted the serial connection code into your application. But I did remove all of the calibration code so we can focus on getting the connection and message sending/receiving stuff rock solid. It will be easy to add back in once that is done. I'm almost there, just have 2 little issues I describe in the email.

stonewater · Post by **stonewater** » Mon Aug 17, 2015 1:16 pm

my V1 is calibrated retty good, but still having problems with the last 1/2 inch of reach, it really looks like it is a delta arm length problem. anyway has anyone designed a mount that can use the digital caliper like the one rollie used in his Vid? if we could leave the stock hotend on and just pass the end of the caliper thru the holes in the top plate of the extruder mount I would be good to go since I already have the grizzly version of that particular digital caliper. I realy do not want to take my hot end apart... again. since I just put in a cartridge heater and new thermistor and its printing nice right now.

Tom C

mhackney · Post by **mhackney** » Mon Aug 17, 2015 2:35 pm

Ok, we are making some good progress now. I passed the framework that makes connections and communicates to the printer to Rollie. He's migrating the calibration code over. I'm testing it now.

I am building on mono on a Mac so we can support Windows, Mac and Unix. But, I'm curious if anyone has experience with mono and Xamarin Studio - this is basically the environment MatterControl uses. I am actually trying to build the latest MatterControl from sources and running into an annoying issue that should be simple for someone with more experience. Basically I have an unresolved reference to the agg-sharp lib - it's an unresolved namespace for

Code: Select all

using MatterHackers.Agg.UI;

in MatterControlPluginBasic.cs. This same "using" exists in other sources in the tree and they compile fine. It's driving me crazy and google is no help. I did send a private email to MatterHackers this morning but have not heard back. If anyone is compiling MatterControl on any platform, please let me know!

My plan is to create a plugin for the calibration code. I also believe that the work I did on Barycentric Interpolation earlier this year to compensate for that last few % is going to be required to get the best results. I've seen too many deltas that have weird "pockets" or humps of non-planarity even when calibrated perfectly at the 7 spots. I'm thinking I can automate the gcode processing right in MatterControl as it sends the code to the printer. This eliminates the headache of doing this externally and actually makes the parsing a bit simpler.

Jimustanguitar · Post by **Jimustanguitar** » Mon Aug 17, 2015 3:20 pm

mhackney wrote:My plan is to create a plugin for the calibration code. I also believe that the work I did on Barycentric Interpolation earlier this year to compensate for that last few % is going to be required to get the best results. I've seen too many deltas that have weird "pockets" or humps of non-planarity even when calibrated perfectly at the 7 spots. I'm thinking I can automate the gcode processing right in MatterControl as it sends the code to the printer. This eliminates the headache of doing this externally and actually makes the parsing a bit simpler.

^^nice!^^
I agree, and can confirm that there's still a touch of wonky to chase down on machines like mine.

What's the current state of XY scaling correction? Can this be done virtually based on the adjustments calculated by the tool, or would this likely require measurement or printing a test object?

mhackney · Post by **mhackney** » Mon Aug 17, 2015 3:28 pm

Ok, good news #1 - I am now compiling and can run MatterControl. As suspected, it was a simple thing due to a new environment. Basically, I had to go into the References for each module and make sure "using"s were checked. Turned out there were a lot more but I was systematic and now the app is up. Haven't tested to see if it actually works but it looks good.

Jim, XY scaling could be done in the same way but a bit more work. Is your XY scaling asymmetric? If not, you should be able to fix it. That said the tool has no X-Y reference, only a Z reference (the probe) so it would require printing and measuring. On a CNC mill/router you use a known standard and explicitly measure the steps and map those to steps/mm or steps/in. It would be more complex on a delta since you have 3 degrees of travel contributing to the X and Y movement.

RollieRowland · Post by **RollieRowland** » Mon Aug 17, 2015 6:43 pm

mhackney wrote:Ok, we are making some good progress now. I passed the framework that makes connections and communicates to the printer to Rollie. He's migrating the calibration code over. I'm testing it now.

I am building on mono on a Mac so we can support Windows, Mac and Unix. But, I'm curious if anyone has experience with mono and Xamarin Studio - this is basically the environment MatterControl uses. I am actually trying to build the latest MatterControl from sources and running into an annoying issue that should be simple for someone with more experience. Basically I have an unresolved reference to the agg-sharp lib - it's an unresolved namespace for
Code: Select all
using MatterHackers.Agg.UI; 
in MatterControlPluginBasic.cs. This same "using" exists in other sources in the tree and they compile fine. It's driving me crazy and google is no help. I did send a private email to MatterHackers this morning but have not heard back. If anyone is compiling MatterControl on any platform, please let me know!

My plan is to create a plugin for the calibration code. I also believe that the work I did on Barycentric Interpolation earlier this year to compensate for that last few % is going to be required to get the best results. I've seen too many deltas that have weird "pockets" or humps of non-planarity even when calibrated perfectly at the 7 spots. I'm thinking I can automate the gcode processing right in MatterControl as it sends the code to the printer. This eliminates the headache of doing this externally and actually makes the parsing a bit simpler.

I should tell you to be careful with setting the variables in the program in the More tab. There was a missing ".Text" so it assigned an object to the Z-probing speed, which in turn set it to zero. This of course does not probe at zero mm/s, it probes at a default speed, that being dangerously fast. Change _serialPort.WriteLine("M206 T3 P812 X" + textProbingSpeed.ToString()); to _serialPort.WriteLine("M206 T3 P812 X" + textProbingSpeed.Text.ToString()); if you are still testing, otherwise I will send you an updated version that has been tested.

For your previous testing on the barycentric interpolation, did this method essentially contort the bottom of the gcode so it would print flat? Are these pockets/bumps radial? Or are they just outside of the tower "triangle"? I can't imagine there being a pocket/bump within the constrains of the towers, but if there were it would have to be due to a warped plate. If we could figure out the source of this issue, we could try to eliminate the problem at the source. However, if someone's plate is warped, or something else is wrong to cause something like this to occur, this would be an excellent solution.

Also, I can't wait to see what you come up with for a plugin, that will be incredible!

And Jim, for the XY scaling I am currently looking into finding any correspondence between what the z displacement is, compared to the xy displacement for each tower. If I find a pattern, there is a possibility I could generate an equation that may find the offset in the Delta Radii. I am hoping to find a correspondence, but if not then we will have to do this manually. But IF I find something out, I will need at least 2-3 other people to test as well for consistency/accuracy.

mhackney · Post by **mhackney** » Mon Aug 17, 2015 6:56 pm

Got the changes, thanks.

Yes, basically what I do is make a Z map of the build surface. Then, I modify the Z word in the line of gcode to explicitly set the Z for the layer and to account for the mapping. The defects are somewhat radial or egg shaped but I've seen a bit of everything when mapping something like 10 delta printers (other people I know). We're talking about fairly small deviations on a well calibrated machine but it can be enough to cause problems on the first layer. I actually ease out the Z map after the first layer until it is back to normal after 5 layers. I will probably make this behavior an option. The Z map from center to tower are usually pretty consistent and good. It is the regions between the towers that usually show the problem. I am 100% positive it is not a warped plate because I ALWAYS do a probe run in one orientation and then rotate the plate 90° and do it again. The defects stay in exactly the same place, ruling out the plate. I have also tried to force the geometry of the machine by twisting, bending, pushing, etc the towers, carriages and effector over one of these areas to see which has an effect on the non-planarity. I've not really had any success isolating this, leading me to believe the common build geometry parameters are not the contributor.

mhackney · Post by **mhackney** » Mon Aug 17, 2015 7:00 pm

I was going to add, it will be awhile before the plug in is ready since I want to make sure you have time to get the calibration code stabilized and I have a couple of big events over the next few weeks that are taking a lot of my time. I just got the MC sources building today and now going through the plug-in architecture to see how it works.

RollieRowland · Post by **RollieRowland** » Mon Aug 17, 2015 7:19 pm

mhackney wrote:Got the changes, thanks.

Yes, basically what I do is make a Z map of the build surface. Then, I modify the Z word in the line of gcode to explicitly set the Z for the layer and to account for the mapping. The defects are somewhat radial or egg shaped but I've seen a bit of everything when mapping something like 10 delta printers (other people I know). We're talking about fairly small deviations on a well calibrated machine but it can be enough to cause problems on the first layer. I actually ease out the Z map after the first layer until it is back to normal after 5 layers. I will probably make this behavior an option. The Z map from center to tower are usually pretty consistent and good. It is the regions between the towers that usually show the problem. I am 100% positive it is not a warped plate because I ALWAYS do a probe run in one orientation and then rotate the plate 90° and do it again. The defects stay in exactly the same place, ruling out the plate. I have also tried to force the geometry of the machine by twisting, bending, pushing, etc the towers, carriages and effector over one of these areas to see which has an effect on the non-planarity. I've not really had any success isolating this, leading me to believe the common build geometry parameters are not the contributor.

If the effects are radial they make sense to me, however the non-radial height errors would be concerning to me... I do not have the slightest idea what would cause this. I would like to see a generated height-map of one or two of these printers if you would still be able to. I have taken measurements all around my plate after calibration, and it was consistent with the calibration. So, something like this would be interesting to look into.

I can imagine the printer not being entirely perfect could cause this type of issue, as you were saying with modifying the geometry of the machine. I have tried this by forcefully making my towers square. It brought the heights closer to normal but was still significantly off - which is why I am going to rebuild my frame soon.

This would definitely be helpful to some, and I would like to try it as well.

mhackney · Post by **mhackney** » Mon Aug 17, 2015 7:22 pm

I'll try to dig out some data. In my case, the errors were +/- .06mm. Just enough to cause problems printing "open lattice" prints that require near perfection to stick. Like the white part in this this reel:

[img]http://mhackney.zenfolio.com/img/s6/v14 ... 6467-3.jpg[/img]

I want to be able to print an entire plate of these but I'll almost always have 1 not stick on the first layer so I limit myself to 3 at a time.

RollieRowland · Post by **RollieRowland** » Mon Aug 17, 2015 7:42 pm

mhackney wrote:I'll try to dig out some data. In my case, the errors were +/- .06mm. Just enough to cause problems printing "open lattice" prints that require near perfection to stick. Like the white part in this this reel:

[img]http://mhackney.zenfolio.com/img/s6/v14 ... 6467-3.jpg[/img]

I want to be able to print an entire plate of these but I'll almost always have 1 not stick on the first layer so I limit myself to 3 at a time.

That difference is enough to cause issues, and I can see how that would be a pain to print that portion.

Also, I have a question. On the Rostock Max V2, what is the theoretical Delta Radius?

mhackney · Post by **mhackney** » Mon Aug 17, 2015 7:45 pm

I have a RM v-before-1 so I can't help. It changed a little with the new carriages too. Also, have you read Steve Graves excellent "Delta Robot Kinematics" PDF? I can email you a copy if not. The print envelope on a delta is not actually circular, it is trilobal.

mhackney · Post by **mhackney** » Mon Aug 17, 2015 7:47 pm

By the way, I think we need to add a feature: calibrate and store to EEPROM or just calibrate and report results. That way I can work on my Rostock and not worry about messing up my production machine!

RollieRowland · Post by **RollieRowland** » Mon Aug 17, 2015 7:55 pm

mhackney wrote:I have a RM v-before-1 so I can't help. It changed a little with the new carriages too. Also, have you read Steve Graves excellent "Delta Robot Kinematics" PDF? I can email you a copy if not. The print envelope on a delta is not actually circular, it is trilobal.

I did know that it wasn't circular, however, I did Not know that it was trilobal. That makes sense now. Also, I will have to dig through google or the firmware to find it. But I have not read this, if you wouldn't mind sending it, I am sure it could help me out!

And that would not be an issue to implement, should we export an EEProm file that can be loaded if the user is using Repetier host? And just write the settings to a text file if they cannot load the EEProm file, like in Matter Control. Another option would be to ask the user if they want a backup and export there eeprom before the calibration.

mhackney · Post by **mhackney** » Mon Aug 17, 2015 7:59 pm

I just emailed you the paper, enjoy! I've had a couple of great email exchanges with Steve, nice guy.

Yes, saving an EEPROM file would be perfect. I don't think the mac RH supports it but its easy enough to read. I would err on the keep it simple side for now, you get the most bang for the buck with writing an EEPROM file I think. Ultimately, this could be the route to Smoothie config file saving too.

"trilobal" is not 100% accurate. It's more like "truncated trilobal" as you'll see in the paper.

RollieRowland · Post by **RollieRowland** » Mon Aug 17, 2015 8:10 pm

mhackney wrote:I just emailed you the paper, enjoy! I've had a couple of great email exchanges with Steve, nice guy.

Yes, saving an EEPROM file would be perfect. I don't think the mac RH supports it but its easy enough to read. I would err on the keep it simple side for now, you get the most bang for the buck with writing an EEPROM file I think. Ultimately, this could be the route to Smoothie config file saving too.

"trilobal" is not 100% accurate. It's more like "truncated trilobal" as you'll see in the paper.

Thank you! And then EEProm file it is! I'll work on that later tonight or tomorrow morning, it shouldn't take very long.

Welcome to the SeeMeCNC Community

OpenDACT(Delta Automatic Calibration Tool) - For Repetier

Re: Delta Automatic Calibration Tool - For Repetier Firmware

Re: Delta Automatic Calibration Tool - For Repetier Firmware

Re: Delta Automatic Calibration Tool - For Repetier Firmware

Re: Delta Automatic Calibration Tool - For Repetier Firmware

Re: Delta Automatic Calibration Tool - For Repetier Firmware

Re: Delta Automatic Calibration Tool - For Repetier Firmware

Re: Delta Automatic Calibration Tool - For Repetier Firmware

Re: Delta Automatic Calibration Tool - For Repetier Firmware

Re: Delta Automatic Calibration Tool - For Repetier Firmware

Re: Delta Automatic Calibration Tool - For Repetier Firmware

Re: Delta Automatic Calibration Tool - For Repetier Firmware

Re: Delta Automatic Calibration Tool - For Repetier Firmware

Re: Delta Automatic Calibration Tool - For Repetier Firmware

Re: Delta Automatic Calibration Tool - For Repetier Firmware

Re: Delta Automatic Calibration Tool - For Repetier Firmware

Re: Delta Automatic Calibration Tool - For Repetier Firmware

Re: Delta Automatic Calibration Tool - For Repetier Firmware

Re: Delta Automatic Calibration Tool - For Repetier Firmware

Re: Delta Automatic Calibration Tool - For Repetier Firmware

Re: Delta Automatic Calibration Tool - For Repetier Firmware

Re: Delta Automatic Calibration Tool - For Repetier Firmware

Re: Delta Automatic Calibration Tool - For Repetier Firmware

Re: Delta Automatic Calibration Tool - For Repetier Firmware

Re: Delta Automatic Calibration Tool - For Repetier Firmware

Re: Delta Automatic Calibration Tool - For Repetier Firmware