Would be great if there was a countdown timer to the next toolchange in the current job. I see that this has been requested a couple times in past years, but was ignored. How about it? It would help with using my Nomad3 to be able to know when to go back to it to be ready for the next change. I’m still near it, but if using another tool and have the ear protection on, I don’t always notice that it has stopped and a lot of time is wasted.
9 Likes
Good Idea, Chris! I was thinking something similar the other day.
1 Like
The toolpath has a time estimate, the total job has a progress bar and timer on it. I guess I never worried about counting down to the tool change because I can glance at the cut and roughly tell where it’s at in relation to the next toolpath change. If I can’t quickly glance at the machine, I’m not really monitoring the machine as close as I should be.
1 Like
That’s a good point for the larger form factor machines but on a Nomad 3 I can sympathize with the request.
It’s an enclosed machine and the sight can be a little limited at some angles. Couple that with some seriously long running operations when working with things like brass, I’ve definitely missed an op or two while sitting at the computer in the same room 
Dang hearing protection, ruining my cycle times 
2 Likes
Makes sense, I’m an operator so no matter what’s running I’ve been trained to keep a close eye on it.
1 Like
That’s just good advice when doing most anything 
Most of my training boils down to “if it’s hot, don’t touch it. If you don’t know if it’s hot, don’t touch it. If it falls, don’t try to catch it…it might be heavy, or hot, or both.” Which is also great advice all around
3 Likes
In the jobs I’m making in Meshcam from CAD files, I don’t have a feel for when tool changes will be generated. If I don’t make a note of the times displayed when the toolpaths are created, I have no clue during the job when they will be coming up. Doing parts in brass, it could be hours between them. Having a displayed time till the next one would be a huge help for me.
I’m only creating in CC as of now, I can see your need based on your workflow. Not being familiar with Meshcam, is there any way to export a toolpath spreadsheet or something equivalent that has this info?
Given your circumstances, my workaround would be to screen shot the times displayed when toolpaths were created or jot them down. I know it’s extra work, more than likely less time expended on making note in the beginning vs losing hours later by not recognizing the machine has been sitting idle for awhile?
Just thinking out load to maximize your workflow efficiency util there are more options in CM.
Good suggestion Tim, though it would still be easier if the application did it for us, especially in cases where an old project is run again - rather not have to keep a notebook full lof times just in case! The application could easily scan through the gcode looking for tool changes and calculate the times between them.
I agree with you for sure, just not sure what it takes and how many things are ahead this request that impact more projects/people?
One word–stack lights. Wait, that’s two words… But with now two Nomads and a soon-to-be CNC Taig lathe, I’ve been wondering in idle moments how to maybe implement stack lights (or a homebrew equivalent, maybe a few RGB LEDS driven by a Pi Pico2 or something…) on the machines.
2 Likes
Detecting pwm to the spindle shouldn’t be too difficult…maybe even doable with non-contact if the pwm generates enough noise on the wires 
not sure if there’s anything outside of requiring reasonably complex diy nonsense though. Just depends on the appetite for diving into a new rabbit hole.
I’m probably overthinking this (that has never happened before…) It would not need a whole stacklight implementation.
gcode has an M3 command that turns the spindle on and an M5 command that turns the spindle off. Tying into that somehow would allow a simple light that is lit when, and only when, the spindle was turning. Mount that light on a mast and you’d have a “stackless light” (I do plan to trademark that phrase…)
I guess it’s a question of what is really needed–just glance across the room and know if the machine is done with its current task, or “PM me when you need attention”…
Another possibility is the coolant commands.
grbl has M8 flood coolant enabled by default, and optionally M7 mist coolant can be enabled at compile time. The grbl config.h contains
// Enables a second coolant control pin via the mist coolant g-code command M7 on the Arduino Uno
// analog pin 4. Only use this option if you require a second coolant control pin.
// NOTE: The M8 flood coolant control pin on analog pin 3 will still be functional regardless.
// #define ENABLE_M7 // Disabled by default. Uncomment to enable.
I don’t know about the newer CM boards, but the original 883.1 has an actual Arduino Uno with all the DIO pins intact, and the coolant pin(s) could be repurposed to turn on and off a light–just tweak the postprocessor to turn on M7/M8 at M3 spindle on and toggle it back off at M5 spindle off.
That’s assuming that most folks would not use gcode-controlled flood or mist coolant with their Nomads and Shapeokos.
NOTE: Carbide3D’s official position is that they do not condone users messing with the grbl.
I can quite understand that. I bricked my 883.1 a few times in the process of learning how to compile a useable grbl 1.1h for it…
1 Like
Would also definitely find this a welcome feature and support it. Right now I have to flip over to CC and try to estimate it.
The more I think about this, the more I’m leaning towards a hardware hey, I’m done! approach rather than a software estimate.
On the surface, you just add up n distance at Fn speed, m distance at Fm speed, r distance at rapid speed, etc.
But depending on how each distance is performed, the estimate will tend to be optimistic. With a highly-contoured path composed of many short vectors, the machine may never achieve the commanded cutting speed, but be constantly on the acceleration/deceleration part of the speed curve. This will cause the actual time consumed to be longer than the estimate.
Related, on my hobbyist-level 3D printer, at one point in the long print it said “34 minutes remaining”. Two hours later, it said “14 minutes remaining”… This incident is what got me to thinking about what a time estimate really involved.
My GPS is similarly optimistic. Its time estimates are based on always traveling the posted speed limit. Sitting in rush-hour traffic, inching ahead through 3 cycles of the traffic lights to get through a particularly busy intersection, I can watch the time estimate increase in real-time… 
But perhaps the C3D crew can come up with a very astute algorithm to parse the gcode and account for the acceleration curve of the particular machine being used. Forget the perhaps, they are certainly talented enough to do it! 
The absolute best estimate of the cut time would be to run the gcode through CM but not actually move the motors (apply a “neural cutout” (ref. Neal Stephenson’s Jackpot novels) to all of the driver chips…) and find out how long it takes. The only downside of this method would be that generating the estimate would take exactly as long as performing the cut… 
You can do that by putting Grbl into “Check mode” by sending $C to the controller using the MDI — plot twist, it takes less time to send/process commands purely electronically than it does if one has to wait for the motors to spin up, accelerate, and compleat a given move before the machine is able to process the next command.
2 Likes
Well no, I would run the gcode through the motion planner but have the motors disabled. That’s the point of the exercise… Generate the actual steps through grbl and all, get the start and end times from the system clock and do a simple subtraction of the one from the other… 
But that’s starting (starting?) to get silly. I’m controlling a stepper at work in a little mechanism with a Raspberry Pi, and could inquire to the microsecond how long a motion sequence takes–once it has happened. Since the motor is running open loop, the Pi doesn’t know (or care!) if it is actually moving or not…
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.