Best posts made by Nightreaver

Hey! So i've been having similar issue recently but i think i'm making progress now. So when you calculate/measure the z offset, don't use paper!
there is a document on the duet wiki https://duet3d.dozuki.com/Wiki/Test_and_calibrate_the_Z_probe

They say: move the nozzle until its touching the bed and i assume they mean it and that's what I do. Then follow the calibration steps on the wiki. don't use paper and move the nozzle downuntil the gap (should look like no gap at all) is closed. then measure the distance and take it over into your z offset.

one more thing is... don't use the corner or your bed for homing z. I moved from the corner to home in the middle of my bed and it works much better with calibration.

Since then i really have a nice first layer!

For those who are interested...

I took a similar solution for MQTT and adapted it to duet3d api endpoint.
It works fine so far as im using it for myself, tho not all options for MQTT publishing are implemented yet.
Feel free to try it and report bugs.

https://github.com/Nightreaver/RRF_WebIF_MQTT

I think having MQTT for this scenario makes sense to me.

I already like the Idea of having MQTT as part of the DuetFirmware as described here: https://github.com/dc42/RepRapFirmware/issues/284

Having a more detailed status will allow you to use MQTT to do lots of things with the report.
Even taking a picture would be possible that way if the status is properly prepared.

So lets say the MQTT connection is setup like wifi with some M-code, and you have another "M-code" (like M118 Px) to send a message to a MQTT topic, which is checked form another service/agent that will take care of anything else.

Also like mentioned in my ticket, you can use it to tigger power supplies like Tasmota-Compatible via Homeassistant/OpenHAB.

Setting up the Broker itself is part of another system, you usually dont use MQTT if there itsn't anything else in place. For these scenarios you might already have a broker running. Even if not, that broker can simply run on a RaspberryPI that you might use for the Webcam as well.

I really support that MQTT idea. MQTT with a proper topic-layout can be used to do many many more things...

Nightreaver created this issue in dc42/RepRapFirmware

closed MQTT Status Update / MQTT power control #284

Something I can also recommend to you, is splitting the home[all|x|y|z].g files into seperate ones.
I had trouble with homeall not working while x or y separately worked well.

homeall.g

; homeall.g
; called to home all axes

M98 P"/sys/homex.g"       ;start homing x
M98 P"/sys/homey.g"       ;start homing y
M98 P"/sys/homez.g"       ;start homing z

G1 H1 X0             ; return 0 X axis
G1 H1 Y0             ; return 0 Y axis

and then put for code for x y z homing in separate files.

This also helps to find bugs when it comes to "why homez doesn't work standalone, but works when homeall is used" kind of things.

@57buick Hey if you want to lift the nozzle after calibration, your trigger height must become smaller, not bigger.
So maybe try something like Z1.65 or 1.61

yes you might use it, but then I'm having another ESP32/8622 device beside the esp of the duet, to get a feature via I2C that could be "easily" integrated via MQTT on the current duet?

I know there is many workaround to solve my issue, but MQTT is a neat solution.

Also think of this
https://forum.duet3d.com/topic/9668/telnet-printing-using-a-filament-monitor

There is already solution that work with MQTT and telegram.

So i.e. the Duet is updating a "Status" mqtt topic, when this is changing to "out of filament" send a telegram message. no need of utilizing and coding arduino or micropython. it can be done with much simpler and higher level language.

And as other already said, why do i have need to have another device for much simpler things when i already have a 179$ duet in place.

Feels like fixing my porsche with cheap volvo parts...

@dc42 said in New M-code to send a network request:

I have it on the list for RRF3 for the Duet to be able to send network messages. Whether we support sending via HTTP or MQTT or something else has not been decided yet.

IMHO is MQTT THE IoT protocol.

Other opinions ( "mqtt vs http" ) :

https://medium.com/mqtt-buddy/mqtt-vs-http-which-one-is-the-best-for-iot-c868169b3105
https://www.linkedin.com/pulse/internet-things-http-vs-websockets-mqtt-ronak-singh-cspo
https://cloud.google.com/blog/products/iot-devices/http-vs-mqtt-a-tale-of-two-iot-protocols

I'd probably not go, an reinvent the wheel with "something else". But im biased

Hello, I wann to suggest a solution to a problem im seeing.

The issues comes up with using the BLTouch (or similar) Probes. The M558 B option was added because the bed-heating will cause interference with the BLTouch sensor, so while probing the Heater has to be turned off.

This is just adding cause another issue, while probing many points or a large grid, the bed temperature might drop 15 degree or more while probing, depending on your environment.

Im suggesting to add a "Temperature Threshold" to the M558. This threshold will define how much the bed temperature can drop before probing will be pause, the bed heated again and once the "default" temperature is reached the probing will continue.

Example: Bed Temperature target ist 60°C and the threshold is set to 5°C. Once you start probing the heater will be off. Once the temperature reached 54.9° the probing will stop at the current/next probe spot, the bed will be re-heated to 60°C and the heating will be turned of (as defined with B1). After that, probing will continue till the threshold iss hit again. This can be an unlimited number of pauses, smaller thresholds will cause more frequent re-heatings and therefore a longer probing in general. but should deliver better probing results.

Of course, this new parameter only makes sense with M558 B1.