@n7jti The "L" made no difference at all.
Posts made by N7JTI
-
RE: Setup Relay-Controlled Spindle
@nightowl999 I can already switch my router on and off via a relay. The problem here is that I have to hand-edit the g-code that comes out of the post-processor in order to get my router to turn on and off automatically. That is painful. I'd rather have the router respond to M3/M5.
So how do we get a pin to be high/low in response to an M3/M5 command?
-
RE: Setup Relay-Controlled Spindle
@o_lampe I tried using nil as a pin and it errors when I try it. SO I'm using an unused pin. I'll give the "L" a shot
-
RE: Setup Relay-Controlled Spindle
Is there some better place on the forum to post this?
-
Setup Relay-Controlled Spindle
I'm trying to get M3/M5 to work for spindle control on my Duet3 controlled CNC. I have a relay that controls power to my trimmer-router based spindle. There is no RPM control, just on-off.
I can control the relay... If I just define it as a GPIO I can toggle the GPIO. So, this works to define the GPIO
M950 P1 C"out1"
The following code does NOT work to define a spindle. I get no errors, and I can't see a spindle defined in the web interface and M3 does not actuate the relay. out3 is not used.
; Set CNC mode M950 R0 C"out3+out1" Q100 M563 P0 S"Spindle 1" R0 ; Create tool 0 with spindle 0 and call it "Spindle 1" M453
What am I missing here?
Thanks,
Alan -
RE: N7JTI Duet3 CNC Build
@alpenprinter So sorry it has taken me so long to get back to this.
- Yes, I'm a Fusion360 user.
- I use a version of the DIY CNC Fusion 360 CAM post processor: https://github.com/guffy1234/mpcnc_posts_processor
- The software DOES create the M3 and M5 commands.
- I do 3D probing using a probe block that I bought from Avid.
If you are looking for the code or configuration that I use for my z-probe then you can have a look at my github repo where I store my configuration: https://github.com/n7jti/duet3-avid-cnc
Sorry I'm so late in getting this info back to you. I hope you find it at least interesting if not actually helpful.
-
RE: Firmware Skips a few gcode instructions -- known issue?
Ok, the machine seems to be performing mostly correctly now. I'm still seeing my macro probing the wrong direction occasionally, but I haven't caught it doing that in the last half-our. So I'm going to mark this as "solved" since my problem of the head occasionally not lifting seems to be fixed by the updated firmware.
If I can find a clear pattern for when the probing macro probes "towards the workpiece" in the wrong direction I'll open another question.
Thanks again for the great support!
-
RE: Firmware Skips a few gcode instructions -- known issue?
Ok, so here's the problem I've got with G30. It probes the bed and sets the machine coordinates.
That isn't helpful. I need the WCS coordinates to be updated to z0.
-
RE: Firmware Skips a few gcode instructions -- known issue?
Ok, I think I may have found it. The dive height I set negative becase it was probing the wrong direction... that seemed to have unintended consequences. So it is no longer diving after touching the plate.
... -
RE: Firmware Skips a few gcode instructions -- known issue?
@Phaedrux but the problem I seem to be having with BOTH of these is that the directions are very backwards. instead of lifting on a g30 contact it is diving. And instead of probing DOWN towards the touchplate with the G38 command it is probing UP.
Does the beta firmware probing not pay attention to which direction is positive on my z-axis? This used to work.
-
RE: Firmware Skips a few gcode instructions -- known issue?
@Phaedrux Well, that just cost me a bit and damaged my touch-pate.
I ran "g30" and the head dropped carefully down till it touched the plate... and then drove the v-bit straight down into the plate until the motors couldn't drive any further... badly scratching the touch plate and chipping the bit.
So, what I would like to have seen it do is STOP when it made contact with the touch plate.
So, how is G30 supposed to work?
-
RE: Firmware Skips a few gcode instructions -- known issue?
@Phaedrux My recent updates to try and get probing to actually probe down far enough to reliably set zero
; Z-Probe
M558 K0 P5 H20 C"^!io1.in" F120 T6000 ; Z probe speed and travel speed
G31 X0 Y0 Z25.4 ; set the z-probe trigger height to 1 inch -
RE: Firmware Skips a few gcode instructions -- known issue?
@Phaedrux The z-probe is just a machined touch plate. Basically it acts like a switch, but really it is just measuring current passing through the tool itself into the touch plate. Well, to be brutally specific, the tool is "ground" and the current source is the touch plate. x-y offset should be zero, as the tool itself makes the contact and there is no offset. The z-offset is 1 inch.
I haven't been able to figure out how to get G30 to do anything like what I need. I've pasted the macro I use to set my z0 below. Should this be possible from a G30 command? How?
The behavior of this macro seemed to be different with the new firmware. I've had to update my "dive height" with an h-parameter in M558 so that it probes toward the workpiece more than just a handful of mm.
z_probe.g macro
; Probe in Z and reset 0
G91 ; Set Relative Mode
G38.2 Z P0 ; probe in the z direction
G10 L20 P1 Z25.4 ; set the z-height of WCS 1 to 1 inch
G0 Z50 ; rise up around 25mm to remove the z-plate
G90 ; Set Absolute Mode -
RE: Firmware Skips a few gcode instructions -- known issue?
Alright, I just completed two more rounds of that same gcode using the beta firmware.
-
Probing with my z-probe now appears to be unreliable. It either doesn't probe downward, or probes downward very little. This was very reliable before. I couldn't find any documentation related to changes in this area. Did I miss something?
-
After the upgrade I lost my CNC specific web control software. Could this have been the problem? Is there a version of the CNC specific web interface that is approved/safe for the beta firmware?
Those two issues noted: Both cuts completed without error. Here are the "after" photos:
![1_1609353446134_20201230_103207.jpg](Uploading 100%) 0_1609353446133_20201230_103159.jpg](Uploading 100%) -
-
RE: Firmware Skips a few gcode instructions -- known issue?
I need to go cut some more stock out of my sheet of MDF to try this again. But my son just noticed that even the first one isn't cut correctly. If you look carefully at about the 3:00 position you'll see another much less serious case where the head didn't fully lift before doing the movement.
Could this be related to the mixing of the G0 and G1 commands? Could one of them be "interrupting" the earlier command?
I'll have the results with the beta firmware in an hour or so.
Here's an example of the gcode The lift doesn't complete before the head moves:
G1 X100.404 Z-1.5
G1 Y95.405 Z-0.001
; MOVEMENT_RAPID
G0 Z5 F300
G0 X84.976 Y75.025 F2500
G0 Z3 F300
; MOVEMENT_LEAD_IN
G1 Z-0.001 F1905
; MOVEMENT_CUTTING
G1 X87.096 Z-1.5
G1 Y72.905 Z-0.001 -
RE: Firmware Skips a few gcode instructions -- known issue?
; Configuration file for Duet WiFi (firmware version 3)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v3.1.8 on Mon Nov 23 2020 08:08:52 GMT-0800 (Pacific Standard Time); General preferences
G90 ; send absolute coordinates...
M83 ; ...but relative extruder moves
M550 P"avid_cnc" ; set printer name
M669 K0 ; select Cartesian Mode; Drives
M569 P0 S1 ; physical drive 0 goes forwards
M569 P1 S0 ; physical drive 1 goes backwards
M569 P2 S0 ; physical drive 2 goes backwards
M569 P3 S0 ; physical drive 3 goes backwards
M584 X0 Y1:2 Z3 ; set drive mapping
M350 X16 Y16 Z16 I1 ; configure microstepping with interpolation
M92 X251.9685 Y251.9685 Z251.9685 ; set steps per mmM566 X900.00 Y900.00 Z60.00 ; set maximum instantaneous speed changes (mm/min)
M203 X2500.0 Y2500.00 Z1000.0 ; set maximum speeds (mm/min)
M201 X500.00 Y500.00 Z250.00 ; set accelerations (mm/s^2)
M906 X2000 Y2000 Z2000 I30 ; set motor currents (mA) and motor idle factor in per cent
M84 S30 ; Set idle timeout; Axis Limits
M208 X0:789 Y0:997 Z0:243 ; set axis minima & maxima; Endstops
M574 X1 S1 P"!io3.in" ; configure low end on X
M574 Y1 S1 P"!io5.in+!io6.in" ; configure dual self-squaring low end on y
M574 Z2 S1 p"!io8.in" ; configure high end on z (z homes high); Stop if hit the endstops
M950 J0 C"!io4.in" ; X far-end
M950 J1 C"!io7.in" ; Y far-end
M581 T0 P0:1 X Y Z S1 ; Stop when endstops are reached; Z-Probe
M558 K0 P5 C"^!io1.in" F120 T6000 ; Z probe speed and travel speed
G31 Z25.4 ; set the z-probe trigger height to 1 inch; Pendant
M575 P1 B57600 S1 ; enable serial comms; Heaters
M140 H-1 ; disable heated bed (overrides default heater mapping); Fans
M950 F0 C"!out4+^out4.tach" Q2500 ; create fan 0 on pin fan0 and set its frequency
M106 P0 S0 H-1 ; set fan 0 value. Thermostatic control is turned off; Dust Collection
M950 P0 C"out2" ; Create GPIO pin on out2 for dust collection; Tools
M563 P0 D0 F0 ; define tool 0
G10 P0 X0 Y0 Z0 ; set tool 0 axis offsets
G10 P0 R0 S0 ; set initial tool 0 active and standby temperatures to 0C; Set CNC mode
M453 S0 C"out1" R1 ; turn on CNC mode and set out1 as spindle control; Custom settings are not defined
; Miscellaneous
T0 ; select first tool; Allow movement on non-homed axes -- Remove this when endstops arrive
M564 S0 H0 -
RE: Firmware Skips a few gcode instructions -- known issue?
m122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.1.1 running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-956BA-NA3TN-6J1DL-3S86P-9TBUT
Used output buffers: 1 of 40 (10 max)
=== RTOS ===
Static ram: 154604
Dynamic ram: 162024 of which 52 recycled
Exception stack ram used: 512
Never used ram: 76024
Tasks: NETWORK(ready,1968) HEAT(blocked,1416) CanReceiv(suspended,3820) CanSender(suspended,1432) CanClock(blocked,1436) TMC(suspended,68) MAIN(running,5056) IDLE(ready,76)
Owned mutexes:
=== Platform ===
Last reset 02:10:47 ago, cause: software
Last software reset at 2020-12-30 01:07, reason: User, spinning module LinuxInterface, available RAM 75800 bytes (slot 3)
Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task MAIN
Error status: 0
MCU temperature: min 26.8, current 28.6, max 31.0
Supply voltage: min 0.2, current 0.3, max 24.4, under voltage events: 0, over voltage events: 0, power good: no
12V rail voltage: min 0.1, current 0.2, max 12.4, under voltage events: 2
Driver 0: standstill, reads 11456, writes 39 timeouts 0, SG min/max 0/635
Driver 1: standstill, reads 11448, writes 47 timeouts 0, SG min/max 0/674
Driver 2: standstill, reads 11448, writes 47 timeouts 0, SG min/max 0/692
Driver 3: standstill, reads 11448, writes 47 timeouts 0, SG min/max 0/619
Driver 4: standstill, reads 11473, writes 22 timeouts 0, SG min/max 0/0
Driver 5: standstill, reads 11473, writes 22 timeouts 0, SG min/max 0/0
Date/time: 2020-12-30 03:18:30
Slowest loop: 4.79ms; fastest: 0.13ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 375, MinFreeDm: 368, MaxWait: 99492ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 482, completed moves: 482, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
=== Heat ===
Bed heaters = -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is ready with "M122" 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
Code queue is empty.
=== Network ===
Slowest loop: 1.05ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions
HTTP sessions: 0 of 8- Ethernet -
State: disabled
Error counts: 0 0 0 0 0
Socket states: 0 0 0 0 0 0 0 0
=== CAN ===
Messages sent 4, longest wait 0ms for type 0
=== Linux interface ===
State: 0, failed transfers: 0
Last transfer: 13ms ago
RX/TX seq numbers: 55924/55926
SPI underruns 0, overruns 0
Number of disconnects: 0
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.1.1
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 32.21
- Ethernet -
-
Firmware Skips a few gcode instructions -- known issue?
I've been doing some carving with my CNC and noticed a mistake in the carving. If I run my g-code file the first time, it carves correctly. Here is a photo of the gcode file being executed correctly.
but when I switch out the stock and run the same file a 2nd time, it doesn't lift to cut the third line and leaves an unintended v-carve grove in the carving. Both carves are the same gcode file run in succession. So the problem can't be in the g-code, so it is in the firmware or the hardware. Here is a picture of the file being run incorrectly. Note the head doesn't lift between v-carving the 2nd and 3rd lines leaving an extra line in the stock that isn't in the g-code.
Is this a known issue? Is there already a fix for this? I can reliably repro the issue using the gcode below.
- reset the machine
- Home the machine
- Set my work coordinates in WCS1
- jog the machine over to the center of my stock
- Set the z-height using my touch probe (and my z-probing macro)
- turn on my spindle and start the file.
- after the carve is complete, turn off the spindle. jog the head up and back so I can get to the stock.
- unclamp the stock, flip over. reclamp the stock, restart the spindle
- Run the gcode file a 2nd time by clicking it from the jobs menu.
- Watch the machine not lift before rapiding to the third line (~ line 60 of the gcode).