Less clicks to start job using Carbide Motion?

I have been using Carbide Motion for a few years and now that I am using it for production work I am seeing how there are a few steps at the start of every job that take up quite a bit of time. Time that could be saved. Perhaps there is a way to fix this?

Specifically it looks like the UI prompts to do a tool change and also set the RPM are irrelevant as the tool is already in and the RPM is already set - using a Makita mind you.

From my experience this eats about 4-5 clicks and 20 seconds of time as you can’t rush the buttons (problem noted in this post too). When doing many jobs in a day, or jobs that are quick, this really starts to add up.

So my question is how do I disable these prompts? It would be great to just click “Start” once after the file is loaded.

I looked in settings but did not see anything obvious, though of course I could be missing it.

Note I am using Carbide Motion 575 but have had this problem since the 400’s

See screenshots:




1 Like

Getting and enabling a BitRunner will eliminate the prompts for spindle on/off and setting the speed.

1 Like

Personally I now get the two starts, The first one takes you to the [Run Job] menu. Maybe it would make more sense if the first screen said [Load New File] and [“Run Job”]. I do believe it is just a bit confusing to say “start” twice, but once you understand it takes you to the [Run Job] menu it might make sense.

While I am at it :slight_smile: , some things in this area that could have made a bit more sense to me starting out :slight_smile: The first screen [job Info] is more like the “Job Setup” menu. I personally believe the Initialize button should remain here and just change to Re-initialize. I know it kind of moves to the Quick Actions (Other Actions), but in my small world things should be clear and not move around :slight_smile:

Quick Actions, or better yet “Other Actions”, to me are more MDI commands or custom Jogs. I find I waste time going out of jog and over to run then into Quick Actions and then back to Jog. I do this as the fast jog is so slow at 1500 while Init. and rapid position are 5000 and 6000 :frowning: I set up Quick Action jogs to my normal workplace zero. Maybe just the Z should be capped at 1500 and X,Y could go to 5000. That would make it a whole lot easier for me :slight_smile:
I am sure there is a good reason Quick Action is where it is though.

One of my suggestions for sometime in the future :slight_smile: is to make it a bit more clear is that there should be a [Job Setup] menu and a [Job Run] menu and the [Job Setup] should contain the things to setup a job prior to running it IE [Load New File] [Read Notes] [Load New Tool] maybe [Load Material] [ Run Job] [Re-initialize] [Other Actions] . IDK That kind of looks like the basic flow to me.

I know C3D promotes CM as easy to use and beginner friendly, Yes for me starting out it was a bit confusing on the wording. and some of the flow. but it is hard to get in trouble :slight_smile:

We will get there :slight_smile: Perfect takes time :slight_smile: In the mean time I will gladly except very good :slight_smile:
Thanks C3D Great work

2 Likes

As a new user I like the current layout. I’ve run several projects and and I’ve always had the correct cutter set at the correct speeds. I’ve also not cut my table in half or forgot to shut off the router when I should’ve. I feel like C3D has made operating their machine very easy for a beginner. Maybe they can add an I’m a pro button that pops up a disclaimer that one can accept, that’s yes I agree that if I screw up, it was on me.

5 Likes

While there is nothing wrong with using CM this is the only reason I moved.

Give Gsender a try, just know that when you say start it starts.

4 Likes

When I do production runs I edit the g-code. Cut’s it down to about 2 clicks.
Remove the tool and rpm call out and it will skip it.
Of course run it a few times without the edit to make sure there aren’t any crashes.
NC FILE EXAMPLE
NC FILE EXAMPLE-MODIFIED

3 Likes

Less clicks would be nice, also less movement would be nice.

Since the user can set their own X&Y coordinate of the bitsetter location, can there also be a place for the user to set their own preferred X&Y coordinate for the tool change location?

Seems odd that it moves all the way over to the center to do a tool change then moves to the far right to do a tool length offset, when you could have replaced the tool right beside the bitsetter.

Thanks.

5 Likes

That’s a good point — we’ll put custom tool change locations in as a feature request now.

3 Likes

Plus in another post I wrote. The Bit exchange location is right on the edge of the centre Tee Track so if you drop a bit :frowning: and then after clipping the edge, it can take a bad bounce on to the floor :frowning: :frowning: I would like to see a Custom location too. For me, 1: As far forward as the BitSetter. So over my soft work pad not the work surface. and yes closer to the BitSetter.

And Custom Rapid jog locations or a turbo speed for the XY would help speed up my process. My XY zero is normally always in the same ish spot. it is painfully slow to slowly jog to it to set the Z Zero

Just possible suggestions for the future as I am a happy camper :slight_smile:

You can use Quick Actions to create custom Jog locations. When you are at the location you want, switch to Machine Co-ordinates and note the location. Then edit one of the example Quick Actions to suit.

2 Likes

Thanks yes that is true but I believe the sprit of the discussion here was to reduce Clicks and therefore Time . I do use the Quick Actions but you have to exit jog => confirm => go to quick actions on the setup info page => go to custom quick actions => then confirm => then go back into jog => then confirm => then … That is a lot of clicks. so Custom Actions or Custom Rapid Jog would save a lot of time.

Lots of people have voice about the amount of clicks which relates to time. Most of these clicks are required to keep to the sprit of their workflow for all levels of users. I mentioned some maybe alternative ways to reduce time by reducing travel time which might not disrupt the workflow. - Reduce the travel to the Bitsetter. - Reduce the travel time to get to your work / setup positions
:slight_smile:

Excellent Will, user defined tool change location will mean fewer bits hitting the concrete if dropped.

1 Like

There is a similar annoyance on startup, at least on my HDM. It seems like Carbide3d really is proud of its tool setting routine, as it asks constantly for you to do so. In many cases this is a good idea since failure to set the tool is a common oops resulting in a crash. But it absolutely should not be a requirement for initializing the machine. There are many cases where one does not have a tool in place and simply wants to home the machine and then get some work done (like tramming the machine or a workpiece) without a tool. GRBL understands this, as a $h will simply set the home. But it is not possible to start up CM without doing tool setting in the current software.

That’s why many of us, after gaining experience with CM, have switch to one of the many other gcode senders.

1 Like

I’ve stuck with CC/CM combo because of the simplicity of tool changes with the BitSetter. Before I got the BitSetter I used bCNC (which I loved). I’ve gotten a bit tired with the newbie-ness level of CM though - bCNC had TONS of features that I used. Especially the camera functions, the in process gcode sim that showed you where you were in a job, and the ability to run it on Linux.

Will any of the newer gcode senders recognize and use the BitSetter for tool changes? I’ve never really experimented here and you alls responses have gotten me thinking . . .

Wow great replies everyone thanks for the tips and chiming in!

Overall I am not using the BitSetter and don’t think that should be a requisite for reducing the amount of time and button clicks needed in a production environment.

A lot of time I am using only one bit and it’s already zeroed in. My ops are only a few minutes long and the clicking and whatnot can literally add up to a few percentage points of the overall time. I shouldn’t need to buy another product that isn’t necessary to fix this issue.

Although I do understand that Carbide might enforce these actions as a safety move, or at least a gentle sales funnel into the various add-ons, but as someone who uses this tool in work - time is money.

I do appreciate knowing that it is possible to edit the G-Code. Though this could introduce errors. And, as a programmer, I know that this could easily be solved by exposing the option to enable these prompts as a button in the Motion settings. Done.

Alas, if this feature does not manifest, I’ll probably check out other senders. That’s a whole new world but maybe there are other features, in addition to the reduction of clicking, that these senders afford?

Either way this tool has come a long way since the S03 and it’s worth noting that there has been great improvement. Just a few details and UI/UX improvements could go a long way to solidifying the tool’s ability to be used in a production environment.