Planar surface DXF export misses features

tom_oinn

Hi,

I have a model with some fairly complex geometry. If I select a planar face and use the 'export to DXF / DWG' option to build a DXF file for our laser cutter the resultant file has a lot of line segments which are either in the wrong place or are missing entirely. Some faces export okay, some are completely broken with less than half the lines they should have. Obviously this is a bit of an issue! Any ideas?

Specifically in https://cad.onshape.com/documents/c59feeabb1ca4d06a1137866/w/fc05b3e9c12d4886a69af567/e/555a890c25e24dd89163f00b the corner plate (within each pylon) and the platform parts do not export successfully. 

Tom

tom_oinn

On closer inspection this isn't actually an onShape issue, the software I use on the laser (LaserCut5.3) can't handle the new DXF format. This is a problem though, are there any plans to support earlier DXF formats, or at least to provide information on which format is used?

tom_oinn

Specifically the issue is the inclusion of splines in the DXF file, LaserCut can't handle these and needs them converted to polylines before import.

tom_oinn

Okay - if anyone else is trying to do this, here's a horrific hack. Export as DXF. Load into SolidWorks eDrawings. Print to PDF (yeah yeah I know). Import PDF into Inkscape. Reset line widths to 0, fix dimensions. Save from Inkscape as DXF R14. Laser cut parts while swearing at computers in general.

You can see why I'd like an option in OnShape!

andrew_troup

In earlier times the output of dxfs from an  Onshape sketch used a dxf/dwg version which was unnecessarily modern (2013), but according to this thread, this was addressed some time ago: 

https://forum.onshape.com/discussion/562/export-of-2d-profiles-from-ons-version

The version was rolled right back to R11

However Help does not specify this: I have raised a ticket to clarify the latter issue.

A quick search of the forum brought up this recent topic, but it's a slightly different question (Drawing export for CNC)
https://forum.onshape.com/discussion/comment/11001#Comment_11001

andrew_troup

For others seeking to do this in the meantime, a Google search on "convert splines to polylines" describes how it can be easily done in Autocad, using the SPLINEDIT command

For those to whom paying for Autocad products would be like making campaign contributions to a political party whose policies you dislike, here's a video on doing the same in Draftsight (free knock-off of Autocad)

https://www.youtube.com/watch?v=ybLfrCpR0Mc

tom_oinn

Thanks - that (using Draftsight) would be a shorter loop. I note that it's not only the relatively elderly LaserCut5.3 software that can't handle the generated DXFs though, Inkscape can't import either (exactly the same issues apply). Sure, Inkscape isn't a CAD package but it's what a *lot* of our members use with our laser cutters.

This might not sound like a big deal, as you say there are ways around it and the files clearly do contain the information, but my experience of UK hackspaces is that we pretty much all have the same laser cutters, and they're one of the most used pieces of equipment in our space. Given our hackspace here in Cambridge has 260 members, and by the time you add other spaces just in the UK with this kind of cutter you're talking about thousands of potential users who would find this an unreasonable burden.

There are some other tweaks and new features which would make our lives much easier, I'll describe them in a new thread though.

Tom

andrew_troup

Is there a good reason for a portion of that community to use Inkscape, and a strong disincentive for them to use something else?

Polylines are really a kludge arising from computational limitations from the fairly distant past, and I think it would take a strong case (and, realistically, one from paying users) to persuade anyone to carry that kludge further than strictly necessary into the future.

Not to say this won't happen: consider qwerty keyboards and derailleurs....
(not that they are great advertisements for the practice)

tom_oinn

Inkscape isn't the issue, I mention it because it was the first thing I used when testing whether the problem was in Onshape or elsewhere. We do suggest that people use it for the laser because it (unlike Onshape at present) can export files which the laser software can read, and because it's easy to use. Sure, it's not proper CAD software but it's friendly, well supported and good enough for most use.

I agree that a spline is a better way to represent a curve, that's self evident. It doesn't, however, help those of us who've invested thousands of pounds in laser cutters where the software cannot handle splines. Many packages provide an option to render splines to polylines (it's a staple computer graphics algorithm, not rocket science). At Makespace we've invested something like twenty thousand pounds in laser cutter hardware, believe me, we're happy to pay for software if it works! 

I think it's a mistake to assume that hackspace members aren't potential paying customers - we've had six startups from Makespace that I'm aware of over the last year, I get most of my consultancy income through contacts there. Our members include CTOs of nearby SMEs who use the facilities to prototype products, venture capitalists, etc. It's not just kids with arduinos (although we have plenty of those too!)

tom_oinn

Right, I've done some DXF delving and I now know why Inkscape and LaserCut don't like the file generated from Onshape.

It's actually nothing to do with splines, the files Onshape produces are R12 DXF compliant so can't contain splines even if they wanted to! It's related to the centre points of CIRCLE and ARC entities within the DXF.

DXF coordinates are three dimensional. For most CAM or drawing output, the Z coordinate of all points is normally set to 0. Onshape's exported DXF files, however, do not do this. The Z coordinate of all ARC and CIRCLE centres (I've not checked other coordinates but I imagine the same issue may arise) are set to +A and -A seemingly at random, where 'A' is a number that varies, I'm not sure why or what it is, but it's set to the same value for every centre in a given DXF file.

I can't find a defined meaning for this, but I have found that if I check this Z value, and *if negative* mirror ARC and CIRCLE centre coordinates in the Y axis of the DXF file, including resetting ARC start and end angles correspondingly, then the file imports into Inkscape as I'd expect (and, as Inkscape and Lasercut were behaving the same way, I assume it'll import into our cutting software).

Other software has either figured out the same workaround, or has more clue than I do about what this is actually meant to be specifying, but for my purposes the following Python script converted a file into something I could use:

import ezdxf

dwg = ezdxf.readfile("tri2.dxf")

def flatten(c):

  (x,y,z) = c

  return (x*z/abs(z), y, 0)

def mirror(a):

  a = 180-a

  if a < 0:

    a = a+360

  return a

for e in dwg.entities:

  if e.dxftype()=="CIRCLE":

    e.dxf.center = flatten(e.dxf.center)

  elif e.dxftype()=="ARC":

    (x,y,z) = e.dxf.center

    if z < 0:

      start_angle = e.dxf.start_angle

      end_angle = e.dxf.end_angle

      e.dxf.start_angle = mirror(end_angle)

      e.dxf.end_angle = mirror(start_angle)

    e.dxf.center = flatten(e.dxf.center) 

dwg.saveas("out2.dxf")

This feels like a real hack, but it *does* work and produces a file I can use with the laser, so I'm happy for now. I'd really like to know why we have non-zero Z coordinates in a 2d drawing, and why some are negative - Onshape devs anywhere?

andrew_troup

Nice detective work, there, @tom_oinn !

The ball appears to be in Onshape's court
(BTW - I searched early forum posts and found that the dxf version was taken down from 2013 to R11 (!) in April this year. Which was a really impressive response, within 2 weeks of it being raised ... but maybe it was rushed a bit, judging by what you say the file contains)

It seems possible +A or -A is the z depth of each point (measured to an orthogonal plane through the origin), but this only has explanatory power if the planes or faces you're exporting from are orthogonal to the global coordinate system.

In this case the z depths, by this metric, would all be the same in a given sketch.
But this is rank speculation, and almost certainly wrong.

_Ðave_

Out of curiosity I exported some sketches as dxf and opened in mastercam. All of the Z depths were equal to the distance the sketch plane was from the origin in Onshape. I don't know maybe that helps.

tom_oinn

I've observed that this only happens if you have a mirror operation somewhere in your part. The simplest I could get was to sketch a rectangle with a circular hole in, extrude it, mirror the extrusion (adding to the same part) so you have a rectangular block with two cylindrical channels. Export the face of the block and you have four lines and two circles, the centre of the second circle has the negative Z and mirrored X coordinates and requires fixing (there's also a difference in the extrusion vector, which is 0,0,1 in one case and 0,0,-1 in the other.

tom_oinn

The current version of the fix script is up at https://github.com/BaseBot/triangula/tree/master/tools if anyone else finds it useful, ASF license, help yourself. Note that this only corrects for arc and circle elements, it's possible this problem applies to others but my designs haven't included any other entities which needed fixing.

ritchie_

Many thanks @tom_oinn for your script!

I discovered the mirrored Z-depth issue today when trying to export a planar surface as a .dxf for some waterjet software and it couldn't manage an auto-path.

Researching further, I found that FreeCAD and A360 also struggle with the file. FreeCAD is the most instructive of the bunch as it is able to render the Z position, and A360 just silently fails although it doesn't expose any Z-axis data to the user AutoCAD 2016 for Mac apparently has no difficulty with the file as provided by OnShape, I suppose it's also silently fixing it up on the way in.

I initially tried just flipping the offending Z-axis values with a text editor, but didn't also correct the X and Y positions like @tom_oinn's script does. I'm closer now after running a file through the converter and then squashing all other objects to 0.0, although I'm still missing segments when importing to A360.


Curiously the FlowPATH software sees all the shapes, it just can't join segments that aren't on the same z height and so ends up unnecessarily traversing all over the place like a drunk robot. Because it can't find a closed path anywhere, it can't tell what is the inside of the object and what is the outside. This is compared to FreeCAD below which initially had some shapes translated by X and Y as well, and A360 which is plain old missing some pieces.



Direct from OnShape into FreeCAD:



After running @tom_oinn's script:



After manually moving all other objects to z=0.0. I now know more than I'd like about the DXF format and how nasty it is. As someone who creates software and technology for a living, my apologies to the CAD community for the horrors which AutoDESK has cast upon the world



Same flattened-to-0.0 file as above, imported to A360. Maybe if the waterjet software works but A360 still hasn't figured it out we can stop here, although I'd think for completeness this feature should probably work with more other software..




Thanks for considering, OnShape team!

ritchie_

As an update, it looks like A360 has difficulties rendering arcs from 0.0-90.0° - extending these to 0.0-90.1° will cause them to draw??