1000 Lines

[Bob La Londe]

however g-code output will then be limited to 1000 lines

Nice.  Seems I recall it used to be 500 lines.  While 1000 lines would force me to write hundreds of code files for most of the jobs I do today I have to say, "You can do quite a lot of work with a 1000 lines of code."  

I was looking to see if there were bug fix notes when I saw that.  Has the issue with sometimes not getting an actual start point near your set point been fixed? 

[dh42]

Hello,

the max number of Gcode lines has been increased to 1000 lines since N version.

I was looking to see if there were bug fix notes when I saw that.  Has the issue with sometimes not getting an actual start point near your set point been fixed? 

no I do not think so

you have a link to a topic with an example file ?

++
David

[Bob La Londe]

I usually run into the issue with large (can't upload even zipped) and almost always proprietary files.  When I try to do a sample that is not the private proprietary property of a customer it usually works.

I believe I posted a video of a work around using multiple 3D MOPs to do 2D work a while back.  The work around only works for a first pass.  You have to create multiple MOPs for the work around to work for more than one pass.  Very cludgey.  

When I have posted about the start point issue in the past most replies were along the lines of "works for me," so I just deal with it instead of asking further.

[dh42]

When I try to do a sample that is not the private proprietary property of a customer it usually works.

LOL ! ... I know ...

I usually run into the issue with large (can't upload even zipped) and almost always proprietary files.

Maybe you can try to send the file to Andy by Email directly, so it will not shown on the forum ? It's what I do when I can't share a file and when I can't repeat the bug with a test file.

++
David

[Bob La Londe]

Here is one:

[dh42]

I will look at later; big migraine today ... need to stay in the dark ...

++
David

[dh42]

Hello Bob,

I take a look on your file.

the pb I see with the start point are:

(viewed with the toolpathfilter and simulated on cutviewer)

- 1/2 surface1 -> the start point is set at the upper-left side of the rectangle, but the cut start at the upper-right side.

- 1/2 surface -> Ok start at the correct position

- 1/2 surface2 -> mirror of surface1 -> same pb as 1

- 1/2 surface3 -> mirror of surface -> OK

- Pocket1 -> OK

- Pocket2 & 3 -> start at the opposite side

It's what you are talking about ?

There is another problem with the machining direction ; changing the machining direction as no effect .. (except for mixed)

++
David

[Bob La Londe]

Here is an example of the finished part cut using that partial file I uploaded.  As you can see incorrect starts points would be catastrophic.  The roughing pass is optimized for maxiimum material removal rate with a .245" DOC and about a 20% stepover.  If instead it starts in the wrong place with 100% engagement as it does in my example it will jerk the part out of the vise or it could stall the spindle depending on your available horsepower.  

I used all profile cuts instead, but it was not intuitive at all to do it that way.  

(The finish pass was still done with negative roughing clearance and a pocket, but it didn't matter because the bulk of the material had been removed then.)

  

[dh42]

Hello,

Ok, I adds a link in the bug section and ad it to the list (maybe it as been already reported, but I've not finished to explore the bug section ... some are very old)

http://www.atelier-des-fougeres.fr/Cambam/Aide/Bug_report.html

++
David

[pixelmaker]

Bob,

As you can see incorrect starts points would be catastrophic.

Not the startpoint is important for "maxiimum material removal", but the cut direction. You use a mixed cut direction so every second toolpath has the "wrong direction", no matter in which direction the toolpaths are processed. You can also work with a lead in to prevent full engagement.

If you change the startpoint to the other side no toolpath has a different cut direction. Every second toolpath climbed or is conventional.
A pocket in Cambam never had a working startpoint for the horizontal or vertical hatch.
Before a couple of years we learned to use polylines and the engraving mop if we need to determine the cutting direction.

A simple workaround is to switch of the optimisation. Then the cut starts at the opposite side.

@ David
I think it will be better to set a direct link in the bug.
When I saw the error message I found no explanation and no sample file. Following the links I have just made a return trip on the server.
I had to read the post from Bob and your answers to understand what is happend.
After understanding what Bob will tell us I remember directly that CB never had a startpoint in pocket with hatches.

http://www.cambam.co.uk/forum/index.php?topic=3395.0

ralf

[Bob La Londe]

Response to TANGENT: Why is it the "wrong" direction when you are roughing off material or surfacing when the desired result is achieved?  Is it more efficient (faster) to cut in only one direction and then use a rapid effectively doubling your total amount of travel?  The machine this is run on is rigid enough to handle it.  Its also nearly powerful enough to make the cut at 100% engagement that is wrong, but it would jerk the piece out of the vise.  Of course the next tangent critique would be to set the piece deeper in the vise, but that would require mounting the part multiple times and result in a rough cut that might not be cleaned up fully by the finish pass.  

I think we have a "perceived" wrong here based on our own preferred practices.  

I'm not sure why a start point would even be needed on a pocket for anything other than hatches.  If you use the default inside-outside it just starts in the middle.  If I have some time I'll experiment with other pocketing methods and see if it has any affect.  Seems like if the start point has no effect then it should not be an option in the operation.  Anyway, regardless of whether or not the cut is set for conventional, climb, or mixed it would start in a spot that would result in 100% engagement when speed and feed is calculated for 20% engagement and the very option that would appear to be there to correct this does not work.  In this case a profile does work also, but there are times when a profile will not work.  I'ld post an example, but the example I already posted illustrates that the option does not work.  I had no way of knowing that it was an accepted not working feature rather than a bug until now.  

I still say its a bug.  

FYI:  Profiles don't always work either.  I posted a simple example that illustrates the point.  

WORK AROUND:  And I hate to mention this, but there is a nasty ugly work around.  Mirror the geometry, then mirror the MOP.  The problem is CB doesn't show where the MOP actually starts.  You have to sim it in something else.  Might not be to big a deal if you are only doing one or two simple MOPs, but I rarely do jobs that are only one or two simple MOPs.  The main reason I don't like to mention work arounds is that it takes away from the bug.  Yes I want to get this job done today, but I'll have another one tomorrow and I'll have to spend time doing the same ugly work around again.  

Turn Off Optimization:  Is that a consistent predictable result?  I'll have to do some sims and see.

[Dragonfly]

While speaking about it, I'd like to know what actually is included in the optimization list.
This is because I remember I got unpleasantly surprised that features I wanted to stay got turned off with optimization off. While I only wanted to have the MOPs in the order of selection of geometry because currently CB optimization does strange rapids to and fro while the next MOP is literary right under the tool.

[dh42]

Hello,

Turn Off Optimization:  Is that a consistent predictable result?  I'll have to do some sims and see.

Not working for me ; with any optimization mode or none, the toolpath always start at same side of the rectangle ; worst, with "none", the mixed mode don't work

(I very very rarely use vertical/horizontal hatch pocket, so I'm not aware of all problems that it cause)

++
David

[Bob La Londe]

Thanks David.  I didn't think it would work, but I wanted to verify it before saying so.  I appreciate you taking the time to check it.  The double mirror method will work, but its ugly and it could be forgotten because its not obvious in future rework of a project.  Of course anything along those lines that isn't accounted for can cause other problems. 

[pixelmaker]

I didn't think it would work

Try it. The two attached images are the same file, the view filter shows only the first toolpath.
With any "Optimisation Mode" the toolpath starts  at the right side.
I switch the "Optimisation Mode" to "none" and the toolpath starts at the left side.
I set no start point because CamBam never knows a start point with horizontal or vertical hatch.
You also can´t choose a milling direction for this hatch filling. With any "Optimisation Mode" you get a climb and without a optimisation you get a conventional direction.
Yes it is a bug, but this Bug exists as long as the hatch filling and optimisation modes are existing.

worst, with "none", the mixed mode don't work

Yes, that is true.
If I need those toolpaths I copy a polyline with "Array Copy" and use the engraving mop. Then I get what I want.
This is what I mean the horizontal and vertical hatches never work.


ralf