Posts made by JADoglio

Thanks, I installed the add in and it should be useful. Can buttons be added to the standard pages that already exist in DWC like "Status" or "Dashboard" using this tool, or is that beyond what it was designed to do? Also, this only solves part of the issue. The bigger issue is how do I cancel or intercept the inherent M0 issued by Rep Rap so the firmware does not ALWAYS turn off the heaters at the end of the gcode execution for a print. Since the inherent M0 runs after the machine configured end print script runs, I should be able to intercept it and cancel/modify it before it executes. I am pretty sure at this point that it can't be, but it seems I should be able to configure the execution of my files to behave as I want them to. Your thoughts are always appreciated.

@dc42 Thanks I will have a look!

@dc42

Interesting, I have written a lot of macros and I have been learning how to use variables and and adding logic to the macros. So, of you are referring to just creating a macro to this, that is not what I am looking for. If I can create a macro and then create a button on the status page (on both the DWC and the Panel Due) to activate it, that would be perfect? Is that possible? If it is, what resources can you point me to to see how this would work. Thanks

@dc42

Phaedrux, I was just trying to find a way to do one click stop print with the option to leave the heaters on. I often find I start a print and quickly figure out that I made some mistake and need to adjust something. It is easy enough to do it with pause and cancel. The issue is it takes a few more seconds while the system writes the resume data and then calls the option to cancel and it also turns off the heaters and fans even though the next print starts seconds later. I thought this would be easy.

It seems it is not. In trying to do this I also became very familiar with the process and limitations of M0. I was also a bit surprised to learn that M0 is called automatically at the end of every print. I use a stop print macro to do the same things, not knowing it was not needed. I understand this was probably built in for safety reasons. The feature to make sure the heaters and fans were turned off after the print is good but it would be nice to have the option to manually turn that off and use my own macros to manage how the print ends..

DC42, thanks for the suggestion. Based on the above you have probably figured out why M112 is not a preferred option.

I appreciate the help. You might want to consider update M0 so when it is issued from the command line it pauses the print (if it is not already), then stops the print using stop.g.

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.5.3 (2024-09-18 11:25:48) running on Duet 3 Mini5plus WiFi (standalone mode)
Board ID: 5FTQV-B396U-D65J0-40KMQ-KZ03Z-HQ1PY
Used output buffers: 11 of 40 (32 max)
Error in macro line 146 while starting up: in file macro line 146 column 71: meta command: unknown variable 'manual_m0_detected'
=== RTOS ===
Static ram: 103368
Dynamic ram: 122904 of which 132 recycled
Never used RAM 12492, free system stack 198 words
Tasks: NETWORK(2,nWait 7,13.9%,228) HEAT(3,nWait 1,0.0%,325) Move(4,nWait 6,0.0%,355) CanReceiv(6,nWait 1,0.0%,939) CanSender(5,nWait 7,0.0%,336) CanClock(7,delaying,0.0%,334) TMC(4,nWait 6,1.5%,110) MAIN(1,running,83.5%,665) IDLE(0,ready,0.3%,29) AIN(4,delaying,0.8%,268), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:01:29 ago, cause: power up
Last software reset at 2025-02-11 15:45, reason: HardFault imprec, FilamentSensors spinning, available RAM 12492, slot 1
Software reset code 0x406d HFSR 0x40000000 CFSR 0x00000400 ICSR 0x00489803 BFAR 0xe000ed38 SP 0x20012020 Task NETW Freestk 488 ok
Stack: 2002c658 200322f8 200014e4 00000000 20033496 0003039d 000302b4 610f6000 2002c640 2002c640 00000001 2002c496 2001882c 2001ea80 00030523 00000000 00000000 00000000 200120b8 00000014 00000000 00000002 ebbf0050 f807a8c0 0800016a 00000001 00034c99
Error status: 0x00
Aux0 errors 0,0,0
MCU revision 3, ADC conversions started 67589, completed 67588, timed out 0, errs 0
MCU temperature: min 19.9, current 25.0, max 25.2
Supply voltage: min 23.8, current 23.9, max 23.9, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/3, heap memory allocated/used/recyclable 2048/148/36, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, read errors 0, write errors 0, ifcnt 10, reads 8136, writes 10, timeouts 0, DMA errors 0, CC errors 0
Driver 1: standstill, SG min 0, read errors 0, write errors 0, ifcnt 10, reads 8136, writes 10, timeouts 0, DMA errors 0, CC errors 0
Driver 2: standstill, SG min 0, read errors 0, write errors 0, ifcnt 10, reads 8136, writes 10, timeouts 0, DMA errors 0, CC errors 0
Driver 3: standstill, SG min 0, read errors 0, write errors 0, ifcnt 10, reads 8136, writes 10, timeouts 0, DMA errors 0, CC errors 0
Driver 4: standstill, SG min 0, read errors 0, write errors 0, ifcnt 10, reads 8136, writes 10, timeouts 0, DMA errors 0, CC errors 0
Driver 5: standstill, SG min 0, read errors 0, write errors 0, ifcnt 10, reads 8136, writes 10, timeouts 0, DMA errors 0, CC errors 0
Driver 6: standstill, SG min 0, read errors 0, write errors 0, ifcnt 10, reads 8136, writes 10, timeouts 0, DMA errors 0, CC errors 0
Date/time: 2025-02-12 11:20:44
Cache data hit count 166834675
Slowest loop: 7.17ms; fastest: 0.16ms
=== Storage ===
Free file entries: 19
SD card 0 detected, interface speed: 22.5MBytes/sec
SD card longest read time 3.6ms, write time 3.6ms, max retries 0
=== Move ===
DMs created 83, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, max steps late 0, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== DDARing 1 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Movement locks held by null, null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x0000803
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 808, received 0, lost 0, errs 422845, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 26 (min 26), ts 450/0/0
Tx timeouts 0,0,449,0,0,357 last cancelled message type 30 dest 127
=== Network ===
Slowest loop: 9.50ms; fastest: 0.00ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
=== WiFi ===
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notrdy 0, noresp 0
Firmware version 2.1.0
MAC address d8:bf:c0:14:df:67
Module reset reason: Power up, Vcc 3.33, flash size 2097152, free heap 36436
WiFi IP address 192.168.4.79
Signal strength -39dBm, channel 11, mode 802.11n, reconnections 0
Clock register 00002001
Socket states: 0 0 0 0 0 0 0 0

@Phaedrux 3.5.3

Here is the description for M0 actions:

The effect of M0 depends on the state of the machine.
The firmware finishes any moves left in its buffer.
Either: if the axes are homed and if a print is paused (M25), it executes the macro file cancel.g if present.
Or: if M0 is sent at any other time, stop.g is run if present.

The problem I am having is that when I issue M0 from the command line and the machine is running it does not execute stop.g, it reports an error that I have to pause the print before I run M0 to stop the print.

When I add M25 as the first line of stop.g to pause the print, I get the same error and the print does not stop.

Am I misunderstanding something here, or is this not behaving as it is supposed to?

Thanks in advance for any help understanding this better.

@Phaedrux
Side note: We have gotten pretty off topic at this point, sorry about that, and I am sure there is probably a better string for this discussion. If you want to move it, please do. As your systems are open source, and used and modified by many for their custom purposes I am sure their is a need to continue updating and doing other things as Duet does today. Your devices are popular, well built, and very well supported and there is also a user base that does not care about the open source, or customization opportunities with your hardware. We are just end users looking for a reliable solution to a need. From that perspective, I offer the following comments.

Thanks again, One last suggestion.

If the link in the DWC system-specific tab actually was a "Check for Updates" link that looked at the Github repository, then verified if an update was available or not, and then it gave the user the option of downloading the update and automatically installing it, or not, that would be a huge help for users. That would probably save you all a lot time not having to answer these kind of questions because the right files would be downloaded and installed for the right hardware without the user needing to know any of the specifics.

Github is a great repository for all sorts of technical computer programming/development information. However, it can be very intimidating for many/maybe most, of your users. For me, it has been a very slow learning curve as nothing about navigating Github is obvious. I am a PC computer savvy user (started with an Apple II Plus in 1980). I also have some programming knowledge and a lot of web experience. And even with that, I am just starting to be mostly comfortable navigating Github. When Duet started out, I am sure Github was great/invaluable for the people using it.

Today, people are using your hardware for a lot of things. We have a job to do and we just want do it. We want the systems needed to just do the work and if they need updating periodically, we want them to update behind the scene, without a lot of need to know how it is being done. We just want our hardware to work. I guess the short version of what I am saying is that I think a lot of people using Duet hardware today just wants to know what time it is, we have no inclination to build a watch.

You have a phone and, I am sure, many computers. The programs on those devices update constantly. While that is sometimes annoying, it is at least seamless and does not require me to know anything about the program or how it is being updated.

As I noted at the beginning, this is concept is somewhat antithetical to the whole open source concept, but I think/hope they can both live in harmony making Duet hardware more attractive and easier to manage to a larger user base. Sorry for the long note, but I have been thinking about this since my first update on my Duet 2 WiFi over 4 years ago.

Thanks again for all your help over the past several years.

@Phaedrux Thanks again, I tried to do install procedure 1. I never did find the IAP file. Short editorial, as this is mandatory file to complete the install, it seems like it should be as easy to find as the bin file? You guys really do a yeoman's job keeping us all going, but as this is the second time I have had issues finding this file.. I am just saying.

In the Github repository I did find the Duet2Combinedfirmware.bin file. When I uploaded that, 3.5.1 installed as it should and the firmware and DWC are now both on 3.5.1.

On the original install of 3.5.1 I went to the github page using the link on General tab. I did not realize that that only took me to the DWC update file and not the firmware. So, it was doing what I was telling it to do, I just did not realize that.

As I understand it, you normally recommend updating both the DWC and the firmware and keep them on the same versions. If this is correct, then it would seem that the link should take me to a page where I would download both. As I am a long way from any kind of expert on how other people use these boards, maybe the link makes sense as is. In that case, perhaps adding another link to the combined DWC and the firmware download page could also be added.

Thanks again, I am not being critical, like I said you and David and whoever else are helping you do a great job. I always appreciate the support you all provide.

Jim

@Phaedrux Thanks...I tried here are the results

I also then reinstalled 3.4.6. That installed and reset the DWC to 3.4.6. So, everything matched.

I then did a hard rest on the board powering off, then on.

I then redownloaded 3.5.1 and used the system tab upload to install it again.

Sadly, with the same result as before. Still showing firmware version as 3.4.6 and DWC as 3.5.1.

@Phaedrux I used the install update button on the machine-specific tab. I also, just tried to upload it again from the system tab and again, it installed without errors, but I still got the same result. I did not revert back to 3.4.6 first, not sure if that makes a difference. Thanks

@Phaedrux Thanks. I wound up finding another version of this file online and it seems to work fine. I suspect there was some hidden control characters in the other file messing it up. For the moment no need to pursue further.

However, I did download and install version 3.5.1 on my Duet 2 WiFi board. I down;oaded the zip from the Github page and used the installer in the DWC. It installed fine but when it was done it reported the following. I thought both the DWC and the Duet 2 should have updated to 3.5.1? Was this only a DWC update? Thanks

So, without changing anything else, I added a G28 to home after the Z offset probing commands. With just the G28 the system homes but the probe still does not retract. However, if I add a M402 command after the G28, the system does the G30 probes, then the G28 homes, then M402 forces the probe to retract. I also added manual G1 commands to the end of the file to retract the probe and those work as well. Not sure if that helps understand what is going on, but I hope it means something to somebody here because I should not need the last G28/M402 or the manual movements to retract the probe in this macro. At least I have a work around for the issue but I would like to understand why macro does not work as it should. Thanks for any help anyone might have.

;Z Offset Calibration Finish

M98 P"Check to see if probe is attached.g" 

G90												;set absolute

M401

G1 Z20											;raise Z up 20 mm

G30 S-1	F150									;(G30) home z (S-1) record z height

G4 P500											;pause .5 sec

G1 Z20											;raise Z up 20 mm

G30 S-1	F150									;(G30) home z (S-1) record z height

G4 P500											;pause .5 sec

G1 Z20											;raise Z up 20 mm

G30 S-1	F150									;(G30) home z (S-1) record z height

G4 P500											;pause .5 sec

G1 X175 Y175 Z25								;move Hot End to X175 Y175

M291 P"Check Consule for Results of Probing "  S2 ;instruct user to check results in Consol

G1 X63 Z20 F20000
G1 Y345
G1 X175
G1 Y175

;G28 Z

;M402

@Phaedrux Do you have any ideas why a macro would execute normally up until the last command line and then terminate without reporting an error and without executing the last command line in the macro (in this case M402)? It seems not executing all lines in the macro would create some kind of abend that would trigger some kind of error? Thanks

@OwenD Thanks for the input. See comments below.

So your condition is going to return true any time the micro switch is not actually pressed if it's an N/O circuit and likewise return false if it's an N/C circuit
How is it defined in config.g?

Config.g M558 P5 C"^io2.in" H10 A10 S0.005 F1200:150 T18000 ; set Z probe type to switch type for Voron PCB Klicky on pins IO_2.in and the dive height (H10)
Switch is NC

You can check in the object model browser which value you have during the process.
When connected as a NC switch the probe value is 0. When triggered it is 1000

I would have thought you'd be checking if the probe was attached rather than whether it's "active" ?
Semantics.. I used active/attached interchangeably in this case, attached is more descript.

EDIT
Your code seems to assume that as soon as the probe is picked up you get a value of 1000. When picked up, as noted above, the probe value is 0. The code doesn't assume this, that is what happens.

That may be possible, but as stated the value is meant to be an indicator of whether the switch is depressed by touching the bed.
If the probe is docked and not electrically present do you get a null value? Sorry, not sure what this is asking.
That may be a way to check if it's attached.

Also it's much better to put your code in blocks rather than as attachments Thanks will use this in the future.

@Phaedrux Thanks. I just did that (M291 P"Check Consule for Results of Probing " S2) and it did block and ask for OK to proceed, when I clicked on the OK the system just cleared the message and then stopped. Probe still not docked.

BTW, if I manually issue a M402 the probe docks as it should. But if I include M402 in the file, it just reports "Probe Retract Failed"

I am running a Duet 3 Mini 5+ (Mini5plus)
Firmware: RepRapFirmware for Duet 3 Mini 5+ 3.4.6 (2023-07-21)
Duet WiFi Server Version: 1.27
Probe: PCB Klicky

I included the set of macros I use for determining my Z offset. The first file is used to start the process and then bed.g is called to tram the bed, then the finish macro runs the G30 probing to determine the offset.

Everything runs as expected, except that at the end of the Z Offset Calibration Finish file either the hot end just stops after the M291 command and the probe does not retract, or I get a message "probe failed to retract". Which one depends on what I put after M291. The current version just stops and does not retract with no message. If I use M402, or M98P"retractprobe.g" I get the error. I even tried adding a g28 at the end. With that, it did the homing but still did not retract the probe.

Any ideas to get this probe to retract after this routine would be appreciated. Thanks

_Z Offset Calibration Macro.txt
bed.g.txt
Z Offset Z Calibration Finish.g.txt
retractprobe.g.txt

@moth4017 Thanks. That pretty well answers the question. I am buying an Omron and will start over. I suspect it will help.

As always, I am never quite sure where to ask questions. So, if this is the wrong group, please point me in the right direction. I built a new klicky probe for my Voron 2.4 running Duet 3 Mini 5+ hardware and DWC 3.4.6. I bought cheap Chinese switches instead of the Omron (my mistake). The switches seem to be less accurate than the Omron I was using , as it seems to often take more probe attempts to get a good reading.

I did a probe repeatability and got these results;
M292 G32 bed probe heights: -0.090 -0.094 -0.094 -0.097 -0.097 -0.097 -0.090 -0.090 -0.094 -0.094 -0.094 -0.094 -0.092 -0.094 -0.094 -0.097 -0.099 -0.097 -0.094 -0.092 -0.090 -0.092 -0.096 -0.094 -0.097 -0.094 -0.092, mean -0.094, deviation from mean 0.003. These results seem pretty good to me, but if anyone can confirm that, or tell me what they should, be that would be appreciated.

@gloomyandy Thanks. That was the source of the issue. I figured out how to get around it. I appreciate the help. Regards, Jim