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.
@rjenkinsgb that works, thanks for that - so I'll have to write the IP addresses in the student workflow. Hopefully won't confuse them too much. @jay_s_uk Not bad, just busy as usual. It's strange but writing http://anything.local accesses the web controls.
@fcwilt No they shouldn't, and students will need training before accessing. I may put a password as an additional failsafe. The issue I had was using one computer to operate two CNC controllers due to space limitations. I guess I could get a modem and create my own local network as an alternative.
@jay_s_uk Hi Jay hope you are well! No, the names are different but both can access http://duet.local.
@fcwilt Hi Frederick - the CNC machines are in an educational setting - the network is only accessible via user accounts login details, so using access points seemed a lot easier with multiple users. When using client mode with multiple printers - what happens if you write http://duet.local in the URL? Maybe I'll have to get IT in to work out a solution.
@dc42 Was desperately hoping someone would create a kinematic for cartesian with a rotary z - for tangential knife cutters or concrete/clay printers with vector following nozzle.
@droftarts sorry this has taken me a while to reply too but using different IP addresses and moving between controllers on a single computer (changing wifi login using access points) doesn't result in the controller name updating in the browser without a manual browser refresh. This feels like a potential safety issue as the controller can still connect and commands accepted. Is there some g-code that can be placed into the config.g or daemon.g file which refreshes the browser after wifi reconnection?
@droftarts Thanks for that - I did wonder if having the same IP address would cause issues. I have had to change my workflow to include changing the pendant address but that is a small price to avoid this problem. I will test it out over the next week or so and report back what I notice.
Hiya - this is a general observation that I wanted to share. I'd be curious to know what people experience are for what is a rare problem. I have recently set up two workbees with my own self-built CNC controllers in an educational setting. I am using duet 2 wifi's with access points sending gcode from a single computer. I had a mishap when one wifi connection was disrupted and the computer automatically connected to the second however the browser didn't refresh to reveal the name of the controller I was connected too - named in the top left corner. I went to move one machine while the other was processing gcode and this resulted in the spindle turning off. The simple solution is to get a second computer and to make sure the login details are not swapped. But I'm wondering if it's possible and worth automatically refreshing the browser when reconnecting to the wifi network so the correction duet controller name is always displayed in the top left corner.
@dc42 Morning, I'm using a Duet 2 Wifi.
@dc42 Please let me know if you want me to test anything.
@jay_s_uk I'm not sure what I've done now but the spindle is not turning on when M916 is sent. I actually think it only turned on previously after plunging because there happen to be an M3 command in the gcode being processed. So essentially resume from power loss doesn't work for CNC as the M3 R1 is missing.
I wonder if there needs to be different resurrect.g files for CNC, FFF and Laser modes. If there is a way of identify the line the job gets paused on, I guess we can write our own macros.
Possibly another thing for @dc42 to write on the list.
Hiya - I've noticed an issue with resuming after a controlled power down. The spindle router tool, turns on too late and there is not enough time for the spindle to come to full speed before moving along cut toolpaths. It also does this after the spindle has plunged back into the material. Normally with CNC routers the tool turns on, comes to speed and then plunges into material. Even if it is plunging into an already existing cut line - coming to speed can rattle the tool against the edge of material and leave a noticeable mark. The spindle would best turn on during the resurrect-prologue.g or earlier in the resurrect.g file. I think deselecting the tool is causing this - T-1 P0 followed by T1 P6. Is there a way of changing this without having to manually update this every time it is needed?
I'm using RRF 3.4.0beta7+7.
M98 Phomeall.g ; home all axes
M3 S1000 ; Turn on spindle
G1 R1 X0 Y0 F1200 ; rapid move X0 Y0
; File "0:/gcodes/Test for Power Down Job Resume.nc" resume print after print paused at 2022-01-31 10:20
G21
G92 X49.337 Y163.160 Z-37.050
G60 S1
T1 P0
M98 P"resurrect-prologue.g"
M116
M290 X0.000 Y0.000 Z0.000 R0
T-1 P0
T1 P6
; Workplace coordinates
G10 L2 P1 X0.00 Y0.00 Z0.00
G10 L2 P2 X2.20 Y7.85 Z-29.85
G10 L2 P3 X0.00 Y0.00 Z0.00
G10 L2 P4 X0.00 Y0.00 Z0.00
G10 L2 P5 X0.00 Y0.00 Z0.00
G10 L2 P6 X0.00 Y0.00 Z0.00
G10 L2 P7 X0.00 Y0.00 Z0.00
G10 L2 P8 X0.00 Y0.00 Z0.00
G10 L2 P9 X0.00 Y0.00 Z0.00
G55
M106 S0.00
M116
G92 E0.00000
M82
M486 S-1
G17
M23 "0:/gcodes/Test for Power Down Job Resume.nc"
M26 S49831
G0 F6000 Z-35.050
G0 F6000 X49.337 Y163.160
G0 F6000 Z-37.050
G1 F3000.0 P0
G21
M24
Hello - is there a way of creating a popup text input box within the web interface, so a user can input a measurement, for example a G10 tool offset during a macro?
The workflow I'm imagining would be something like - setting a tool in spindle router to zero on top of material to be cut. prompt to input offset manually which is the material thickness - moving the zero position to the bottom of the material.
G10 P1 Z"G291 PInput Offset here: S#"@dc42 It's a Duet 2 Wifi in stand alone mode.
=== 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
@jay_s_uk Do you mean using YAT?
@chrishamm Hiya - I'm not able to send the M122 command as the send button is displaying a spinning wheel of doom.
I think this is an issue with M291 being within M98 commands. I also tried calling a macro at the end of a gcode job so the user would be prompted to move the spindle to a safe location or cancel.
G53 G1 F1000 Z-1 ; move z axis to safe z
T-1 ; Deselect tool
M291 P"Move carraige to safe X Y Axis location at rear of machine." R"WARNING" S3 ; saftey message
G53 G0 Y710 ; move gantry to rear of y axis
If I cancel the message which should perform a m292 P1 - I cannot input any commands into the console and the duet seem to get stuck in a loop.
@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.