Yet another CNC improvement (Outside machine limits)
-
Hate to be posting so many requests, but I know you're trying to improve the CNC side of the firmware so this should help.
I noticed an issue today. I had my workpiece centered in the vise on my CNC table, but my vise is not centered. When I went to cut it, there was a layer on a chamfer around the outside that hit my machine x axis limit and triggered a stop. All good and dandy. I actually had it set too small anyway.
The issue became apparent after reviewing the recording of the cut on webcam. (And here's my guess as to how it went down inside the firmware)
The moment the command buffer loaded the command to move outside the machine limits the spindle stopped. However, the move commands continued up until the command just before going outside the limits.
This could have been very bad (especially on machines far more powerful than mine and metal stock). Thankfully this occurred on a fine roughing pass so the bit didn't really make much contact, but had this occurred during the initial roughing pass bits could have broken, or worse.
I suggest when a command is received that is outside an axis limit, the spindle should be kept on until the buffer is emptied.
Side note, does this trigger a pause/cancel/stop g script because I can't tell, but it seems it just stops in position. I would also think it should trigger cancel.g if not already doing so.
-
Been there when I have added spindle control to my WorkBee... Set the spindle stop command to G4 P0 M5 instead of just M5. That way it will wait to execute all moves before turning off the spindle.
While not discovering that when crashing the machine, I had a very long straight cut as the final thing in a file and I found out that the spindle was already stopped at the end of the cut. Luckily it was just the final pass with no actual material to remove, but.....
-
I've checked the code. It should behave as follows (firmware 2.02 or 2.03beta):
-
M3/4/5 commands get synchronised with movement commands. So all preceding moves should complete before the M5 is executed. This will fail if the scheduled vs. completed move counts go wrong. When the machine is at rest (all queued moves completed), the scheduled and executed move counts reported by M122 should be equal.
-
A G0/1/2/3 command that commands an endpoint outside limits will just be omitted and execution will proceed with the next command. This is probably not what you need for a CNC. I guess the SD job should be aborted - correct?
-
A G2/3 command whose endpoint is within limits but has an intermediate position outside limits will be aborted when it tries to go outside limits. Execution will continue with the next command. Again, this is probably not what you want.
-
-
@dc42 I have not re-tested the M3/4/5 behavior with latest firmware. It is a test I can do next week.
As for commands outside machine limits, better having a piece of material that can be moved and properly processed instead of having a ruined piece of material! So issuing just a warning is not the best solution! Simply stopping the job is a much better one!
-
I have added the following work items for release 2,03:
- Check that in all modes, if insufficient axes are homed then the SD job is aborted
- In CNC or Laser mode, abort job if it goes outside machine limits, https://forum.duet3d.com/topic/9269/yet-another-cnc-improvement-outside-machine-limits/4
- In simulation mode, if the job was aborted for any reason, report this instead of reporting the simulated print time
-
@catalin_ro said in Yet another CNC improvement (Outside machine limits):
4 P0 M5 i
Hey just got back from a vacation...
Thanks, cool trick with the dwell spindle stop. Will try it out next run.
If that works no need to modify the M3/4/5's. Cool beans.
-
I want to believe that the M3/4/5 command is synchronized, but I don't see it reflected on my Duet running 2.02 when actually running.
I saw it again even when not going outside machine limits. A final chamfering pass on the inside of a rectangle. Just before finishing the last edge the spindle stopped, as it was only three or four commands away at that point.
Spindle stopped when executing either line N35310 or N35315 (unsure exactly).
N35305 G1 Y-38.979
N35310 G1 X-11.005 Y-40.978 Z-1.819
N35315 G1 X-13.004 Y-38.979 Z-3.818
N35320 G1 X-74.22
N35325 G0 Z15;ENGRAVE1 3
N35330 M5
N35335 G90
N35340 G54
N35345 G0 Z100
N35350 M291 P"chamfer mill, D=22mm, S=6mm, F=2, A=60, hss" R"Tool Change" S3
N35355 T0
N35360 M98 P"/macros/Tool Probe Auto"The machine continued with the G commands for the final edge (N35315, N35320 N35325) and just scraped the bit along the whole way with it not spinning.
I hadn't tried the G4 P0 M5 for that run so I will update with the new results after I make that change to my post-processor.
I just did a little test with manual GCode entry as well and while running a slow G1 straight line pass I am able to start and stop the spindle with M3/4/5 at will at any point during the move, is this supposed to behave the same as from a file? Because if it is, I shouldn't be able to send an M5 in the middle of a G1 move. Is it possible there is something in my config.g that is allowing this?
For G0/1/2/3 commands that go outside axis limits I would agree that aborting the SD job is the best strategy. With CNC re-running the code over and over again should do nothing because we take material away while 3D printers add material making resuming/restarting much harder.
And yes I think the same solution for G0/1 will work for G2/3 intermediates.
-
I just tried this with some manual gcode entry.
Starting at X-11
G1 X-50 F50waited a few seconds until it was about a 1/4 done with the move
G4 P0 M5
Spindle stopped immediately.
Think I'm gonna go back to a single GCode file per tool until this is working.
-
@hpiz said in Yet another CNC improvement (Outside machine limits):
I just tried this with some manual gcode entry.
Starting at X-11
G1 X-50 F50
waited a few seconds until it was about a 1/4 done with the move
G4 P0 M5
Spindle stopped immediately.That's expected. GCodes received over HTTP or from PanelDue are not synchronised. GCodes read from a streaming source are synchronised. So to test the synchronisation, put the M3/M4/M5/G1 commands in a print file or a macro file. Let me know if you find a sequence that doesn't work as expected.
