Date   
Re: Guide pins on smd solder mask.. #pcbgcode

peterg1000
 
Edited

I tested the change described in my previous post and to my surprise the stencil cutouts were MUCH larger - I clearly haven't understood the software very well !!

Fortunately the following change DOES work and stencil sizes are exactly as defined by the Eagle footprint.

                        // Tool size compensation - modified 06/08/20 to correct compensation calculations
                        dx -= tool_dia ; dy -= tool_dia ;   //    Division by 2 removed

                        // Carve out the pad
                        if (dx > 0 && dy > 0) {
                            int hx = dx / 2 , hy = dy / 2 ;

Peter

Re: #drill #etch #gcode #drill #etch #gcode

John Ferguson
 

HI Peter,

After some mishaps with very small vias (Well, in truth, too small) I was advised that it is better to drill first, then etch. Doing it this way eliminates a need to spot-drill, although I suppose you might be able to spot drill first without etching.  In any case, I've had no problem since starting to drill first.

I'm not sure I know what code I'm running now.  I run LinuxCNC on a PC to drive the router. 

I must say, I've been very happy with this setup.  I do use dxf for the physical board design and SheetCAM to generate the G-Code for big holes and the perimeter.  I can offset inside or outside line or on the line with SheetCAM so I usually get exactly what I asked for although sometimes I don't ask for what I really wanted.

best regards,

John Ferguson

On 8/6/20 11:59 AM, peterg1000 via groups.io wrote:
Hi John,

The main downside was that when doing spot drills, which were meant to be only 0.3mm deep, the spot was drilled to the full depth defined for drilling - all done with the etching tool.  Anyway all's well that ends well, it now spots and drills correctly with G82  !!

At least I now have a vague understanding of how this amazing piece of software works - JJ is a genius !!

I've not yet implemented the EOF move but have corrected the stencil size anomaly that was bugging me - I'll post the alteration I made under the correct topic later on.

Cheers,
Peter

Re: #drill #etch #gcode #drill #etch #gcode

peterg1000
 

Hi John,

The main downside was that when doing spot drills, which were meant to be only 0.3mm deep, the spot was drilled to the full depth defined for drilling - all done with the etching tool.  Anyway all's well that ends well, it now spots and drills correctly with G82  !!

At least I now have a vague understanding of how this amazing piece of software works - JJ is a genius !!

I've not yet implemented the EOF move but have corrected the stencil size anomaly that was bugging me - I'll post the alteration I made under the correct topic later on.

Cheers,
Peter

Re: #drill #etch #gcode #drill #etch #gcode

John Ferguson
 

Peter,

I took G82 out of my code because I couldn't see any purpose in having dwell at the bottom of a through-hole. How does G82 have anything to do with your current issue?

John

On 8/6/20 4:34 AM, peterg1000 via groups.io wrote:
I've now unearthed the gruesome truth!!  The culpritt gcode-defaults.h file was down loaded from John Ferguson's post on April 11 (#8087) because having the machine return to X = 0, Y = 0 Z = n.nnn for a manual tool change seemed a good idea.   

What I failed to realise was the John had left a booby trap in his file by disabling G82 codes for drilling  (Sorry John, no Christmas card this year!!). 

To compound the problem, the backup I used contained the same file.   Pity I didn't follow the golden rule - "Record every change, otherwise it will bite you sooner or later !! ".

Still don't know why the fresh download didn't work - no graphics and some options not on the screen.  That's for another rainy day (or week).                   

.

Re: #drill #etch #gcode #drill #etch #gcode

John Ferguson
 

Wow,

Sorry Peter.  I suppose I fell into the trap of having something work for me without realizing I'd messed something else up. Clearly I need to revisit this.

apologies,

JOhn

On 8/6/20 4:34 AM, peterg1000 via groups.io wrote:


I've now unearthed the gruesome truth!!  The culpritt
gcode-defaults.h file was down loaded from John Ferguson's
post on April 11 (#8087) because having the machine return
to X = 0, Y = 0 Z = n.nnn for a manual tool change seemed a
good idea.

What I failed to realise was the John had left a booby trap
in his file by disabling G82 codes for drilling  (Sorry
John, no Christmas card this year!!).

To compound the problem, the backup I used contained the
same file.   Pity I didn't follow the golden rule - "Record
every change, otherwise it will bite you sooner or later !! ".

Still don't know why the fresh download didn't work - no
graphics and some options not on the screen.  That's for
another rainy day (or week).

.

Re: Guide pins on smd solder mask.. #pcbgcode

peterg1000
 

Finally I have tracked down the code in "pcb-gcode.ulp" that does the calculations for tool diameter compensation.  Note that tool diameter ends up being divided by 4  in hx and hy !!!!! Hence my problem. 

                        // Tool size compensation
                        dx -= tool_dia / 2; dy -= tool_dia / 2;                                      // My note  - divided by 2

                        // Carve out the pad
                        if (dx > 0 && dy > 0) {
                            int hx = dx / 2, hy = dy / 2;                                                //My note - divided  by ANOTHER 2 !!!!

I think if the last line is modified to be :-

                           int hx = dx , hy = dy 

then the resulting smd stencil cutout will be exactly as defined in Eagle.

Re: #drill #etch #gcode #drill #etch #gcode

peterg1000
 

I've now unearthed the gruesome truth!!  The culpritt gcode-defaults.h file was down loaded from John Ferguson's post on April 11 (#8087) because having the machine return to X = 0, Y = 0 Z = n.nnn for a manual tool change seemed a good idea.   

What I failed to realise was the John had left a booby trap in his file by disabling G82 codes for drilling  (Sorry John, no Christmas card this year!!). 

To compound the problem, the backup I used contained the same file.   Pity I didn't follow the golden rule - "Record every change, otherwise it will bite you sooner or later !! ".

Still don't know why the fresh download didn't work - no graphics and some options not on the screen.  That's for another rainy day (or week).                   

.

Re: Guide pins on smd solder mask.. #pcbgcode

Jerry Lee Marcel
 

On Mon, Aug 3, 2020 at 11:00 PM, peterg1000 wrote:
This shows the calculated tool path to lie inside the smd pad corners, and the differences are equal to (tool diam)/4. This means
that the actual stencil size is correctly centred, but larger, in the above case, by 0.075mm in each dimension (0.3mmtool).
I'm not proficient at pcbgcode, so maybe that won't be relevant, but, with the dxf-to-G-code converters I use, there is the choice between outside, inside or on-the-line.

Re: #drill #etch #gcode #drill #etch #gcode

peterg1000
 
Edited

I think I have recovered the situation with regard to the G82 code - the problem lies in the gcode-defaults.h file.  The one I had been using, dated 31/07/20 on my system, explicitly states :-

//
// Drilling holes
//
// Not using G82 so it will be very generic.
//
string DRILL_CODE       = ";( G82 not used )";
string RELEASE_PLANE    = "R" + FORMAT;
string DWELL_TIME       = PARAM + "%f";

Whereas the file that works dated 28/04/18 ( from another backup taken recently before a different change was made to this file) contains:-

//
// Drilling holes
//
// G82 Xx.xxx Yy.yyy Z.zzz Fff.f Rr.rrr #dwell
//
string DRILL_CODE       = "G82 ";
string RELEASE_PLANE    = "R" + FORMAT;
string DWELL_TIME       = PARAM + "%f";
string DRILL_FIRST_HOLE = DRILL_CODE + MOVE_XYZ + FR_FORMAT + RELEASE_PLANE + DWELL_TIME + EOL;
string DRILL_HOLE       = DRILL_CODE + MOVE_XY + EOL;

I had forgotten that a change was entered to  "string END_PROGRAM "  which somehow resulted in the  31/07/20 file being used.  Unfortunately I have no exact idea how this file arrived.  I did see the forum post regarding moving to X = 0, Y = 0, Z = n.nnn, and though I had implemented this correctly.

Incidentally I did try to download a fresh copy of the .zip file, but the recovered application (in a completely separate folder ) never ran correctly as it was apparently unable to access proper image files. I abandoned this approach as another diversion I didn't need!!

Re: #drill #etch #gcode #drill #etch #gcode

John Johnson
 

Looks like 'Use simple drill code' is turned on. Pg. 14 in the manual for more info.

Regards,
John

On Aug 5, 2020, 7:46 AM -0400, peterg1000 via groups.io <petergharrison@...>, wrote:
As of a couple of days ago, pcbgcode appear to have suddenly lost the ability to use G82 code in all drilling operations.  I've run extensive tests using alternative backup copies of pcb-gcode, .brd files and earlier versions of Eagle ( currently using 9.6.0, so reverted to 9.5.2 for test).  I'm fresh out of ideas on what might have changed to cause the problem as all the alternative copies were archived from fully working applications.

Could it be caused by something evil in the registry as I know I have run "Advanced System Care" recently??

Spot drills in the etch file now use the same substitute code as the drill file.

What was this code  in the drill file:-
"Absolute Coordinates)
G90
S18000
G00 Z10.0000
G00 X0.0000  Y0.0000 
M03
G04 P7.000000
M05
G00 Z40.0000
M06 T01  ; 0.9000 
G01 Z0.0000  F175  
M06
G00 Z2.0000 
M03
G04 P7.000000
G82 X6.0960  Y10.1600 Z-2.2500 F175   R2.0000  P1.000000
G82 X6.0960  Y12.7000
G82 X6.0960  Y15.2400
G82 X23.3934 Y8.4836 
G82 X23.3934 Y5.9436 
M05
G00 Z40.0000 "

Has now become this:-
"(Absolute Coordinates)
G90
S18000
G00 Z10.0000
G00 X0.0000 Y0.0000
M03
G04 P7.000000
M05
G00 Z40.0000
M06 T01  ; 0.9000
G01 Z0.0000 F175.00
M06
G00 Z3.0000
M03
G04 P7.000000
G00 Z3.000000
G00 X6.0960 Y10.1600
G01 Z-2.2500 F175.00
G01 Z3.000000
(R3.0000  P1.000000)
G00 X6.0960 Y12.7000
G01 Z-2.250000
G01 Z3.000000
G00 X6.0960 Y15.2400
G01 Z-2.250000
G01 Z3.000000
G00 X23.3934 Y8.4836
G01 Z-2.250000
G01 Z3.000000
G00 X23.3934 Y5.9436
G01 Z-2.250000
G01 Z3.000000
M05
G00 Z40.0000 "

Peter H

#drill #etch #gcode #drill #etch #gcode

peterg1000
 

As of a couple of days ago, pcbgcode appear to have suddenly lost the ability to use G82 code in all drilling operations.  I've run extensive tests using alternative backup copies of pcb-gcode, .brd files and earlier versions of Eagle ( currently using 9.6.0, so reverted to 9.5.2 for test).  I'm fresh out of ideas on what might have changed to cause the problem as all the alternative copies were archived from fully working applications.

Could it be caused by something evil in the registry as I know I have run "Advanced System Care" recently??

Spot drills in the etch file now use the same substitute code as the drill file.

What was this code  in the drill file:-
"Absolute Coordinates)
G90
S18000
G00 Z10.0000
G00 X0.0000  Y0.0000 
M03
G04 P7.000000
M05
G00 Z40.0000
M06 T01  ; 0.9000 
G01 Z0.0000  F175  
M06
G00 Z2.0000 
M03
G04 P7.000000
G82 X6.0960  Y10.1600 Z-2.2500 F175   R2.0000  P1.000000
G82 X6.0960  Y12.7000
G82 X6.0960  Y15.2400
G82 X23.3934 Y8.4836 
G82 X23.3934 Y5.9436 
M05
G00 Z40.0000 "

Has now become this:-
"(Absolute Coordinates)
G90
S18000
G00 Z10.0000
G00 X0.0000 Y0.0000
M03
G04 P7.000000
M05
G00 Z40.0000
M06 T01  ; 0.9000
G01 Z0.0000 F175.00
M06
G00 Z3.0000
M03
G04 P7.000000
G00 Z3.000000
G00 X6.0960 Y10.1600
G01 Z-2.2500 F175.00
G01 Z3.000000
(R3.0000  P1.000000)
G00 X6.0960 Y12.7000
G01 Z-2.250000
G01 Z3.000000
G00 X6.0960 Y15.2400
G01 Z-2.250000
G01 Z3.000000
G00 X23.3934 Y8.4836
G01 Z-2.250000
G01 Z3.000000
G00 X23.3934 Y5.9436
G01 Z-2.250000
G01 Z3.000000
M05
G00 Z40.0000 "

Peter H

Re: Guide pins on smd solder mask.. #pcbgcode

peterg1000
 

Hi John

Thanks for your reply - and your comments about milling the outline.  I have for some time been doing just what you suggested and
place the milling paths half the tool diameter outside the dimension lines.

You did however set me thinking about the calcs needed to create the stencil tool paths.  After a lot of searching I found an
isolated rectangular pad which was part of library footprint and extracted the co-ordinates of the corners as defined in a .brd
file using that library part and the associated tool path from the stencil file. I've analysed the situation below.

The chosen pad has dimensions (x,y) of 2.5mm by 3mm as defined in the "smd name" in the library file - this same information is
also present in the associated Eagle ".brd" file.  The coordinates of the corners of the smd pad as defined in the board file are
as follows:-

Upper right   X39.6691 Y5.5259
Lower right   X39.6691 Y2.5259
Upper left    X37.1691 Y5.5259
Lower left    X37.1691 y2.5259

Having run "pcb-gcode"  with a tool diameter of 0.3mm declared I checked the gcode produced in the "stencil.txt" file.

G00 Z2.0000
G00 X39.5941 Y5.4509
G01 Z-0.1250 F250.00
G01 X39.5941 Y2.6009 F500.00
G01 X37.2441 Y2.6009
G01 X37.2441 Y5.4509
G01 X39.5941 Y5.4509
G01 X39.5941 Y2.6009
G00 Z2.0000

This shows the calculated tool path to lie inside the smd pad corners, and the differences are equal to (tool diam)/4. This means
that the actual stencil size is correctly centred, but larger, in the above case, by 0.075mm in each dimension (0.3mmtool).
Using an smd pad for a location pin for a stencil produced as above would allow a potential error of +-0.25 x tool diameter.

Was this discrepancy intended, because I would much prefer the sizes to match exactly so as to minimise registration errors. Can
the calcs be easily modified to modify the stencil tool path to be 0.5 x tool diam inside the smd outline?

Sorry this is rather long winded but when dealing with the smallest smd components every fraction of a mm counts!!

Regards,
Peter.

Re: Guide pins on smd solder mask.. #pcbgcode

John Johnson
 

If I follow your question: pcb-gcode doesn't do any tool offset for tool diameter (other than when creating track isolation/etch files). If there is a line to be cut in the milling layer, the center of the tool will follow that line. One workaround is to create lines on the milling layer that are offset when you lay them down. The easiest way is to set the line width to the tool diameter, and use that as a guide.
It might be possible to create custom components based on the ones you have, with any cutouts offset to compensate for tool diameter.


Regards,
John

On 31 Jul 2020, at 5:46, peterg1000 via groups.io wrote:

In order to properly locate a stencil over an etched circuit board I have placed circular smd pads at appropriate places on the board.  Holes to accommodate guide pins are placed centrally on this pad.  When the matching stencil is generated it is  square and slightly larger than the original smd pad.  Two questions arise, firstly - is it possible to generate circular holes in a stencil, and secondly - is the oversize intended?

After a lot of checking it would seem that in the case of my circular pad, the final hole ends up half a tool diameter larger than the original pad size.  Viewing the cutouts for other devices on the board, they would appear to be similarly oversized as well.

For example I placed an smd pad 0.05" diameter on the circuit board and the coordinates on the stencil for the sides of the matching square hole Gcode turn out to be 0.04413 in length.  With a tool diameter of 0.01182" (3mm ) I would have expected this to be 0.050" -  0.01182" (i.e.0.03818" ).  Curiously enough this is almost exactly half a tool diameter smaller than the actual value. Is this intended, an error in calculation or just co-incidence ?

Peter Harrison

Guide pins on smd solder mask.. #pcbgcode

peterg1000
 

In order to properly locate a stencil over an etched circuit board I have placed circular smd pads at appropriate places on the board.  Holes to accommodate guide pins are placed centrally on this pad.  When the matching stencil is generated it is  square and slightly larger than the original smd pad.  Two questions arise, firstly - is it possible to generate circular holes in a stencil, and secondly - is the oversize intended?

After a lot of checking it would seem that in the case of my circular pad, the final hole ends up half a tool diameter larger than the original pad size.  Viewing the cutouts for other devices on the board, they would appear to be similarly oversized as well.

For example I placed an smd pad 0.05" diameter on the circuit board and the coordinates on the stencil for the sides of the matching square hole Gcode turn out to be 0.04413 in length.  With a tool diameter of 0.01182" (3mm ) I would have expected this to be 0.050" -  0.01182" (i.e.0.03818" ).  Curiously enough this is almost exactly half a tool diameter smaller than the actual value. Is this intended, an error in calculation or just co-incidence ?

Peter Harrison

Re: PCB-Gcode in Fusion 360 #pcbgcode

joeaverage
 

Hi,
that comports well with what I see happening in EAGLE, namely a pour isolated by a small but increasing amount 
with successive iterations. 

The process does not (visually) appear the same in Fusion. I would guess that PCB-gcode calls for a pour and as a result Fusion
generates a panel with the appropriate data, isolation distance, thermals etc. My guess is the intention is that the panel should be populated
with your choices if different from the defaults and the panel OKed before the pour is calculated. The panels flash up that briefly that its 
impossible to view or otherwise update it before the next successive panel appears.

I did try creating a ground pour in the original PCB artwork but that did not in itself allow pcb-gcode to work with regard to generating
compliant .etch files.

I also tried creating a .etch file with just a single pass hoping that the panel would exist long enough that I might view it, to no avail.

I have a subscription for Fusion, largely because of the CAD/CAM features but as it includes an unlimited (by comparison to the free
EAGLE offering) PCB design solution I am keen to get it to work. I am not a fan of subscription based software but when I compare the overall
value of the components offered as a single solution it does make sense and I overcame my aversion to a subscription.

Craig.


From: pcbgcode@groups.io <pcbgcode@groups.io> on behalf of John Johnson <john@...>
Sent: Friday, 31 July 2020 2:45 AM
To: pcbgcode@groups.io <pcbgcode@groups.io>; pcbgcode@groups.io <pcbgcode@groups.io>
Subject: Re: [pcbgcode] PCB-Gcode in Fusion 360 #pcbgcode
 
That's correct. The pour works like a ground plane pour, isolating itself from existing tracks by some increasing amount. The pour is then processed as polygonal line segments by pcb-gcode to generate the g-code movements for mechanical etching.
If the pour isn't happening, the whole process fails.

Regards,
John
On Jul 29, 2020, 8:33 PM -0400, joeaverage <joe.average@...>, wrote:
Hi,

"What does the screen look like when the etch files are being created? Do you still see the progressive outlines around the tracks?"

No, the displays flickers briefly as if it's doing the calculations and a 'Pour panel' briefly shows, the panel is part of the new Fusion interface .

Now that you have me thinking about what I see I'm wondering if the 'Pour', being the rectangle of the PCB outline needs to be defined
BEFORE the ulp can generate the Gcode? In which case the Pour panel which has the choice data needs to be active BEFORE the ulp runs?

Craig


From: pcbgcode@groups.io <pcbgcode@groups.io> on behalf of John Johnson <john@...>
Sent: Thursday, 30 July 2020 10:28 AM
To: pcbgcode@groups.io <pcbgcode@groups.io>
Subject: Re: [pcbgcode] PCB-Gcode in Fusion 360 #pcbgcode
 
What does the screen look like when the etch files are being created? Do you still see the progressive outlines around the tracks?


On Jul 29, 2020, at 5:23 PM, joeaverage <joe.average@...> wrote:

Hi,
I have used PCB-Gcode extensively with EAGLE over a number of years but have recently decided to migrate to Fusion 360.
The electronics/PCB package is very closely related to EAGLE and I have found that it is  as easy to use after adjusting to the new interface.

With Fusion all your projects are stored on the cloud, whereas with EAGLE they are stored on your local hard-drive. While there are a number
of ulp's on the cloud pcb-gcode is not among them. It is intended (by Autodesk) that such a ulp will be stored locally.

I have loaded the pcb-gcode ulp to the Doucuments/Fusion360/ulps (on my local PC) file which is provided for use. I have been
able to run the ulp and it generates the required files but the top.etch and bot.etch files are empty despite the .drill and .mill files
being complete with comments, line numbers and compliant Gcode.

Can anyone suggest a reason that good .dill and .mill files are produced but not .etch files?

Craig

Re: PCB-Gcode in Fusion 360 #pcbgcode

John Johnson
 

That's correct. The pour works like a ground plane pour, isolating itself from existing tracks by some increasing amount. The pour is then processed as polygonal line segments by pcb-gcode to generate the g-code movements for mechanical etching.
If the pour isn't happening, the whole process fails.

Regards,
John

On Jul 29, 2020, 8:33 PM -0400, joeaverage <joe.average@...>, wrote:
Hi,

"What does the screen look like when the etch files are being created? Do you still see the progressive outlines around the tracks?"

No, the displays flickers briefly as if it's doing the calculations and a 'Pour panel' briefly shows, the panel is part of the new Fusion interface .

Now that you have me thinking about what I see I'm wondering if the 'Pour', being the rectangle of the PCB outline needs to be defined
BEFORE the ulp can generate the Gcode? In which case the Pour panel which has the choice data needs to be active BEFORE the ulp runs?

Craig


From: pcbgcode@groups.io <pcbgcode@groups.io> on behalf of John Johnson <john@...>
Sent: Thursday, 30 July 2020 10:28 AM
To: pcbgcode@groups.io <pcbgcode@groups.io>
Subject: Re: [pcbgcode] PCB-Gcode in Fusion 360 #pcbgcode
 
What does the screen look like when the etch files are being created? Do you still see the progressive outlines around the tracks?


On Jul 29, 2020, at 5:23 PM, joeaverage <joe.average@...> wrote:

Hi,
I have used PCB-Gcode extensively with EAGLE over a number of years but have recently decided to migrate to Fusion 360.
The electronics/PCB package is very closely related to EAGLE and I have found that it is  as easy to use after adjusting to the new interface.

With Fusion all your projects are stored on the cloud, whereas with EAGLE they are stored on your local hard-drive. While there are a number
of ulp's on the cloud pcb-gcode is not among them. It is intended (by Autodesk) that such a ulp will be stored locally.

I have loaded the pcb-gcode ulp to the Doucuments/Fusion360/ulps (on my local PC) file which is provided for use. I have been
able to run the ulp and it generates the required files but the top.etch and bot.etch files are empty despite the .drill and .mill files
being complete with comments, line numbers and compliant Gcode.

Can anyone suggest a reason that good .dill and .mill files are produced but not .etch files?

Craig

Re: PCB-Gcode in Fusion 360 #pcbgcode

joeaverage
 

Hi, 
I have been experimenting trying to find a solution to the empty .etch files, to no avail as yet.

I have tried making a rectangular pour, both top and bottom sides, without any change, namely strangely
empty .etc files but complete and intact .drill and .mill files.

I presume that the ulp actually runs on the local PC. Only when the project is saved does it get saved to the cloud.
Thus the generated files (.drill, .mill,.top.etch and.bot.etch) get saved to a temporary file on the local hard drive
until or unless the contents of the file is uploaded to the cloud.
The path to the files is reasonably torturous:
C:\Users\User\AppData\Local\Temp\Neutron\ElectronFileOutput\2bc73b8b-e893-4770-9b65-71cfe347664d

The fact that the .drill and .mill files are present and correct after running pcb-gcode suggests that the ulp can navigate
to the required location and create/update the files there. Is it feasible that the potentially much larger .etch files
cannot be created/updated at the location above?

Rather than dig down to the location I would like to save the generated Gcode files in the Documents/Fusion360 file or a subfolder
of it. How would I go about modifying the file path in the setup page?

Craig


From: pcbgcode@groups.io <pcbgcode@groups.io> on behalf of joeaverage <joe.average@...>
Sent: Thursday, 30 July 2020 12:33 PM
To: pcbgcode@groups.io <pcbgcode@groups.io>
Subject: Re: [pcbgcode] PCB-Gcode in Fusion 360 #pcbgcode
 
Hi,

"What does the screen look like when the etch files are being created? Do you still see the progressive outlines around the tracks?"

No, the displays flickers briefly as if it's doing the calculations and a 'Pour panel' briefly shows, the panel is part of the new Fusion interface .

Now that you have me thinking about what I see I'm wondering if the 'Pour', being the rectangle of the PCB outline needs to be defined
BEFORE the ulp can generate the Gcode? In which case the Pour panel which has the choice data needs to be active BEFORE the ulp runs?

Craig


From: pcbgcode@groups.io <pcbgcode@groups.io> on behalf of John Johnson <john@...>
Sent: Thursday, 30 July 2020 10:28 AM
To: pcbgcode@groups.io <pcbgcode@groups.io>
Subject: Re: [pcbgcode] PCB-Gcode in Fusion 360 #pcbgcode
 
What does the screen look like when the etch files are being created? Do you still see the progressive outlines around the tracks?


On Jul 29, 2020, at 5:23 PM, joeaverage <joe.average@...> wrote:

Hi,
I have used PCB-Gcode extensively with EAGLE over a number of years but have recently decided to migrate to Fusion 360.
The electronics/PCB package is very closely related to EAGLE and I have found that it is  as easy to use after adjusting to the new interface.

With Fusion all your projects are stored on the cloud, whereas with EAGLE they are stored on your local hard-drive. While there are a number
of ulp's on the cloud pcb-gcode is not among them. It is intended (by Autodesk) that such a ulp will be stored locally.

I have loaded the pcb-gcode ulp to the Doucuments/Fusion360/ulps (on my local PC) file which is provided for use. I have been
able to run the ulp and it generates the required files but the top.etch and bot.etch files are empty despite the .drill and .mill files
being complete with comments, line numbers and compliant Gcode.

Can anyone suggest a reason that good .dill and .mill files are produced but not .etch files?

Craig

Re: PCB-Gcode in Fusion 360 #pcbgcode

Jonathan Lockhart
 

Thanks Craig, I will give that a try again. I previously installed and posted about it not running but I think I may have been on the temp folder not documents. I will let you know the results and send any pics I have.

Regards,
Jon

On Wed, Jul 29, 2020, 8:47 PM joeaverage <joe.average@...> wrote:
Hi,

"
How'd you get that to run in Fusion? I installed it to the ULP folder and when I run it I get a blank pop up window. Using the latest version of Fusion on Win10."

I downloaded a fresh copy of the zipped pcb-gcode file direct from Autosoft and installed the entire (un-zipped) contents in the Documents/Fusion360/ulps file.

When running Fusion Electronics Design go to the 'Automate' tab, select the orange "RunULP' icon. Select the local directory (Documents) rather than the Temp folder to which
the cloud based ULPs are loaded to, by the drop down selection. Select pcb-gcode-setup and run.

Craig



From: pcbgcode@groups.io <pcbgcode@groups.io> on behalf of Jonathan Lockhart <jlockhartrt@...>
Sent: Thursday, 30 July 2020 10:37 AM
To: pcbgcode@groups.io <pcbgcode@groups.io>
Subject: Re: [pcbgcode] PCB-Gcode in Fusion 360 #pcbgcode
 
Craig,

How'd you get that to run in Fusion? I installed it to the ULP folder and when I run it I get a blank pop up window. Using the latest version of Fusion on Win10.

Regards,
Jon


On Wed, Jul 29, 2020, 6:29 PM John Johnson <john@...> wrote:
What does the screen look like when the etch files are being created? Do you still see the progressive outlines around the tracks?


On Jul 29, 2020, at 5:23 PM, joeaverage <joe.average@...> wrote:

Hi,
I have used PCB-Gcode extensively with EAGLE over a number of years but have recently decided to migrate to Fusion 360.
The electronics/PCB package is very closely related to EAGLE and I have found that it is  as easy to use after adjusting to the new interface.

With Fusion all your projects are stored on the cloud, whereas with EAGLE they are stored on your local hard-drive. While there are a number
of ulp's on the cloud pcb-gcode is not among them. It is intended (by Autodesk) that such a ulp will be stored locally.

I have loaded the pcb-gcode ulp to the Doucuments/Fusion360/ulps (on my local PC) file which is provided for use. I have been
able to run the ulp and it generates the required files but the top.etch and bot.etch files are empty despite the .drill and .mill files
being complete with comments, line numbers and compliant Gcode.

Can anyone suggest a reason that good .dill and .mill files are produced but not .etch files?

Craig

Re: PCB-Gcode in Fusion 360 #pcbgcode

joeaverage
 

Hi,

"
How'd you get that to run in Fusion? I installed it to the ULP folder and when I run it I get a blank pop up window. Using the latest version of Fusion on Win10."

I downloaded a fresh copy of the zipped pcb-gcode file direct from Autosoft and installed the entire (un-zipped) contents in the Documents/Fusion360/ulps file.

When running Fusion Electronics Design go to the 'Automate' tab, select the orange "RunULP' icon. Select the local directory (Documents) rather than the Temp folder to which
the cloud based ULPs are loaded to, by the drop down selection. Select pcb-gcode-setup and run.

Craig



From: pcbgcode@groups.io <pcbgcode@groups.io> on behalf of Jonathan Lockhart <jlockhartrt@...>
Sent: Thursday, 30 July 2020 10:37 AM
To: pcbgcode@groups.io <pcbgcode@groups.io>
Subject: Re: [pcbgcode] PCB-Gcode in Fusion 360 #pcbgcode
 
Craig,

How'd you get that to run in Fusion? I installed it to the ULP folder and when I run it I get a blank pop up window. Using the latest version of Fusion on Win10.

Regards,
Jon


On Wed, Jul 29, 2020, 6:29 PM John Johnson <john@...> wrote:
What does the screen look like when the etch files are being created? Do you still see the progressive outlines around the tracks?


On Jul 29, 2020, at 5:23 PM, joeaverage <joe.average@...> wrote:

Hi,
I have used PCB-Gcode extensively with EAGLE over a number of years but have recently decided to migrate to Fusion 360.
The electronics/PCB package is very closely related to EAGLE and I have found that it is  as easy to use after adjusting to the new interface.

With Fusion all your projects are stored on the cloud, whereas with EAGLE they are stored on your local hard-drive. While there are a number
of ulp's on the cloud pcb-gcode is not among them. It is intended (by Autodesk) that such a ulp will be stored locally.

I have loaded the pcb-gcode ulp to the Doucuments/Fusion360/ulps (on my local PC) file which is provided for use. I have been
able to run the ulp and it generates the required files but the top.etch and bot.etch files are empty despite the .drill and .mill files
being complete with comments, line numbers and compliant Gcode.

Can anyone suggest a reason that good .dill and .mill files are produced but not .etch files?

Craig

Re: PCB-Gcode in Fusion 360 #pcbgcode

joeaverage
 

Hi,

"What does the screen look like when the etch files are being created? Do you still see the progressive outlines around the tracks?"

No, the displays flickers briefly as if it's doing the calculations and a 'Pour panel' briefly shows, the panel is part of the new Fusion interface .

Now that you have me thinking about what I see I'm wondering if the 'Pour', being the rectangle of the PCB outline needs to be defined
BEFORE the ulp can generate the Gcode? In which case the Pour panel which has the choice data needs to be active BEFORE the ulp runs?

Craig


From: pcbgcode@groups.io <pcbgcode@groups.io> on behalf of John Johnson <john@...>
Sent: Thursday, 30 July 2020 10:28 AM
To: pcbgcode@groups.io <pcbgcode@groups.io>
Subject: Re: [pcbgcode] PCB-Gcode in Fusion 360 #pcbgcode
 
What does the screen look like when the etch files are being created? Do you still see the progressive outlines around the tracks?


On Jul 29, 2020, at 5:23 PM, joeaverage <joe.average@...> wrote:

Hi,
I have used PCB-Gcode extensively with EAGLE over a number of years but have recently decided to migrate to Fusion 360.
The electronics/PCB package is very closely related to EAGLE and I have found that it is  as easy to use after adjusting to the new interface.

With Fusion all your projects are stored on the cloud, whereas with EAGLE they are stored on your local hard-drive. While there are a number
of ulp's on the cloud pcb-gcode is not among them. It is intended (by Autodesk) that such a ulp will be stored locally.

I have loaded the pcb-gcode ulp to the Doucuments/Fusion360/ulps (on my local PC) file which is provided for use. I have been
able to run the ulp and it generates the required files but the top.etch and bot.etch files are empty despite the .drill and .mill files
being complete with comments, line numbers and compliant Gcode.

Can anyone suggest a reason that good .dill and .mill files are produced but not .etch files?

Craig