Carbide Motion 2 Beta

Announcements
122

@3dsteve @Randy I think the double tool measurement comes from a “mismatch” between CM and MC.

MC sends a tool change order in the first steps of the job.

It is generally safe to assume that the nomad has been zeroed with the initial tool so it seems pointless to measure tool length right at the beginning of the job.

I can’t try now but you could edit out the tool change command (M6) from the .nc file. Removing the line should prevent CM from measuring the tool again. If there is an G38 command, I suspect it has to be removed too. From memory, there was no g38 in the .nc file and i believe CM “translates” M6 into a m5+Prompt to change+Home to probe+g38.2 or something to that effect.

Back to one of my previous post in another thread, it’d be really great if MC offered the option of not inserting M6 (or if it supported post processors with the nomad license). Sorry to be a badger but it seems the same issue is hitting in multiple ways…s

123

@TotallyFred, I’ll respectfully disagree with your reasoning. The safe thing for CM to do is to not assume the same tool has been used for zeroing as for initial machining. On my Tormach I regularly zero the machine to the stock using a 1/8" dowel pin. There are good reasons to do so on the Nomad also.

If it weren’t for the MC Carbide3d license “postprocessor lock”, it would be trivial to edit the Carbide-mm or Carbide-inch postprocessor to remove the M6 line, and call it “Carbide-single-tool-mm” or such. But you would need to be very very careful to actually only use one tool. The only time you are likely to do that is in 2.5D machining–in my years of using MeshCAM there are only a few instances where I have not used a larger roughing than finishing tool, but my MC use is almost exclusively 3D contouring (the first job I ran through the Nomad was the Millennium Falcon Hello Galaxy, or, the Force is strong with this machine ).

And as you say, it is trivial to use a text editor to remove (or comment out) the M6 line.

But, rather than all that rigamarole, I’d still opt for a simple “Don’t (re)measure tool” button on the CM screen alongside the “Don’t (re)home” button.

So far in my Nomad use, probably 10% of the gcode I’ve run through it has been MeshCAM-generated. So in my case a MeshCAM-specific “fix” would be a very incomplete fix. But I don’t much mind the few extra seconds of re-measuring the tool when the machine will be running 10 or 60 minutes or (in the Falcon case) 3+ hours per side

I’ll always vote for the fail-safe option. When I asked Rob about the “spurious” homing before each tool measurement, he said that is also a failsafe. If a user overrides the holding torque of any of the axes’ stepper motors during a tool loading (wrench or hand slips, etc. and bumps the carriage or table) the machine would be out of position without knowing it, since it operates open-loop. I’ve overcome the steppers, but that was intentional to see how much safety margin there was before I was confident in clicking “don’t re-home”.

Rob has always been really good at listenting to input and generally comes up with a solution that pleases. So definitely send in your preferences in the software.

1 Like
124

Here, here @Randy!

Too many CNC accidents occur because safety features are defeated or “I know better” attitudes lead to “edits” than I care to remember. I’ve seen too many pieces ruined, spindles crashed and tool damaged broken to even be tempted to optimize like this.

Think about it folks. How much time is one really saving? Just how many tool changes do you do?

Like it or not, we get complacent, or tired, or forget something and this leads to a mistake… and the mistake leads to disaster.

mark

P.S.

The Vectric packages post processor language supports spindle speed changes without requiring a tool change sequence - same tool is KNOWN to be loaded, the feeds and speeds needs to be changed.

This type of optimization is very safe and very useful. For instance, one hogs (super fast roughing) and roughs with the same end mill. Perhaps, MeshCAM could consider something similar?

125

@mbellon, MeshCAM does keep track of the tool called for, and if the same tool is used for roughing and finishing, will not issue an M6 command at the transition between roughing and finishin, just an Snnnnn if required for a spindle RPM change.

But I don’t know of a CAM program that does not issue an M6 on first calling for a new tool. That is pretty fundamental code.

On my Tormach, I will supress the first “move to toolchange position” command (a specific Tormach macro) when I have touched off with the first tool, but never supress the M6 line itself.

Randy

126

@Randy, that’s nice to know that MeshCAM already has the same tool, different feed/speed optimization. Many post processor languages make tool and feed/speed changes explicit (i.e. Vectric). I didn’t see that in the MeshCAM post processor language so I didn’t know that it was “built in”.

It makes perfect sense that this is “built in” because that is very much in line with how Robert implements MeshCAM.

Agree - as I said - the tool change always has to be there, if for nothing else, the machine can track what tool is loaded.

mark

127

@Randy
Please realize that I immensely respect you and appreciate your insights. I think I read all your posts on this forum. Likewise, I find MC very useful and I would not have learned anything about CNC where it not for you and Rob.

Now all respectfully, as an “educated learner”, I will clarify and argument some points and subsequently skip the above disclaimer if you do not mind :wink:

1- I am not claiming that editing-out the M6 lines is a good practice. I personally do not find the homing/measuring such a hassle that it justifies pre-processing the file manually. I can understand it annoys others and I was quite happy to have figured where the CM behavior stemmed from. I do experiment, learn and share my understanding. Notice however that eventually, CM does strip the M6 since the nomad does not understand it.

2- Neither am I saying that having a “skip option” in CM is wrong. Nor am I claiming MC is the only place it should be. My point is that MC assumes CM will fix the gcode for the Nomad while CM seems to assume that the gcode can come from anywhere. I like CM’s philosophy and would like to have the option that MC does not assume CM - this is artificially enforced by license and does pose a problem (see point 5.2)

3- Once again, I learned another good practice reading you: measuring with a different tool is good. Only this time, I do not understand why (not refusing, just not understanding) or whether a specific shape a dowel pin matters (rounded edges, wood or metal,…). This is again a very interesting sub-topic.

4- related to (3), I believe that probably very few first-time users having bought a Nomad and asking questions on this forum would use a dowel pin for the initial set up anyway. This was not part of any tutorial or recommendation I read. I understand the manual is not a CNC class but even the first tests (wrench, head,…) did not specify that step otherwise I would do it. This may explain why there have been so many questions on that topic (including mine).

5- I strongly believe pre-processing GCode is not bad (@mbellon too), probably even Good™ and good to learn anyway

5.1- due to limitations in MC (possibly bugs) and its lack of options/optimization for specific geometries (or maybe lack of documentation), running multiple distinct jobs for the same part seems almost ineluctable. Tool and machine longevity as well as operator’s availability matter so splitting, merging and baking gcode for the purpose of optimization does make a lot of sense. As much as writing gcode manually. Not a complain at all: I have not found another CAM that does as well as MC (lest not at a price I am willing to pay).

5.2- I am indeed quite upset about the OS lock-in further enforced by the post-processor lock since MC assumes CM is present which in turn assumes OSX or Windows. I do not wish to troll on the topic but investigating pre-processing for this matter just adds a more personal touch to point 5.1.

5.3- By mean of drawing parallels, CM bakes the GCode in a way that is similar to pre-processing: intercepts M6, adjusts/strips/compresses long lines, skips the G1A movements, etc. None of this is very difficult to understand and some of which could have been just as well handled with a proper default MC post-processor for the Nomad. There are many other reasons for post-processing. The only difference when I do it is the lack of Rob’s knowledge (admittedly, that’s a big difference).

5.4- Learning and trying comes with its mistakes. I can’t ask you to double check on me every time I have an idea or want to learn something. Thinking and sharing does not mean ignoring experience or “knowing best” by any mean; it means getting autonomous. Please do not assume evil intent.

5.5- And yes, I keep my hand on that big red button when I experiment. Less dangerous on Nomad than with my future, hypothetical, way more expensive and powerful Tormach.

Hope this clarifies my position. I am here to learn, share and respectfully challenge what I do not understand.

Please keep sharing! Thanks!

128

@TotallyFred, my profound apologies if I have seemed to criticize your point of view, or your opinions on how the software should work! I would rather be silent than speak thusly. I am only trying to state fact (other than where I express my own preference, which I don’t hold in higher regard than anyone else’s preference).

But I don’t understand your statement

My point is that MC assumes CM will fix the gcode for the Nomad

MC doesn’t assume anything. MeshCAM just calculates toolpaths given the workpiece geometry, the rawstock geometry and the tools defined. The Carbide team have written a Nomad-specific postprocessor for MeshCAM to format the output for CM, which adds all content outside the pure movements.

CM’s behavior is independent from MeshCAM, because CM will accept gcode from any source, ignoring gcodes that are outside its understanding. (I would love for CM to accept drilling and peck drilling cycles, coordinate system shifts, etc. but I understand the Carbide team’s desire to keep it simple).

The facts as I see them are:

  1. Carbide Motion will measure the tool every time an M6 occurs in the gcode.

  2. Every CAM program I have used generates an M6 command at each new tool call.

  3. Carbide Motion must have a tool (or equivalent “thing” loaded in the spindle) to be able to zero the machine coordinates to the workpiece.

  4. Carbide Motion’s initial homing and tool measurement are before any gcode is yet loaded, and thus before any M6 command. Thus no tool number is defined yet. Thus Carbide Motion does not associate the zeroed coordinates with any tool, just the undefined “thing” loaded in the spindle.

  5. Rob has said that Carbide Motion makes no assumptions on what is loaded in the spindle when a gcode file is started. Thus Carbide Motion measures the tool at the beginning of the gcode, without exception. This is the first tool CM knows about.

I would like to try your proposal of commenting out the M6 at the beginning of the gcode. I have my Nomad disassembled for maintenance so I can’t try it now. I have sent hand-written gcode (with no M6 command) to face the spoilboard, but that was months ago and I don’t remember CM’s behavior then. I suspect that it was as you propose, no “extra” tool measurement.

I would really like to have a “don’t re-measure tool” button on CM’s run screen. I would use it any time I touched off with the first tool I’d be using. But that would be an “informed opt-out” choice of mine, with the defualt behavior being the safe one, to re-measure the tool. This is just my opinion.

I also think, which if I understand is also your opinion, that it would be good for CM to accept any postprocessor that started with “Carbide”. That would allow informed persons as yourself to customize your own postprocessor to fine-tune the behavior, while “newbies” would be limted to the Carbide postprocessor that ships with the Nomad. I think everyone would win in that situation.

If it sounds like I’m just arguing at this point I will gladly shut up. :wink:

Randy

129

Hey @TotallyFred! I believe you’re misrepresenting what I’ve said. Editing G code is rarely necessary, a necessary evil… I’ve only every done it when the CAM software had a bug and I knew how to fix it manually. I also have the background - Physics, Computer Science, and machining experience - to do this. Power tool use. Be careful! You can lose a finger! :smile:

I think that MeshCAM is simply locked to a post processor, nothing more, when a Carbide3D license is registered. There is no preprocessing or substitution… the post processor runs. No OS or other locking. I dare say that MC knows nothing about CM. It just generates G code using the specified - and fixed - post processor. The “post” has the expectation that CM will run it - no different that any other CAM process (or CNC machine for that matter).

Any “baking in” is derived from the “post” (MeshCAM doesn’t really know that it is pointed to CM). The G code isn’t locked in, it is what the machine requires… with a bit of customization that a “post” writer can do (e.g. when the machining is done, go to a place I specify, tool changes should follow this sequence).

The post processor is available, on your computer, as a text file and it should be editable. For instance, the current Nomad post processor has the circle optimizations commented out. Remove the comments and G02/G03 will be used when it makes sense.

MeshCAM is like other CAM software, it refers to the G code as abstract operations (e.g. set up the machine prolog and epilog, I need to move rapidly to here, I need a tool change, I need to cut from here to here in 3 space, I need to cut a circle clockwise) and requests the post processor to translate the abstract operations to one or more G codes.

The post processor is not accessible before or after CAM software runs. The “post” is more of a “mapper” or “converter” that is used by the CAM software to handle machine specifics than anything else.

CM doesn’t intercept or change anything, it converts each G code, as necessary, into internal commands that are sent to the machine to run. It doesn’t fix anything. It is not preprocessing, it’s a simple translator that happens to track what the machine is being told to do. M6 happens to have a someone complex translation compared to other G codes.

MeshCAM takes a certain philosophical approach to CAM. With a few exceptions, it is always thinking in 3D. Since it is trying to “feel around” a 3D surface - the STL file - in order to figure out how to machine it, there isn’t much advisory information available to allow it to optimize - it can only optimize what it can figure out. @Randy describes it as a blind man with a cane and that is a very good description of machining the elephant.

Other CAM programs are much more intimately tied to the CAD data. When this extra information is available much more optimizations are possible. None-the-less, fancy CAM programs ask the user to describe operations on the geometry based on machining knowledge - hog here, finish like this here, group these features together handle them the same way. It is not uncommon to have 3, 4, 5 or more operations specified for each feature! When all of the advising is done, the fancy CAM software takes all of the information and optimizes it. This is why fancy CAM software is pricey. It’s not about generating correct G code; it’s about that plus removing a lot of things that a human would have to do. You tell me the specifications, let me worry about the details.

In order to present simplicity, MeshCAM limits the number of operations that one may apply. These operations are handled at the entire surface level; we don’t get to specify much about individual features.

It may take multiple applications of MeshCAM to do something truly complex. That is where fancy CAD/CAM (e.g. Fusion 360) can be more “natural”.

mark

P.S.

Yes, it would be nice to have a “power user” option that allows one to see other post processors for MC. That said, you can manage this yourself now and play.

Writing and tweaking post processors is not for the faint of heart. Make a mistake and you can crash an expensive machine causing untold damage. One should certainly be proficient with G code, including being able to write sequences from scratch - and should have a formal G Code simulator of known, trustworthy quality to inspect the G code before allowing it to touch a machine (GW-Editor is on example).

I speak from experience having written several post processors for several machines (I just posted the Vectric post processors for the Nomad). Learning often comes from our mistakes and CNC mistakes are often expensive. Please be careful if you decide to hack. YMMV.

130

@TotallyFred, you are correct in that it sometimes takes two or more passes through MeshCAM to fully machine a part. MeshCAM allows one roughing tool and one finishing tool. I have sometimes run a second MeshCAM job with a finer finishing tool and no roughing. Before Rob implemented 3D roughing, I would do a “semi-finishing” pass to leave a small, even “skin” on the part, which would minimize the tool deflection on the final finishing pass. But 3D roughing with a ball-ended mill has replaced that entirely.

Randy

131

@Randy @mbellon

thanks and don’t stop!

I just wanted to make sure you do not think I am ignoring your advices. This being clarified, and since we are between gentlemen, let’s skip all form of disclaimers and assume no offense is meant nor taken.

I have a CS and Physics, chemistry, mechanics etc background too (Civil Engineer specialized in CS) - I only started in machining with the Nomad and take any chance to meet experienced people when I can. I have understanding but little knowledge yet.

I full agree with your comments and understand the background.

@mbellon, the precise trouble is that the MC license we received with the Nomad is locked for the Nomad burnt-in post processor. As such, it behaves as implicitly implying CM. I do not think this was intentional, even less evil… it just is the way it is. What I would gladly fix with a post-processor (learned from @Randy), I simply can’t.

I make small tools and equipment for my home science lab (cogs and gears, enclosures, lens holders etc.), make stuff (maker style) like PCB’s, fix my kid’s toys or simply muse around the software architecture trying to discover what I have not read about yet. In a nutshell: I play with it.

I started learning Fusion360 and got somewhat ok at it but I am slow with it, it is a beast to handle and upgrades on its own for the better and the worst (dear cloud…). For my use case, I like OpenSCAD as it is lightweight, was a breeze to learn and is fundamentally program driven etc. I was planning to test Fusion360 python scripting when I can get a little time. We’ll see if the Fusion CAM helps but quite frankly, I like the idea behind MeshCam.

WRT the fancy geometries, I have opened a separate thread to avoid polluting this one:

thanks!

132

@TotallyFred

We often do not know the background of a poster. Even with a technical background, there may not be machining or CNC training. Much of what we write is “blind” - so standard disclaimers and stern warnings go out. Nothing ad hominem. We’re cool.

My understanding of MC is different than yours. The MC for Carbide3D is a full, standard MC distribution. All of the post processors are there; they are editable. The C3D license locks the post processor by name - it is not baked in code, it is a baked in file selection. One also gets the extra menu with tool selection and such.

There is nothing stopping one from digging into the CM distro and editing the post. Standard stern warnings apply.

CM, when it starts, may do things with the machine that we cannot see… Effectively add code the post prolog code. After that… it’s just a G code runner. No preprocessing in the CS sense of it.

The pointed to post works for the Nomad and Shapeoko. The later does not have a tool length sensor nor spindle control. I suspect that CM remains the same; the GRBL inside the machines is slightly different to deal with the differences.

C3D chose to lock as a way to prevent many of the horrible, damaging things that a “n00b” does due to post selection. They get frustrated and “try things” and disaster awaits. Sadly, I’ve seen this all too often and understand the motivation.

Mark

P.S.

Nothing stopping you from buying a non-C3D MC license and have no restrictions. A pain, yes that is.

133

@TotallyFred: on learning new machining, CAD and CAM. Yes, it is painful. The glory is when you’ve learned, look at what you can make! :smile:

When I learned machining, I was taught by Manhattan Project and former Navy machinist mates near the end of their carriers. They had come through the depression and the war and were very, very concerned about mistakes, safety, not wasting, and being efficient with your time.

They made McGyver look like a baby in diapers!

In the beginning, they would teach us how to do things and then watch us do it. Once they saw that we could do many things they would leave us to making, only rarely peaking in and making a comment. Once we we good at things, now we were dangerous. When confronted with something complex, we would often get totally frustrated because we couldn’t machine it or it would take ridiculous amounts of time and operations to accomplish the task.

Universally, they would come over and say something to the effect of “Don’t blame the tools. That is a sign of a incompetent machinist. GO AND THINK ABOUT IT MORE!” They would send us away to ponder. It was expected that you would come back with a good solution or proof that it couldn’t be done (usually followed by “now let me introduce you to this tool/machine…”).

There was almost always a way to do it and do it well/efficiently. They wanted us to learn to push our tools to the edge. Use what you have, get creative and so forth. Get the job done! Figure out how to make the process more efficient later.

Coming from machining as a manual process I think it is a bit easier to see how to do complex CNC jobs… but really, it’s the same process. Use what you have, deal with part of the problem. Do it again, and again, until you’re done.

Learning to think like they did - many layers, iterations and creative use of what was on hand, internalize the underlying processes and principals; being able to do it “better” is a luxury - is valuable, albeit painful.

MeshCAM is does some fancy stuff (optimizations like what fancy, expensive CAM does) but, by design, it limits the number of operations per pass/invocation. This makes it much less confusing for new CNCers, more than capable of handling a great deal of the jobs out there, and not an expensive, complex piece of software.

MeshCAM is pretty awesome for what it does - and this is from someone who regularly uses high end CAM programs. If one sticks with it, like the people I learned from, you can learn to think about how to use it, repeatedly, to get a job done and done “reasonably” well/efficiently.

Fusion 360 is all about fusing CAD and CAM - to make things smoother - and to use more complex CAM tools. Now you’re working on individual features, not the surface (as MeshCAM does), but one now has increased complexity to learn… and lots of it. You’re into “hard core” machining expectations.

Speaking from experience, one spends a GREAT DEAL of time in their CAD program. We acquire “CAD think”. Switching to another CAD program is often very painful and time consuming, at least to be as or more efficient than we were with the old package. Jumping to new CAD has to make sense.

Likewise, CAM leads to “CAM think”. We can make it work with what we have… but it may not be as nice as elsewhere. If it is worth it, we jump to another CAM package… and suffer as we learn.

Fusion 360 looks really, really good. I still use my tools because it doesn’t offer what I want yet (4 and 5 axis continuous machining), I’m familiar with them and have quite a bit of $$$ invested in them.

If you’re ready to choose a CAD package, Fusion 360 is a very good choice. That it has CAM as well is very, very nice.

Choose what tools make sense to you. If you find CAD that is right for you. Use it! Spit out the CAD data in the richest format possible and use CAM that works for you.

mark

134

I’m interested in this technique. Can you please tell me, where do you get the pin? Is it just a regular hardware store shelf pin, or something more precise from a CNC supply shop?
And how tightly does the pin have to hold the rolling paper when you sandwich it against the edge of the stock? I’ve been using rolling paper with a standard 1/8" bit, and gently tugging while moving the cutter .01mm at a time, until the paper won’t move without tearing. Before starting I try to turn the cutter so it gets as close as possible to the stock, if that makes sense. Does this seem like the correct approach?

Any corrections/suggestions are appreciated.

135

@MrHume, I also move the axis at the minimum increment until the paper is pinched. For me, a dowel pin is much easier for touching off X and Y, because it is a continuous cylinder. Touching off with a cutter, I need to be careful to rotate the cutter so the helical flute is in a position to contact the surface, especially when the stock/part surface is not very tall. Also, the broad end of the pin (one end is always ground to a nice broad dome) makes it easier for me to detect pinching of the paper and not be distracted by accidentally tearing it on a sharp flute. But that’s just my preference and YMMV. :relaxed:

Randy

136

Thanks, @Randy! Do you use a special “machinist’s pin” or something like that? Or will a garden variety hardware store pin work?

137

Oh sorry, I forgot that part. I use a good-quality dowel pin. Good quality pins have a diameter tolerance of .0003" or less. I’m not sure what you mean by “garden variety” but I don’t know if “big box” stores sell precision pins. McMaster-Carr is where I have bought good pins.

Randy

1 Like
138

anyone having the new version of CM “forget” which directory it was in last? very frustrating to nav to my cam file directory each time.
windows 10 machine.

139

I noticed that this morning. Also, on the old version, when it says “Update Available,” it links you to Carbide3D’s nonexistant “…/download” page instead of /downloadS. Emphasis on the S. Might want to make a static redirect for “Downloads” until further notice.

140

where would I find release notes on each version of carbide motion?

141

Hi,
I have the same problem, any solution yet?
thanks!