CamBam
News:
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
February 27, 2020, 15:01:40 pm


Login with username, password and session length


Pages: [1]
  Print  
Author Topic: Is this a bug?  (Read 6352 times)
lloydsp
CNC Jedi
*****
Offline Offline

Posts: 8145



View Profile
« on: January 08, 2011, 01:31:54 am »

I have attached two .cb files... one that will simulate just fine, and the other which drives cutviewer crazy.

There is only one difference between the two.  In the "works" file, the 3-profile MOp cuts to -0.35"
In the "broke" file, the same profile cuts to -0.36".  Nothing else did I change.

Is this a bug?  Or is it something really fundamental I don't understand about overlapping geometries?

The problem is, I cannot deliberately make an arbitrarily-deep cut on that profile.  Sometimes it works, other times it crashes cutviewer (and my real mill).

Thanks,

LLoyd

* Ball-in-Cube 3 broke.cb (290.77 KB - downloaded 202 times.)
* Ball-in-Cube 3 works.cb (290.77 KB - downloaded 191 times.)
Logged

"Pyro for Fun and Profit for More Than Fifty Years"
dh42
Administrator
CNC Jedi
*****
Offline Offline

Posts: 5765



View Profile WWW
« Reply #1 on: January 08, 2011, 02:02:24 am »

Hello

I try the 2 file, and ..... the 2 broke  Grin

I think it's a Cutviewer bug, because simulation is well on mach3

on CW I get the result on pictures  Huh

You can set your stock size and use the Mach3-CV postpro to directly say cutviewer stocksize and tooldiameter.
look on the file "ball_in_cube_cw"

++
David

* Ball-in-Cube_CW.cb (290.76 KB - downloaded 178 times.)

* Sans titre-4.jpg (126.47 KB, 800x608 - viewed 329 times.)
Logged
lloydsp
CNC Jedi
*****
Offline Offline

Posts: 8145



View Profile
« Reply #2 on: January 08, 2011, 02:14:28 am »

David, to me your result looks more like a configuration problem than the bug I'm suspecting.  It's perfectly regular, where the "broke" file gives me a good milling sim except with one errant arc that zooms outside the profile.  If you change _gcode.nci value IJkformat_abs=center-start to IJkformat_abs=center, your Cutviewer should act like mine.

Here's an experiment I did that might tell more:

I generated the toolpaths for both MOps, then I disabled one, generated G-code, then flipped to the other and generated g-code, then enabled both and generated it for both MOps.

Each individual "chunk" worked fine in simulation.  Editing (splicing) them together (only removing redundant setup and file-end stuff) resulted in a combined file that worked fine, too.  But when CAMBAM generated the combined g-code itself, it errors in simulation.

I think this is a bug in how CAMBAM treats the transition in g-code from the first to the second MOp.  It is the "last circle" in the 3-D profile MOp that goes wild...

LLoyd
« Last Edit: January 08, 2011, 02:38:49 am by lloydsp » Logged

"Pyro for Fun and Profit for More Than Fifty Years"
dh42
Administrator
CNC Jedi
*****
Offline Offline

Posts: 5765



View Profile WWW
« Reply #3 on: January 08, 2011, 02:31:29 am »

strange ...

Even I invert, disable or delete the second MOP (the square) I get the same result in CW, that never works ....

If I try waterlinefinish in place of waterlinerough, I get error message from windows when generating toolpath !

Work well if using horizontal or vertical in place of waterline.

Good night
David
Logged
lloydsp
CNC Jedi
*****
Offline Offline

Posts: 8145



View Profile
« Reply #4 on: January 08, 2011, 02:43:29 am »

Those MOps work in absolute-center mode.  Change your cutviewer configuration file _gcode.nci
entry from IJkformat_abs=Center-Start to IJKformat_abs=Center, and you'll see what I'm seeing.

LLoyd
Logged

"Pyro for Fun and Profit for More Than Fifty Years"
lloydsp
CNC Jedi
*****
Offline Offline

Posts: 8145



View Profile
« Reply #5 on: January 08, 2011, 02:47:20 am »

If I try waterlinefinish in place of waterlinerough, I get error message from windows when generating toolpath !


That's because of another _suspected_ "bug" that I haven't yet gotten a read on from 10bulls.  If the stock surface isn't exactly at or just a few thousanths of an inch above the top of the profile surface, Waterline Finish reports that odd error, instead of just telling you that the stock surface must be near the profile surface.

LLoyd
Logged

"Pyro for Fun and Profit for More Than Fifty Years"
dh42
Administrator
CNC Jedi
*****
Offline Offline

Posts: 5765



View Profile WWW
« Reply #6 on: January 08, 2011, 03:11:53 am »

Ok, after modified the postpro I get the same pb you talk about, but not understand why ...

If I switch the ArcCenterMode = incremental, and with the normal postpro, even the broke file is OK on CW.


++
David

Logged
10bulls
Administrator
CNC Jedi
*****
Offline Offline

Posts: 2133


Coding Jedi


View Profile WWW
« Reply #7 on: January 08, 2011, 16:47:22 pm »

This is a bit odd...

Mach3 reads the file OK.

The entire first roughing operation seems to work OK in CutViewer.

I don't think it is last arc move of the first operation.
Oddly, it appears to go wrong on the line that has S2000 for the second operation Huh
In fact if you remove that line it seems to work OK.

I think I will refer that one to CutViewer.

Although I am not sure why you are having problems with the Bridgeport?
What problems are you seeing when you run the file?

Sorry for not feeding back on the stock surface error reported with the waterline finish.  This bug is fixed now in the development version so will be OK in the next release.
Logged
lloydsp
CNC Jedi
*****
Offline Offline

Posts: 8145



View Profile
« Reply #8 on: January 08, 2011, 17:06:02 pm »

Although I am not sure why you are having problems with the Bridgeport?
What problems are you seeing when you run the file?

--------------------------
Andy, I'll be honest and say that I have not yet air-milled that last version of the files.  In the progress getting to this point, though, any time CutViewer blows up on an arc, my machine does, too.

This evening, I will run the part, and see what the machine does, then report back.

It _is_ odd, and the appending of the two MOps separately into one successful file sort of confirms that this might be a CutViewer problem.

Thanks, also for that 3-D finish fix.  It's an annoyance, only, but certainly would lead to future service requests.

LLoyd
Logged

"Pyro for Fun and Profit for More Than Fifty Years"
lloydsp
CNC Jedi
*****
Offline Offline

Posts: 8145



View Profile
« Reply #9 on: January 08, 2011, 22:45:02 pm »

Andy, good news for you, but it has me stalled:  This is a CutViewer problem.

It milled fine in wax on the R2E4.

This "ball" project was a way to proof some problems I'm having on a more complex job ("real" work).  I got those weird paths on that job (in simulation), and did the ball profiles to find the crux of the issue.

As I think back, once I fixed the absolute centers on arcs issue, I don't recall actually having milled a bad arc.

Please forward this as a CutViewer problem.  FWIW, I'm not sure it's actually related to the speed change, but rather that CutViewer might be taking that or some other part of another command as data for a previous one.  I think I have had that aberrant arc appear in other parts where there was no tool change, but where a change of strategy from (say) flat pocketing to 3-D profile pocketing was being done, but where I had edited out the tool change as superfluous.

LLoyd
Logged

"Pyro for Fun and Profit for More Than Fifty Years"
10bulls
Administrator
CNC Jedi
*****
Offline Offline

Posts: 2133


Coding Jedi


View Profile WWW
« Reply #10 on: January 08, 2011, 23:14:15 pm »

Just to let you know, I have passed this on to CutViewer and will let you know as soon as I hear something.

On a whim, I tried adding a G0 (no parameters) just above the S2000 line and that stopped the problem too.

So it's a bit of an ugly hack, but in your post processor, MOP section, if you do someting like this...

{$comment} {$mop.name} {$endcomment}
{$toolchange}
{$velocitymode} {$workplane}
{$mop.header}
G0             <------ bodge alert!
{$spindle} {$s}
{$blocks}
{$mop.footer}

That might be a work around until the CutViewer issue is resolved?
Logged
lloydsp
CNC Jedi
*****
Offline Offline

Posts: 8145



View Profile
« Reply #11 on: January 08, 2011, 23:24:37 pm »

I'll try that, Andy.  That may be just the thing to get me off my pins until later.

Thanks,

LLoyd
Logged

"Pyro for Fun and Profit for More Than Fifty Years"
lloydsp
CNC Jedi
*****
Offline Offline

Posts: 8145



View Profile
« Reply #12 on: January 08, 2011, 23:43:08 pm »

I don't know exactly how systems may vary, but putting the G0 before the speed control did not fix it.  However, putting a bald G0 just before the toolchange did. (?)

I will try it on the problem job, and see how that turns out.

LLoyd
Logged

"Pyro for Fun and Profit for More Than Fifty Years"
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines

Valid XHTML 1.0! Valid CSS! Dilber MC Theme by HarzeM
Page created in 0.14 seconds with 19 queries.

Copyright © 2018 HexRay Ltd. | Sitemap