We ran our first jobs in Millmage tonight, and got some testing done well. We did encounter the save and inverse toolpaths bug, but won’t raise this one as it’s noted.
One thing that happened which was rather confusing, was that after running our first program, the spindle rocketing towards the work surface without starting freaked me out, so I hit stop to inspect the gcode. It was fine, millmage simply starts the spindle 20mm from the bit instead of at Zmax. Anyway, my stop seemed to put the controller into a ‘busy’ state, so restarted Millmage, imported the project again [the controller remained on for all of this process]
- On restart, the project wouldn’t frame as it was exceeding controller limits, which seemed a little hinky.
- So I homed and set the wcs to machine zero. (DRO for both read correctly)
- I then framed again, and it ran the program in the original framing (from before the reboot - as if the wcs was still set to x-200y-200)
- But it seemed off, my DRO looked correct, so I closed millmage and checked the gcode again
- Definitely something going on, the gcode was running in the newly set wcs (same as machine zero, not where it was framing) - Loaded the program into iosender to confirm, and this confirmed the framing was just hinky.
Anyway, I loaded millmage again, and it now behaved correctly. Framed from xyz0. I set my work coordinates again, knowing it’d only start the spindle close to the piece, and everything ran perfectly.
It’s almost as if the ‘framing’ feature in millmage had got stuck using the old WCS somehow?