Posts made by peridot

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.

Is consistency a requirement? Is there software that would break if G31 by itself changed to report the recorded values? Of course there would have to be some other way to find out about the probe status, perhaps G31 P-1.

Good point, AndreS; I use an ATX power supply, and to my astonishment the 12V circuit drops by about a volt when the heated bed switches on - I can hear it as the fan speeds change. I really would have thought the voltage regulation would be more stable.

That would be a nice solution.

Of course, there's a can of worms here - I'd actually be happy if the power turned off whenever the machine was idle and cold (motors on idle, all thermostatic fans low, no commands in the queue) but that's a bit complicated if you're worried about motors losing track of microstep positions. At that point I'd also wish for the power to be turned on whenever there were commands in the queue or nonzero temperature settings, and then I'd practically never have to use explicit M80/M81 commands. But simply allowing a "wait to power down" solves my specific case.

Alternatively, perhaps adding some options to M116 ("Wait") would be an approach to this sort of thing? Right now it just waits for some or all temperatures to reach their setpoints, but if you could ask it to wait until the temperature of heater n was at its target, above T, or below T, that would cover almost all imaginable "wait for temperature" possibilities. That plus a systematic way to interrupt waits or other in-progress actions would cover a wide range of possible scripting setups.

I use PS_ON to control my printer's 12V circuit, and in particular, my hot end fan. So at the end of the print, I'd like to automatically run M81 to shut off the power supply. I don't want to do this while the hot end is still hot, so I would like my end g-code to wait until the hot end is below (say) 150 Celsius. Is there a good way to do this?

Currently I use M109 S150. This does work, but as the hot end approaches the requested temperature, the PID temperature control kicks in and the heater turns on, slowing the cooling to reduce overshoot. Lately it has gotten worse, perhaps because the heater is better tuned for ~200 C, and the PID loop hovers around 153 C for a while before eventually cooling to the goal temperature. All this is of course unnecessary; I just want to wait until the temperature is below 150 C. Marlin had a G-code extension to allow this specific request, I believe it was M109 R150, but that definitely doesn't work in RepRapFirmware.

There's another, less important use case - waiting for the heated bed to cool before switching off my big cooling fan and signaling to the user that the print should be cool and easy to detach from the bed. Or, going the other direction, commanding the heated bed to 65 C and then waiting until it reached 50 C to start the hot end heater. I realize G-code should not become a full programming language, but a "wait for temperature above/below/stable" command, as well as a UI way to interrupt such, would be helpful.

Indeed. My standard approach for getting at unsecured services on closed networks is to ssh in to a machine on the network, then use ssh port forwarding to get in to the service. Often I can ssh in to the same machine offering the service, but of course this is not possible with the Duet; I would need a separate SSH host machine. I think there may exist a way to set up a machine that receives HTTPS requests, authenticates them adequately, and then forwards them as plain HTTP to the Duet, but I've never set such a thing up.

The g-code network configuration only does anything for non-WiFi Duets.

I'm not sure exactly what kind of port forwarding you're trying to do, but there have been posts on the forum discussing how to make a Duet WiFi accessible from the outside world.

Your best bet for hitting printing speed limits is a largish smooth object printed in spiral vase mode - there are no corners or stops anywhere, so as long as the radius of curvature isn't too tight the printer can get up to its maximum speed and stay there.

For my printer I get fairly reasonable non-printing motion up to 300 mm/s, but print moves are limited by how fast the extruder can extrude. Currently my extruder is tuned to quite conservative settings (in terms of maximum speed, acceleration, and jerk) because I had some trouble. Maximum speed you can tune by simply extruding into air and seeing when you start skipping steps; of course this will depend on filament type and temperature. Acceleration and jerk settings for the extruder I find a bit more mysterious, but they're probably more relevant to retraction than to printing. Since it's your extruder you're testing, this makes sense; if you've got a good mechanical system, your print speed is limited by how fast your extruder can push your filament through your hot end.

@kraegar:

Alright. I've scripted it in my slicer to control P1, so no biggie.

Can I ask which slicer you used for this? I can't figure out how to make slic3r's fan control control anything but the first fan.

As an aside, can I point out that this should serve as a warning to us all?

When the MOSFET failed, it failed shorted, leaving the attached device running at full. For a fan, this is annoying, but for a heater a shorted MOSFET could start a fire. The board would happily detect an overtemperature condition, but it would respond only by commanding the MOSFET to shut off, which would do nothing. If the setup used PS_ON, and if the firmware triggered an emergency stop on overtemperature, the fire would be averted.

@dcaron:

G30 P3 S Z-100000 ; probe and calibrate with 4 parameters (as there is 4 points)

This is highly suspicious - you should have S followed by a number, in this case presumably 4 since the comment suggests you want to calibrate four parameters.