Posts made by Tinman

@AndyE3D OK, I think I found out the cause of the problem- at least I have a theory... In my macro I had the z probe macro and xy probe macro making three samples and then averaging them to come up with the final WCS figures. The averaged figures have more decimal places and this seems to mess with the ability of the board to process a longer multi-machining-process file. When I remove the averaging procedures from the probing macros everything seems to run fine.

@AndyE3D Thanks for looking at everything. I did try with M0 removed and had the same trouble. I haven't used any triggers or daemon.g or anything fancy. I will try inserting an M400 in the macros.

In my most recent attempt at a multi toolchange file I removed the M0. Early in the job the z axis decided it wanted to dive at top speed into the workpiece. It was alarming.

As before when I take exactly the same job and break it up into individual jobs everything runs fine.

@AndyE3D So the order of macros is:

1. Centre Workpiece.g is run so that the WCS knows where the top centre of the workpiece is.
2. The Tall Axle Insert Whole Job.gc file is run and before milling starts and with each tool change it calls:
   a)ManualToolChange.g which then calls
   i)ToolZProbe.g

There are two sensors used.
1. a sexbolt sensor which is used to determine xyz probe length as well as tool length
2. an xyz probe mounted in the spindle for the duration of the Centre Workpiece.g process

There is also a global variable defined in config.g which is used to exchange z offset information between the Centre Workpiece.g macro and the ToolZProbe.g macro. You can see it in this file

config.g

@AndyE3D And before the job is run a macro is run to set the WCS to the centre top of the workpiece:

Centre Workpiece.g

@AndyE3D That macro also calls a macro that determines the tool length:

ToolZProbe.g

@AndyE3D Really appreciate your time on this. I have attached the manual toolchange file. My macros are admittedly not the prettiest code since they are a work in progress. We will develop final macros when the concepts are proven.

ManualToolChange.g

@dc42 I've been wanting to do a video for the group to show "how to" do a job with tool changes but I keep delaying because nobody wants to watch me freeze up my mill. It used to work fine. I have a nagging feeling that it has to do with the extra precision now that I do multi-sampled averaged probing to set the WCS. Perhaps the extra decimal places are confusing the machine.

@dc42 Indeed, it started as me trying to troubleshoot the problem myself and I wasn't able to rename it when I couldn't solve it. Please rename the thread if that's possible.

@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.

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

@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.

@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 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 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.

@Sindarius That's excellent! Thanks!

@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

@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 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?

@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.

The WCS dropdown menu in DWC acts a little funny. After a system start it doesn't show what WCS it currently uses (if it's not using a WCS it should probably say NA or something). When trying to select a WCS it seems to be offset by one value from the one that was selected. It doesn't stop me from running the machine however someone should probably look at it.