Using an IR temperature sensor connected to the SBC
-
Hi all,
Situation : developing a DSF plugin, which uses an IR temp sensor attached to the SBC to do some observations of the print and control nozzle temperature (and the feed multiplier )
The original idea was to somehow make RRF treat the output of this measurement device (or more precisely, the output of my python script on the SBC) as a new temperature sensor, so that I can implement my own control logic and basically replace the existing nozzle temperature control and use the thermocouple in the heatblock just as a watchdog/ safety measure against over heating.
Q1I did quite a bit of forum digging, but I am still unsure if this is a viable option? The only way I can think of is wiring the free SPI output on the SBC to the temperature daughterboard connection.. ? I realize that RRF will need to be adapted (and then I would really need some guidance on what areas are of critical importance in RRF source to not break anything.. too much)
Later I realized that I can simply use DSF-python to send M106 /M220 commands straight from my python script. This is an order of magnitude easier to achieve, but the performance will suffer, since I would rely on the gains that are set in the RRF for the nozzle heater, and will just be providing a new set-point. I suppose I could mess with those PID gains to get a faster rise time with some overshoot..
Q2 Is there some magical way to have my python script on the SBC directly controlling the PWM for the nozzle heater? Someone said there are no dumb questions
Any input greatly appreciated
-
Although an IR sensor may make a useful remote diagnostic for general conditions, I doubt it will work too well for the hot end control. IR sensors are very sensitive to surface conditions. A clean, shiny nozzle will have a low emissivity, and read cold. As soon as it gets a little dirty, the emissivity will rise, and it will read hotter.
I see a lot of people on numerous forums who have tried to 'calibrate' their thermistor (or other readout) temperature against an IR thermometer, and somehow, the assumption is made that the IR thermometer is the correct value. This is almost certainly wrong, in most cases. There are way too many optical factors that go into these to make them really useful. Expensive, commercial, multi-band sensors can be good, because they can make a reasonable assumption about the emissivity, but basic single band ones are only useful for general surveys of temperature differences across a uniform surface.
On the other hand, as a general diagnostic, it might be interesting to watch how the surface of the sample cools at different fan speeds, print speeds, etc., and use this to develop better printing conditions. Let us know what you learn. -
@pjl I'd be careful with controlling heaters directly from the SBC - we deliberately let RRF do the critical stuff like heater control and general timing because the risk of hang-ups is basically non-existent on the Duet whereas it may occur for different reasons on the SBC.
That being said, you could probably configure a heater output as a servo pin and control it directly using M280 from an unused input channel (SBC should be free most of the time). However, the better solution would be to add a new temp sensor type to RRF and to control it directly from there. See https://github.com/Duet3D/RepRapFirmware/tree/3.4-dev/src/Heating/Sensors for further information.
-
@mendenmh Thanks for the input, you're absolutely correct about emissivity issues. In this case though, I'm more interested in filament temperatures rather than the nozzle. I will still be doing emissivity corrections on the data. And calibrating a thermistor to an IR sensor reading is quite funny
@chrishamm I have the same concerns about safety, and agree that adapting RRF is the proper way to go. The problem being, that with my lack of C++ chops, when I started going through the source, I got quite intimidated
(honestly it looks like I just wont manage to fit in my time budget, I am hesitant to bother people too much here about this)
If I made a new sensor type, can the data be obtained through the ribbon cable SPI bus or is it too busy and I would still need connect a free SBC GPIO output to an input connector on the Duet? e.g. SBC SPI out -> SPI on the Duet's temperature daughterboard connector (then I suppose in that case I need to hijack the spiTemperatureSensor.cpp, is that all that I would need to mess about with? )Im not sure I understand what you mean by "configure heater output as a servo pin"
you suggest having my SBC script send M280 commands through dsf-python and then configure OUT_1 as a servo output? If so, cool, didnt know thats possible. Would consider as dubious plan B
Thanks for the comments
