I tried the restart on a long carve, (that turned out to be extremely long due to my stupidity) paused the program at a bit change, powered down the machine, left computer powered up. Came back next morning and had to reload the program, ok did that. Initialized machine, entered line number of the tool change, pushed start. The router started cutting at xyz zero. Knowing I had no cuts at that location, I stopped and redid everything, with of course the same result. I had to enter the file and disable the roughing pass, then I restarted as a new project file. Not sure what I did wrong, but maybe another step by step review for pausing a cut in the middle and coming back the next day to restart again could help me on the long cuts.
I think Michael’s comment was on the workflow, no so much the functionality of the reset (which seems to work as expected 
)
I don’t know how deterministic gcode generation is across the board but I imagine something like generating a new adaptive toolpath could cause pathing variation resulting material in unexpected locations 
EG: He didn’t simply “restart” the same gcode from a specific line. Rather, he stopped the operation and modified the toolpath (effectively re-writing the gcode) before starting that new file at the same line the old file left off.
Maybe an unintentional use of the feature but if it works, it works. I’d probably just do a quick diff of the gcode first to spot check if when I end up doing the same thing. I suppose if I see a bunch of interlaced red and green, I’ll know it wasn’t deterministic 
You’re right- I misread the comment. This is not a generic use case we’d recommend unless you REALLY know what you’re doing.
1 Like
A post was split to a new topic: Editing and previewing G-code
Am I misunderstanding the pause feature? I thought it could be used to restart the long cut after a brief stop. I did try to restart at the same line number, but it cut in the wrong place. That is why I redid it as a new file, so I could continue the cut.
I think there are a couple of things:
- There could be a bug in CM. To determine that, we need the G-code being run and the line number on which a restart was attempted.
- This is a new feature, so we don’t know how people will misunderstand the intent, or do things that we didn’t anticipate.
- This feature can be abused by those who know what they’re doing, and it will work fine. If “normal” folks try to do that, they might get a crash (See @mhotchin above)
Bottom line, if you get unexpected behavior, send us the file and the line number.
2 Likes
This would just allow me to look at the output view that is not in the source program. I this case I got a Vectric file for a project and used it with CM without issue. I changed the size of the project and everything looks good in Vectric. I go to cut the new piece and the orientation of the object is now top-center instead of center of the workpiece. This is only visible in CM not Vectric preview. This is why I needed the offline mode. With the NC Viewer and NotePad++ that William listed above I can do this so I have a work around. Thanks for the efforts.
problem is…if the program crashes or computer reboots, the streaming data is gone. thats why hoping they can stream to a disk file. I guess i can also add software to screen capture every few seconds.
1 Like
I have been running CM644 this week and have an observation. If I shut the machine off and come back the next day, the Z zero is not persistent. The X and Y are, but the Z is not.
1 Like
This has been true all along, I posted about it a few weeks ago. CM compensates for varying stickout, with the help of the bitsetter, when running a program with bit changes but it won’t remember after the machine has been shut down.
1 Like
Maybe with the latest 6xx versions, but I had the stable 6xx version before this one and Z was persistent. So this is within the last few beta versions.
Sorry, I may have mis-spoke on that since I only began monitoring this a few weeks ago. I assume you’re saying that, until some point, CM used to remember the Z assuming you hadn’t removed the previous bit.
1 Like
It should still do that — but one has to remeasure the tool when for instance, one uses Rapid Position Z+6mm.
I do measure the tool before I even load the job.
1 Like
I did not know that. I won’t ever use Rapid Posistion z+6mm again. I wonder why…it isn’t resetting the Z…or is it?
1 Like
No, Rapid Position + 6mm simply moves to that position — if the tool hasn’t been measured yet, it will be measured.
2 Likes
That doesn’t make any sense because we’ve learned before that many (most) folks do not reset the machine zero regularly, if ever. That leads to a massive number of support tickets when anything changes, and we haven’t seen anything.
So, I wonder if we’re talking about different things here. The absolute Z offset is retained, but after a reboot, it’s not updated to deal with the tool length until a BitSetter cycle is run. If you jog before a BitSetter cycle, then the Z coordinate will not be correct. The same would be true with the MDI. Does this sound like what you’re talking about?
3 Likes
Aahah. So, when shutting the machine down, leave the bit in and measure tool length first thing (after initialization) on restarting to preserve Z?
I think the question is really, “When does the Z value reflect the tip of the cutter after a restart?”
Only after a BitSetter cycle runs.
But, even if you assume you’re ok (or don’t know that fact), running a program will trigger a BitSetter cycle, so it’ll be good to go.
1 Like
I’ll check again Monday, but the relative is reset, even after a “Load New Tool” cycle. I generally run the spindle warm-up first and I usually send it to the middle quick position for that. Maybe that has the effect of a jog or MDI, thus erasing the relative position?