@droftarts Great! Exactly what I was looking for, must have overlooked the note. Thanks!

@Chriss I know that using "R1" in an M98 call can change the behavior of a macro such that it can be interrupted. The behavior still isn't what you might expect though, reference the G-code dictionary. I haven't tested calling g-code files within another g-code file using M98 and seeing if those can be paused.

When I opened up to take a picture of the wiring, I noticed a piece of unconnected wire that had fallen off and was resting on the Duex. I guess I'm lucky not to have shortened anything, but the issue is definitely resolved 🙂

Thanks @gloomyandy for your indirect help 🙂

@Chriss glad you got this sorted! I missed the LED as well.

@chrishamm that indeed did the trick. It also fixed the issue with the order of powering the device. Many thanks.

@victornguyening Most likely is that the firmware on the Duet 2 and PanelDue are out of sync. Send M115 in the console in DWC and post the response, and go to the 'Setup' screen on the PanelDue, and the firmware version will be reported at the top.

Also check your config.g has M575 P1 S1 B57600 to enable support for PanelDue.

Ian

@droftarts @jay_s_uk

Thanks guys... I found it there. I was under the impression that the setting was somewhere in the firmware and not in the DWC.

Cheers, Chriss

@DonStauffer that buffer won't work for I2C because it is unidirectional; but the Adafruit board sounds OK to connect directly.

@Mklein23 great, hopefully this resolves the initial problem of not being able to connect to DWC!

Ian

@DonStauffer state.status is "processing" only while a job is running from SD card. It's still "processing" even if the job calls a macro.

@olympio what will you be using to trigger the duet to trigger the Wifi read? This is probably better handled in possible by the overall control software. Adding this to RepRapFirmware would be quite a significant bit of work.

@dc42 Yes, great. it is that. We solved the issue by using a semiconductor relay allowing to provide external trigger for our Duet 3 board input, in which we chose the active-to-inactive stage change. Thanks again!

@soare0 Thank you.

anybody got an idea or a pointer for my problem?

@bug2k22 The Duet3D images are based on the official RPi OS so it's definitely an easier choice. A few differences I can think of:

Different boot screen* Auto-setup of correct TfrRdy pin in DSF config (needed on RPi 5 only) Preinstalled packages from unstable package feed Auto-start of DWC in full-screen mode* A couple of extra preinstalled packages including required dependencies like AppArmor Only applies to GUI image

@T3P3Tony thanks. I have a converter on the way

@T3P3Tony

I think I'm actually OK with it working the way it does. I moved my build surface back so the far edge is at the end stop. I then gave myself some overhang at the front. Now when I start a print I move the nozzle off the build surface at the front and prime. When I start the print, any ooz gets sliced off.

Thanks For the help

@SANJR please supply a link to the technical data for the welder and explain how you have connected it to the Duet.

For anyone interested, the issue is that FAT32 only supports up to 32Gb. Larger capacity SD cards use EXFAT format but that's subject to Microsoft patents.

@DonStauffer Did you have DWC tabs open in your browser, one editing bed.g and the other editing config.g? Or anything else significant that might explain the behaviour?

Please can you also confirm the exact DWC and RRF versions. Probably one for @chrishamm to look at!

Ian