[CRITTERBOARDS]

My software is not getting the job done, or I’m not going about it the right way.
I’m new to the world of CNC I recently purchased a small CNC router that runs a trim router as a spindle. My purpose is very single minded the only thing I wish to accomplish is making inlays in wood, these inlays for example are walnut inlayed in maple and they are at lest 1” thick. The problem I’m encountering is I can’t seem to get a good fit the software I’m using to create the vector / plotter file is Corel 12. The G code seems to jerk or leave flat spots. The way I try to make the file is create a ¼ wide line Trace it on outline thus creating two parallel lines which I separate to create two files. Seems like is should work, but its just not coming out clean. I can’t determine if its my plotter file or the G code that’s causing the problem. Now is this a good way of pursuing this problem or dose somebody know of a better way of creating inlay patterns.

[HuFlungDung]

Can you post a sample file? Some of us can maybe backplot it and see how it looks in a real cadcam program.

Are you getting gouges? Does the tool lift when it needs to? Are all the movements lines, no arcs?

[CRITTERBOARDS]

Can you post a sample file? Some of us can maybe backplot it and see how it looks in a real cadcam program.

Are you getting gouges? Does the tool lift when it needs to? Are all the movements lines, no arcs?

What format would you like, Plotter or the G code?

It goes from one point to the next in a strait line and in a curve I end up with a small flat maybe .005”. The other pattern will have the save flats thus not lining up, and I do have it set at 0. I’m thinking if there is software that will generate the code to the right of left of the line not the center it would probably solve my dilemma.

[HuFlungDung]

Gcode please

[CRITTERBOARDS]

I couldn’t seem to attach the g code file. So i rename the extension to TXT, hope it works

[CRITTERBOARDS]

Hears a sample of what I’m trying to do this one is the first test so it not the best but gives you an exaggerated example of the problem

[HuFlungDung]

Well, I backplotted the gcode (using OneCNC), and I would say it looks okay. I'd cut it

If you are having machine jerk problems, it may be due to lack of processing power in your cnc, attempting to run very short segment code at high speed.

Turn down the decimal place accuracy on your posting program, you don't need 6 significant digits This alone may improve processing speed on your cnc.

Then, after reposting at 3 or 4 digit accuracy, then if you still see the machine jerking, then reduce the feedrate (maybe in half) and see if the machine can process it fast enough to keep the drive buffer full.

[HuFlungDung]

Btw, if you can figure out how to do G41/G42 tool radius comp on your machine, then you can perhaps make do with one centralized profile and cut on either side of it. But, there could be a problem with entry/exit to/from the profile.

I'd recommend for that type of work that you might take a demo of OneCNC Express. This will allow you to pocket the interior, as well as profile offset either side of a line, choose different tools on a mere whim, etc. It'll put the fun into your work

[CRITTERBOARDS]

Ok my manual says G41 left G42 right. If I’m reading this correct I add G41 or G42 in the code and it should give me the offsets I’m locking for?

[Dave's_Not_Here]

... what, if any difference, will the ability to "read ahead" on the toolpath have on smoothing out the transitions... coupled with possible feed rate adjustments, etc...

[HuFlungDung]

You're right, Dave. Several lines of "look ahead" are required of the controller. It needs to keep the command buffer to the motors full, so that continuous motion is possible.

G41/G42 could certainly be used on a centralized toolpath for your purpose. However, applying tool comp requires a bit of practice, to see exactly how the machine begins and ends when it starts onto the profile, and leaves it. This is because the machine begins at some start position, tool comp is called, and it then has to get into position to the right or left of the profile. The amount of the movement will be the tool's radius. This is called the "lead in" to the radius compensated path.

You'll have to insert the tool's diameter (or radius, depending on how the controller is set up) in its tool comp register. Then, you have to call for the comp to be applied, typically with a
G41 D1
for tool #1

When the path is completed, the compensation should be cancelled with a G40 in the code.

[CRITTERBOARDS]

Manual combination is going to be way more involved than I want to get into. I’m just going to pursue the software that will do it for me.

[Dave's_Not_Here]

.... so controllers that not only have "look ahead" capability but significantly sized buffers, will handle the shorter, choppier paths better since the controller would hold larger amounts of "look ahead" data than the smaller buffers that would empty and wait. It would also allow for faster feed rates because the larger buffers hold more directions and can keep up with the feed rate.... right/wrong?

I have some wide disparity between buffer sizes.... but bigger seems to me to be better.

Also, don't current controller programs allow for you to input lead in and lead out so it isn't a manual correction to the G-Code?

Still trying to get a grasp of all the inter-relationships between the Stepper specifications and capabilities and what the software will compensate for...

ie. I know that volts and Amps as well as RPM and reduction, etc... all interplay to make one stepper better suited to a task than another... that somewhere in the controller and driver settings, along with a ratio reduction using pulleys, you are able to improve the performane of the stepper over it's out-of-the-box set up if it were connected directly to the ballscrew via. a coupler.... Having seen a number of question relative to Stepper choices and modification, I need to understand this more so I can make the proper choice in motors... then layer on controller and drive settings... it gets my head spinning...

[HuFlungDung]

Dave, I think what you've said about buffer size is correct. If a program consists of XYZ moves that are .01" long, and you command the machine to move at 40 inch/min, that is 66 blocks per second of command information that have to be consistently output. That does not mean that a control with two or three lines of lookahead is not sufficient, because there is no time parameter associated with look ahead. Lookahead has more to do with adjusting feedrates on an upcoming corner, whether to apply decel to the feedrate, etc.

Raw block processing power per second is the feature needed for short segment 3d.

RE: G41/G42: a manual correction to the gcode is not required if using cam software that outputs the command in the correct places in the code. But, a machine movement is still required when turning on full cutter radius compensation. This movement to add the radius compensation amount is generated within the controller itself. However, the programmer anticipates that this motion will occur, and must prepare to leave room for the tool to move onto the right or left side of the programmed path.

This anticipation of the machine movement when comp is called, is why lead-in and lead-out "pigtails" are added to the actual profile path. These pigtails are short lines, at least equal to the cutter radius. In effect, you are giving the machine a safe starting point, that is not on your actual part profile, and telling it, "If you start from here, add the tool radius movement when G41/G42 is called, the tool is already in a safe position relative to this profile". You can then feed the tool down and begin the cut.

[Dave's_Not_Here]

That does not mean that a control with two or three lines of lookahead is not sufficient, because there is no time parameter associated with look ahead. Lookahead has more to do with adjusting feedrates on an upcoming corner, whether to apply decel to the feedrate, etc.

So the controller looks ahead in the g-code and recognizes the change in direction and "inserts" feed rate compensations based on settings in the controller interface made prior to initiating the program? (assumming you let Mach 2 generate the code and you didn't import from another source?)

Raw block processing power per second is the feature needed for short segment 3d.

This is measured how? at the CPU level?

However, the programmer anticipates that this motion will occur, and must prepare to leave room for the tool to move onto the right or left side of the programmed path. This anticipation of the machine movement when comp is called, is why lead-in and lead-out "pigtails" are added to the actual profile path. These pigtails are short lines, at least equal to the cutter radius. In effect, you are giving the machine a safe starting point, that is not on your actual part profile, and telling it, "If you start from here, add the tool radius movement when G41/G42 is called, the tool is already in a safe position relative to this profile". You can then feed the tool down and begin the cut.

When you say that the programmer anticipates... and must prepare to leave room... to the right/left (inside or outside of actual path) .. and

in effect you are giving the machine a safe starting point, that is not on your actual part profile

what is the difference between "programmed path" and "actual part profile?" I assummed that you either initiated a plunge cut inside the toolpath for pocket milling or a plunge cut outside the toolpath for profile milling... while compensating for the tool radius.

[HuFlungDung]

Dave, I don't know the intricacies of how the command buffer is regulated, or watches for direction changes and all that. Other guys who are writing controller software, would know.

I assume that you could do a block processing speed test on your own machine, running your own programs.

First, you need to calibrate your machine, to make sure that a 10" long move at F10. executes in exactly one minute.

The developer of the cnc controller should have a good idea of what the blocks/sec number would be. You could do this with a program that is, say, 10,000 blocks long. It should not have long moves in it, the shorter they are, the more accurate is the test.

You need to know the total travel distance that the program calls for. You can then try executing the program at various feedrates. Simply calculate how long the program should take to run at the machine. At a high enough feedrate, the controller will begin to fail to supply the movement commands fast enough to keep the machine at the commanded feedrate. From this, you can derive an estimate of how many blocks of instructions (single lines of gcode) are being processed per second.

RE: programmed path: this is the path that contains all the movements that need to be programmed to complete the part. The profile path is a subset, because it only contains arc and line data that define the shape of the part. The plunge movements, the G41/G42 comp movements, the lead in and the lead out movements, these can all be seen in the gcode program, but do not define the shape of the part.

[Dave's_Not_Here]

Good info!

Thanks!

[CRITTERBOARDS]

Well I solved my software issue, I downloaded a demo of Rams Mill and was able to get the offset I needed right away. The bigger problem is my machine, the gantry seems to have way more play than it should but if I try to tighten it every thing jams up the unit was not designed for deep cuts, but taking cuts of less than 1/8 per pass at maybe 20”m I still have wobble and flare out too the tune of about .020 at my entry point. So I’m in the market for a new router.