Sounds like I should try Cura 5.0!

@tfjield only event messages and only the last one I think.
still a pain in the ....

@infiniteloop In this case, the Duet is the 'router'. It's the message you get in Windows if the Access Point/Router rejects the password.

Ian

@oliof ok thank you for or help

@phaedrux Thank you for your quick response!

@wifibeagle
Reprinted a part that required the G4 delay after deleting that command. No problems with the print. It appears 3.4.1 may have cured the problem even if it has not completely solved the mystery.

I can live with that!

@fusedeep said in Network security key being requested by laptop for both duets:

Bit of a nightmare.

Don't panic - there are better times to do so. And please stay with one thread, don't open a second one👿

Could you post your config.g?

What do you see to make you think steps are skipped?

Do you have a print example that shows the difference between 3.3 and 3.4?

If it can't be done in the firmware, there are hardware modules that do it (used by aeroplane modelers for flaps or undercarriage). Search "servo slow" or "servo speed reducer". About £10 - £15 typically (a few cheaper on ebay).

Good to hear. Let us know if you have any other snags.

I think that will likely solve the problem most of the time.

Otherwise to select a tool, you must click on it's name in DWC, or manually send T0 to activate it before any temps will take effect.

@hauschka said in Execute gcode mid print - without getting queued:

Hi forum,

I wanted to know if there's a way to execute gcode commands in the middle of a print file without overwriting the ongoing printjob.

For example: babystepping to adjust printheight mid-print. Do these commands require a special prefix or can I just send any gcode command mid-print.

You can send almost any GCode command mid-print. A few will be ignored when printing from SD card unless they are in the print file, for example M0 will be ignored unless the print is paused.

Similarly, is there a way to immeditely execute commands, as opposed to having them queued in the buffer for execution?
(e.g. how is the software emergency stop handled?)

Movement commands will be put in the movement queue for execution; except that babystepping attempts to bypass the movement queue. Emergency stop is also treated specially (it discards the movement queue). Commands that affect the motion system will wait for the movement queue to empty. Most commands that do not affect the motion system will be handled almost immediately.

@nightowl999 said in I'm not saying it's not my fault...:

so I’d be interested to see how you’ve done it.

Here is a stripped down version of one of my homing routines.

If the endstop is triggered at the start of the move I first backoff a bit to see if it clears.

Most of the time this won't cause any problems unless the endstop was stuck on and there was no room to backoff because of the current axis position.

If that is of concern to you, simply remove the code the does the check and the backoff.

You will notice the code at the end that talks about moving to the centerline. That is because my endstops rarely are at the exact min or max position of the axis. A G1 H1 move sets the logical axis position to the axis min or max setting (depending on where the endstop is located) but that doesn't mean the axis is actually at the position. Since I always configure my printers to have X=0 Y=0 at the center of the bed, by testing I determine how far I have to move the axis, after the G1 H1 moves complete, to reach the centerline. Once I know that number it goes into the homing code followed by the G92 which then sets the logical position to 0.

; === homeY.g BOF === ; --- setup to home Y --- var msg = "" M291 R"Homing Y" P"Please wait..." T0 ; --- check Y endstop state --- if sensors.endstops[1].triggered G91 ; relative movements G1 H2 Y-35 F3000 ; if triggered backoff so both G1 H1 moves below will be performed ; --- check endstop state again to be sure it cleared --- if sensors.endstops[1].triggered set var.msg = "homeY: Cannot home - the endstop seems to be stuck on" M291 R{var.msg} P"Aborting" S2 abort var.msg ; --- home Y --- G91 ; relative movements G1 H1 Y299 F3000 ; fast move to endstop G1 Y-10 ; backoff a bit as needed to clear endstop G1 H1 Y15 F300 ; slow move to endstop ; --- finish up --- G91 ; relative movements G1 Y-117 F3000 ; move as needed to get to Y centerline of bed G92 Y0 ; sync logical and physical M291 R"Y Homed" P"Done" T1

@phaedrux said in Print wtih 2 Colling fans:

@mangelli said in Print wtih 2 Colling fans:

M106 S255 P2

Your slicer probably has a setting to tell it which fan to target. If you have it leave off the P value, the duet will just use the fans assigned to the tool.

Yes, the problem was the Slicer`s settings. Thank you so much for your help.
I was looking in the wrong place all the time.

@deckingman Thanks for the response. That is the case, and all the tests were performed at 0.5:0.5 index.

@Phaedrux @engikeneer
I do confirm that the issue was the cooling settings.
The ColorFabb On Demand filament, in that particular color, is prone to create the issue.
Polyterra filament does not create any issue with the constant cooling setting as in S3D

IMG_7413.JPG IMG_7412.JPG

There's a moral to this unfortunate/fortunate story, but I can't quite put my finger on it..😦

@jay_s_uk thanks!!!!
It’s solve the error...

M98 P"config.g"
HTTP is enabled on port 80

; Endstops
M574 X2 S1 P"^xstop" ; configure switch-type (e.g. microswitch) endstop for high end on X via pin ^xstop
M574 Y2 S1 P"^ystop" ; configure switch-type (e.g. microswitch) endstop for high end on Y via pin ^ystop
;M574 Z1 S2 P5 ; configure Z-probe endstop for low end on Z

@engikeneer yeah thats what I was thinking of aswell. Going to try it later today

Re-tuned with the tools over the center of the bed. The two Volcano tools both gave me the inconsistent behavior warning this time (where as only one did last time). They gave me:

M307 H3 R1.312 K0.283:0.128 D7.94 E1.35 S1.00 B0 V24.1 M307 H4 R1.396 K0.290:0.166 D7.39 E1.35 S1.00 B0 V24.1

The second part of the K value is still fairly different between the two Volcano tools. At this stage I think I will go with what I have and wait and see if I hit any faults or other issues and come back to this when I have been printing with it more.