missing Gcode

[swarfer]

Hi again
I loaded the 'Hello World' example and created Gcode but the Gcode is missing some edges, particularly across the top of the "HELLO" word.
I then regenerated the code with different bits sizes, and also scaled the entire thing to 75mm wide (to fit my bit of foam for an actual test cut) and redid all the cut paths and still got the same missing edges.

Right now I have just opened the cam site (Firefox) and loaded the default Gcode in CAMotics and it shows the missing edges....

the outside cut on WORLD fairs better but is missing the vertical part of the internal cut on the R

[swarfer]

an extra image to show that the cam system also thinks the Gcode ism issing an edge even though the cut line (wide red line) shows that edge, there is no thin red line for the Gcode movement.

[petervanderwalt]

Checking!

[petervanderwalt]

Okay, commented out a thing I added recently: 870cd96

Each entity is a list of vertices in an array. I want to add Ramp plunges (urgently need that man (: ) so the logic here was to find the longest segment in the array, and circularly rotate the array, so we start at the longest segment (enough space to do a ramp) - but it seems to break and drop a segment - will fix it later, but for now, removed that (:

[swarfer]

in SketchUcam the ramp code does this:
1 - the optimizer find the closest segment to the last cut end, this is to minimize non-cut travel distance.
2 - if ramping is on then check the length of the first cut segment found above, if shorter than bit_diam/2 then try next segment. if a 'long enough' segment is never found the convert to a plunge move AND issue a warning comment in the Gcode. User has to decide if plunging is ok or if some fiddling needs to be done to prevent plunging. (like adding a pre-drilled hole to plunge into)

the bit-diam/2 is a 'this generally works' but it does depend on specific bit geometry. it is based on the geometry of my collection of 2 flute carbide router bits (-: it will not work on a large diameter shell mill where your ramp length will need to be > bit_diam. I did not make this 'yet another option' because there are already too many options for most people to absorb.

[petervanderwalt]

1 - optimiser: we don't have one (yet) - but on the todo
2 - agreed we 'll force a good enough ramp angle too - this here CAM is basic! The idea is more as a get started tool, then you move onto decent advanced CAM software when your needs or skills require it. That does help a lot to make things easier for both us and the user.

Doing a slightly different style of ramp (I guess born from personal preference) - we (although its temporarily disabled now) resort the vectices to place the longest vertex first (helps with the automated Tabs and with plunges) - then inside the first segment, i do a back and forth plunge like this - (to half the depth, and then back down to full depth) - this was born from trial and error - works really well with plain old wood cutting router bits (builders warehouse style for R60ish)

I have two things to do here:

1. Fix the circular rotate function - it seems to loose a segment (start or end) on some jobs.
2. Move the Plungle operation to the Toolpath generator (right now its in the gcode gen, but I want this in the Toolpath generator instead, so the gcode generator doesnt have to think about it - its just another move along the toolpath

[swarfer]

that looks good. I need to work on the ramp length in SketchUcam, at the moment it uses the whole segment but it should be limited to a multiple of the tool diameter AND the given angle limit and then cut the rest of the segment at the set depth.
be aware that router bits have an advantage in wood, the wood cracks out in the non cutting area at the end of the bit, but in plastics/metals you end up with a nub there that is not cut. That is why I limit to bitdiam/2, you have to ramp at least that far to get some cutting, AND you have to limit the angle. my measuring of a 6mm bit showed that anything over 15 degrees will hit the non cutting body of the bit.

[petervanderwalt]

Fixed the bug with the rotation. Was pretty simple once i looked at it.

Say we have this geometry to draw a box:

0,0
0,10
10,0
10,0
0,0 // Go back to start 

After a circular rotation it became, for example

10,0
0,0 // Go back to start 
0,0
0,10
10,0

The 0,0 is the problem now, as we can't go back to where the vertice started, and instead have two points with same geometry in the middle. Lol.

So fix was easy, splice off the last coordinate (as i know our cam ALWAYS has last=first)
Then rotate circularly
Then tack the first point back onto the end of the array so the loop is closed.

Now yea yea I know, someday i'll need to support open vectors too. but for now (: I dont have to.