Posts made by James

I've got my rods pretty close. After the decimal they are 93, 94, 94, 95, 98 and 98. So, max difference of 0.05mm between the longest and shortest. Is there any way to account for different lengths in the config files? Assuming not, what is considered the best order in which to connect the rods to the effector? For example, should I pair similar lengths, or perhaps should I pair dissimilar lengths to make the average of each pair similar?

20um?!? Sh*t. Well, I just ordered a larger caliper and a digital protractor. I'm guessing that play in the rod ends is important too at this level. I need to change those. Hopefully in a few days I'll get the error down. Thanks!

How high a deviation after calibration is acceptable? Can you also then use bed mapping (I assume that autocalibration figures out the geometry, while bed mapping assumes the geometry is correct and corrects for bed deviations)?

That fixed it– I had use the wrong number of teeth in my calculation for M92. Uggghhh.

Anyway, this is what I get now:

"Calibrated 6 factors using 10 points, deviation before 7.591 after 1.077"

Running again, I got:

"Calibrated 6 factors using 10 points, deviation before 2.104 after 0.941"

Is that flat enough? If that's mm, seems like it might be too much error.

M665 H is within a millimeter of exact. I think I have M92 set incorrectly so that it is not moving the distance it thinks. Using 0.9 degree motors = 400 steps per revolution x 16X microstepping / 36mm per revolution (for 18 teeth) = 177.78 steps/rev, meaning that M92 should be:

M92 X177.78 Y177.78 Z177.78

Is that correct? I assume you have to account for microstepping per the sample calculations I see, although it seems like it would be simpler to always enter M92 by whole step and allow microstepping to be calculated from that.

This seems to work better now, with increased dive speed and a 1 second delay between probe attempts.

However, at the very beginning, the nozzle comes straight down to the center of the plate (which is not the first point specified), hits the plate, and grinds across it towards the edge. The hit sensors are triggering during this time (between 30 and 35 times as the nozzle scrapes/skips across the plate), but the nozzle essentially never leaves the plate (it might come up slightly – hard to see and hard to tell what is vibration versus planned movement -- but certainly doesn't come up to my setting of H20 between strikes). Only after that does it seem like the "real" autocalibration begins (but by this time I don't think it actually knows where the nozzle is -- perhaps grinding it into the plate causes the motors to skip steps).

Any idea what this first odd phase is?

====== bed.g ======
; Auto calibration routine for delta printers
; Before running this, you should have set up your zprobe Z offset to suit your build, in the G31 command in config.g.

M561 ; clear any bed transform, otherwise homing may be at the wrong height
G31 X0 Y0 P100 ; don't want any probe offset for this, P is probe activation threshold, should not matter for digital, which should always count as 1000 when "on" but this lowering because web control panel does not always show 1000
G28 ; home the printer

; Reduce the motor current for bed leveling in case the tip crashes into the bed
; Normally current is 1000, presumably will revert to main config.g value when done
M906 X600 Y600 Z600 I60 ; Set motor currents (mA, 1000 is default), Idle = I60 is default

; Change the default M558 dive height (H, mm), dive speed (F, mm/min),
; pause between probes (R in secs, default 0), and T, travel speed between points (mm/min)
M558 H20 F1200 R1 T1200

; Probe the bed
; Changed from original, just using a square for testing
; To generate circular parameters see http://escher3d.com/pages/wizards/wizardbed.php
; setting H to small negative value since in theory a piezo needs to move to signal
G30 P0 X-50 Y-50 H-0.2 Z-9999 ; upper left
G30 P1 X0 Y-50 H-0.2 Z-9999 ; upper middle
G30 P2 X50 Y-50 H-0.2 Z-9999 ; upper right
G30 P3 X-50 Y0 H-0.2 Z-9999 ; middle left
G30 P4 X0 Y0 H-0.2 Z-9999 ; middle middle
G30 P5 X50 Y0 H-0.2 Z-9999 ; middle right
G30 P6 X-50 Y50 H-0.2 Z-9999 ; bottom left
G30 P7 X0 Y50 H-0.2 Z-9999 ; bottom middle
G30 P8 X50 Y50 H-0.2 Z-9999 ; bottom right

; Note S7 includes diagonal rod length but requires oversize bed. See:
; https://duet3d.com/wiki/Configuring_RepRapFirmware_for_a_Delta_printer
G30 P9 X0 Y0 Z-99999 S6 ; center, and auto-calibrate 6 factors

G1 X0 Y0 Z150 F15000 ; get the head out of the way of the bed

Awesome, thanks. Sounds like I can increase dive speed with M558 F, and inscrease the pause with M558 R. That should allow me to figure out what is going on.

I second Frederick's question lol. But either way if it's happening every 1-2ms, it's probably not the issue since it would quickly be 0.

Thanks for the information. What do you mean that probing will not normally slow down with a digital probe? I thought it went slowly starting at the M558 H value. When I set it to H30, even with a digital probe, it moved really slowly for a long time (presumably 3cm).

Can you explain how the M558 H parameter works exactly? For example, using the default of H3, that means "probing" starts 3mm above where it thinks the bed is. But, what exactly is "probing"? Does that just mean that the nozzle moves slowly (at least for some probe types)? Or is it a logical state that says "OK, now I'm looking for the bed (whereas beyond 3mm I was not)."

I ask because, in the second case, if you use H3, but the bed is 4mm higher than expected, the nozzle hits the bed before it is "probing." If that hit doesn't count because "probing" wasn't active yet, that's a problem. I don't care how fast the nozzle hits the bed – I can control that via M203, I just want to be sure I understand what counts as a hit.

Also, if the probe slowing down once it is within the H value is part of the routine (although perhaps it is not for a digital probe, as implied above), is it possible to avoid this behavior with, e.g., H0 or some other trick?

If slow nozzle speed in Z is intrinsically tied to probing and there is no work around, I would ask that a feature be added to give control over the probing speed.

Is there any way to make the nozzle not slow down as it probes? Hitting too slowly is a problem for piezos.

Here is a video of the entire autocalibration run, until it gives up. The behavior is the same no matter what parameters I choose.

https://www.youtube.com/watch?v=L1L3FlEsBXE&feature=youtu.be

I've played with this some more, physically damping the system with sorbothane to make sure there aren't actual oscillations causing false positives. That doesn't appear to be the problem. It's something about the nozzle movement that I don't understand. Despite there being 9 points in bed.g, it strikes the bed a lot more than 9 times (does it sample each spot multiple times?), sort of wood-peckering a spot, moving on, doing the same thing, and then getting those errors and starting to waive around in the air maybe an inch above the bed.

I'm stumped. I've tried signal times from the Teensy ranging from 2ms to 100ms+, I've tried adding debounce logic and delays (even though with the sorbothane it is largely necessary), and I've tried adjusting the number of points collected from the sensors, and the average and max values that cause endstop activation. Of course I could just raise the thresholds even higher, but the way the nozzle is moving and the generation of false positives during the process doesn't make sense – essentially turning down the sensitivity doesn't seem like the answer.

I have some under-bed piezo sensors, connected via logic running on a Teensy, serving as my E0 endstop. This seems to work very reliably. If I tap the bed, the web interface shows that the endstop is activated, 100% of the time. False negatives never seem to be an issue, though the motors can cause a false positive when they first turn on, but are ok after that I think, though perhaps direction changes cause more EMI?

Anyway, when I go to run the autocalibration routine two problems occur:

1. It is probing too far from the center and can slip off the bed. Even if I reduce my printable radius in config.g, that doesn't seem to affect the probing points in bed.g. It seems like the desired behavior would be not to probe outside of the printable radius. Am I doing something wrong?

2. It repeatedly says: "Error: Z probe already triggered at start of probing move".

Perhaps this has to do with how long I am sending the endstop signal for? I currently have the Teensy sampling 20 times over 20ms to make sure the signal isn't noise, and then if the signal is legitimate, it sends a digital HIGH for 50ms (arbitrary – I have tried various values, and will try shorter ones now, but I started with longer ones to make sure I could see the activation on the web interface). 50ms seems like a short time to me, but perhaps the Duet expects the signal to disappear faster than that?

If the 50ms signal shouldn't be a problem, then I am wondering if the motors changing direction are making burst of EMI that are triggering false positives. I can raise the threshold for a real signal, but that could be harder to deal with so I'd like to find out first if it's just a timing issue.

Thanks for the suggestions. I did reduce the motor current through config.g, but obviously not enough.

If I was using a Cartesian, I'd definitely use backup endstops. This doesn't seem possible with a delta since there isn't actually one Z axis. I'm beginning to feel like deltas are more trouble than they are worth.

Love to see a pic of this assembled!

I like the way people are bolting on the rod end connectors so that the effector plate itself is very simple. Has this been done with regular (non-magnetic) rod ends?

Yeah… How do I make an embarrassed face lol.

I figured the 104 thing out last night. Once you choose proper values (I ended up using a 1 nF capacitor), such a simple circuit is quite effective at filtering the high frequency noise with almost no impact on the signal.

Coincidentally, I just had another mishap that motor current sensing would have been useful for. I thought I had z_probe working, so I hit the button for delta auto-calibration. Apparently the z_probe sensor was not actually working and the nozzle proceeded to plunge into the bed – hard -- and keep right on going, scraping sideways until it fell off the edge of the bed.

These motors are pretty strong. Strong enough to damage the nozzle, the bed, the effector arms on a delta, maybe chew up the GT2 belts a little, etc. Given this, not having any kind of check for when the motor is obviously using too much current, over a pretty long distance or period of time, seems like a bad idea.

Can someone explain why full-step sensing isn't useful? For a Cartesian (forget about the fact that I'm using a delta, since I think the step to nozzle movement ratio differs depending on where the nozzle is), I believe that a full step, assuming a 16 tooth gear with 2mm pitch and a 1.8 degree motor, is 160 microns (0.16mm). Presumably with 0.9 degree motors, a full step would be 80 microns. Would it be useful to me to know if the nozzle hit something (hard!), even if I don't know it for up to 80-160 microns later? Yes!! Stopping less than a millimeter after impact is far less likely to break things than if the motors just keep on going.

Am I not understanding something about the TMC stall guard? Because if it can take a reading each full step and then cut power if the data doesn't make sense, I really, really think that feature should be taken advantage of, and my reading of the docs on StallGuard seem to indicate this is possible (see FAQ at https://www.motioncontrolshop.com/products/tmc-239-sa)).

Thanks for the input – I'll try disabling that if I end up needing to. With some changes to the resistor and capacitor values, I have the noise down to about +/- 0.2V, which I think is ok. I can easily discriminate the piezo signal from the noise with my eye -- now I just need to make sure the circuit can.

I tried a low pass filter in front of my external circuit using a 2K resistor and a 22 pF capacitor.

This does seem to cut down the noise a bit. That's actually a little strange to me because those values are calculated to have a frequency cutoff of 3.45 MHz – far higher than either the signal or the noise. But, if I up the capacitor to 104 pF, which theoretically has a cutoff of 765 KHz (still far higher than the signal or the noise), then the circuit doesn't work at all.

Any thoughts on how to cut down the noise more effectively would be great. As would knowing if this noise should be there at all!

Ditto. Looks clean and light!