@thetazzbot please share your config.g, deployprobe.g and retractprobe.g files.

@dc42 said in reference to the last used tool:

entered

that did it. Thank you!

@T3P3Tony sounds perfect, since the warning is about something outside the print area but ahs no way of creating problems (something to work also from the slicer perspective I think)
Thanks!

@claustro I know I'm very late here but I experianced some problems with Orca too. It may help somebody (probably me) in the future.

I use this in the start gcode in the slicer:

set global.tool_temp_initial={first_layer_temperature[initial_extruder]} set global.bed_temp_initial=[first_layer_bed_temperature] M98 P"/macros/print_scripts/start2.g"

My start2.g looks like that than:

; ##################### Custom Start G-Code ;M118 S"---------------------------------------- start2.g" M118 S"Wait for the bed to reach temp" M190 S{global.bed_temp_initial} M290 S0 R0 ; Set the babysteps back to zero M118 S"Home all" G28 ; Home All G1 X0 Y70 F5000 ; Move out of the way ; Wait till the corner sensor has reached 80% of the bed M118 S"Wait till bed corner has 80% temp" M98 P"/macros/print_scripts/bed_wait_till_80percent.g" ; Clean the nozzle ;M118 S"Clean the nozzle" ;M98 P"/macros/print_scripts/nozzle_clean.g" ; Autoz plugin ;M118 S"AutoZ" ;M98 P"/macros/autoz/autoz.g" ;M118 S"Stepper current high" M98 P"/macros/print_scripts/xy_current_high.g" ;M118 S"Load hight map" G29 S1 ; Load height map and activate bed compensation (done by autoz.g) ; Unload ;G29 S2 ; set hotend temperature and wait for it to be reached ;M118 S"Set first layer temp" M109 S{global.tool_temp_initial} ;G1 E18 F500 ; extrude into the meltzone (revo) ; #### Nozzle CLean G90 ; absolute positioning G1 X220 Y259 Z15 F7000 ; Move next to the brush ;M118 S":: Clean" G1 Z5.00 ; Drop to the cleaning hight G91 ; relative positioning ; Start cleaning moves ;G1 X30 F5400 G1 X-45 G1 X45 G1 X-45 G1 X45 G1 X-45 G1 X22 G1 Z7 ; Raise nozzle and finish cleaning G90 ; absolute positioning M400 ;M118 S"Purge Line" M98 P"/macros/print_scripts/purge_line.g"

The benefit is that my config in the slicer is as agnostic as possible and I can switch the slicers far faster without syncing the "start g-codes" in the slicers.

Cheers, Chriss

@Phaedrux said in Duet 2 wifi + FLSUN Q5 problems with probe:

: M558 P8 C"!e0_stop"

M558 P8 C"!e0_stop" did the trick. The probe isn't giving an already triggered error anymore, however, it did expose a mechanical issue I'm having where it probes the first two points, but then when going to probe the third point, it jerks and pulls the effector up and stops triggering the probe. I am fairly sure this is some issue with one of the axis' arms but it looks like once I get that solved, it'll work fine. I really appreciate the assistance! You are awesome!

@Simone in my PrusaSlicer configuration I selected GCode flavor: RepRapFirmware, and it looks like in the Custom GCode section it has set Color change GCode to M600. So it may just work.

An alternative is to configure multiple tools in config.g, one for each colour, all using the same heater and extruder. In the tpost0.g file use a M291 command to ask the user "Load filament for Tool 0, press OK when done" and similarly for the other tools. Then slice the model in PrusaSlicer to use a different tool for each colour.

@oliof oliof, english is no my mother language, if I wrote something that communicated a "no attitude" as you describe, I apologize. My intention was not report error on a post not meant for that, that is why didnt went on fully details about the error and asked for the proper way to report it

Following your reaction I guess I should have done it here: the error on pulse filament sensor Im obsrving from som time, if that even when starting a print, I get and almost inmediate error from firmware, filament-error.g is triggered, but when requesting the calibration data, i get a "no calibration data" message menaing the sensor still has not gotten enough info to make such calibration, so how it is possible that firmware "detected" a filament error"?
Im running 3.4.6, duet3 SBC

@Chriss the prototype E3D tool changers used a servo to lock/unlock tools, but it didn't last long enough, so E3D switched to using a small stepper motor. Your clone may be different.

@JRCL https://github.com/Duet3D/RepRapFirmware/wiki/HTTP-requests

@dc42 Nice! Im waiting for this type of features, it will help in many industrial aplications. If this is possible i want do beta tests.
Do you know when it will be aviable? Or how i can now setup rs485 in this setup? Maybe you have seen any programs on rpi that will help me.

Thanks!

@Phaedrux Thank you, how did I forget this? Anyway, I updated the post.

-John

@Phaedrux Thank you! I really want to try it! Very necessary.

@sebkritikel Thanks, I'm concerned only about the motor characteristics of servos / steppers.
With fast long travels steppers have very little torque and are troublesome.
But on the other hand step dir is not a perfect solution to drive servos also.

There is little info about these subjects so probably we will go all Duet to save time and trouble.

Still a great achievement to show how to handle I2C peripherals in a more integrated fashion without depending on firmware changes to make them work. Kudos @DonStauffer !

https://docs.duet3d.com/en/User_manual/Connecting_hardware/Fans_connecting#duet-2-using-12v-fans-when-vin-is-24v

https://docs.duet3d.com/en/User_manual/Connecting_hardware/Power_choosing

@CarlBosson for a 100C enclosure you will need to find a high temperature microswitch, or have spares around for temperature induced degradation. There is a high temp version of Euclid but you need to get in touch with @sinned6915 directly to get one.