Posts made by Leonard03

@T3P3Tony Understood. Thank you for the clarification. I will wait

@T3P3Tony That's fantastic, thank you!

@T3P3Tony said in M291: cancel vs timeout:

Once concern with making (for example) user action rather than timeout -2 would be a breaking change where peoples existing scripts would not work if they explicitly checked for -1

I thought about that and there might be some ideas for this.
First, don't include an timeout in the M291 line, so the result can never be -2 for example.
Second, in existing macros that works, the only modification that might need is instead of an result = -1 to result <= -1 so the behavior might remain unchanged (right?)
Those are only my ideas. Any feedback is welcomed

@T3P3Tony Thank you for your replay

Regarding checking the time, I already tried this using daemon, but if a blocking dialog is already active, the response from daemon is somehow in background, so I need to do something with the active one and after that daemon can show its dialog.

In short: I would like to do a "heater timeout" to cool the nozzle if I'm not around the printer if an event has occurred.

The long version:
If manual cancel and the timeout can be distinct, it would be possible to distinguish between an "automatic" action or an user input.

Lets take the case of a filament runout:
Just lift the nozzle a bit and wait there, at temperature, but Without pausing.
if I am around the printer when the runout has occurred I can tell the printer to reload a new spool and continue, without pausing the job (parking the nozzle).
Else if, I am around the printer but I don't have a new spool prepared at hand.
in this case, park the nozzle but keep the heater on.
Else, if I'm not around pause the print AND turn off the hotend heater, eg. overnight

My particular case is this:

while true
	M98 P"0:/sys/MMU Control/moveIdler.g" S5
	M291 P"FINDA didn't switch off while unloading filament. Try unloading manually. Ensure filament can move and FINDA works." R"FINDA FILAM. STUCK" S4 J0 K{"Retry","PAUSE",} F0
	if input = 0
		M98 P"0:/sys/MMU Control/moveIdler.g" S0
		M98 P"0:/sys/MMU Control/unloadToPTFE.g"
		if global.errQueue[#global.errQueue-1] != "FINDA_FILAMENT_STUCK"
			break
		else
			continue
	else
		set global.tcBlock = true
		if state.status = "processing"
			set global.pause = true
				M226
			break

If lets say the cancel button can set the result = -1 and the timeout can set the result = -2 the above can be changed to this

while true
	M98 P"0:/sys/MMU Control/moveIdler.g" S5
	M291 P"FINDA didn't switch off while unloading filament. Try unloading manually. Ensure filament can move and FINDA works." R"FINDA FILAM. STUCK" S4 J2 K{"Retry",} F0 T600
	if input = 0	; retry button
		M98 P"0:/sys/MMU Control/moveIdler.g" S0
		M98 P"0:/sys/MMU Control/unloadToPTFE.g"
		if global.errQueue[#global.errQueue-1] != "FINDA_FILAMENT_STUCK"
			break
		else
			continue
	elif result = -1	; cancel button, pause the print
		set global.tcBlock = true
		if state.status = "processing"
			set global.pause = true
			M226
			break
	elif result = -2	; timeout after 10 minutes, pause the print
		set global.tcBlock = true
		if state.status = "processing"
			M568 P0 A0	;turn off heater 0
			set global.pause = true
			M226
			break

Is there any way to tell if a dialog box with a cancel button has been cancelled or it has timed out?

I am sorry.. Only now I've seen on GitHub issue/feature request #930.
Is there any chance that this feature request to be part of rc.1 ? Or it will be implemented after 3.6.0 stable?

Remapping driver 3 from the extruder to an axis (V axis in my case) seems to rise the stall event. So it seems to be a bug with extruder stall detection in this version.
By the way, during a move, M122 shows that the extruder SG is not available..

Hello everybody!
Can anyone please confirm that extruder stall detection works on 3.6.0-beta.3 or +1 on a Duet2 WIFi?

M915 P3 S-64 H10 or M915 E S-64 H10 should rise a stall event with virtually no movement, right?
Move command is G1 H1 E70 F600, extruder is a Bondtech BMG, around 415 esteps
Reducing motor current during this phase I tried from 10 to 80 percent
Acceleration 3000mm/min
Acceleration during homing move 1000mm/s

For me at least, a 3D printer is the perfect companion for those who like to do electronic projects.

Electronics are my toys from when I was born, so this hobby persists to this day. Every project needs some kind of enclosure.

I'm thinking about an Arduino/Raspberry Pi. As these boards can interact with many peripherals, 3D printing is indispensable for that "professional" touch.

There are generic "project boxes," generic ones, injection molded. But it is something generic. As an enthusiast, I think that every project, custom and unique.

If in some shop I see something that catches my attention, most of the time in my mind comes an "I can do it better", for me at least.

For an enclosure for that board, sensors, lights, and everything else, it is one thing to mount it with double-sided tape (maybe), and it is another thing that every LED, sensor, and internal layout has its own nut, bolt, and its own place to be mounted to.

Another benefit of 3D printing in this area is the freedom to choose your own color schemes and different materials you can print (e.g., matte vs. glossy vs. CF).

I've seen very good projects done using generic components and plastic components, but in my opinion, those can't beat your personal idea, and the fact that this technology can really bring a thought to reality just as you imagine it.

Just yesterday, I noticed that temperatures now are shown as integers in DWC and PanelDue. I also checked the Object Model, and all temperatures are reported as integers. Yes, there is a decimal point in DWC and PanelDue, but it is always 0.
For example, heating the nozzle shows 80.0, 81.0, 82.0, etc.
It is not an issue per se, but I thought it was worth pointing out.
This happens at least with 3.6.0-beta.2+4. I don't know if earlier versions behaved the same.

@dc42

@dc42 said in [RRF 3.6.0-beta.2 Error code 7]:

Was the issue readily reproducible using the earlier beta version, or didn't occur just once?

This issue occurred twice, with two different gcodes and two different RRF versions.
With 3.6.0-beta.1 I had some Code 3 errors wich now are solved.
With 3.6.0-beta.2 first saw the Code 7 but printing the same gcode again next day did the trick. First time I got that error, second time completed without any issues.
Second occasion when I encountered this error was with another gcode (that in the first post) but again, repeating a slightly modified gcode (repositioned a modifier in PrusaSlier) completed without any issues.

I cannot reproduce this error twice, and it was very random. A simulation of that gcodes completed every time without problems. Printing that gcodes second time, again, completed without issues.

By the way, also with beta.2+4 now I can get a M122 report via DWC.

As regarding the PannelDue and DWC:
I followed @chrishamm advices from this post https://forum.duet3d.com/post/347660 and modified those parameters:
Number of maximum AJAX retries: from 20 to 3;
Time to wait between AJAX retries (ms): from 200 to 250;
PanelDue baud rate: from 57600 to 115200.

Now I have a pretty good connection for DWC. Still disconnects sometimes but is waaay better and stable then before.

The only side effect being that now the PanelDue now says that it receives malformed responses after around 15 seconds after the M0 at the end of a job files is completed. Even in that case can send command to the board, but not the other way around. Strange thing is that if I hit "print again" either from PanelDue itself or from DWC, comms with it goes to normal. Reverting the baud rate does not make any difference for this behavior.

Solved by 3.6.0-beta.2+4 Thank you Duet3D team!

Hello everyone!

I got a strage issue with my printer, after an 8 hours print, i got this error:

Sadly I cannot get a M122 report for two reasons:
In DWC with 3.6.x I cannot get an M122 report even if other comands works as expected
Over USB, I needed to do an emergency stop wich cleared the relevant report..

My board is a Duet 2 WiFi + Duex5 with MMU3

Anyway, I will upload my config files to google drive and update this post.
All that I have is the gcode and the aproximate layer height when the error occured

By the way, with beta 1 for only one print I got the exact same error, the next day I do a simulation wich completed as expected, printed the exact same gcode without any problems. So, seems to be a random issue wich I can't reproduce myself twice. I started a slightly modified print now to see how it goes

Thank you in advance, and any help is welcomed!

Update:
This is the gcode in question: Jack Case_STEC7_0.2mm_PLA_5h24m.gcode
The error occurred on layer 312 / Z height 62.40 most likely somewhere around line 117292 in that gcode

This is my config/SD card https://drive.google.com/drive/folders/1OcTPiUw0RlYuLT-Skopb6It37nG4u9Io?usp=sharing

Hello everyone! @kingofthegeeks might worth check the cables and mainly the screw terminals between PSU and the main board. I have a Duet 2 WiFi and some time ago got the exact same issues as you described. At power up, random overtemperature on all drivers even if the printer was working as expected. In that case I never got an undervoltage warning. Everything keept goind apart from overtemperatures on basicaly every driver (2wifi + duex5). Turned out that the connector between the psu and the board somehow loosen and got molten

@dc42 It works! And it works flawlessly!
With this build I've done some multihour prints with many tool changes and they worked perfect, no more resets (at least from thar reason).
For the PanelDue, using PanelDueFirmware-3.5.0-rc7-testcomm DWC is more responsive, more fluid, it updates more often and the connection is more consistent.
As a side note - annoying but don't bother me too much - after some time the DWC disappears altogether. I can ping the board, but no DWC. But until that point works flawlessly. By the way, trying to disable and reenable the wifi module (idle or printing) resulting in a stuckinspinloop when trying to enable it again.

Again, thank you very much for your time and help solving this issue!

@dc42 for me seems that made a big difference. Not a single drop in DWC into a 7 hours print so far

@dc42 Thank you very much for your response and for the binaries.
I will download them now and test tomorrow and report back

@dc42 said in Duet 2 WiFi HardFault invState:

Do you still have a copy of the .map file for the version of RRF that generated the M122 report in your original post?

Yes, I attached it here, but I changed the extension jut to have the ability to add it here. The extension is .map not .binDuet2CombinedFirmware_MAP.bin

@dc42 thank you for the answer. Sadly I can't find a good way to ground the V6 heatsink from the cold side. It is possible to use TVS diodes as a workaround? I'm using a PT100 daughterboard. It is possible to add at least one diode to one of the temperature sensor? Or they will affect the sensor/daughterboard functionality?

@Exerqtor that been said.. now I'm thinking about my setup.. I forgot that between the motor and the drive gears for a BMG is the big plastic gear
Seems like I'd grounded only the extruder motor, not the filament path in any way.. Great, another thing to think about

@Exerqtor here I cand give you an ideea about grounding. After I had almost the same issue about one year ago (?) as David said, I've grounded all seven steppers on by printer by a ring connector (if this is how is called) and three washers between sthe motors and the mounting points. The washers should be the same thickness as the ring of the connector. Not the most elegant way, but it does the job. All connections I've done to the ATX PSU and from there on is groundes by the power plug (seems that the duet2wifi is grounded with the PSU by the negative terminal).

Abount grounding the hotend, I'm running an E3D V6 gold edition with the PT100 and the DB but back then I've contacted E3D but they sayd that the heatsink of the hotend is not conductive, so the only grounding for the filament path is by the motor shaft being in contact with it

Hello! I started to have the same symptoms with my board (https://forum.duet3d.com/topic/33857/duet-2-wifi-hardfault-invstate) and I wonder if this tyoe of reset has something to do with the powersupply itself. Can a quick drop in the powersupply output result in this type of crash? A drop that is long enogh to cause a drop in the 3v3 circuit of the processor?
Just an idea..