Hiya - I wanted to share this post on my website documenting a basic Duet CNC Controller that I've built. I've included illustrations of the wiring diagrams in logical stages, bill of material, as well as my system and macro files, workflow, and post processor for Vcarve. I wouldn't have been able to piece it all together if it wasn't for this forum - so many thanks for all the pointers along the way. I hope this post will help people building their Duet CNC Controller.
Hiya - This is something I've mentioned before but I'd like to request non buffering commands for future firmware versions. That is to say when one macro of movement is being executed the web interface and paneldue should not accept additional instructions until the last one has completed. This is for safety reasons and particularly a problem with CNC routers / and larger 3D printers. It's very easy to accidently press a movement button or macro twice and while soft limits might prevent crashing - material / limbs can get caught between moving parts.
The issue was partly addressed in this post by JoeSmale - with their pendant being able to turn buffering off. I still think this option needs to be available in the web interface.
I can confirm I've been able to create macros to set the wasteboard and tool length. My wasteboard setting macro is:
M291 P"Jog spindle until tool tip touches surface of waste board." R"Set Waste Board" S3 X1 Y1 Z1 ; jog to wasteboard
G10 L2 P9 Z{move.axes[2].machinePosition} ; save coordinate to G59.3 WC
G10 L2 P2 Z{move.axes[2].workplaceOffsets[8]} – {move.axes[2].workplaceOffsets[7]} ; Subtract G59.3 from G59.2 and set offset in G55
M400 ; wait for last command to end
M500 ; store to memory
G55 ; swap to G55 WC
and stationary tool length setting macro:
G55 ; return to G55 WC
G10 P1 X0 Y0 Z0 ; reset axis tool offset
M291 P"Press Ok to peform probe cycle" R"Warning" S3
G30 S-1 K0 ; begin probing movement
G91 ; incremental movement
G1 F500 Z3 ; move up 3mm
G90 ; absolute movement
G30 S-1 K0 ; begin probing movement
M400 ; wait for current move to finish
G10 L2 P8 Z{move.axes[2].machinePosition} ; store probe ocaiton to G59.2 P8
G10 L2 P2 Z{move.axes[2].workplaceOffsets[8]} – {move.axes[2].workplaceOffsets[7]} ; Subtract G59.3 from G59.2
M500 ; store to memory
G53 G0 Z-10 ; move to safe z position
I use G54 to mirror the G53 machine position - so work in G55. I use G59.3 to set the wasteboard, and G59.2 for stationary touch probe. for set Thank @jay_s_uk for pointing me in the right direction.
@joesmale That does look great - the ability to turn off buffering will makes using the pendant a lot safer. I do feel that feature needs to be built into the RRF especially if the controllers are able to power bigger and larger machines - both CNC and 3D Printers.
@chrishamm - I've just swapped over to the latest DWC 3.3.0 from the CNC one. I prefer the smaller buttons in the dashboard - and lack of move to Go To Work XYZ Zero which would have caused a crash on my set-up. I have multiple tools which I can see now in CNC mode - I can see which mode I am in - as I will use a laser on my set up as well. I think the addition of the machine position and what work coordinate is active in the status bar would be good enough for me and most CNC users. Look forward to trying some of the new plugins too. Many thanks.
@phaedrux Thanks but I'm not sure yet. I'm planning to use 4 tools on my CNC machine. T0 - laser, T1 - Spindle Router (main tool), T2 - Pen Tool in Spindle, and T3 - Tangential Knife. I'm still getting my head around workflow, working out offsets and g-code generation for multiple tool jobs.
@EducatingSavvas In RRF3.01 RC6 you can now remove the line G60 S0 ; Save Spindle Speed from the pause.g file and change M3 R0 to M3 R1; Turn on PWM in the resume.g file.
@jay_s_uk Thanks for sharing that! There's a lot of food for my thoughts, and the touch probes look really good btw. My set up is a little different as I have a stationary button which acts as my tool touch probe. It is also set below the surface of my wasteboard at the front of my machine.
So this is not tested, but I imagine I could use:
M291 X1 Y1 Z1 ; jog to wasteboard
G10 L2 P9 Z{move.axes[2].machinePosition} ; Save coordinate to G59.3 WC
M500 ; Store to memory
I can then move to my probe location at the front of my machine:
M291 P"STAND CLEAR! Move to Probe Location." R"Warning" S3
G90 ; absolute movement
G53 G0 Z-10; ; move to safe Z in machine coordinate system
G53 G0 X83 Y41.7 ; move X and Y second in machine coordinate system above stationary probe button
and then perform my probe cycle.
M291 P"Ensure tool is above stationary probe location." R"Warning" S3
G10 P8 X0 Y0 Z0 ; reset axis tool offset
G30 S-1 ; Probe at the current XY position and report
G91 ; incremental movement
G10 L8 P8 Z{move.axes[2].machinePosition} ; adjust G59.2 WCS
G10 L20 P1 Z{move.axes[2].workplaceOffsets[9]-move.axes[2].workplaceOffsets[8]} ; Set origin of G54 Z relative to the current position of the tool, minus wasteboard offset from tool probe offset???
M500 ; store to memory
G53 G0 Z-10 ; move to safe z position
Going to have to trail this out when I next have time. It didn't occur to me that I could save axis location to workspace coordinates but this is a great lead. And in theory I won't have to perform the first part until I resurface flat the wasteboard. I'll report back on the weekend once I have tested it. Cheers!
@chrishamm Hi and thanks for the update. I've just updated to the new web controls from 3.3 but have lost any information about machine and work positions at the top of the dashboard. I am using CNC Mode. I can see it returns in Printer Mode. Is it also possible to have the option to see this information for advanced users, and to also remove the Go To Zero button under the movement buttons. If someone is using the wasteboard as Z0 and material has been fixed, moving to zero will crash the bit.
Ah thanks - will it ever likely be implemented?
I've included the following lines in my config file.
M950 P0 C"e0heat" ; Allocated GPOP Port 0 to Heater 1
M453 C"e1heat" Q300 R24000 ; Set to CNC mode, using Tool 1, 24000 Max RPM
and have updated my post processor in V-carve to include M42 P0 S1 next to the M3 S# command and M42 P0 S0 next to M5. So I can still use my machine.
But is there a way of switching additional pins alongside the one assigned to the M3/M5 command without editing the post processor? I'd like to control LED lights when g-code commands are executed, as a kind of safety traffic light system. Red for M3. Yellow for G1 G0 G2 G3 movements.
@jay_s_uk I'm going to have to wait till I wire up the test rig onto my CNC machine to test this. It's too confusing to imagine the stages without seeing the machine moving. May take a while to report back.
Hi - I think I've noticed a bug with RRF 3.4beta7 - after resuming from a pause the job doesn't commence. To make this complicated I am testing an external trigger which I am using as a door enclosure interlock for a CNC machine. Pausing using the web interface and the external trigger seem to cause the same response while resuming. The status of the machine goes from resuming to processing but there is no movement. This isn't an issue with RRF3.3.
The door external trigger is defined as such in the config.g file:
M950 J5 C"e0stop" ; use e0stop for input j5
M581 T5 P5 S0 R0 ; T5 trigger active-to-inactive edge at anytime
Condition2.g looks like this:
while sensors.gpIn[5].value=0
M291 S2 R"Enclosure Door Open" P"Close the door and press OK to continue."
Trigger5.g looks like this:
if state.status == "processing" & sensors.gpIn[5].value=0
M25 ; Pause
My start.g file looks like this:
M98 P"Condition2.g" ; call condition2.g to check enclosure door pin
My pause.g file looks like this:
G91 ; relative positioning
G1 Z5 F500 ; slowly move z axis to safe location clearing material
G90 ; absolute positioning
M5 ; turn off spindle PWM & spindle enable
G53 G1 F1000 Z129 ; move z axis to safe z
And resume.g file like this:
M98 P"condition2.g" ; Call Condition2 to check enclosure door pin.
M3 R1 ; Turn on Spindle Enable
G4 S1 ; Dwell to give time for spindle to reach speed.
Hope this post find everyone well despite everything.
I'm in the process of migrating my firmware from RRF2.05 to RRF3.01 and wanted to clarify an issue I raised some time ago in this post: https://forum.duet3d.com/topic/11665/assigning-multiple-pins-for-cnc-m3-command-use
It was suggested that the M453 command could be extended to include C"out3+out4+out5" 'where the first 2 pins are assumed to be on/off pins for forward and reverse, and the third pin is assumed to be the PWM control pin for both directions.' Has this been implemented in recent firmware updates?
Alternative Axis Movement/Speed Control (for CNC & Larger 3D Printers)
Hiya - this is just an idea, but I'm curious to know if it's possible to have an alternative movement controls for the duet.
At the moment, the axis movement is based on selecting a specified distance with a pre-set speed on the web interface, or with a pendent where a wheel is turned and the selected axis movement occurs. In both cases the movement carries on after the action of pressing the button or rotating the wheel has stopped.
Is it possible to have an alternative movement control where there are arrows for the axis in either direction - and for the movement to only occur while the arrow is pressed and to stop when un-pressed with no buffering. There could be four speeds, such as fast, medium, slow and per-step.
I'm sure most people have managed to crash their tools into material, hold-downs or plunge into the wasteboard using the current movement method. It's also requires more steps and planning. I only suggest this as that latter feels like a safer way to move axes - and prevent crashing. If you imagine a large 8x4 CNC machine - it would be easy to become inpatient moving over a large distance and to overshoot your mark.
I'd be curious to know if people would prefer this?
@jay_s_uk I can confirm the use of arcs in the gcode seems to be the problem. I removed any lines referring to arc moves from the post processor and the long resume time has stopped with RRF3.4. But this now means the Gcode files are really large.
Firmware Wishlist
Hiya – I’m just making an observation about VFD spindle stopping times which might be useful to consider some behaviour of the Duet.
I'm using a RS Pro L510s VFD for a small 1.5kw spindle on my setup. These VFD are very customisable, for example I am able to programme mine to accept an input to switch between a main and secondary frequency select. That was I can use the signal from the duet – and switch to a manual mode using a potentiometer. I am also able to use a signal from my physical E-stop and to have two different stopping speeds. Under a normal M5 command the spindle will stop in just under 10 seconds but if I press the physical estop – along with an external M112 trigger for the duet, I have physically wired the E-stop to my VFD to perform a faster stop under 4 seconds.
I’ve noticed that if I press the digital estop button either on the web interface or paneldue, the spindle stops at the M5 speed. I want to request that the m112 command be revised so include the ability to select an arbitrary pin to use as an output trigger for braking components external to the duet – such as a spindle frequency drive.
Cheers, Savvas
@dc42 I'm aware of these style pendants and not a great fan of them. They seem inefficient with the number of steps for moving, plus they can still overshoot their mark when the wheel has stopped turning. That along with the buffering of commands makes this feel unsafe especially for larger machines. If a duet based system is risk-assessed for use say within an educational institution those behaviours will work against it being chosen over something else.
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.4.0beta7+7 (2022-01-14 08:59:56) running on Duet WiFi 1.02 or later
Board ID: 0JD0M-9P6B2-NJ4S8-6J9D8-3S46P-TV6AM
Used output buffers: 2 of 24 (15 max)
=== RTOS ===
Static ram: 23844
Dynamic ram: 73496 of which 324 recycled
Never used RAM 11488, free system stack 130 words
Tasks: NETWORK(ready,13.2%,258) HEAT(notifyWait,0.0%,353) Move(notifyWait,0.0%,307) MAIN(running,86.8%,362) IDLE(ready,0.0%,30), total 100.0%
Owned mutexes: USB(MAIN)
=== Platform ===
Last reset 00:06:52 ago, cause: power up
Last software reset at 2022-01-24 13:29, reason: User, GCodes spinning, available RAM 11272, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Step timer max interval 0
MCU temperature: min 31.9, current 32.8, max 33.3
Supply voltage: min 24.2, current 24.3, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/24/24, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: pos 400, standstill, SG min n/a
Driver 1: pos 400, standstill, SG min n/a
Driver 2: pos -400, standstill, SG min n/a
Driver 3: pos 400, standstill, SG min n/a
Driver 4: pos 0, standstill, SG min n/a
Driver 5: pos 0
Driver 6: pos 0
Driver 7: pos 0
Driver 8: pos 0
Driver 9: pos 0
Driver 10: pos 0
Driver 11: pos 0
Date/time: 2022-01-24 14:02:19
Cache data hit count 4294967295
Slowest loop: 3.90ms; fastest: 0.20ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 3.3ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, segments created 3, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 11, completed 11, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARi
ng ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is ready with "m122" 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty
=== Network ===
Slowest loop: 201.05ms; fastest: 0.10ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(1), 1 sessions
HTTP sessions: 1 of 8
@egauss Have you looked at this yet: https://duet3d.dozuki.com/Wiki/Stall_detection_and_sensorless_homing
@alex-cr Hi Alex - I've used triggers but since going from RRF3.3 to RRF3.4beta7 there seems to be an issue with resuming. I think something as safety critical as an interlock should be defined by it's own gcode. It's just a suggestion, as some workflows seems to be overlooked.
For example using M291 S3 command in a start.g file doesn't cancel the job about to commence if the message is cancelled.