CamBam
News:
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
December 12, 2019, 03:50:40 am


Login with username, password and session length


Pages: 1 [2]
  Print  
Author Topic: [1-49] Weird Engrave Issue Using Work Offsets G54 & G55  (Read 1978 times)
Bob La Londe
CNC Jedi
*****
Offline Offline

Posts: 3811


^ 8.5 pounds on my own hand poured bait.


View Profile WWW
« Reply #15 on: November 06, 2019, 00:41:11 am »

This test file duplicates the bad results.  I just cut and paste the MOPs from the working file to this test file and created some new items to engrave. 


* TEST.cb (8.26 KB - downloaded 18 times.)
Logged

Getting started on CNC?  In or passing through my area?
If I have the time I'll be glad to show you a little in my shop. 

Some Stuff I Make with CamBam
http://www.CNCMOLDS.com
dh42
Administrator
CNC Jedi
*****
Offline Offline

Posts: 5676



View Profile WWW
« Reply #16 on: November 06, 2019, 03:23:09 am »

Hello

Using a separate shape for the second mop set don't solve the problem ... except if the copied shape is slightly moved.

I found a workaround without to create and move a second shapes set.

On the second mop set, I added a transformation matrix ->  translation X about 0.001" and the problem seems to go away.

Hope it can help you until Andy solve this bug.

++
David

* TEST_DH.cb (8.33 KB - downloaded 15 times.)

* Sans titre-1.jpg (78.18 KB, 824x707 - viewed 36 times.)
« Last Edit: November 06, 2019, 03:28:35 am by dh42 » Logged
dave benson
CNC Jedi
*****
Offline Offline

Posts: 1171


View Profile
« Reply #17 on: November 06, 2019, 05:11:00 am »

Ok.
I'm assuming this:
1.. You have two identical stock items,and you wish to engrave two words of text on each.
2..The two stock items are placed six inches apart in the X axis along your mill table in vices or fixtures.
3.. You want  CB to generate a file with the Gxx's in it to move from one fixture to another to do the engraving.

The first thing I noticed was the polyline start errors, so I ran the text, now converted to polylines through the file cleaner.
I then adjusted each mop's header and footer.
I generated the file with no polyline start errors, and then ran it through the simulator and mach 3.
It runs ok in Mach3.
I started off with G54 and then went to G55 just for the sake of clarity.

Dave

* TEST changed working offsets.cb (33.49 KB - downloaded 14 times.)

* No polyline start errors rums in sim and Mach3.PNG (175.47 KB, 1314x599 - viewed 38 times.)

* Sim.PNG (42.56 KB, 840x541 - viewed 31 times.)

* Using offsets.PNG (172.68 KB, 988x387 - viewed 30 times.)
Logged
Bob La Londe
CNC Jedi
*****
Offline Offline

Posts: 3811


^ 8.5 pounds on my own hand poured bait.


View Profile WWW
« Reply #18 on: November 06, 2019, 15:13:28 pm »

Ok.
I'm assuming this:
1.. You have two identical stock items,and you wish to engrave two words of text on each.

Two items anyway.  They are much more complex than in the sample.  They are cleaned and projected polylines.  The surface where the engraving goes is .9 inches below the stock surface.
Quote

2..The two stock items are placed six inches apart in the X axis along your mill table in vices or fixtures.

The distance apart is irrelevant.  They are located by the work offset defined on the machine.  They can be offset on all axis.  The code doesn't change.
Quote

3.. You want  CB to generate a file with the Gxx's in it to move from one fixture to another to do the engraving.

G00 fast plunge to just above engrave height as in the first pair of operations.  Then normal plunge to cut depth.
Quote

The first thing I noticed was the polyline start errors, so I ran the text, now converted to polylines through the file cleaner.
I then adjusted each mop's header and footer.
I generated the file with no polyline start errors, and then ran it through the simulator and mach 3.
It runs ok in Mach3.
I started off with G54 and then went to G55 just for the sake of clarity.

The order of the work offsets didn't matter.  When I swapped them back and forth whichever set of operations was first operated correctly, and whichever set was second did not.
Quote

Dave

Thanks.  I'll go over what you have here and see if it helps in the real application.  I still have over 20 units to cut out of the 50 piece order.  By just separating out the engrave operations to their own files I am saving over *50 minutes per pair.  If I can eliminate one restart (tool changes are still manual) I could save a few more minutes.  Right now I am cutting **primary operations at a rate 4 units per day.  

* I originally reported that the MOPs that operated correctly took 19 minutes.  That was a guess based on the elapsed time clock shown on the control screen.  They actually take a little over 14 minutes.  

** This is a part that requires 4 setups to complete.  The first setup currently takes a little under 3 hrs to cut two parts.  The following setups take about 30 minutes and about 3 minutes and 3 minutes to complete.  Those are being done on a different machine.  I'm actually doing one setup twice with work stops on the machine as its faster than changing tools on that machine.  So 5 setups to make one part.  LOL.  
« Last Edit: November 06, 2019, 19:53:11 pm by Bob La Londe » Logged

Getting started on CNC?  In or passing through my area?
If I have the time I'll be glad to show you a little in my shop. 

Some Stuff I Make with CamBam
http://www.CNCMOLDS.com
dave benson
CNC Jedi
*****
Offline Offline

Posts: 1171


View Profile
« Reply #19 on: November 06, 2019, 23:15:19 pm »

Quote
The distance apart is irrelevant.  They are located by the work offset defined on the machine.  They can be offset on all axis.  The code doesn't change.

Bingo, That's why CB knows naught about them, and more importantly they (the offsets are a controller thing) can play no part in the  CB's Gcode generation so that puts this bug report to bed.
If you have problems with your CB generated file, it simply can not be the offsets.

I've never used the offsets in this manner, when confronted with a situation like this (needing separate files for the engraving)
my go to is to use subroutines and have everything in one file. they are very powerful, but people shy away from them
in the cam world because they think they are to difficult to use or just don't know about them.

Good Luck, I'm sure you'll work it out.

Dave
Logged
dh42
Administrator
CNC Jedi
*****
Offline Offline

Posts: 5676



View Profile WWW
« Reply #20 on: November 07, 2019, 00:43:39 am »

Hello

Quote
Bingo, That's why CB knows naught about them, and more importantly they (the offsets are a controller thing) can play no part in the  CB's Gcode generation so that puts this bug report to bed.

Not exactly, there is a bug, but it is not because the use of G5x, but because CB seems to have a problem when two identical toolpaths are generated at the same position. If you slightly move the toolpath with the transformation matrix, the bug go away.

have a look to the attached file here that solve the bug. (at least for this example)
https://www.cambam.co.uk/forum/index.php?topic=8273.msg65779#msg65779

there is certainly other factors (maybe wrong polylines or this mysterious "wrong poly start" warning) that act, because sometimes, depending of the drawing objects used, it works ....

++
David
« Last Edit: November 07, 2019, 00:46:30 am by dh42 » Logged
Bob La Londe
CNC Jedi
*****
Offline Offline

Posts: 3811


^ 8.5 pounds on my own hand poured bait.


View Profile WWW
« Reply #21 on: November 07, 2019, 01:48:05 am »

Quote
The distance apart is irrelevant.  They are located by the work offset defined on the machine.  They can be offset on all axis.  The code doesn't change.

Bingo, That's why CB knows naught about them, and more importantly they (the offsets are a controller thing) can play no part in the  CB's Gcode generation so that puts this bug report to bed.
If you have problems with your CB generated file, it simply can not be the offsets.

I've never used the offsets in this manner, when confronted with a situation like this (needing separate files for the engraving)
my go to is to use subroutines and have everything in one file. they are very powerful, but people shy away from them
in the cam world because they think they are to difficult to use or just don't know about them.

Good Luck, I'm sure you'll work it out.

Dave

So why didn't exactly identical MOPS with 100% exactly identical parameters produce identical code?  They quite clearly did not.  Like I said, the offsets are irrelevant.  I took the time to point out that was the ONLY (AND NOTHING ELSE) difference between the MOPs before somebody said "AHA THEY ARE DIFFERENT," and drew a different false conclusion.  

That's the other side of providing to much information sometimes. 

 
« Last Edit: November 07, 2019, 01:53:36 am by Bob La Londe » Logged

Getting started on CNC?  In or passing through my area?
If I have the time I'll be glad to show you a little in my shop. 

Some Stuff I Make with CamBam
http://www.CNCMOLDS.com
dave benson
CNC Jedi
*****
Offline Offline

Posts: 1171


View Profile
« Reply #22 on: November 07, 2019, 03:20:05 am »

In a bug report titled: 
Quote
Weird Engrave Issue Using Work Offsets G54 & G55
Quote
Like I said, the offsets are irrelevant.
You didn't  think this at the start.

Quote
So why didn't exactly identical MOPS with 100% exactly identical parameters produce identical code?  They quite clearly did not.

I demonstrated this in the first file I posted, simply by turning the mops off different code was produced with no offsets, to demonstrate  the point that, what happens in the previous mop matters. I would have told you this first up, if this was a General thread regarding having trouble with engraving and not a bug report. CB does have some bugs but this is not one of them.

Quote
Not exactly, there is a bug, but it is not because the use of G5x, but because CB seems to have a problem when two identical toolpaths are generated at the same position. If you slightly move the toolpath with the transformation matrix, the bug go away.

When I get some time David I'll have a look into it, if this bug seems to be random, then it's probably a precision
related thing, at times I've fixed a seemingly random problem by round up some values.

Dave
Logged
Bob La Londe
CNC Jedi
*****
Offline Offline

Posts: 3811


^ 8.5 pounds on my own hand poured bait.


View Profile WWW
« Reply #23 on: November 07, 2019, 14:48:04 pm »

In a bug report titled:  
Quote
Weird Engrave Issue Using Work Offsets G54 & G55
Quote
Like I said, the offsets are irrelevant.
You didn't  think this at the start

I didn't know what to think at the start.  I knew that was the only difference in the MOPs.  I would specifically note that was not the ONLY information I provided.  Even from the start.  Even then I knew that the work offsets "SHOULDN'T" affect the code generation.  When code was created independently they worked as intended.  I took the time to point out very specifically that the problem occurred when both sets of MOPs created code together and that changing the order of the MOPs DIDN'T change the order of the BUG.  

I know how work offsets work, or atleast how they are "supposed" to work.  Its one of the great benefits of having multiple vises or clamping fixtures on the machine bed.  It allows you to use different references for different things as needed or desired.  Its not the first time I've used work offsets to cut a part in each vise instead of measuring the relative positions of the vise and having to set the relative position of two pieces of stock.  Now that I think about it though.  It may be the first time I have cut identical parts using work offsets in both vises on that machine.  Usually I cut two halves of a part which are usually mirror images of each other.  

The fact is there is a problem.  CamBam was generating two totally different code sets from the same parameters.  If you want to argue over the irrelevant knock yourself out.  You win.  It was proven to my satisfaction there IS a bug.  

Gary,  I knew it was not a Mach BUG from the start.  While I used Mach as my demo in the video clip the code was being executed on a LinuxCNC variant machine.  Well besides having already looked at the code to see it was different and seen the red rapids on one set and blue tool paths on the other in the Mach screen.  I have also seen the issues you mentioned about slow movement in Mach.  I used to see it when using G53 in my tool change macros.  G53 (and probably some other G codes) use the last speed set in code.  Its a handy move because it moves in machine coordinates regardless of the current work offset.  I also think there is a slight difference in how Mach and LinuxCNC handle it.  
« Last Edit: November 07, 2019, 17:21:43 pm by Bob La Londe » Logged

Getting started on CNC?  In or passing through my area?
If I have the time I'll be glad to show you a little in my shop. 

Some Stuff I Make with CamBam
http://www.CNCMOLDS.com
Bob La Londe
CNC Jedi
*****
Offline Offline

Posts: 3811


^ 8.5 pounds on my own hand poured bait.


View Profile WWW
« Reply #24 on: November 07, 2019, 17:29:34 pm »

David,  .001mm is not significant for most applications, but .001 inches would noticeably change the width of the final cut in this circumstance if its in depth.  Because this is a projected set of lines the engraving in some locations would look even worse if shifted left to right or front to back.  The edges are mapped around a curved edge on the surface.  

I still have several of these to machine to complete the order so I will check to see if a smaller translation or depth and depth increment such as .0001 inches is enough to clear up the issues for this application.  It would still save some time even at this point to have one less restart.  

In my actual working file I do not get wrong polyline starts.  The sample file used a stick font created by George Race. 

« Last Edit: November 07, 2019, 17:31:06 pm by Bob La Londe » Logged

Getting started on CNC?  In or passing through my area?
If I have the time I'll be glad to show you a little in my shop. 

Some Stuff I Make with CamBam
http://www.CNCMOLDS.com
dh42
Administrator
CNC Jedi
*****
Offline Offline

Posts: 5676



View Profile WWW
« Reply #25 on: November 07, 2019, 22:45:26 pm »

Hello

Yes, I also tried to compensate the toolpath move by using a different Gcode origin for the second set of MOP (they are moved in a separate CamPart with an origin moved from the same value of the toolpaths move) ... but no luck, that compensate the move ... but the bug is coming back ...

I used 0.001 on the previous example, but it also works with moving the TP for only 0.0001" (but not with 0.00001")

++
David
Logged
dh42
Administrator
CNC Jedi
*****
Offline Offline

Posts: 5676



View Profile WWW
« Reply #26 on: November 07, 2019, 23:33:32 pm »

Quote
(but not with 0.00001")

Ah ah ! .. it can works with moving 0.00001" in X if I change the number format string in the post processor.

My previous setting was: 0.0###

If I replace it by 0.0#### moving the TP 0.00001" solve the bug too

I wonder if the fast plunge is calculated by the mop itself or by the post processor ?

++
David

 
« Last Edit: November 07, 2019, 23:40:30 pm by dh42 » Logged
Bob La Londe
CNC Jedi
*****
Offline Offline

Posts: 3811


^ 8.5 pounds on my own hand poured bait.


View Profile WWW
« Reply #27 on: November 07, 2019, 23:53:38 pm »

An translation of .0001" is good enough.  Interestingly it did not work with a Z translation.  An X translation did the trick.  

If my microphone wasn't broke I'd make a video about it.  LOL. 
Logged

Getting started on CNC?  In or passing through my area?
If I have the time I'll be glad to show you a little in my shop. 

Some Stuff I Make with CamBam
http://www.CNCMOLDS.com
Dragonfly
CNC Jedi
*****
Offline Offline

Posts: 2224



View Profile
« Reply #28 on: November 10, 2019, 08:10:27 am »

I think I found (possibly) a clue when the plunge speed bug occurs.
Here is a file I did yesterday. In Part2.Pocket1 is set to use spiral lead-in with angle 0 (CB decides what angle to use for reaching the DOC). First two depth levels mill as expected - rapid move down do fast plunge height (1 mm above stock) and then slow plunge with spiral lead-in. On the third pass (and next ones too) the code misses the rapid on Z, instead it starts moving down at plunge speed from clearance.

( Pocket1 ) Stock surface is at +12 mm
G17
M3 S18000
G0 X-9.1001 Y5.9
G0 Z13.0 - First depth level
G1 F150.0 Z12.0
G1 F700.0 X9.0999 Z11.6538
G1 Y6.1 Z11.65
G1 X-9.1001 Z11.3038
G1 Y5.9 Z11.3
G1 X-10.9001
G1 Y4.1
G1 X10.8999
G1 Y7.9
G1 X-10.9001
G1 Y5.9
G1 X-12.7001
G1 Y2.3
G1 X12.6999
G1 Y9.7
G1 X-12.7001
G1 Y5.9
G1 X-14.5001
G1 Y0.5
G1 X14.4999
G1 Y11.5
G1 X-14.5001
G1 Y5.9
G0 Z20.0
G0 X-9.1001
G0 Z12.3 - Second depth level
G1 F150.0 Z11.3
G1 F700.0 X9.0999 Z10.9538
G1 Y6.1 Z10.95
G1 X-9.1001 Z10.6038
G1 Y5.9 Z10.6
G1 X-10.9001
G1 Y4.1
G1 X10.8999
G1 Y7.9
G1 X-10.9001
G1 Y5.9
G1 X-12.7001
G1 Y2.3
G1 X12.6999
G1 Y9.7
G1 X-12.7001
G1 Y5.9
G1 X-14.5001
G1 Y0.5
G1 X14.4999
G1 Y11.5
G1 X-14.5001
G1 Y5.9
G0 Z20.0
G0 X-9.1001
G1 F150.0 Z10.6 - Third depth level. Instead of G0 G1 is used
(next four lines are the spiral lead-in)
G1 F700.0 X9.0999 Z10.2538
G1 Y6.1 Z10.25
G1 X-9.1001 Z9.9038
G1 Y5.9 Z9.9
G1 X-10.9001
G1 Y4.1
.....
If I turn off the spiral lead-in the pocket mills without these glitches. Haven't tested it with manually set angle for the spiral lead-in.
And because spiral milling is in fact a continuous spiral lead-in it maybe an explanation why the glitch occurs on consecutive spiral mill MOPs over the same center.

* X-MotorStand2.cb (31.59 KB - downloaded 12 times.)
« Last Edit: November 10, 2019, 08:12:59 am by Dragonfly » Logged
Pages: 1 [2]
  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.136 seconds with 19 queries.

Copyright © 2018 HexRay Ltd. | Sitemap