The Green Bank Telescope (admittedly a rather bigger robot than we deal with) has two big red emergency stop buttons: one is a "soft stop" that shuts down all motion as fast as possible without risking damage to the telescope, and a "hard stop" that just slams all the brakes on full. The latter is for use if, say, someone is about to be crushed or shoved off a hundred-meter drop. Expect damage to the instrument.

For our printers, we need to decide what "emergency" means. Their motion systems are (mostly?) too wimpy to damage people, and they have no sharp power tool attachments or blindingly bright lasers. So I'd say the biggest emergency is "there's a short causing a fire". A distant second would be no risk to life or limb but some potential damage to the machine (head crash, hot part of the machine sitting on a part not meant to be hot). But the real question is, once the emergency has been recognized, is additional motion safe? If the emergency has occurred because the effector is not where it is supposed to be, is there anywhere safe you can ask it to move?

The safest emergency stop for a printer would be to cut all power. So a circuit breaker on the mains input seems like the easiest, possibly with a big red mushroom to make it easier to hit in a hurry. This will shut down all sources of heat, even if (say) the bed heater MOSFET has failed shorted. I'd be inclined to make a smoke alarm trigger this kind of stop.

Second-safest would shut down only the "high-voltage" circuit, the parts that typically run on 12/24 V (or maybe mains, for the bed heater). This would leave the MCU up to record what happened, and if it has some kind of display (LCD, web interface, panel) it could show errors and allow a restart from software. I believe this is what the "emergency stop" on Marlin/RepRapDiscount LCDs does. It's also what the big red "Emergency Stop" button on the Duet's web interface does. Of course, while shutting the 12/24V circuit down kills the heat input to any potential fires, it means you can't move anything and your hot end fan shuts off too, so you could end up with a jammed hot end or a melted spot in your bed.

While printing, the "Pause" button stops printing and pulls the head away from the print, but leaves the heaters on. You can then cancel. This isn't much of an emergency stop, because if you're hitting it because the head has crashed into something, then who knows where the "get the head away" motion will take you; in my experience, probably crashing into the printer frame and dislodging the magballs. Plus it leaves all the heaters on, so if some weird thermal runaway has happened it'll keep happening. Nevertheless it sounds the closest to what you want. So: can you rig a physical button to, effectively, hit "pause"? Or to run a specified macro? I don't see why not. Easiest to hook it up to an unused endstop pin, and you might not even need to recompile the firmware - I think it supports "triggers" that activate particular bits of g-code.

As for what the macro should do, for my delta I'd go with

• "move the effector up a lot" (because that never shoots off into hyperspace), and
• shut off power (M81).

For an even gentler stop, you could ask the hot end to cool to (say) 140 C before shutting off the power, but unfortunately it can be awkward to interrupt such a wait-for-temperature if you want to actually do something immediately afterwards.

So the question is: how can you make an endstop trigger a macro?

(Also where do you get an appropriately serious-looking button? I should ask my father if he has any of those awesome old knife switches or Bakelite buttons lying around his radio room.)

I think the most pressing safety issue along these lines is persuading people to use PS_ON. For those of us using ATX supplies it's easy, but they're only 12V and a bit weedy for running a heated bed. For the people using 24V LED supplies, possibly also with SSR-controlled mains heated beds, it's got to be tempting to just leave the high voltage circuit on whenever the printer's on. But then there's no way for the firmware to shut off all heater power in case of thermal runaway - setting PWM to zero doesn't help if the MOSFET is the problem. I believe making PS_ON work here should just be a matter of running a mains electromechanical relay (with protection diodes and things) off the PS_ON pin and powering the 5V circuit from a spare USB charger.

I'd like to point out that there's an easier way to try to use the PS_ON pin: supply the Duet with an always-on 5V. Then the Duet can freely switch the ATX supply on or off as needed without affecting its own ability to execute commands or respond to WiFi. ATX supplies provide such an always-on 5V supply, so people using an ATX supply can easily do this.

It sounds like you're trying to do something trickier: allow the Duet to turn itself off completely. For that you have to keep the power on until the Duet can command it to stay on, as you have discovered.

If you want to re-probe with this method, just add G1 Z10 and G30 S-1 as many times as needed. I found the instructions a little confusing because they seemed to need consistent autoprobe results (which I still don't get, although individual probes do seem to be repeatable) and it also seems to make some assumptions about the paper thickness and its relation to the desired print height.

I agree that there's no point computing H values if the probe heights are not repeatable, but when I run a manual probing sequence (i.e. ending with G30 Pn S-1) I do get more or less repeatable results. Unfortunately even with the computed H values I still don't get good pre-fit deviations out of the autoprobe (and the post-fit deviations are not always great either).

Although the wiki includes instructions on computing the H corrections for autoprobing, I found a different approach made more sense to me. Is what I describe a reasonable approach? Should I replace what's on the wiki, add this as an alternative, or simply leave it as it is?

First of all, for each point in bed.g, the H value is the difference between sensor trigger height and actual height. So to probe each point, you should start with a G30 and then measure the height at which a paper is pinned. The prior calibration settings should be irrelevant since all we're doing is vertical moves, and the G30 sets a meaningful zero. So the procedure I suggest is:

• For the center point: G1 X0 Y0 Z10

• G30 (with no paper); this sets the Z=0 based on the G31 probe Z offset

• Put the paper under and use G30 Z_number_ to find the height at which the paper is pinned by a repeatable amount

• Record this value

• Now for each point in bed.g, use G1 X_value_ Y_value_ Z10 to go there, then repeat the previous three steps

• Now you have a list of Z heights, one for each point in bed.g (including X0 Y0). The appropriate H value is value at X0 Y0 - value; put these in your bed.g

Once you have these values in your bed.g, as long as your printer's offsets are repeatable and your bed is physically flat, your autocalibration should give nice low consistent residuals. If you want to adjust the vertical height of the nozzle when printing the first layer, do that with the G31 Z offset value in config.g.

Unfortunately I can't claim fantastic results with my printer; I'm not sure why.

@dc42:

@peridot:

…I say this having calibrated my hot end thermistor to read about five degrees high at room temperature because that makes it better around 200 C...

I don't know why you found that necessary, but if you measured the actual temperature with a thermocouple inserted into the hot end melt zone then it may mean the thermistor temperature is not quite the same as the melt zone temperature.

The B value of 4388 that I suggest for the E3D thermistor is aimed at giving the most accurate readings at 25C and 220C. The latest 1.17 dev build of RRF supports the Steinhart-Hart C coefficient for more accurate measurement. Without it, the temperature readings at 120C and 290C are less than 3C out.

It wasn't necessary, exactly; I set the B value based on 200 and 250 C and let it come out to whatever it came out to at room temperature. Initially I totally misread the table and got outrageous values, but once I put the right numbers in, it's only about five degrees off, for a degree or two improvement on the 200-250 C range. It's the principle of the thing. As I said earlier, getting the temperature really exact would be more about improving the thermal design than about calibration. I don't have a better temperature-measuring device, so even the B value I got is based on the manufacturer's table, which is probably not measured either but based on one more Steinhart-Hart coefficient than the version I set up supports.

Also I think the readout when the machine is cold, showing five degrees' imaginary difference between bed and heater, is a healthy reminder of the gap between measurement and reality.

@Toddimus:

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.

We actually do care about room temperature measurements. (I say this having calibrated my hot end thermistor to read about five degrees high at room temperature because that makes it better around 200 C.) The actual values are not very important, but reliable detection of heater faults is essential for fire prevention. If you have an apparent open condition at room temperature, the business of detecting whether the hot end temperature is rising by the right amount becomes more challenging. As long as the firmware can reliably detect when the thermistor has fallen off the hot end partially or completely it's not a problem, but if users get frustrated with spurious heater faults and use unsafe settings a fire risk can arise. This seems like a pretty important design criterion for a hot end - does it present an increased risk of setting your printer on fire if something goes wrong?

It's not clear to me that thermistor precision is the limiting factor in hot end temperature management. Certainly it isn't on mine, where my thermistor doesn't fit into the proper place on the E3D heater block so it's stuck in place with thermal goop. Making sure that the temperature-measuring device is measuring the temperature of the plastic being extruded is a key concern, particularly when extruding rapidly so that fresh cold filament is coming into the melt zone. The thermal conductivity between the heater, the melt zone, the nozzle, and the temperature sensor matters a lot here, as do the thermal masses of the various parts and the heat flux through the heat break. I'm sure Dyze has done a good job of all this, but I suspect that even in good hot ends these issues are what limits how well we can control the temperature of our extruded plastic.

I'd also point out that the time constant inferred by the Duet temperature calibration process tells us something about our hot ends - precision temperature control in the face of environmental insults (cooling fans, fresh cold filament, retraction) will work much better if that time constant is shorter, so that the PID loop can respond rapidly to changes. Simply changing the PID numbers won't help; the issue is how long the thermistor takes to notice changes in plastic temperature, which has to do with thermal mass and conductivity.

Thanks! I'll take a look once I'm not tinkering with anything else.

@T3P3Tony:

@peridot:

My application for the library is to experiment with advanced or alternative probing strategies, or to otherwise use the Z probe to evaluate the mechanical repeatability of your printer. (This is particularly pressing because my printer is unhappy in some as-yet-unexplained way.) You could also do things like experiment with aggressive speed/acceleration/jerk settings and see at what point you begin losing steps or developing severe mechanical slop.

This is a really good idea actually. Abstracted further it might allow for CAD/CAM programs to directly control a Duet controlled machine. So 1 click send to printer from with Autodesk 123D etc would be more realisable.

It should be possible for it to be a fairly self-contained python module/script, so it might make it easy to (say) make a "Send to Duet" button in Slic3r like the "Send to Octoprint" one. Integration with Cura might be a little easier since its UI is in Python anyway. A flexible binding, though, allows the possibility of two-way communication - the slicer could query the printer to find out what speeds it has been set to allow, for example. More generally I want to make it easy to move complicated tasks off the Duet and into a non-realtime environment with gigabytes instead of kilobytes of memory. Even tasks that should ultimately run on the Duet would be easier to debug on the PC.

I haven't looked too closely at what's involved, but I have written a similar hack to let me experiment with programmable calibration by sending G-code over USB to Marlin. So the HTTP/JSON interface really ought not be too bad.

Would it be enough to turn on the fans when the steppers are not idle? The steppers draw more or less a constant current, so shouldn't the drivers get hot in a quite predictable way? I guess using actual thermostatic control would let fans run only every so often even if the steppers had a tendency to overheat.

@iDevelo:

@peridot:

I am interested in accessing the Duet from other programs than the Duet Web Control, but I'm not interested in an alternative UI - the web control is basically fine.

The application is a wrapper for the web UI and nothing more. Basically a custom web browser.

I think we're talking at cross purposes here - the Duet provides an interface layer that is HTTP requests and JSON responses (plus some static files). The Duet Web Control is a user interface that is downloaded in those static files and that runs in your browser. Are you proposing a special browser that somehow interacts with the existing Duet Web Control code in a way normal browsers can't? Are you talking about modifying the DWC code so that it can communicate with the browser it runs inside in some special way that only works with your custom browser? Or are you talking about an alternative UI that doesn't use a browser at all, just the HTTP/JSON interface?

I am interested in accessing the Duet from other programs than the Duet Web Control, but I'm not interested in an alternative UI - the web control is basically fine (though I encourage you to submit improvements - it is open source!). I'd like a library, preferably in python, that made it easy to control a Duet from a program running on a PC. This is in some ways a simpler task, since it basically just needs to make HTTP requests and then decode the JSON responses. But if such a library were available, it would then be easy to write a UI on top of it, for any platform that supports python.

My application for the library is to experiment with advanced or alternative probing strategies, or to otherwise use the Z probe to evaluate the mechanical repeatability of your printer. (This is particularly pressing because my printer is unhappy in some as-yet-unexplained way.) You could also do things like experiment with aggressive speed/acceleration/jerk settings and see at what point you begin losing steps or developing severe mechanical slop.