[jpbldr]

It's been a while since I've checked in here... hoping someone has an idea here. I have a Probotix machine. I've had this issue a few times before, and every time it happens, I've had trouble resolving it. The issue is that corners that should be square, end up getting a radius if they are not at the start/stop point.

All of my modeling is done in Fusion 360. The toolpath simulation in Fusion creates the correct result. However, when I run the program on my machine, the actual toolpath shortcuts around the corners creating a radius, where there should be a sharp 90* angle. The preview of the toolpath on the Probotix/LinuxCNC shows the correct path, but when I run it, the actual path has these errors at sharp corners. You can see it on the screen as it cuts, where the actual toolpath, displayed in red, does not follow the loaded toolpath, which is previewed in white.

I will get some pics uploaded to show what I'm talking about, both on the monitor of the machine, as well as on the parts I'm cutting.

Brian

 

[difalkner]

Without knowing any more than what you've told us it could be your Post Processor choice. What are you using?

 

[jpbldr]

David,

Post is the same one I have always used in Fusion, I think EMC2/LinuxCNC. When this occurred in the past, one of the things that seemed to trigger it was increasing the feed speed. But in every case, the preview shown on the machine shows the correct path, while the actual path when running deviates from that. It shows up on the screen while running that the actual path is deviating from the preview. So, for example, during a trace operation of a rectangle sketch, where it should be four straight lines with sharp corners... the result is one sharp, square corner at the start/end point, but the other 3 corners have a radius.

SO!! frustrating, because I don't know if its something in Fusion, or something in the machine software. In this case, I had done a few examples of a part(drink coaster/ornament for an annual party) with small changes until I was happy with it.. Then I started tweaking the feeds to get a faster cycle time, and made a few minor changes to the depth of various trace operations. I had cut one or 2 that were good, and then after minor changes to feed, and depth settings, this issue came up. I've tried reverting to the previous settings, to no avail.... aaggghhh In this case, the feed/speed are all the same for an engrave operation, and 2 trace operations, all with the same tool (45* engrave) These 3 operations are all contained in one post. The engrave of lettering is fine, the trace of the perimeter of part to create a chamfered edge is fine, but the trace of a simple line sketch of a flag perimeter and stripes results in one square corner, and 3 with a radius.

Brian

 

[difalkner]

Is there a point in slowing the feed rate that this doesn't happen? Do you have Feed Optimization turned on in the Passes tab (box checked)?

 

[jpbldr]

It started initially when I increased the speed (to 60ipm), but I have reduced the speed back to what it was before the problem occurred (40ipm)

I didn't intentionally change the feed optimization, but it's possible I had an errant click that I didn't catch. I will check that.

Brian

 

[jpbldr]

David,

Thanks for your reply. You were right on with the feed optimization setting being something to look at. It was not "checked" in the passes tab.

I had created a personal tool library in Fusion some time ago, but had not done any engraving since... And now that I think about it, I don't think that is even a parameter for tool info. It has to be done for each operation. In any case, I have the program working good now, using feed optimization settings. Running nicely now at the 100 ipm feed I was going for.

Thanks,

Brian

 

[4DThinker]

It's is caused by a G64 g-code or the lack of one. When used with a large precision value it increases cut speed by rounding off corners rather than slowing down to a stop then accelerating again. The faster your feed speed the rounder the corner. G64 P0.001 is in my post processor setup code block, and causes the bit to stay within .001" of the vectors/nodes. Change the P value to a larger number and you'll start to see rounded corners but faster cut times. When I have arcs in my vector file I check to make sure they aren't made of a series of very short vectors. If they are the cut will slow down to make sure it hits every node. If I used G64 P0.01 then LinuzCNC would only worry about being within 1/100" from each and cruise quicker around curves. I might end up seeing a little rounding of sharp corners though. You might look into other g-codes like G60 and G61.