Posts made by Toddimus

First of all, VERY COOL idea. I presently have FSRs on my bed. I'm following this thread with lots of interest.

One thought on redundancy, using your idea of back to back transducers… Maybe set it up such that both sensors are handled separately with signal conditioning, then the outputs are logically "AND"ed together. Then, if both don't trigger as expected (maybe after an RC time constant??), the ANDed output stays triggered (or is somehow latched triggered), which will signal an issue to the Duet's firmware.

Or similarly, have a second output from the signal conditioning board that would change states if the outputs don't behave as expected (i.e. last time, only one triggered). This signal could be monitored by the Duet firmware to identify a fault condition.

In either of these cases, you would probably have to match the gain and offset of the signal conditioning/comparator for each sensor such that they trigger at the same time. Or get really slick about it and let a tiny PIC automatically configure gain/offset for each side and also have it drive the triggered output with a buffered signal.

Hope that all makes sense. I don't know if what I suggest is feasible, but I thought I'd throw it out there.

@dc42:

Sorry I won't be able to look at this for several more days. I've already looked at the code changes in 1.15c and I didn't find anything to explain it.

If you wish, you could try connecting the fsr board to the Z probe connector instead of E0 and use probe type 5.

I tried this and it worked! The signal line from the FSR board (Green wire) moved to "Z_PROBE_IN". Black to GND and Red to +3.3V.

It must have had something to do with the E0 endstop being used as the probe signal input.

I also tried firmware 1.15c with 18 bed probe points and that worked as well. So the only things I changed were going from E0 STOP to Z_PROBE_IN for the FSR probe board signal connection. This required changing the M558 parameter from P4 to P5.

For clarification, the G0 vs. G1 conversation that happened in the recent posts… I don't believe it has anything to do with the FSR probes not working. That was something to do with the reported object height on the DWC interface.

@dc42:

Those of you who are having Z probe trouble going from 1.15b to 1.15c, what probe type do you have set in M558, and how do you have the probe connected?

Any more thoughts on this issue?
I know you are quite busy, and hopefully have a life outside 3D printing, so I understand any delay.

Mine is connected to the E0 endstop.
Jumper on JohnSL board is set for NC

M558 P4 X0 Y0 Z0
M574 X2 Y2 Z2 S0 // hall effect switches at the top of each delta tower
G31 X0 Y0 Z0 P500

Thanks DC

I just had the same problem with the FSR sensors (JohnSL board). With 1.15c when I try an auto bed calibration on my delta, it says the endstops are already triggered. No hardware change. Reverted back to 1.15b and it works again. I tried rebooting the duet wifi, but that didn't help.

I do have a 17 point bed.g file. 10 points on perimeter and 6 points halfway in and one in the center. Don't know if that matters.

I do have the jumper on the JohnSL board to make the board look like (I think) a normally closed switch. This didn't get changed between firmware.

Not sure why but it is something different in 1.15c.

Thanks for the info. Now that I have my printer mostly dialed in, I'm looking into slicers and slicing parameters. I was curious how you did it.
Cheers!

Very, very cool.

Out of curiosity, is this done with the "vase" spiral mode, or are there more than one perimeters per layer?

If it's not a spiral, how did you deal with the seams? Are they running up the back of his head?

And what slicer program did you use?

Makes perfect sense. I just noticed that "one of these things is not like the other".

Thanks for posting this. It might come in handy down the road.
I had a look through the schematics and noticed that Fan1 doesn't have the 10k pull-down between the gate and ground like the others have. It probably doesn't matter if the processor has internal pull downs.

Quick update…

Using the 1.15 rc3 firmware, I was able to tune my heated bed after increasing the dead time parameter. I did 4 tuning runs on the hot end and 2 runs on the bed. They gave very consistent results, which I averaged and put into the M307 lines in my config.g file.

I now have the hot end and bed calibrated and they seem to work really well! Overshoot on the both the bed and hot end is maybe 0.5 deg C max. Once stabilized, they stay very consistent.

I also updated to the latest release 1.15 and DWC and webserver files.

Good job dc42 and chrishamm!

I was able to get my E3D V6 heater to auto tune after reducing the max PWM level to 0.3 and setting the max temp to 260 so:
M303 H1 P0.3 S260 yielded:

M307 H1
Heater 1 model: gain 732.3, time constant 176.9, dead time 4.1, max PWM 1.00, in use: yes, mode: PID
Setpoint change: P10.6, I0.06, D30.2
Load change: P10.6, I1.30, D30.2

I also got this message:
Warning: Heater 1 appears to be over-powered and a fire risk! If left on at full power, its temperature is predicted to reach 752C.
Auto tune heater 1 with PWM=0.30 completed in 500 sec, maximum temperature reached 228.2C
Use M307 H1 to see the result

Sounds scary, but I realize it is a pretty powerful heater. I'm running the 12V E3D cartridge at 15VDC.

Now, I try to auto tune my bed heater (Rostock Max V2 12V heater, with an aluminum heat spreader from Trick Laser under the stock glass plate). I tried a few settings but none seemed to work.

The last one I tried was:
M303 H0 P1.0 S140
And I got this message about 30 seconds later:
Auto tune cancelled because temperature is not increasing

I realize the bed heater is underpowered and has a lot of thermal capacity with the heat spreader. Any way to increase the timeout for temperature increase so I can get it to auto tune?

EDIT – I think I may have found a solution!! I sent:
M307 B0 H0 D60
to set the dead time to 60 seconds. Curiously, it didn't actually show up as received on the DWC interface, like the other commands seem to do... but it set it nonetheless.

When I ran:
M307 H0, it seemed to have updated the dead time to 60.

Tuning the bed heater now....

Thank you both for your work on the firmware! I'll give it a try in the next day or so.

I looked into this extruder/hot end setup and from what I gather, their reasoning for the 500C thermistor is not so much that you can get up to 500C with it, it's more that it has better resolution in the 200's C range. The website is hard to link directly to a specific part, but if you go here:
https://dyzedesign.com/support/
then go to the "DyzEnd - FAQ" section below and click on the item number 2 "How accurate is the temperature thermistor?", they have a pretty compelling reason that their thermistor is better. It has high resolution in the ~180C to ~280C range, which is exactly where we want to heat a hot end. The resolution at room temperature is bad, but that doesn't really matter much to us.

Curious what dc42 has to say about this after looking into their "special" thermistor. It actually sounds pretty cool.

Well done sir! Well done.
You have been busy.
Are those plumb bobs dual purpose for both positioning the aluminum extrusions normal to the bed and the counter weights for the flying extruder?

I got some of these and they seem to work well too:
Housings:
http://www.digikey.com/product-search/en?keywords=WM2000-ND
http://www.digikey.com/product-search/en?keywords=WM2001-ND
http://www.digikey.com/product-search/en?keywords=WM2002-ND
Crimp pins:
http://www.digikey.com/product-search/en?keywords=WM2623-ND

@demonio669:

I like to add other requests to the list:

…

• A ccd sensor to check filament diameter to dinamicaly execute M200 gcode to change filament diameter to allow volumetric extrusion (http://www.thingiverse.com/thing:699308 and [[url=http://www.thingiverse.com]www.thingiverse.com] )

This would be awesome!

How about if you try to move it out at the extents you were having trouble with? Like at x290 or y290

Just a few ideas if you haven't already thought of these…

If you are doing a bed calibration at the beginning and using calibration points out near the extents of the printable area:

• is there something out near those outer extents that binds up in the slides/carriages/effector (leading to missed steps or even skipping of a belt tooth??)

• or are one or more of the belts damaged out at the extreme positions (this could lead to some hysteresis of position)

• or is your suspended extruder cold end/Bowden tube somehow pulling on the effector when you calibrate out at the extremes

• or is there a "booger" or burr in your ball ends out near the furthest extent of calibration or movement that could cause an error in position (less likely, but had to include it in the list)

• or is the current supplied by the steppers just not quite enough to pull the carriages out of those extreme positions (missed steps)

• Last but not least… is the plumb bob heavy enough to cause missed steps or even "sag" of the carriages between movement commands (you had the idle current set to 40%, which might not be enough to hold things in place??)

So to test out the motor current being the issue…
Instead of this line in your config.g:

[[language]]
M906 X1600 Y1600 Z1600 E1200 I40        ; Set motor currents (mA) and increase idle current to 40%

```try this instead:

[[language]]
M906 X2000 Y2000 Z2000 E1200 I60 ; Increase motor currents (mA) and increase idle current to 60%

I know when I was first trying to get my bed calibration parameters dialed in, I had a few hard crashes into the bed with the nozzle. Nothing seems to be damaged, but it sure didn't sound good. I haven't taken things apart to inspect but I'm hoping I didn't damage the belts.

I just can't imagine it being a software bug that is only affecting your setup this way. Granted, you probably have one of the bigger delta machines out there so you are in uncharted territory with this board. My bet is that it's either something mechanical or some settings of parameters in the config.g or somehow bed.g file.

Another data point…

I also have a Rostock Max (V2) with FSRs and the JohnSL board. I installed some Hall Effect sensors in lieu of the mechanical ends stops at the top, which may give slightly more repeatable results for end stops (as opposed to the mechanical stops). I have the JohnSL board sensitivity set to whatever was default. I didn't have any extra jumpers lying around.

One thing I did differently than your notes above show is that I only did an initial home/delta auto-calibration at the beginning of the whole test run. It sounds like you homed after each point. I'm assuming this probably doesn't matter. I also took 5-6 probe values at each point. Interestingly, the values measured at the same probe point varied by around 0.04 to 0.06mm across the multiple probes done one right after another.

Your offset numbers look similar to mine, except that mine were slightly lower (average around -0.24mm, min -0.19mm, max -0.33mm). With a 140mm probe radius (6 points at periphery, 6 halfway and one center), I'm getting right about 0.100mm standard deviation after an auto calibrate. I also saw this number much lower (around 0.06-0.08mm) when I used a 120mm probe radius. I found that I needed to adjust the Z offset for the probe (i.e. center point) from the original values I found during calibration, in order to get a correct first layer height.

As an aside, I notice that one of my FSRs takes more force to trigger. I can tell this when I'm probing between the towers and only one of the LEDs lights up, when two theoretically should light up. I designed some little FSR mounts that use the snowflake mounting holes and keep the sensor aligned with the axes, as opposed to being offset as you said yours were. In other words, the mounts/sensors are concentric with the snowflake mounting holes and frame base mounting holes adjacent to the towers. The backside of the sensor itself is centered over the top of a carefully prepared countersunk hole that places the top of a flat head screw co-planar with the floor of the FSR mount. I'm still not sure I like my FSR mounting setup because I'm concerned it might be a bit over-constrained in the X-Y directions. This may be the cause of the one sensor taking more force to trigger.

Which brings me to my next question... does everyone like the little orange silicone pads that come with the FSR kit? I'm wondering if they have too much "springiness" or softness. I put one on the base of each plunger that comes into contact with the sensor itself.

@RCarlyle
Good input. That makes sense. Thanks!