@jay_s_uk
You could use the delayed start code I have posted here as the basis.
Send your soak time as a parameter and it will report the time remaining at the intervals set.
You'd just have to call it after you set your temps instead of at the beginning of start.g like I have, as I want to avoid having heaters on during that delay.

@T3P3Tony Using M226 within the filament-runout.g had a weird behavior, the printhead would remain standing still on the bed, not moving on to execute the pause.g at all.

The normal M25 behaviour is much preferred over this, as the printhead should be moved away from the print as quickly as possible in a runout event, to prevent material from oozing out on the print and causing possible issues

I did notice some other small mistakes within the filament-runout.g (using if instead of elif on some parts), but those aren't the cause of the problem, just some oddities that I've fixed on my end now

@OwenD said in Store Height Maps in a Folder:

@CCS86
If you use G29 S3 P"0:/myFolder/myMap.csv" you can save it wherever you want and call it what you want.
You just have to remember to use the same P parameter when you load it
G29 S1 P"0:/myFolder/myMap.csv"

Does the heightmap plugin find them in there?

30e5fea1-ae7b-4639-a512-f58f11be5ae4-image.png

@OwenD

Thank you!

This is the most recent version of my super simple universal tool change macro:

M5 ;stop spindle M291 P" " R{"Please load Tool #"^ state.currentTool} S4 K{"Continue","Cancel"} ;display message box with "Continue" and "Cancel" if {input=1} if state.status="processing" ;check if a programm is running M2 ; end programm echo "Toolchange cancelled, terminating programm..." else echo "Toolchange cancelled..." else ; continue macro if user presses "Continue" echo "Tool#"^ state.currentTool ^" loaded"

@embezon you should use rr_model. It is the HTTP counterpart to M409, just as rr_status is the HTTP counterpart to one of the M408 subfunctions.

@MintyTrebor

That's a nice idea. I will look into it. I'd like to make any solution independent of internet connectivity. So part of my consideration would be, is it worth trying to implement a basic broker within DuetLapse3 (Python).

I have also looked at M118 P3 which suggests the ability to send http (would be ideal since I can easily implement the necessary API's). Alas, searching through older threads, it seems that is not possible.

I recall there were thread about implementing http or MQTT, so I geuess MQTT got the nod.

@AndMaz thanks for testing this.

@chrishamm thank you for quick response.

That won't work because we need to free memory as quickly as possible, there isn't a huge amount of available RAM in standalone mode. RRF saves G-code replies per HTTP session and those sessions are keyed by IPv4 address. That concept would have to be changed first to allow for use-cases like yours.

The logic would be similar to the one that's currently in place. In other words, the reply contents would be deleted after the client has fetched them or if the client has not requested the reply within reasonable time (1 second). But I agree with you that this would imply re-working the current logic @ the firmware.

For now I will try to go with a mutex that will block concurrent reqs to the device. Hopefully, it this will avoid diagnostics data to "leak" into Commander service

@RogerPodacter said in Remove filament-sensor and extruder motor same board requirement:

i'm interested in removing a similar limit from Duet which blocks using the temperature sensor and hotend heater on 2 different boards.

basically i want to use a Type K thermocouple daughter board in combination with my toolboard 1LC. i dont quite understand the safety concerns with this setup.

how feasible is it for me to compile my own firmware and flash it for a custom setup? hoping i could use VS Code.

This is less likely to be possible as the realtime nature of PID loop handling probably won't play nicely with not co-locating the temp sensor & heater. This would come at the expense of temperature consistency

@T3P3Tony don't know how to mark it as solved but here it goes

Update The original issue is solved https://github.com/Duet3D/RepRapFirmware/commit/f5fa23c3fd9eab9dc97cbefe317c3b0ee31cdf71 and released in v3.5beta2 (Link https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-350beta2)

0 dc42 committed to Duet3D/RepRapFirmware Fix for FTP change to root directory (included in 3.5beta2 release)

@dc42 in DWC, the time remaining counter derived from slicer print time estimate starts when you start the print and heater time is included.

@dc42 also from the Marlin discord

Prusa MK3 firmware's thermal modeling is making some great advances, able to detect thermal anomalies that could indicate a blob of filament building up on the nozzle, and allowing for continuation. We'll get those enhancements into MPCTEMP and our own thermal protection at some point. Prusa developers on Slack are a little cagey about when they will contribute Marlin patches, but at least they are asking about it.

Are you planning any work towards this?

@SputnikOC3d

Hi,

would you share the stl from your umbilical-1lc-mount-combination?

Thank you very much,
Pierre

@justus2342 i dont know the answer, but i am not worried about it since 8gb SD cards are so cheap and common now, even if it accelerates the shelf life, i can live with replacing the SD card once every 2 years.

but its a good question. @dc42 may know.

Will it be possible to determine backlash with the X-carve XYZ touch probe?

I'm sure there's a macro to find the center of the XY-hole, but can it spit out backlash numbers, too?

@dc42
Guess that's all true, and how i'm currently doing it.

The reasoning on my end was to have it as a safeguard more than anything. To avoid a 250+ degree nozzle kissing the bed.

@deckingman
Like i touched on above i was thinking down the lines of avoiding having a too hot nozzle touching the bed surface. I run my nozzle at 150c when probing, to soften any oozed plastic, but I also don't want to have it much hotter than that since I'm quite sure it will leave marks in the PEI over time.

That said, i will keep doing it in the macros ✌️ And rather look into polishing the safeguards/how it's handeled in the macros.

@justus2342 for CoreXY and similar printers using linear kinematics, per-motor limits are already applied. However, we have received a complain about this, because Klipper doesn't apply per-motor limits; which means that if you configure RRF and Klipper with the same M201 and M203 limits then Klipper prints faster. In fact RRF should be configured with larger limits than Klipper, to benefit from the greater speeds available when both motors contribute to XY movement.

Good morning @DC42,

Thank you very much, you don't know how glad I am to hear it, I'm looking forward to try beta2, I'll be preparing my codes to test it.

It's really wonderful to work with you

Best regards
Aitor

@dc42
Thanks for implementing this so quickly.
Can we also have the other math functions extended as time permits?
abs()
mod()
etc...