OctoPrint plugin...

[geneb]

The firmware isn't the magical part. Not Repetier anyway.

g.

[DerStig]

The firmware isn't the magical part. Not Repetier anyway.

g.

I don't care what it is as long as it fixes the bed tilt issue I have with a square build

[pouncingiguana]

New firmware just dropped. Update your firmware, Run G29 to do initial calibration, then turn the octoprint plugin loose on it. Gene's plugin in available here: https://github.com/geneb/OctoPrint-Delt ... master.zip

Use at your own risk. Possibly other people's too.

[enggmaug]

Gene, I know you as THE "manual guy", and I recognize your talent in writting up documentation.

Would you mind giving basic architecture/design description for this pluggin ?
It would really help me to try porting this for FSR setup on my V1.... whenever I have time for it. (man, so many projects, and so little time...)

[geneb]

Just take a look at the JavaScript source code. The bit you're after is currently looking for "PROBE-ZOFFSET" - just change this to deal with whatever your firmware outputs when the z hit happens. I don't know how "normal" Repetier behaves. The only printers I have FSRs on are equipped with Duet controllers.

g.

[wcogen]

I have been using this plugin for three days now. It is working really well for me. Reporting 0.03 or 0.02 after the G29 and Delta autocalibration runs. I am getting excellent first layers. Consistent results. Thank you. Thank you all.

[geneb]

You're welcome!

g.

[enggmaug]

Just take a look at the JavaScript source code. The bit you're after is currently looking for "PROBE-ZOFFSET" - just change this to deal with whatever your firmware outputs when the z hit happens. I don't know how "normal" Repetier behaves. The only printers I have FSRs on are equipped with Duet controllers.

g.

Yes, I see that. It does not seem too complicated.

I need to check what the default repetier firmware outputs when I G30 it, though.

[nebbian]

Just take a look at the JavaScript source code. The bit you're after is currently looking for "PROBE-ZOFFSET" - just change this to deal with whatever your firmware outputs when the z hit happens. I don't know how "normal" Repetier behaves. The only printers I have FSRs on are equipped with Duet controllers.

g.

Yes, I see that. It does not seem too complicated.

I need to check what the default repetier firmware outputs when I G30 it, though.

I did a lot of this last night, funnily enough. If you move to 20mm above the bed, and then do a G30, and your bed is 0.12mm higher than expected, it will report 20.12. I can't give you the exact syntax right now.

I was doing lots of calibrations using DC42's web interface, so was writing the numbers that were all around 20 in the boxes. Then you go through and subtract 20 from the numbers.

The process I was using was:

• * Send G code to move to recommended point, 20mm above bed
  * Send G code to deploy probe
  * Send G30

Lather, rinse, repeat. Manually subtract 20 from the values, press calculate, enter the values in the EEPROM, home, and do it all again.

Then get out the set square, make a story stick, adjust the turnbuckles, go through the process again.

I've got a deviation of 0.03 which is OK, but I can tell from the first layer that I still have a little way to go. While I can print thick disks in ABS that take up the whole bed, and they don't detach, the lines aren't totally uniform in extrusion width over the whole bed.

What's frustrating is that I had it printing perfectly for months, then SOMETHING happened and it went way out of calibration.

I was having grumpy thoughts of either munging the octoprint plugin to work with stock Repetier, or just saying fkit and modifying Repetier to have this calibration.

I was having grumpier thoughts of checking for tower twist as well, I know what this looks like on a print and hence why after spending 2 hours adjusting the frame and re-calibrating, after seeing a print I had to start again on the re-adjust process to get the twist out.

[nebbian]

Just take a look at the JavaScript source code. The bit you're after is currently looking for "PROBE-ZOFFSET" - just change this to deal with whatever your firmware outputs when the z hit happens. I don't know how "normal" Repetier behaves. The only printers I have FSRs on are equipped with Duet controllers.

g.

Yes, I see that. It does not seem too complicated.

I need to check what the default repetier firmware outputs when I G30 it, though.

When 20mm above the bed, some sample G30 outputs are as follows:

Code: Select all

Z-probe:20.00 X:55.32 Y:-29.78
Z-probe:19.98 X:-48.60 Y:-29.78
Z-probe:20.02 X:3.36 Y:0.22

[enggmaug]

Are the values in X and Y consistent with the XY position you placed the effector at before calling G30 ?

[nebbian]

Are the values in X and Y consistent with the XY position you placed the effector at before calling G30 ?

They are... when you remember to turn off bed compensation first
M322 S3

Man I've been giving that Escher calculator a workout over the last week. I was consistently getting deviation of 0.02, but sadly the calculator doesn't probe points, or make calculations, that account for tower twist. So you can get a 0.02 deviation but still be at least 0.05 off in certain parts (between probe points) when printing a large circle.
And it also doesn't account for effector tilt as I discovered when measuring a largish part that has to be perfect.

Blegh. Deltas can be frustrating.

It would be really awesome if some firmware existed that could measure ALL the things that take deltas out of calibration, and account for them. There's no physical reason why not, it's just a matter of moving the carriages to the right spot each time. That would take so much frustration out of the Delta experience.

I have a large part (240mm diameter complex cylinder, 1.5 days to print) that really needs to be printed, the project depends on it. I've spent a week constantly calibrating, tweaking, recalibrating, the works, and still haven't been able to print it. I've got some better rod ends coming on Tuesday and will get those carriages and rods absolutely perfect. Hopefully then I can get this silly part printed.

[enggmaug]

Until now, I used the opendact tool.
It is not perfect, very buggy, but it does the job, and it does calculate tower rotation and more.

I'm trying to get this pluggin to work, because I use Octopi, and I don't want to keep changing USB from pi to PC and then back. (And because the community says it's the best calibration algorithm for deltas).

But if it's a one time thing, maybe you could give OIpenDact a try... ?

[geneb]

The plugin also does tower rotation - it's essentially the same routine (minus the new grid compensation) that the Duet uses for calibration. You're not going to find any better.

g.

[mhackney]

nebbian, this is exactly what auto grid based compensation does. With the combination of auto calibration and grid compensation in firmware, you will get perfect first (and all) layers every time. David has implemented grid compensation in the 1.17RC branch of dc42. So with his best of class auto calibration and now grid based compensation, you have the best of everything on Duet with dc42. There really is NOTHING better available.

I've been using grid compensation since it was pre-release and it has completely eliminated the gremlins in my Rostock MAX V1 that multiple arm (original,, Traxis, magnetic ball, new ball joints), carriages (at least one for each of the previous), effector changes and rebuilds were never able to eliminate. A Duet 0.6, 0.8.5 or Duet WiFi can all run this code. It is a trivial price to pay to eliminate the frustration and lost time chasing issues that you may never resolve mechanically or with calibration. There is just something about the delta geometry and kinematics that on some occasions seem to create inexplicable problems. Of my 9 deltas, only that original V1 has never responded to mechanical tweaks and updates and auto calibration. But delta grid based compensation finally beat it into submission.

[nebbian]

Grid based compensation would be nice, and it's in Repetier. Repetier also has tower rotation.

What I was getting at is that even though you can enter the tower rotation angles, this doesn't take into account tower twist. This shows up as the nozzle being further away from the bed when close to the left hand side of a tower, and closer to the bed when close to the right hand side of each tower. It's symmetrical around the whole bed, with the same error on all three towers. To my knowledge RepRapFirmware doesn't have this. I know that grid based compensation can help with this issue, but that seems to me to be the wrong tool for the job.

No firmware that I know of can handle effector tilt either, which would mean printing a specially shaped part, and taking lots of different measurements of the part and entering them into a calculator to give three separate numbers. These numbers would then be combined together when printing to fudge the position of the effector.

On small parts, none of this really matters. On large parts that need to fit into other parts for engineering purposes, this does matter. And it's frustrating. Most people don't seem to care that their parts are slightly off, when printed in different areas of the bed. Most people don't measure the actual distance that their carriages move, so as to take into account the fact that GT2 belt isn't exactly 2mm between teeth. Most people don't take variations of extrusion into account when measuring their parts. Most people don't ensure that their rod ends are perfectly level, and at 90 degrees to the centre of the bed.

I haven't gotten a Duet yet because they are really expensive, especially when you also need to get a special display for it. I have two Deltas so would have to multiply this by 2. To my knowledge it doesn't support babystepping either, something that Repetier on RAMPS had had forever. So I'd end up with an expensive controller that wouldn't do what my current RAMPS board does.
I also have a problem with supporting a person/company that incessantly spams the RepRap forums. *sigh*

Oh well, carry on. I'm making some new arms for my bigger printer today, and will go through the whole mechanical setup with a very fine toothed comb to eliminate as much error as I can.

[Dale Eason]

I'm trying to install the calibration plugin to OctoPrint but I can't figure out how to get it installed. First I needed to install pip. I installed pip on the pi. Then I tried to install the plugin using pip commands as shown on the github site of the plugin. However it fails and says.
Could not import OctoPrint's setuptools, are you sure you are running that under the same python installation that OctoPrint is installed under?

I see that comes from OctoPrint's python code and says it can not import octoprint_setuptools. I don't know what I need to setup first and then run the pip command.

What have others done to get this plugin working?

UPDATE: Never mind from the net I found I had to first do
source ~/oprint/bin/activate
That gets me to the right installation.

Dale

[geneb]

You don't need a display at all with the Duet. Neither of my upgraded v1s have them. It's all web interface. I'm not even sure what "babystepping" is in this context. Link?

While Repetier supports the tower rotation parameter it has no facility to figure it out. if you've got actual tower twist, you need to correct the mechanical defect in the printer and stop trying to make the software do it.

If dc42 was spamming the RepRap forums, he wouldn't be there for long. Just because you don't care for the product, doesn't mean it's spam.

g.

[Xenocrates]

For reference costwise:

Rambo: 170$ from ultimachine
Duet Wifi: 170$ from Filastruder
Display adapter for Rambo, Monochrome: 50$
Paneldue with 4.3 inch color touchscreen: 85$

Capabilities:
Rambo, 8 bit, 5 drives, difficult to expand, locked 1/16 microstepping
Duet wifi: Firmware/Gcode configured microstepping down to 1/256, 32 bit, continuous motion planning, with 2A+ stepper drivers
Display adapter: 20x4 character display, requires controller to process and update data, rotary encoder+button
Paneldue: 480P color display with resistive touch, and onboard controllers allowing minimal overhead. Pad for rotary encoder+button, but not installed.

Yes, it costs a bit more for a paneldue than a display adapter. But to say the board is more expensive than it's contemporaries is an outright lie. Not to mention that it is currently more capable, extensible, and configurable than the competition. It is a premium product from a first party manufacturer with R/D costs to pay. It will cost more than a Ramps, Radds, or Rumba board, because it is a much newer, much smaller volume product that needs to have a higher margin, as well as quality components. I would also like to mention that DC42 is putting effort into supporting the older LCD style displays, although not a whole lot (Most of his user base is OK with either web interface or paneldue, and don't need a little display that is honestly crap and will drain system resources)

Of course, feel free to take it with a grain of salt. There are warts on the Duet, and I don't pretend otherwise. But I would buy it again over any other on the market. I've put my money where my mouth is, and I honestly love it.

[626Pilot]

Towers being twisted or leaning is something I looked into correcting for the sake of my auto-calibration Smoothie fork. I had a mathematician look at it, but he couldn't figure it out. I couldn't either.

It is a very difficult problem to solve. On a Delta printer, you can correct for such things in firmware (theoretically), but it won't completely solve the problem because the nozzle itself will still be tilted. The extruded plastic will be squished more on one side than the other, and it will change as the effector moves around in the XY plane. Accuracy of the finished part then goes out the window. The only way to fix this in firmware is not to use a Delta printer. If we had some kind of Stewart platform (each side of the effector gets two motors determining its position, rather than one), then the firmware could figure out how to keep the effector flat. That would also be cool for other reasons. Stewart platform robots can follow contours, for example. They are sometimes used in CNC milling applications that have to be able to cut from many different angles. I have seen one or two 3D printers like this on YouTube, highly experimental of course. If you wanted to do that, you would have to write a firmware extension for the kinematics, and another to do the calibration. This would be quite straightforward in Smoothieware, but I don't think anyone is selling kits for that kind of 3D printer, so you would have to build it yourself. If you have to go that far, I would suggest looking at other printers (like CoreXY or Cartesian) instead. They have their own issues, but maybe those issues are easier to solve. I don't know whether they are, but if I can't get a perfect drivetrain set up for my Delta printers, the next step is to look into CoreXY. I am frankly getting tired of all the fiddling. It seems like I almost never just print something.

The major weakness of Delta printers is that it's very hard to build a perfect drivetrain for them - one that is both highly accurate, and that lasts for a long time. Trick Laser's Traxxas arms start out very accurate, but eventually, the ABS part of the joint wears down and develops slop. (The rubber bands pulling the arms together help, but only a little.) SeeMeCNC's captive ball joints have a little bit of lash, at least on my Eris printer - the ball part is acetal, but the cup part is ABS. I think over time the ABS will probably wear down, just as it does in the Traxxas joints. They also have springs pulling the arms together, but they don't solve the problem of uneven wear inside the joints. (Even if the wear was 100% uniform, which it isn't because of gravity, it would still let the effector tilt.)

I have been using magnetic arms on my MAX Metal (excellent frame by Trick Laser), and they are pretty good, but they do wear over time because the concave part of the joint is made out of PLA. (PLA is harder than ABS, but still far from impervious to wear.) The guy who sells them is doing them in acetal now, and I might give that a try. Acetal is WAY more wear-resistant than PLA or ABS, so they should last for tens of thousands of printing hours without developing much (or any) slop. The convex part of the joint is chromed steel, so obviously that's going to last for a long time. The trouble with this solution is that while the joints can be very good, I still have to use printed carriages and effectors, which I have to print with a printer that is less than perfect. I am getting a resin printer next month, and the first thing I'm going to do with it is bang out a set of effectors and carriages that will at least be really dimensionally accurate. I hope (but don't know for sure) that this will be the right solution. It still relies on screwing down metal ball joints, and because they have to be screwed down, they have to be leveled somehow. I've produced some compressible printed TPU washers for this purpose. Fingers crossed.

I wish someone had already figured all these things out years ago. Like I said above, it's tiresome. I don't know how many hours I've put into firmware dev, but it's over a thousand. Then, more hundreds if not thousands of hours on trying to get the effector and carriages just right. It's starting to feel like too much. If someone could sell me a drivetrain that doesn't have the same material weaknesses of the above, that they could prove conclusively would always be accurate and not develop any lash or slop for at least five thousand printing hours, and I mean really prove it with hard data (not anecdotes), they would have my business TO-DAY.

[mhackney]

***sarcasm on***

Feel free to use Repetier's grid compensation and tell us how that works for you.

***sarcasm off***

[626Pilot]

I also have a problem with supporting a person/company that incessantly spams the RepRap forums. *sigh*

He and I have both worked on extending pre-existing firmware to do Delta calibration, and so we have spent some time conversing. He is friendly and helpful, and I gave my firmware the option to use RMS to determine average error because he suggested it to me. His product is good, and if it had grid-based Z correction this time last year, I would probably still be using it. If he has a solution to someone's problem, and he isn't being annoying about it, then I think it's appropriate for him to say something.

I spent countless hours trying to calibrate my Rostock MAX v1 before I even started working on auto-calibration firmware. To have a solution for a few hundred bucks that does everything for you is fantastic. It saves you so much time, and time is money! That is what you are really paying for, in my opinion. Not having to figure out Delta kinematics, which are non-linear and hard to grasp.