@dc42 thank you ill try that

@MaracMB I have moved it to the firmware wish list. If you have an Idex machine where each tool is on its own Z axis then this would be theoretically possible but of course requires firmware work and the dual independent motion systems is not exactly the same sort of solution because in the case of the idex machine the motion systems are not independent.

@agf998 in DWC you can force the display to remain in FDM mode always, go to:

Settings-> General->Dashboard Mode

and select FFF
1eaa2247-dfa3-47e1-9eb5-42dfeb343a78-image.png

What you could try is to use SBC mode and set the immutable flag on config.g on the linux side. Then you would need to be superuser to unset the flag before changes to config.g would be saved. I would not recommend this though, because its hard to debug when things go awry.

And even if config.g.would be locked down, users can change roughly every aspect of machine configuration dynamically via gcodes. So the next step would be to only allow "reasonable operator" and "admin" commands depending on who uses the machine -- and there is no facility for this. Its a can of worms.

It's likely that you just need to adjust your Z jerk setting to be a bit higher.

@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)

@o_lampe said in Toolhead preheat prior to a tool change.:

@hestiahuang I proposed to establish a tahead.g macro which runs, as soon as the look ahead planner finds a toolchange.
This could probably be too late, depending on the length of look ahead.
Finding the best solution is way harder, since each line of code can take longer or shorter.
My dual extruders always run at full temperature. Even when a tool is parked. I park the nozzle over a piece of nylon to prevent oozing and purge the tool, when it's reactivated.

Any link about your tahead.g? Oh... I think I can check your post history and locate it. Thanks!

@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?