@dc42 I wonder if you have any further suggestions on this issue? I'm really keen to work with you to get it sorted, but without anybody seeming able to identify anything obvious in the macro, no error messages to indicate any problem on the Duet, but with a total failure of movement and a rather core function needed for every CNC toolpath I'm unsure where to go next..? Should I just write-off this approach and go with a G38 based route like @Yveske, or are there more things I can try to help you diagnose the issue?

I was really hoping to move onto replacement Vue modules so that Ooznest customers (and others) can make use of the latest firmware 3.xx improvements (which I need for consistent laser support) and the excellent DWC-CNC work of @Sindarius (to hopefully provide a longer-term maintainable RRF3 compatible UI) - but at the moment I'm dead in the water. I obviously cannot expect customers to update their installations if I can't reproduce the existing capabilities they currently have under RRF2 & Ryan's original DWC.

Many thanks in advance. E

OK - thanks @dc42. I've re-uploaded alongside the WifiEth.bin from the RRF3.2.2Beta2 and confirmed the new firmware looks good:

Board: Duet 2 Ethernet (2Ethernet)
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.3beta2+1 (2021-03-19) 

The probe test macros, exactly as above, continues to give no error or motion I'm afraid.

One aspect of my set-up I should be clear about is I am running the DWC-CNC-CNC02-3.2.0-RC1 (built from the tagged branch on https://github.com/Duet3D/DWC-CNC) from my local machine and connecting to the Duet2 over ethernet. I'm using this UI to upload the firmware patches and trigger the macro. This is our test machine, so it has been upgraded from RRF2 in quite a few incremental steps now. Could any of these things be a source of this problem?

Can I just also formally confirm that my macro (as posted above) does run on the test rigs you have at your end - I'm not sure we have quite stated that explicitly so thought I should check?

E

@dc42 perhaps you could post a 'canonical' macro sample showing the commands as you intend them to be used and that you have verified at your end? If there is a typo/mistake in my macro this would help us to flush it out.

The set-up I (and I think many Workbee customers) have is simple and because of Ooznest's documentation: https://learn.ooznest.co.uk/Guide/Assembling+Your+Original+WorkBee+XYZ+Touch+Probe/61they should be configured pretty consistently. At this point I just need to reproduce the simplest Z probe (Step 8 ) under firmware 3.2.2 - which is needed before any CNC toolpath can be run.

The macro needs to drive the tool down in Z until contact with plate is made (wiring as per the link - plate is essentially an NO switch) and set Z0 in the current work-space to be this position, plus the thickness of the plate.

I cannot emphasise enough how core this functionality is. The Duet under RFW3.xx is not, in practical terms, usable as a CNC controller without it. It has been over a month since I raised this problem...

Thanks @dc42. The laser is connected directly to heater 3 (pin 8 ) and that inversion does appear to be all that was required.

So, just to clarify in case anyone else is reading this:

M452 C"!exp.heater3" R1000 F5000 

Will work on the toolpath post processor now.

Thanks again.

E

My machine has the Opt laser 6W add-on for the Ooznest Workbee in its default configuration. I believe that Opt recommend PWM control of between 5000-10000Hz. Our software scales (by default) the S formatted power range between 0-1000.

https://optlasersgrav.com/cnc-laser-upgrade-kits/workbee-laser-upgrade-with-plh3d-6w-xf-laser-head

I'm still trying to safely migrate to RRF3.2 and I have been trying to replace the simple RRF2 'Laser mode on' and 'Laser mode off' macros with the RRF3.2 equivalents.

Hardware under RRF2 works as expected with the following 'Laser mode on' macro:

M307 H3 A-1 C-1 D-1
M452 P3 R1000 F5000 S1

The replacement macro I am trying is currently:

M452 C"exp.heater3" R1000 F5000

This certainly enables the laser, but at full power and it does not appear to be subsequently controllable by M3/M5, G1s with S0 or G0 moves (which in this default setting should automatically turn it off shouldn't they?) This is rather alarming, to say the least.

Has anyone had any experience or success with this setup under RRF3.2? As always any advice gratefully received...

E

PS - my firmware remains at RRF3.2.2Beta2 as per my last posting

@chimaeragh thanks for posting those. I am just working through the simplest Z-only probe initially (@Kane on the other thread has a version of the macro that is now working for me). Once we have the Z probe working reliably (and I understand the subtleties of why my original macro was incorrect) I will use these to explore the tool diameter measurements.

Cheers
E

@kane - that seems to work for me! Many thanks. I simply changed the e1stop for the e0stop on my machine, but apart from that it seems to now run as I originally expected. There are a number of differences between our versions (we have commands in a different order and I use a different probe and dummy tool number, for example). I'll go through them line now and see if I can identify the precise problem with my original macro. I'll also see if I can confirm the other issue you mention.

Thanks again!

E

(@scrhall thanks for checking this too, by the way, much appreciated)

@dc42 perhaps you could post a 'canonical' macro sample showing the commands as you intend them to be used and that you have verified at your end? If there is a typo/mistake in my macro this would help us to flush it out.

The set-up I (and I think many Workbee customers) have is simple and because of Ooznest's documentation: https://learn.ooznest.co.uk/Guide/Assembling+Your+Original+WorkBee+XYZ+Touch+Probe/61they should be configured pretty consistently. At this point I just need to reproduce the simplest Z probe (Step 8 ) under firmware 3.2.2 - which is needed before any CNC toolpath can be run.

The macro needs to drive the tool down in Z until contact with plate is made (wiring as per the link - plate is essentially an NO switch) and set Z0 in the current work-space to be this position, plus the thickness of the plate.

I cannot emphasise enough how core this functionality is. The Duet under RFW3.xx is not, in practical terms, usable as a CNC controller without it. It has been over a month since I raised this problem...

OK - thanks @dc42. I've re-uploaded alongside the WifiEth.bin from the RRF3.2.2Beta2 and confirmed the new firmware looks good:

Board: Duet 2 Ethernet (2Ethernet)
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.3beta2+1 (2021-03-19) 

The probe test macros, exactly as above, continues to give no error or motion I'm afraid.

One aspect of my set-up I should be clear about is I am running the DWC-CNC-CNC02-3.2.0-RC1 (built from the tagged branch on https://github.com/Duet3D/DWC-CNC) from my local machine and connecting to the Duet2 over ethernet. I'm using this UI to upload the firmware patches and trigger the macro. This is our test machine, so it has been upgraded from RRF2 in quite a few incremental steps now. Could any of these things be a source of this problem?

Can I just also formally confirm that my macro (as posted above) does run on the test rigs you have at your end - I'm not sure we have quite stated that explicitly so thought I should check?

E

On uploading and installing Duet2CombinedFirmware.bin from your zip I get the following error:

Error: M997: In-application programming binary "0:/firmware/Duet2_SDiap32_WiFiEth.bin" not found

Do I need this additional file from somewhere, it is not included in the zip above?

E

Thanks guys - @dc42 I'll flash the new firmware this weekend and report back.

@dc42 I wonder if you have any further suggestions on this issue? I'm really keen to work with you to get it sorted, but without anybody seeming able to identify anything obvious in the macro, no error messages to indicate any problem on the Duet, but with a total failure of movement and a rather core function needed for every CNC toolpath I'm unsure where to go next..? Should I just write-off this approach and go with a G38 based route like @Yveske, or are there more things I can try to help you diagnose the issue?

I was really hoping to move onto replacement Vue modules so that Ooznest customers (and others) can make use of the latest firmware 3.xx improvements (which I need for consistent laser support) and the excellent DWC-CNC work of @Sindarius (to hopefully provide a longer-term maintainable RRF3 compatible UI) - but at the moment I'm dead in the water. I obviously cannot expect customers to update their installations if I can't reproduce the existing capabilities they currently have under RRF2 & Ryan's original DWC.

Many thanks in advance. E