Cannot Export PCB files??

[zigzag2015]

Hi,

I have for some years exported Fusion PCB files to EAGLE that I can further process it. Today I find that the option to export in an EAGLE format is no longer an option. I can export a Fusion file format but thats no good within EAGLE.

I last used this option just this morning. Whats changed?

Craig

[jorge_garcia]

Hi @zigzag2015 ,

We are actually using the contour methods for this, and the results so far are promising. We want to make sure we have a full solution before getting back to you. You can create templates for generating the GCODE in the machining environment, so once you have the template right you can generate the GCODE with only a few clicks. 

The GCODE ULP as awesome as it is was not made by us, so the user could chose to update it to conform to Fusion. The polygon implementation within Fusion is wildly different from EAGLE. When we export to EAGLE we just use EAGLE's functions to generate the polys so no extra effort there. The advantage of Fusion's implementation is that you no longer have the resolution trade off that comes from a rastered polygon.

Generating the GCODE in Fusion, is just about getting the setup right and then making a couple of templates. Once you have those you can generate the Gcode quickly. That's what we are trying to refine.

In the meantime, what type of drills do you use and what specific milling machine do you use? We are trying to get as close to the files you sent us as possible.

Let me know if there's anything else I can do for you.

Best Regards,

[zigzag2015]

Hi Jorge,

'We are actually using the contour methods for this, and the results so far are promising.'

I have tried and found it extremely time consuming whereas pcb-gcode was flawless and seamless.

'The GCODE ULP as awesome as it is was not made by us, so the user could chose to update it to conform to Fusion.'

Well, yes, that's what made it a User Language Program after all. The problem is that Autodesk have changed EAGLE in a way that is to my knowledge not published.....so how would a user modify the ULP?  I'm not an especially strong programmer, so while the source of pcb-gcode is available it is not likely that I can re-program it, whereas a software development team such as Autodesk could. The second issue is that many thousands of EAGLE users have been using pcb-gcode, and thus I contend that Fusion Electronics should confirm to that, not the other way around. That is pure arrogance on behalf of Autodesk....'We bought it, therefore we can do as we like with it without worrying about existing users'.

This is exactly the attitude that so many potential Fusion customers stay away from Autodesk.....Autodesk is seen as rapacious and impervious to customer requests. You play the big game, providing a forum, providing experts to answer queries, and credit to Autodesk....but in this instance you have left pcb-gcode users behind.

You have, to give you your due, made an attempt to provide an alternative with the regular Contour tool path generation method, but it is way substandard to my knowledge.

In the three or four years I've subscribed to Fusion I have asked repeatedly about resurrecting pcb-gcode and the only substantive response is what you cannot or will not do rather than a solution.

As I posted earlier I need a solution, either pcb-gcode or something very close to it. If Autodesk refuse to do so, then I have no choice to migrate to another PCB solution.

Craig

[zigzag2015]

Hi, this is what I mean. When I try to mill the 3d PCB I have to painfully select every single isolated feature. I applied a Roughing pass of three passes of 0.1mm stepover, and in some cases the passes have been generated and yet other places not. The warning is that a pass would not generate due to the lead parameters interfering with an adjacent feature. Well nots not very helpful with a PCB with many close adjacent features is it? Last complaint is that there is an island of contiguous copper, but Fusion decides that the tool path should mill straight through it on the lines of the trace that pass through it.

It gets worse. The second pic of of the same board but with 10 passes of 0.1mm....now see that in some cases the 10 passes have been generated but now some adjacent features are not isolated at all. A board of using this would not be just plain faulty or inconsistent but a TOTAL FAILURE.

The heights have to be selected, the lead parameters have to be selected....so even a faulty toolpath FOR THIS ONE LAYER is going to take half an hour or more. Then there is the other layers like a drill file and a milling file.

[zigzag2015]

Hi, 

as a further critique, I have used a Gcode simulator to display the toolpath passes as generated by pcb-gcode. The settings used are tool diameter 0.18mm,

stepover 0.09mm and target isolation of 1mm. Note that these parameters are very carefully chosen and a result of considerable experiment. My minimum

distance between features (design rule) is 0.2mm. Thus in order for the two features to be isolated then the tool diameter must pass between the two, and thus be smaller than the minimum distance between them....ergo 0.18mm. The stepover is 50%, this ensures the complete removal of copper and has proven to be very useful. I could probably increase the stepover to 75% or 80% but I prefer reliability of isolation over shortest possible toolpath. 

With the parameters set it requires 10, maybe 11 passes to achieve the desired 1mm isolation. Note how pcb-gcode seamlessly increases/decreases the number of passes in a manner to do this without compromising the integrity of an adjacent feature which could be well within the desired isolation distance but still legal under the 0.2mm design rule.

The second pic is the exact same piece of the exact same board but generated by Fusion Contour with the same tool parameters. Aside from the very slow selection process of each individual trace; note how when two traces are close together, in the are highlighted about 0.28mm apart, but within the design rules Fusion does no isolate them at all, and that in other areas it leaves a void where there SHOULD be tool path passes.

It seems that Fusion Contour has a hard time, and in fact fails, to produce a  good toolpath where a roughing pass well removed from the trace or feature would intersect a tool path pass from another adjacent feature.

Craig

[zigzag2015]

Hi, Ok I've made a few discoveries that may assist in getting to a solution.

In pcb-gcode the first pass is always one half the tool diameter away from the trace boundary. Successive passes are one or more stepovers away from that boundary. Compare that to how Fusions Contour works. If you specify a certain number of roughing passes, lets say 5, then the first path is 5 times the stepover away from the trace boundary. Successive paths get closer to that boundary with the final path one half the tool diameter from it, ie the trace is formed and isolated.

Fusion isolates from the outside inwards whereas pcb-gcode isolates from inside outwards.

Where Fusion is going wrong is that if it encounters geometry that it has to respect at the first pass then the toolpath describes a path that respects that geometry but was not in fact part of the geometry you intended but is a part of an adjacent feature.

As proof Fusions Contour works OK if you have NO roughing passes, or alternately the closest but separate feature is further than the number of roughing passes you have specified then it too works fine. For instance Fusions Contour works OK and predictably when either no roughing passes, or one roughing pass is commanded but at two roughing passes it fails.

At two roughing passes it encounters an adjacent trace, and it obediently generates a toolpath around both the trace that we hoped was to be isolated but also the adjacent trace.

By making this observation I can start to make sense of what I had previously considered 'garbage' that Fusion was generating. That does not in itself solve the problem, but at least understanding how and why a function is not performing as you want is as least a step closer to solving it.

The first thing  I tried was to set a negative value for stepover for each roughing pass. Fusion refused. The idea was to have Fusion generate toolpaths from the trace outwards much as pcb-gcode does.

As I posted earlier in this thread pcb-code works by generating a tool path pass and the ADDING that pass into the geometry of the trace. Then it will generate a new and somewhat larger tool path using the enlarged geometery.

Could Fusion be induced to do the same thing? It seems for instance that if Fusion Contour does not use any Roughing passes it performs perfectly well. Could we therefore generate the first tool path then add that extra cut width to the geometry of the trace, and then generate a second tool path using the same

parameters on the enlarged geometry?

This would mean that Fusion would cut from the trace outwards and that replicates how pcb-gcode does it.

Craig

[jorge_garcia]

Hi @zigzag2015 ,

Just to add to Seth's response. You mention the polygon change not being documented but it has been documented. In essence, in EAGLE there's only one polygon ULP object. For the improved version in Fusion this has become 3 different objects. The important one for the G-CODE ulp is this one

https://help.autodesk.com/view/fusion360/ENU/?guid=ECD-ULP-POLYPOUR

If the developer is interested in updating the ULP the above page would help. Here are the other 2 type doc pages just for completeness.

https://help.autodesk.com/view/fusion360/ENU/?guid=ECD-ULP-POLYSHAPE

https://help.autodesk.com/view/fusion360/ENU/?guid=ECD-ULP-POLYCUTOUT

Let us know if Seth's workflow works for you.

Best Regards,

[zigzag2015]

Hi,

I have experimented with the procedure you have outlined, and while time consuming I have  gotten some good toolpaths.

I had previously tried having a vertical lead in only, but found that it excites the 'bug' in Fusion also. The Ramp lead in is the solution.

Second issue I battled with for a while is that often the pads, vias, traces and polys are often slightly different heights and therefore occur as separate bodies which in turn means that when selecting via the Silhouette method results in multiple sections whereon Fusion tries to isolate a trace from its pad for instance. The trick I was missing was to find just the one body that included all the pads, traces, vias etc, and thereafter Fusion Contour works as expected.

This method, even with a template is still quite time consuming. I expect that with more practice I can refine the template/templates to do better. The issue is that to machine one board requires four files, a TopEtch, BottomEtch, BottomDrill and BottomMill file, each requiring a separate template. Is it possible to write a script or macro to automate those procedures?.

There is another issue that has cropped up. 

My normal workflow is to using Fusion CAD to draw the required PCB, including mounting holes, cutouts etc. That 2d sketch is then used to generate a PCB, and that PCB is linked to the Electronic design. This works fine. There is however a few items which may well be milled into the board but are not included in the original sketch. For instance the edge connector I use. Its final location is determined as I design the PCB, not in the original sketch, and thus the milling associated with that component is not available in the board outline and I cannot use Fusion Contour to generate that part of the tool path.

Is it possible to force Fusion to have another layer, in particular layer 46, the milling layer in its 3D view? That would mean that I have some geometry that comes from the PCB design rather than the original Fusion sketch. I see for instance the top and bottom silk screens are available as named views in the 3D view of the PCB....so could the milling layer be similarly generated?

Craig

[LMerchell_1]

Hi,

Regarding "For the improved version in Fusion this has become 3 different objects.", is this why the Export to Eagle does not work for polygon cut-outs?

Larry

[zigzag2015]

Hi,

I think I have found a solution to not having geometry for the PCB milling file. 

If I draw, in the 2D PCB design the additional geometry using layer 20, BoardOutline, the shape of the component milling, that in turn gets pushed to the 3D PCB, which can in turn be milled using Fusion Contour. That in turn means that drawing layer 46, Milling, is now redundant.

Still, to date, I have not been able to generate templates that shorten the time taken to get good Gcode files to match the speed and efficiency of PCB-Gcode but I can see there are some advantages conferred by Fusion Contour. 

In particular PCB-Gcode always produced tool paths as a series of passes, where all geometry of pass four, lets say, needs be completed before any of pass five is

cut and would thus spend considerable machining time traversing from one feature to the next. Contour on the other hand starts at one feature and works through to its completion which bodes well for machining times. In a similar manner when generating the drill files PCB-Gcode would go from one hole to the next on its own algorithm and very often was far from the most efficient of paths, whereas Fusion contour uses a much more efficient path between holes. 

I never had any luck with using PCB-Gcode drill files that allowed for multiple drill sizes, despite perhaps being capable of it. The solution I've used for some years now is just to drill ALL holes with just one 1mm drill bit. It may be necessary to manually drill some to a larger size, but they are always few and did not represent a burden. Fusion Contour however allows the easy selection of different sized drills, and now that I have an ATC spindle I can now seamlessly use two, three or more drill sizes.

So, while my throughput per hour has taken a sizable hit by using Fusion Contour by comparison to PCB-Gcode, there are some advantages to offset the disadvantage. I'm rather hoping that with more practice, tuning of templates and possibly some scripting I can regain some of the time penalty.

Craig

[zigzag2015]

Hi,

well I'm running a board now and while the cutting order is strange to my eye, it is working. Further, I would guess the file size is reduced by about  one third and so has the runtime. All good.......but.......I use Autoleveller, and the Gcode produced by Fusion Contour and Mach4 Post is incompatible with it. The Gcode I'm running now is just the Gcode direct from the Post, and that is Mach4 compliant and is running fine.

Autoleveller is a freeware software utility that allows you to probe a PCB (vertically) and that data is then used to 'massage' the Z height of an Isolation Routing Gcode file.

If you've ever tried milling a PCB you'll know that getting and maintaining cut depth is absolutely critical. 10um too low and you dig into the fibreglass, 10um too high and the copper is not cut. Then add to that; that most PCB blank material has subtle bows and warps often in the tens if not hundreds of um. Autoleveller sorts that out. It is the ONLY way I've ever been able to hold tolerances close enough to use 0.2mm traces, 0.2mm between features etc. In absence of Autoleveller you are required to increase the cut depth to the extent that the very fine traces disappear altogether.

The downside is that Autoleveller cannot process arcs ie G2's and G3's, it requires Gcode composed entirely of G1's and G0's.

The attached pic is of the board that I have just run. Note that the traces (on this particular board) are supposed to be 0.6mm. In fact they are not, in most cases

down to about 0.4mm to 0.3mm. This is because I deliberately nominated a somewhat deeper cut than is ideal, but that was imposed on me by NOT being able to use Autoleveller. None the less the board is well isolated and therefore when complete, that is to say the bottom side trace isolation routed, the holes drilled and the board periphery milled it will be a saleable board.....and it is one that I make a few of so it will be populated and sold.

This certainly proves Seth's and Jorge's contention that it is possible to mill boards with Fusion and in fact does a stellar job. That it works as well as it does is a great relief to me, I needed a solution to EAGLE disappearing, to the extent that I would migrate to some other solution if I had to, not because I want to. Fusion has proven to be extremely useful to me, and a stand-out in terms of cost competetive terms.

So, the next question is is there any way I can impose on Fusion contour to produce Gcode that does not contain arcs, but rather short line segments.....as that is the style that Autoleveller can use?. I'd really rather of course use Fusions output as is, it is efficient and fast.....but without Autoleveller I just cannot guarantee well isolated boards.

Craig

[seth.madore]

It's absolutely possible to have Fusion produce code that outputs only G1 moves. Take the Mach4 post processor and copy the post to either your cloud or a local spot on your computer and then edit this line:

allowedCircularPlanes = undefined; // allow any circular motion

Change it to:

allowedCircularPlanes = 0; // do not allow any circular motion

This will eliminate all G2/G3 moves and only give you G1's

[zigzag2015]

Hi Seth,

that worked just fine, but I'm still not out of the woods.

After editing the Mach4 Post I get Gcode without G2/G3 and that's fine, adds somewhat to the file size, but that's neither here nor there.

The resulting Gcode (from Fusion) has a moderate number of lines that terminate in a decimal point. This causes no issue, my Mach4 CNC solution parses the gcode just fine, generates the tool path and runs it. In a gcode file of 1Mb, there may be several hundred or even thousands of such lines, way too tedious to track down and edit manually

If however I run the gcode through Autleveller (which also has trailing decimal points) the code does not parse, nor generate a tool path, nor run.......and yet there is to my eye no difference between the two??? The only thing I can think of is that there is a difference in one or more of the hidden control characters?

I've spent all of yesterday investigating to see if I could find some reason.

I have written a script that removes the offending trailing decimal points, and thereafter the code runs fine. Autoleveller leaves the trailing decimal point in the exact same place that Fusion left them. So I have two choices, either remove the trailing decimal points from Fusion THEN process through Autoleveller OR remove the trailing decimal points from the Autoleveller output file......either seems to work.

So I have a solution to 'clean up' but is an extra step that I want to avoid. Is it possible to modify the Autodesk supplied Fusion Mach4 Post such that the gcode does not have any trailing decimal points.? Can you think of any reason that while a Fusion generated  gcode file (with some trailing decimal points) will load and run in Mach4 while the same file processed by Autoleveller with exactly the same trailing decimal points does not?

[seth.madore]

Yes, it is possible to remove the trailing decimal points from the Mach 4 post. As to why manually removing them and running thru AutoLeveler doesn't work, I honestly couldn't say, it's not a software I've ever heard of before this conversation 🙂

[LMerchell_1]

Hi,

Regarding "For the improved version in Fusion this has become 3 different objects.", is this why the Export to Eagle does not work for polygon cut-outs?

Larry

[seth.madore]

And to edit your Mach4 post, change var xyzFormat to this:
 var xyzFormat = createFormat({decimals:(unit == MM ? 3 : 4), type:FORMAT_INTEGER});

And then do so likewise for the feedrate:

var feedFormat = createFormat({decimals:(unit == MM ? 0 : 1), type:FORMAT_INTEGER});

[zigzag2015 · Accepted solution]

Hi Seth,

that appears to have solved it. The F word no longer has a trailing decimal point, and that seemed to cause issues.

I made a discovery late yesterday that was causing grief. As I've posted if I were to load the Fusion/Mach4 post output directly then it would load and run whereas if I further processed the code with Autoleveller the code would not be compliant, and damned difficult to see why. I did in the end find a fault.

Autoleveller is a Java program that generates a GCode probing routine for the board de-jour, and once that board is probed (for vertical variations in height

to within um) it 'massages' the original code to accommodate those height variations, and anyone whom has made PCB's by this method will swear its the only way it can be done successfully.

If Autoleveller encounters a straight G1 cutting move longer than 5mm (actually the distance is programmable) it breaks it into 5mm segments, and applies the required height correction to each segment. Thus the Autoleveller processed Gcode will have more lines than the original Gcode file. As it turns out every once in a while the algorithm that breaks the line into segments would generate an X value that had two decimal points, and that would cause Mach4 to baulk....and not surprisingly. It also describes why the original Fusion/Mach4 Post code runs but the Autoleveller processed code does not.

For example:

G1 X50.8976. Y23.654.......where the second decimal point of the X value is a fault.

I did write a script to remove the offending decimal point from such occurrences, usually as few as two or three in a 600kB file. After processing with my script the code runs fine. 

The solution you have given (edit of the Fusion Mach4 post) means that I do not have to use my script.....and that is what I was hoping for.

The upshot is that I have a solution to generate GCode for milling circuit boards WITHOUT relying on EAGLE for the ULP. Even with  templates it does take quite a bit of extra work compared to PCB-Gcode, about 15 to 20 minutes per design which is not ideal, but given that many of the PCBs I do make take an hour or so to machine: its not an excessive burden.

Craig

[jorge_garcia]

Hi @zigzag2015 ,

This has been one of the most interesting threads I've ever participated on. So happy that with @seth.madore expertise we were able to get to a solution. 

I intend to see if I can make some good documentation around this process so that others can benefit. With that said there are a few loose ends I want to make sure are tied on the electronics side.

1) The new polygon objects is why the old GCODE ulp doesn't function in Fusion. The ULP would have to updated to switch from the old polygon ULP objects to the new ones. Given the complexity of the ULP, this update is likely not trivial.
2) Fusion has a Python API, so you may be able to script the templates getting run which may save you some time. @seth.madore Please correct me if I'm off base on this.
3) You've already figured out that your milling contours were superfluous, but besides that they were also not properly implemented in this PCB. As you noted for the board contour everything needs to be on the BoardOutline layer. That outside board edge needs to be one contour, for edge connectors it can be beneficial to include the board outline features as part of the component. These days milling contours are relegated to making special slots within pads for custom slotted pad shapes.

Let me know if you have any other questions or if there's anything else we can do for you.

Best Regards,

[zigzag2015]

Hi Jorge,

I think what I really need to do now is just use this new method. Experience will soon tell what is a bottleneck and what is not.

I think in time to come I may wish to find out more about templates, in particular what is included and what is not. As far as I can tell a template is for a particular operation, say Contour or Adaptive. 

I was thinking along the lines of a Setup being covered by a template. For instance I now have an edited Mach4 post that is used for just isolation routing of PCBs but don't not want that particular post used for anything other than that. That would be a useful addition to a template that defines the parameters of a setup rather than a toolpath like Contour.

Craig

[lmerchellP2N5U]

Hi,

Regarding "For the improved version in Fusion this has become 3 different objects.", is this why the Export to Eagle does not work for polygon cut-outs?

Larry