Unsolved How to get DWC to Display what line of Gcode it is on?

[Tinman]

@gloomyandy The problem goes away if I separate the toolpath steps. I've been working hard to enable toolchanges etc so that I can put in a workpiece, run the file and get a finished part. Having to run 8 separate files to mill a part is not ideal.

[Tinman]

@gloomyandy You may find it interesting that I can take a file that consistently fails at around 2% of completion, delete the last 90% of the file so that the part where it fails is still intact, re-run the file and it sails right past the place it failed before.

Are there issues related to file size when doing CNC files?

[dc42]

@Tinman I see you are running firmware 3.5beta2. Please upgrade to 3.5beta3 and see whether the issue still occurs.

[Tinman]

@dc42 Thanks for looking into this. I have just upgraded to beta 3 and still having this problem. I'd be happy to send you a file to look at.

[Tinman]

@Tinman Until then I need to break CNC jobs into 4 to 8 multiple parts to get the machine to run them without needing to do a hard reset. Problem with a hard reset is that it results in the loss of WCS which is almost always probed on a surface that has now been milled away.

[dc42]

@Tinman I think the issue may be related to the multiple motion systems in RRF 3.5 and the code in your stop.g file. Does the problem go away if you remove the M0 command from the end of the job file? What commands do you have in stop.g?

[Tinman]

@dc42 I opened this topic because I wanted to be able to run a full job with multiple toolchanges from a single gcode file. Perhaps I will start a separate thread about recovering WCS from an e-stop.

For now though, would you take a look at one of my multi toolchange files that fails on beta 2 and beta 3?

[dc42]

@Tinman as I said in my previous post, I think the issue is related to the contents of your stop.g file. So I need to see the contents of that file.

I can think of a way to save and restore the WCS offsets, so please start a separate thread on that topic.

[Tinman]

@dc42 There's not a single line of active code in my stop.g just a few disabled lines:

; stop.g
; called when M0 (Stop) is run (e.g. when a print from SD card is cancelled)
;
; generated by RepRapFirmware Configuration Tool v3.3.15 on Thu Dec 01 2022 17:27:42 GMT-0500 (Eastern Standard Time)

[dc42]

@Tinman thanks. Please make the file available. I am away from the office so I won't be able to try it for a few days.

[Tinman]

@dc42 I had to change extension from .nc to .gc for site to allow upload.

Thanks again for looking at this. It gets about halfway through the initial face milling process before it freezes. Roughly (very roughly) around line 500.

Axle Insert Flat Side Complete Job.gc

[Tinman]

@dc42 The behaviour of this file is even more troubling:

Tall Axle Insert Whole Job.gc

The Z axis randomly climbed by about 70mm during the facing operation and then froze. There is nothing unusual in that section of the file. This kind of behaviour is dangerous in a cnc machine. The latest RRF updates have been great however as our mill becomes more mature and our users want to run real jobs this is going to be a serious obstacle.

[OwenD]

@Tinman
Based on @dc42's comments above about the problem possibly being related to the multiple motion systems have you tried

• Removing M0 from the file (if a second motion system is getting ahead it may be stopping the job)
• If the above is true, it may also turn off the spindle when it reaches M5, so maybe remove as well
• Liberally sprinkle M400 in the code (say every 100 lines). Do this especially before your tool change.

Can't explain the lifting by 70mm unless that was part of another file that's activated by M0, Tnnn or a trigger

What's in "ManualToolChange.g" ?

[Tinman]

@OwenD I previously mentioned that if I delete the last 90% of the file it sails through the trouble section without problem. I suspect it has to do with file length. It seems too simple but I have no other theories.

[dc42]

@Tinman the file length will affect how long to takes the second file reader to find the M0 at the end of the file, or run out of file if there isn't a M0 command.

[Tinman]

@dc42 I do have an M0 at the end of the file. Compared to my 3D printer files these cnc files are quite small. Please look at the file I uploaded.

[OwenD]

This post is deleted!

[Tinman]

@dc42 Please look at my file and tell me why it crashes the board the way it does? I need to be able to support other makers and users of our Milo cnc mill and this has really got me stuck.

[Tinman]

@dc42 I uploaded the file as you requested. Still hoping you can look at it.

[Tinman]

@Phaedrux I'm part of the Millennium Mills design team. I'd be happy to show you how our Milo CNC mill works and how this specific problem is affecting efficient toolpath generation. I think you're also in Canada so I could show you live if that works. I've been avoiding further macro generation because I don't want to recommend these methods to our users if this can't be fixed.