A rebuildlog for a Delta printer

Re: A rebuildlog for a Delta printer

leadinglights — Fri, 27 Oct 2023 10:33:20 -0400

Quote
moosix
The switch to a 24V main PSU is also a good move, as it can provide more power and potentially improve heating and overall performance. Managing different voltage requirements for fans, Arduino, and Raspberry Pi with buck converters is a practical solution. Speaking of interesting games online. There's information about [casinosanalyzer.com] Google Pay casinos that just can't help but delight. Now I'm many times quicker to fund my casino account and nothing can stop me) The addition of an enclosure for the diaphragm pumps and a dual sensor setup for Z-related tasks shows a dedication to optimizing the printing process and enhancing precision.

Thank you for taking an interest, but wtf with the spam in the middle??

Mike

Re: A rebuildlog for a Delta printer

leadinglights — Sun, 08 Oct 2023 11:07:28 -0400

At a loose end while waiting for parts I thought I would report on the present status of the rebuild.

The dockable piezo is above expectations and works well with cloakedcodes's dockableprobe Klipper module. Comparing the mesh from two runs, the two meshes are substantially within 0.00625mm at most points. The under-bed probe gives a nice accurate Z datum, again within one step. I am not presently using the "plastic on nozzle" detection as I haven't worked out how to integrate this with Klipper.

The vacuum bed is in a somewhat less happy position. I have known for a long time that printing ABS on a thin film was pretty much a non-starter as ABS's tendency to curl was greater than any vacuum could overcome. I have however been printing with PLA on a 0.15mm polyester film on the vacuum bed with good results so I decided to incorporate a vacuum pump as part of the rebuild.

On trying out my new vacuum system, having previously used my big laboratory vacuum pump, I discovered something about small diaphragm and vacuum pumps - that they leak backward through the valves. The result of this is that the pump can pull a vacuum of 850mb below atmospheric pressure, but even with a reservoir of 350ml the leakage would result in a vacuum loss of about 5mb per second. Trials with a variety of vacuum pumps gave results not a lot better than this.

Edit: The leak above is with the pump switched off i.e., what vacuum the pump will hold when used to evacuate the reservior.

The problem seems to be that the pressure at which the valves in the pump open, known as the "Cracking Pressure", has to be low to get a good vacuum, but this means that the valve and seat must match very well in order not to leak. The poor leaking performance is a result of an engineering/cost compromise.

The parts I am waiting for are a selection of solenoid valves that can be used to stop the loss of vacuum when the pump is not running.

Mike

Re: A rebuildlog for a Delta printer

leadinglights — Sun, 27 Aug 2023 11:55:06 -0400

Now working generally O.K., but some work to do. I have put a video on [www.youtube.com]

Here is a gif to be going on with

[attachment 120515 ezgif.com-optimize.gif]

I have put a bit more for discussion in Tech-Talk [reprap.org]

Mike

Re: A rebuildlog for a Delta printer

leadinglights — Fri, 18 Aug 2023 09:20:23 -0400

The auxiliary box with the vacuum and blower pumps is finished bar only some shake-out tests. The black carbuncle on the side contains the vacuum failure switch, the air filter for the cooling pumps, the silencer for the vacuum pump, and a box cooling fan.

[attachment 120492 PumpBox.jpg]

The present, and perhaps last, part is a touch probe for bed mapping. Some time ago I decided that underbed sensors were inherently problematic for mapping the whole bed surface. My present approach is to use a single underbed piezoelectric sensor for determining the nozzle Z position, and simultaneously reporting on nozzle cleanliness. A second sensor of the touch type would be used for mapping the surface.

Although a switch type sensor such as a BLTouch or Euclid probe would be satisfactory, I am already using a piezoelectric touch sensor on my Biceps printer so I decided to try something new: A dockable piezoelectric sensor.

The present status of this is that "first light" has been achieved - the sled attaches to the effector and detaches - both smoothly. The piezo senses contact at a very low pressure and what problems are apparent don't seem to be unresolvable. Much more details on this on [reprap.org]

When I finish this I may buy a 1937 SS Jaguar to restore - something nice and easy like that.

Mike

Re: A rebuildlog for a Delta printer

leadinglights — Tue, 20 Jun 2023 06:18:19 -0400

Thank you DragonFire, I think I have found the problem: Sometimes several different problems can all give the same symptoms and this appears to be the case here.
1) The multimeter is reading very high so the stepper drivers were set just above their upper limit.
2) The A4988 that I put in the same position on the RAMPS board is likely faulty. They were all set below the driver limit but the heatsink on one seems to run very hot.
I found these by setting up the previously removed boards (P 2B, Arduino Mega 2560, and RAMPS 1.4) on the workbench and using a trusty AVO multimeter to check the Vref and motor current. Working on the bench was much easier than working in the cramped space on Miranda's underside.
So my IsoTech multimeter, a birthday present in the late 90s is now in the bin. Modern instruments are just not made to last.
I will need to recalibrate and do a lengthy test but feel a little more confident. In the longer term, I may do some further rebuilding, including servicing the motors and replacing limit switches; but for the moment I need a rest.

Mike

Re: A rebuildlog for a Delta printer

DragonFire — Mon, 19 Jun 2023 23:16:32 -0400

Maybe it's REALLY subtle...

... Dust or debris is more likely to accumulate in the pot trimmer for setting the current. Which would increase the resistance, set a higher current than what it was when you put the printer to one side?

That would affect all the steppers roughly equally, which is why they are all running hot.

If you give each trim pot a little squirt of WD40 switch cleaner, that might get it all running smooth n cool.

Re: A rebuildlog for a Delta printer

DragonFire — Mon, 19 Jun 2023 18:41:15 -0400

Oh, and yeah, it could be the steppers are set a bit high, but they shouldn't really have changed since you last had it running?

Regret I can't advise on tweaking, I have used both driver types but am switched what it was on the TMC, I run at .86 on the A4988.

Let's be honest here, ALL of your motors are due a service. Even if it doesn't fix, it's about time they had some internal TLC.

EDIT: Ah... I recall sometimes in a ball bearing, the balls are coated with anti-corrosion layer. If that cracks off, you can get flakes floating around the inside. That does happen with linear rail balls inside the mechanism.

You're telling me you can twist freely, but it might be a little bit more subtle than that,

Re: A rebuildlog for a Delta printer

DragonFire — Mon, 19 Jun 2023 16:35:03 -0400

Might be a failing breaing in that motor then. They do wear and seize eventually.

Or, maybe you got some debris in there jamming it up.

I'd unscrew it from the back and take a look. Generally needs a gentle metal tap to get the aluminium casing bits apart, bui it is all serviceable, and the bearings look identical to skate bearings to me

A spray with a bit of PTFE lube might be all it needs, generally a good last step before you put it back together again. Can get a bit oily to hold though, it's all a bit of a faff first time around taking apart a Nema 17.

EDIT: A loose grub screw on either the motor gear or the return (idler or gear) might be it too. Or, the belt mounting. You did say you had checked everything mechanical but just in case you did not, I thought I'd mention them.

Re: A rebuildlog for a Delta printer

leadinglights — Mon, 19 Jun 2023 06:12:55 -0400

Thanks, DragonFire. As soon as I saw your posting I checked out the extruder but it doesn't look to have any involvement. I have done many repeats now and it looks like the right-hand tower stepper motor is losing steps suddenly. The problem has become more common since it first appeared and everything has been changed except the stepper motors and the TMC 2225 drivers.
The front-running candidates - disregarding demonic possession for now at least, are the following:-
1) The TMC2225 stepper motor driver for that tower is a bit hinky and goes into thermal limiting for a fraction of a second once in a long while. Irms is set to 0.88 amps (Vref=1.25V, sense resistor 0.11Ohm)
2) The stepper motor itself is having a mechanical problem where the rotor is jamming against the stator - maybe there is something loose in the gap?
I wrote that last night but didn't post it. Since then I have changed the drivers to old A4988 drivers which I set to 1.25A and got a fail in the same right-hand stepper motor after about 10 layers of a small print. The motor feels, sounds, smells, and looks good although all 4 drivers seem to be running quite hot.
Sitting here pondering, weak and weary, I wonder if perhaps my old IsoTech multimeter is reading very low. Maybe it is time to break out the 1960s Avo model 8.

Mike

Re: A rebuildlog for a Delta printer

DragonFire — Sun, 18 Jun 2023 15:59:19 -0400

Loose grub screw on the Bowden extruder?

Re: A rebuildlog for a Delta printer

DragonFire — Sun, 18 Jun 2023 15:50:33 -0400

My opinion - you've got a subtle extruder problem.

The maths start off good, but you got slight over extrusion on each layer, and eventually you get no space to extrude. Or, the filament has random tangles in it, but tangles are usually pretty obvious so probably not that.

Or, maybe it's just the filament being a bit wide in places. That causes the overextrusion, jam, and subsequent print failure.

What I'd try doing is a selection of tall, narrow objects, see if they go OK or if they jam at a certain height. That would point to a mechanical problem. Unlikely but it might help eliminate mechanical height of the print being an issue.

I've had "flat head" print failures from both causes, and if your extruder rotation distance is a bit too low, that would over extrude and also cause it. (Software not hardware problem).

It could be the filament feed has a jam problem at certain heights.

Re: A rebuildlog for a Delta printer

leadinglights — Thu, 15 Jun 2023 05:50:03 -0400

O.K., so the rebuild of Miranda seeming almost to be done, I thought I would venture into fields where I rarely tread: The arts - that place inhabited by minds foreign to the Morlocks of the techy world. What I want to do is take a favorite poem, "The Raven" by Edgar Allen Poe, and print a raven perched on a bust of Pallas.
A search on MyMiniFactory yielded several possible candidates so, with a newly downloaded copy of Prusa Slicer Beta 2.6 I launched into the unknown by scaling an SLA to as big as I could fit onto the printer bed, turning on organic supports, and slicing it.
I have done many prints on the newly installed Klipper firmware and tweaked most things to the point of exhaustion. After having a layer slippage when printing a rope bowl, I went over just about every physical or electrical part and replaced anything that was worn, old, or otherwise suspect. Anything that is plugged in has been checked for mating pressure and lubricated with a drop of contact cleaner. Much sweat was sacrificed to the gods "Murphy" and "Sod" who made the laws that govern all of technology.
So it was that after nearly twenty hours of printing, as I admired the elegant dance of Miranda's six arms that I heard an alarming 'KLIK' sound and saw that the nozzle had left its ordained path and was clattering about on the gyroid area where Pallas's brain would be.
Resignedly canceling the print I took the partly completed wreck from the bed and removed the organic supports. What I saw made me really sad as the supports showed how good the print would have been had it gone to completion.

[attachment 120392 Pallas.jpg]
Lovely complexion, a bit pallid though.

I tried several prints since then: The top half and helmet for Pallas was one. Some arms for a new camera to record what was happening is another, but nothing now goes to completion. Looking at the clues, the nozzle seems to come down sharply about 2 mm, typically gets stuck, then tries to continue printing from a random position. Time to failure is completely random.
I suspect that there is a bad contact somewhere so have been going over everything. Connectors have been rechecked and every soldered joint looked at, poked, wiggled, prodded, and cleaned. The stepper has been exercised by running circles in gcode while being thwacked with the blunt end of a screwdriver. I have even replaced the Raspberry Pi 2B with a Raspberry Pi 4 ( 8 GB ) which was intended for another printer and new RAMPS and Arduino Mega 2560 boards await installation.
Although not yet tested, I don't have any faith that I have found the cause of the problem since nothing even vaguely suspect has been found. Could it be a bug in Klipper? Maybe malware in the computer? A poltergeist in the workshop?

[attachment 120393 RavenWithAttitude.jpg]
For the moment I am left with no option but to vent my frustration.

Mike

Re: A rebuildlog for a Delta printer

leadinglights — Tue, 30 May 2023 06:18:14 -0400

Almost everything is working well on the auxiliary pump box now but the vacuum pump is too powerful and I have had to rethink how this will work. The printer bed often develops a small leak through the petroleum jelly that is used on the seal and the pump may be called on perhaps once every couple of minutes for about one second to maintain the vacuum. The problem arises in that the pump is decidedly not rated for continuous operation and a vacuum failure would likely burn out the pump before the failure was detected.
The solution is to reduce the power to the vacuum pump by using a duty cycle of about 60%, a speed at which the vacuum pump can run continuously.
With the redesign, the pump now pulls the full vacuum (ca -90kPa) for about 4 seconds on the initial switch on and then maintains the vacuum at reduced power, running for perhaps 4 seconds every few minutes. Only if the vacuum falls below -50kPa with the pump running continuously will the vacuum fail switch operate and abort the print.
By Murphy's Law, I had used up the PWM pins on the RAMPS AUX1 port that I designated for pump control but now will have to swap some ports.
I had a second problem when I tried to print a Rope Vase [www.thingiverse.com] as it had a layer slippage about a quarter of the way done - something that this printer hasn't done in many years. I restarted the print and monitored it for a while. While I was looking away for a moment I heard a loud click but couldn't find any obvious cause or any damage to the print. Suspecting that it may have come from some thin steel cables that I use as safety belts for the magnetic Delta rods, I removed these. Pictures below of the result which occurred while I was on the phone. Sorry about the crappy picture taken on an ancient Nokia flip phone.

[attachment 120374 IMG_0076.jpg]

I now need to put a video camera on this printer to find out what is happening. Sadly the Raspberry Pi 2B on this printer is a little too puny to run Klipper and a video camera at the same time so I will have to use the Pi 4 that I have just acquired for one of my other printers.

Mike

Re: A rebuildlog for a Delta printer

leadinglights — Tue, 23 May 2023 11:32:50 -0400

I have got the auxiliary box with the pumps fully working, all that is really left to be done is making a 3D printed part holding the case fan, air filter for the cooling pumps, and silencer for the vacuum pump.
I connected up the pumps for the air ring through a gapmeter to find how linear or not the airflow was and found that they are hardly linear at all: At 24V there was hardly any airflow below about 50% duty cycle with 3.6 liters per minute which rose to 5.6l/m at 97% but 7.0l/m at 100%. With one pump at 100% and the other at 75%, the flow was 8.2l/m and 10.3l/m with both pumps at 100%.
The setup for the flow tests is pictured below. The gapmeter is the thing on a tripod on the left with an AWG to supply the variable duty cycle switching on the right.

[attachment 120365 FlowTest.jpg]

The vacuum system for the bed is largely independent of the printer, being switched on manually and with the pump being switched by a vacuum switch to maintain the vacuum. I did feel that it was necessary to have a vacuum failure switch to abort the print should the vacuum fail, but was unable to find a vacuum switch to my specification. Even those fairly close to spec were fiercely expensive and physically too large.
The solution was to make my own vacuum switch with a deliberately very wide hysteresis. The need was for the switch to close when that vacuum fell below -90kPa (about 13.5psi below atmospheric pressure) but only to open again if the vacuum is not maintained below -50kPa.
Below is a picture of the vacuum switch. It uses two small magnets and a tiny reed switch in a "flux thief" magnetic circuit.

[attachment 120366 VacSwitch.jpg]

The other major item is that I have joined the realms of the truly blessed - I received a Raspberry Pi 4B with 8GB memory this morning.

Mike

Re: A rebuildlog for a Delta printer

leadinglights — Mon, 08 May 2023 10:28:32 -0400

A report back on the status of this rebuild. As I said in my last posting, I am working on a box to put the vacuum pump for the build stage (table) and the air ring cooling pumps.
As with many projects, it prove to be a bigger task than anticipated, with many parts being unavailable or unacceptably pricy. Fortunately, though, some parts, such as the BLDC pumps for cooling air, were available on eBay a lot cheaper than I expected.
The box contains a vacuum pump, a vacuum reservoir, and two vacuum switches - one for vacuum regulation and one to warn of vacuum failure. There are also the two BLDC cooling air pumps along with their MOSFET switches along with a 24V 150W PSU, silencer for the vacuum pump, and filters for the two compressors.
The photo below is without the cover or filters. Front connections are the vacuum line, vacuum gauge line, cooling air out, control connector from the 3D printer, switch connector for the vacuum pump, mains power in, and mains power out to the printer.

[attachment 120348 MirandaAuxBox.jpg]

The pumps are working very well, in particular, the two compressors can blow up a hoolie. To get a wide range of control I have PWM control on one pump along with on/off control on the other. I have yet to characterize the pumps or to find how I can control them over the full range from Klipper.

Mike

Re: A rebuildlog for a Delta printer

DragonFire — Tue, 04 Apr 2023 09:01:03 -0400

Odd thing with the new steppers not working... but the f4ault is from the Pi Host not being able to keep up?

I had heard that some TMC drivers dont like working at 12V but you did say you had 2V so cant be that end?

Anyway, if you got it printing fast enough you are doing cooler upgrades, you are doing pretty good I would say.

Re: A rebuildlog for a Delta printer

leadinglights — Tue, 21 Mar 2023 07:25:40 -0400

The most recent changes are to reduce the micro-steps on the tower motors from 32 to 16. Using 32 micro-stepping, the Z homing speed was limited to about 18mm per second and X and Y movements would erratically crash out above about 250mm/s, in each case with the message reported in the last post.

Back to 16 micro-steps and the speeds don't complain at Z at 75mm/s and X and Y at 300mm/s.

A hardware thing I wanted to correct is that before stuffing in all of the extra bits I had an IEC mains inlet socket with a built-in Schaffner filter. I found a way to put a new Schaffner filter although it was a bit of a squeeze - at least I won't panic whenever a neighbor uses a power tool.

The next part of the rebuild is the auxiliary box with a vacuum pump for the bed and two pumps for cooling air. I will need to do some preliminary tests to try to find if I can get decent bridges with just a three-level (no air, some air, more air) or if I need fine throttling. Oh! what fun that will be. 8-)

Mike

Re: A rebuildlog for a Delta printer

leadinglights — Thu, 09 Mar 2023 06:05:12 -0500

The last few days have been largely successful. I have done the basic delta calibration and the enhanced delta calibration and am happy with the results of those as it approximately halves the constructional errors. The results of the pressure advance were beyond my expectations and show that Miranda's Bowden tube is not a significant problem.

[attachment 120227 tower3.jpg]

Frustrating problems at the moment are that the maximum speed the I can home Z, as set by

max_z_velocity = 20

is about, or even less than 20mm per second. If it is set higher than this, and I click "Home All" on mainsail, the mcu throws a spanner in the works with a message:-

Klipper reports: SHUTDOWN

MCU 'mcu' shutdown: Rescheduled timer in the past
This generally occurs when the micro-controller has been
requested to step at a rate higher than it is capable of
obtaining.

What is odd is that I can move at up to 300mm/sec with commands like

G0 Z0 F18000

and it works without complaint but setting max_z_velocity to anything above 20 causes the above shutdown. This problem only appeared when I set micro-steps to 32 with the change of stepper driver modules to TMC2225.

A second problem is that I am unable to access the accelerometer via a connected MCU, a Raspberry Pi Pico. The USB connection seems to be available under a number of aliases but printer.cfg complains that it is not there.

Ah well, at least it keeps me off the streets - which in this weather is no bad thing.

Mike

Re: A rebuildlog for a Delta printer

leadinglights — Tue, 07 Mar 2023 11:31:21 -0500

@jazzboy. Welcome to the club, you will enjoy it if your pleasure at success is greater than your pain when things go wrong. I will put up a picture of Miranda when I have the time to wipe off the evidence of blood, sweat, toil, and tears.

I got my new TMC2225 stepper driver modules yesterday, but only after cursing the supplier for only posting them on the day they were supposed to be delivered.

When I installed the new drivers I expected some changes as the jumpers on the RAMPS had to be changed. I elected to use 32 microsteps instead of the 16 microsteps on the A4988 modules so set the jumpers accordingly but initially left the printer.cfg showing 16 microsteps - the reason being that it should only move half as far and half as fast; initial checks being only that the creeping carriage problem had been cured. A slight surprise was that the direction of the motors was now wrong, but I had seen mention of this in some forum posts.

More of a surprise was when I set the microsteps to 32 in the Printer.cfg. Mainsail immediately complained that it was too fast. Since I had initially set max_velocity to 150, max_acceleration to 1500, and max_z_velocity to 75 - all of these are 1/2 of the speeds in the sample Rostock config. Reducing these to 75, 750, and 50 didn't cure the problem and I was only able to get movement at 40mm/sec and 20mm/sec on Z.

Leaving aside this strange behavior above, obviously, I have either done something stupid or in some way offended the gods, most things have gone smoothly. Basic Delta Calibration allowed me to print a fair calibrate_size and I have fed all of the numbers into Klipper. The numbers were a bit strange but I will do some further adjustments for better print quality and then do another test print.

Mike

Re: A rebuildlog for a Delta printer

jazzboy — Tue, 07 Mar 2023 02:20:38 -0500

This is amazing. I am new to 3d printing even though I purchased the kit in 2016, it was never built until a few weeks ago. Your Miranda seems to be on a parallel path to my Mad Max haha.

[www.facebook.com]

Re: A rebuildlog for a Delta printer

leadinglights — Sat, 04 Mar 2023 07:18:14 -0500

Hopefully, my new TMC2225 drivers will be in the post today as I am champing at the bit to get on to calibration.

[attachment 120206 gap.jpg]

Shown above is the creeping gap alluded to before.

Bed mesh will initially be a bit difficult as my setup is far from typical. The setting of the Z height is done with a single under-bed sensor. Probing with the nozzle directly over the sensor measures not only the Z height but also how clean the nozzle is. The bed mesh is done with a piezo touch sensor. This sensor is splendidly accurate and repeatable but takes about half a dozen probe operations to settle down - thereafter it has a resolution of about 0.25µm and a repeatability < 1µm.

[attachment 120207 PiezoTouchSensor.jpg]

The touch sensor deployed and stowed. I will retire this probe and replace it with a BL touch when Miranda returns to what she does best - printing quietly and reliably but with no great accuracy.

Edit:O.K., the new drivers didn't arrive (bummer) so I have tried again to run the DELTA_CALIBRATE METHOD=manual. I had some hope that it would work as the workshop is pretty cold today and there was no sign of the steppers stuttering. Sadly, the calibration was only marginally successful and there is a variation of about ±0.1mm - a bit too much for printing.

Mike

Re: A rebuildlog for a Delta printer

DragonFire — Fri, 03 Mar 2023 15:54:27 -0500

IIRC, after a simple delta calibrate, it's pretty normal for the printer to stop in the last "probe" position.

A home and a Save Config should change the end of the config files with some additions done by the simple calibrate.

I think you are pretty close to getting the extruder tuned to give the right amount of plastic, and after that you can try doing some prints.

After that doesn't go very well, you'll be doing your best to do a delta calibration mode finished.

The Z of it doesn't matter too much, all the measurements are done in X and Y, and it works out the tower tweaks needed to be consistent.

Only after that will a bed mesh actually work properly, in the meantime the printer will assume you have a flat bed anyway.

Re: A rebuildlog for a Delta printer

leadinglights — Fri, 03 Mar 2023 05:49:47 -0500

@DragonFire. I was not sure what to expect from the SD card entry on the LCD display. I had amalgamated a number of Printer.cfg files that seemed to apply, but had (have) not yet understood quite a lot of detail such as which SD card? What is a virtual SD card? Why do so many people have to burn a Klipper image onto an SD card? and many etceteras. When I saw the SD card entry come up on my 4X20 LCD display I naturally clicked on it and was enlightened - it exists to freeze up the printer.

Otherwise, most things have gone smoothly. Movements and PIDs are good and I started doing the basic Delta Calibration before I reached a temporary hiatus: It didn't want to calibrate. After a while, standing and staring at it in inner frustration I noticed something. The printer was in its home position, with the carriages fully up, when I heard an almost imperceptible click. Looking carefully at the carriages I noticed that there was a gap between the actuator of the limit switch and the adjustment screw. While I was staring at this there was another almost apologetically quiet click and the gap increased - as it did every 20 seconds until I re-homed it.

My money is on there being a thermal problem with one of the A4988 stepper drivers - outside possibilities being electronic noise or a bug or incompatibility somewhere. Now I have to wait for the new TMC2225 drivers to get here - the sheer craminage of the electronics makes unnecessary tinkering an unwelcome prospect.

Mike.

p.s. The first time I submitted the above the forum rejected it, saying that it suspected me to be a bot!!! Talk about the pot calling the kettle black. ..... and now of course I've got this terrible pain in all the diodes down my left-hand side....

Re: A rebuildlog for a Delta printer

DragonFire — Wed, 01 Mar 2023 08:45:06 -0500

Quote
leadinglights
....Another one is that selecting SD card on the LCD control panel results in the Pi freezing up.

Mike

Yeah, in general you don't use the SD card part of the printer control panel when you upgrade. You have to do everything to start a print on the Pi side. BUT, having that control panel is really really handy when you want to fine tune the aforementioned z offset.

It seems like Klipper is hard coded that way, to start a print high rather than low.

Printing with a fat brim gives you a minute or so to tweak the z offset just right, and if yours seems to float about a little between printer resets, this is "normal" for Klipper on a delta.

Here's why - the calibration done from a model gives all the slight imperfections in the axes as far as tower distance and angle goes. Even slightly different rod lengths.

This seems like a kludge until you get used to calibrating a delta with Klipper. Once it has working adjustments coded into the end of the config file, prints then get a lot more straightforward.

Re: A rebuildlog for a Delta printer

leadinglights — Wed, 01 Mar 2023 06:16:36 -0500

@DragonFire. I am a bit concerned whether the Pi 2B has the mojo to do the accelerometer bit so that is why I gave myself the option of the accelerometer having its own Raspberry Pi Pico [www.youtube.com]

@rq3. I have a deep distrust of any smartphones: Being a compulsive early adopter I then found them to be untrustworthy and deceitful. Being one who holds a grudge, I think it will be some years before I trade in my flip phone; and then only under duress.

I have made a good deal of progress on Miranda, but only after a few minor problems. I spent an hour trying to connect to the Raspberry Pi before realizing that I seem to have been playing a shell game with my three Pis and had put the wrong one in. After this little diversion, everything seems to work albeit not without problems. I seem to have half the movement in all axes so will need to find the error in the Printer.cfg. Another one is that selecting SD card on the LCD control panel results in the Pi freezing up.

I hope to spend a couple of days going through the Printer.cfg and getting my basic settings right before doing all of the calibration bits. Since it has gone far more smoothly than I expected so I have decided to replace the A4988 stepper drivers with TMC2225 drivers.

Mike

Re: A rebuildlog for a Delta printer

rq3 — Tue, 28 Feb 2023 19:16:48 -0500

Mike, I have used my IPhone with the "Vibration" app to get resonance readings for both the bed and effector on my delta, running Marlin with Input Shaping by Tom Brazier. It worked oddly well, although the current input shaping is NOT delta compatible, since it only deals with the X and Y axes. The take away is that the IPhone has a pretty darn good accelerometer, and the app I mention uses it pretty darn well.

My resonances are at about 38.8 Hz on both X and Y, whether measured at the bed or the effector.

Re: A rebuildlog for a Delta printer

DragonFire — Tue, 28 Feb 2023 18:45:02 -0500

The reasonance compensation is like the final tweak really. You can either print a model to do that or use acceleration meters to measure it "live". Although I suspect that latter one might not be on an option with 2B as your host.

The model method does give you an idea of what your maximum acceleration is for resonance free printing anyway.

My advice in general when Klipperizing a Delta;-

1) First complete sanity checks that heaters and endstops work properly, axes are moving.

2) Calibrate the rotation distance on the extruder. Measure 100mm of filament, and if you're not getting enough, decrease rotation distance. If you're getting too much, increase rotation distance. Bear in mind that Klipper has to reset every time a configuration change happens, but that's a lot quicker than reburning the firmware to the Arduino every time.

3) Do a full delta calibrate by printing the delta calibration model, measuring it, and inputting the values. This is a horribly involved process the first time around but it's really why Klipper is the best for deltas. And the printer won't properly adjust z offsets until the full calibration is done. The documentation is sketchy at mentioning this but it is there vaguely and has certainly been my experience.

4) After that, you can improve quality and find the limits of pressure advance and resonance compensation / acceleration limiting. Assuming your extruder hasn't worn out and gives erratic results (this has always been a factor with Reprap filaments printers).

If you chance nozzle size or extruder, you will probably have to redo the latter steps, and you might have to recalibrate rotation distance on the extruder too. It depends how Toque-ee it is. With a high torque extruder it won't care about pressure differences or changing filament types.

Re: A rebuildlog for a Delta printer

leadinglights — Mon, 27 Feb 2023 12:21:41 -0500

This stage of the rebuild of Miranda is perhaps not the most entertaining but perhaps I can add some interest with pictures of Miranda's bottom.

The last few days have been trying to cram the additional things into the available space. In this 3D printer, I planned out carefully where I would put the controller but did not allow space for controllers larger than the Mega 2560/RAMPS combination.

[attachment 120191 MirandasBottom.jpg][attachment 120192 MirandaRampsConnections3.jpg]

The RAMPS connections, never easy at the best of times, have become a bit of a nightmare now - There is a connector at every part except the I2C and one stepper motor. Above can be seen the tangle of wires which all have to be inserted in sequence and checked by looking through the perspex of the base of the printer.

By moving the mains connector from the back to the side I managed to liberate enough space for the Raspberry Pi and its power supply, and even improve the connector layout.

[attachment 120193 PiCloseUp.jpg]

In the picture above, the two circular DIN connectors are for the extruder and an accessory box containing the vacuum pump for the bed and the pump for the print cooling air. In the middle is an Ethernet connector to the Raspberry Pi and a USB connector, also to the Pi. On the right are the mains power connector and switch.

Klipper has the ability to measure and cancel the resonances of the printer and largely eliminate many of the printer artifacts. As I have only the most tenuous understanding of how this is done and what is the best way, I have allowed a bit of flexibility by having provision for both a direct connection from the Raspberry Pi 2B to the accelerometer and also by a subsidiary Raspberry Pi Pico to gather the accelerometer data.

[attachment 120194 BackWall.jpg]

Pictured above is the Raspberry Pi Pico along with two piezo controllers for the single underbed piezo sensor and the piezo touch sensor. I will report further on the dual sensor Z and bed mesh sensing in another article when I have it all running.

Mike

Re: A rebuildlog for a Delta printer

leadinglights — Sun, 19 Feb 2023 14:27:21 -0500

I will try out, or at least look closely, at the idea of sending the 5V directly to the GPIO pins. On this immediate project though, I will keep to the micro USB connector - it is only a Pi 2B, which is not quite as demanding as Pi 3 & 4. I am looking at the alternatives to the Raspberry Pi, both because there is little sign of the supply improving, but also because options such as the Rock pi 4C offer things like M.2 SSD.

Mike

Re: A rebuildlog for a Delta printer

yet-another-average-joe — Sat, 18 Feb 2023 18:50:46 -0500

I've been using buck converters for the Pi's, feeding them through the GPIO (direct 5V), getting rid of the crappy USB..
Never had a problem. Safety nazis will tell you that it bypasses the TVS, and chances are it will burn your house down...

I have a PiHole working this way, 24/7, for years, without any problems ; 2 more also are powered this way. With a fake LM2596 chinese module (the ones everybody know). Cheap and easy. Just a piece of protoboard and a a screw terminal.

Meanwell PSUs are hugely overrated. Yes, they are well built, and reliable. But entry level ones (common ones) have no PFC. Not that great...

1st pic : direct 5V over GPIO (with a level shifter, out of topic !)
2nd pic : direct 5V over GPIO on a custom Pi hat
3rd pic : the ubiquitous modules I use

[attachment 120165 20220904_181449.jpg]

[attachment 120166 20221027_231310.jpg]

[attachment 120167 20230219_003955.jpg]