Subdivide Carbide Motion Job Time Remaining

[tobwhy (Toby)]

Current View:

View Upgrade I Propose:

[RichM (Rich Morris)]

I’m a +1 on this one, but doesn’t even need to be that fancy for me. I’d be happy with the time remaining for the current tool along with the time for the whole job.

I usually have CC open while cutting and refer to the enabled toolpaths for a rough idea of the time needed per tool. The CC and CM times are calculated differently, so it helps only so much.

[tobwhy (Toby)]

Yeah, can be as simple as that and I’d be happy.

The thing about times being different between CM and CC is very true. Never have accurate times for advanced v-carve

[OShag (Dave)]

GREAT idea. Seems like it should be fairly easy to implement - although I admit I am nowhere near a programmer in abilities.

[bpedit (Byrne Pedit)]

I agree with Rich, simpler might be better. The timeline might be trickier to execute, I notice CM often changes time estimates and it might not be feasible to commit them to a timeline.

But I like the idea of having them on display. I currently have to write them down for each multi step project I run (all of them!).

[mhotchin (Michael Hotchin)]

Just as a note - Carbide Motion has a Progress Bar, but it is not a timeline. Rather, it is either based on the number of lines of GCode, or the number of characters.

So, locating markers for the tool changes wouldn’t be that hard, CM can easily figure out how far in the file they are (rather than how far in time they are).

[bpedit (Byrne Pedit)]

But this would make it even less usable since most of us are interested in the time between bit changes. When you’re using bits with markedly different feeds and plunges, very common for me, the same number of lines of code will take sizably different times. So the markers on the timeline, if based on lines of code, would be misleading.