Deals on Alibre

Home Model Engine Machinist Forum

Help Support Home Model Engine Machinist Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
I tried to import AutoCAD .dwg files but Alibre could not do it properly. I'll try .dxf files next. Alibre claims it will import dwgs but NAUGHT. (Loud buzzing noise) Has anyone had success with .dxf files?
I have the latest version of Alibre Expert and it opens .dwg files, older ones had issues with them though. Even then, it still does odd things like the information block on a drawing, instead of it being a paragraph, it ends up being one long line of text extending out the right of the drawing. It's adequate but 2D isn't an Alibre strong point.
 
For our small use it's probably a better option to just model it from the PDF/Plan that way you can make adjustments for your way of working and available tools as well as become familiar with the design.

That's pretty much what I do. If I need a 3D model, nothing takes in the standard drafting views from a PDF and turns it into a solid model, so I do that. I've done that most parts of the engine I'm building so far; anything that goes on the CNC mill for repetitive cuts.

The drawings import fairly well, it's just not having any text and having to dimension everything that's a PITA. Any circular features, even the fillet radii at the corners of the conn. rod, have to be drawn in so that Rhino will dimension them.
 
I have the latest version of Alibre Expert and it opens .dwg files, older ones had issues with them though. Even then, it still does odd things like the information block on a drawing, instead of it being a paragraph, it ends up being one long line of text extending out the right of the drawing. It's adequate but 2D isn't an Alibre strong point.
It's possible that my AutoCAD is too old and was specialized for Architecture. It's AutoCAD Architecture 2004. I use it for 3D drawings but to made 2D drawings from that is a bear. Alibre is easy to made 2Ds from, but it's not very powerful. I have Inventor 6, a very old version which is what I prefer over all the others but it crashes too much with the latest version of msux.
 
You'd have to have a pretty specialized import tool that would take PDF and create a solid from it. That is an interesting idea though, and I wonder if anyone has created such a beast. It would definitely be a niche tool, and not a simple task to code/develop. Even having something capable of reading and interpreting dimensioning of a 2D drawing would be a challenge to write, given all of the different ways/places/styles a dimension can be added.
[edit] I just happened to find this: Print2CAD 2022 That app will create a DWG from PDF, but it looks to be intended for the architectural market. Even so, it might be an interesting thing to try out. I doubt it is intelligent enough to read/apply dimensions though.

A better solution might be a change to our culture. There are those that want to keep plans private for fear of having the engines mass produced in China. I get that, and I respect their desire/right. And there are those that are not concerned with the Chinese manufacturing problem and freely distribute their plans via PDF. Maybe part of the answer here is to encourage these latter folks to consider also distributing the DWG, STL, or other native format of the CAD system being used (if any). This is far less transportable, so I think it would be best to also post a PDF, but I've often thought it would be nice not to have to replicate a design in a CAD tool a second time. That said, redrawing in your CAD does form as its own form of validation and fosters your learning.

I also balked at the Alibre deal this time around. I came very close, but I didn't get there. I think it was the whole discussion on the MeshCAM path generation that finally pushed me to waiting. I just didn't have the time to deal with checking it out versus DeskProto or some of the other options discussed. The CAM issues combined with some of the concerns about Atom just held me back. Well, that and the fact that I was way too busy this weekend trying to fix a Mitsubishi servo amplifier for a guy. Give a dog a bone and he'll gnaw on it forever. That is the way I am with this problem... I'm doing all this for free for the guy because it is an interesting challenge, but geez! I've spent a lot of time trying to figure this last problem out!

I did put Alibre Workshop on my Christmas list though. There is a remote possibility that my family got it for me anyhow. That would be cool if they did. Despite my reservations (above), I would never turn it down, and I'd get enough value out of it (truth be told, 3D CAM is not my main interest anyhow... I've a gazillion endmills, but very few are ball type).
 
Last edited:
PDF is a bit like the modern version of buying paper plans, you won't get them onto your screen easily either (well using trace* you can) in a format that can be worked on.

For our small use it's probably a better option to just model it from the PDF/Plan that way you can make adjustments for your way of working and available tools as well as become familiar with the design.

*This post shows how I deal with a drawing or in this case a PDF, next page shows it being machined. Not sure if Atom includes "Trace"

https://www.modelenginemaker.com/index.php/topic,10064.msg229141.html#msg229141
The problem with trace is that it depends on the PDF and the product that generated it being accurate. Not always as I've found out. If the part is scaled other than 1:1, it causes a problem. You are right that remodeling the part is the safe way to go.
 
Provided there are at least a couple of known dimensions you can scale the part in two dimensions to remove any distortion. You can also upscale or downscale if you want to make the part a differnt size to the original.

I really only use it to pick up the shape of undimensioned features such as the cast surfaces of castings which are seldom dimensioned on drawings
 
Even having something capable of reading and interpreting dimensioning of a 2D drawing would be a challenge to write, given all of the different ways/places/styles a dimension can be added.

In the case of importing the pdf file, I was thinking that the dimensions are text and that seemed easy to import. It successfully imports the lines forming the part. The lines for the dimensions, both the ones that lead to the measurement points on the drawing and the ones with the arrowheads all import, just not the numbers. It almost seems like more work to ignore text than just import it as a bunch of lines.
 
Autocad and Solidworks are supposed to be able to do it but the PDF has to be a vector one to be editable as Raster format won't work. MOI will also open Vector PDFs
 
It almost seems like more work to ignore text than just import it as a bunch of lines.
My guess is that this was defensive on their part. Structurally, I suspect that PDF tags text as a different object type, which is why Alibre "knows" it is text. At that point, the developer needed to know what to do with the data. To try and figure out what is being dimensioned is a challenge, and if they left the text in the drawing then it gives the illusion that the drawn objects actually reflect the intent of the dimension.
 
For transferring raster, I've been demoing a free plugin for Rhino called Vectorizer. With base settings, it'll convert an image to splines using RGB. A quick extrude gives me the thickness. I can then resize Dₒ (outer Ø) for that gear and it's good to go.
Vectorizer.PNG
I've been on the edge on Alibre. I think for my unique circumstances, I'll probably stick with Rhino. I need more surfacing tools for projects outside of the model engine world (plugs for carbon fiber layup and other nerdy stuff). Alibre seems to be the nicest F360 alternative for sure if you're into "CAD machining" on butter.
 
I've been on the edge on Alibre. I think for my unique circumstances, I'll probably stick with Rhino. I need more surfacing tools for projects outside of the model engine world (plugs for carbon fiber layup and other nerdy stuff). Alibre seems to be the nicest F360 alternative for sure if you're into "CAD machining" on butter.

Is that Rhino 7?

In addition to the model engine world, I also do things in the 3D Printer world, and have modeled the house, arranging all the work areas and tools when we did our addition for the shop, my ham radio antennas - anyplace where scaled drawings are useful.

About the only thing I don't do is artistic stuff. Not that I haven't dabbled in that, too. I have something like 1200 *.3dm files dating back to '05. I've been using Rhino since ver 3.
 
  • Like
Reactions: Zeb
In the case of importing the pdf file, I was thinking that the dimensions are text and that seemed easy to import. It successfully imports the lines forming the part. The lines for the dimensions, both the ones that lead to the measurement points on the drawing and the ones with the arrowheads all import, just not the numbers. It almost seems like more work to ignore text than just import it as a bunch of lines.

Purely in the name of providing too much useless information:

The problem with importing PDF (into anything - even just importing a PDF of "text" into a word processing program) is that under the hood, a PDF does not contain, or at best only accidentally contains, anything that you would recognize as being "the contents" of the document.

It's not that it's a "strange encoding" or oddly formatted/etc. It's that PDF (portable document format) is intended as a way to send documents around, and to produce "ink on the page" identically wherever you send the document. It's a set of instructions: "make this bit of the screen/paper/whatever black, make that bit of it grey, make that spot over there white".

If you have a dimension (or any other bit of "ink") in a drawing, such as "1.2", there's no guarantee that inside the PDF file, the "1", the decimal, and the "2" are anywhere near each other in the file contents, or that the parts of the dimension "know about" eachother in any way. There's not even any guarantee that all the parts of the "1" are near each other, or even that the PDF even knows that the ink it's rendering there is intended to be a "1". There are simply instructions in the PDF - potentially scattered throughout it - that say "make this bit black, make that bit white", and when those instructions are carried out, it ends up drawing "1.2" on your screen or paper.

The fact that sometimes other software that's viewing a PDF knows that it was "1.2" is _only_ because the software that created the document, also added comments to the PDF that say "oh, and this bit of ink is intended to represent the text 1.2". That comment however is /not/ what renders, and it's entirely possible for it to not be true!

So... TLDR: PDFs really should be thought of as digital paper. If you can copy/import _any_ content out of them, it is only by the grace of the program that _wrote_ the PDF, and what you can copy out of them is not necessarily accurate to what you _see_ when you look at the PDF on-screen or printed.
 
Well, just so's y'all knows, I doesn't has CNC or any of that modern snazzy stuff. I only have a little ol' lathe and am tryin' to gets me mill into the tiny garage today! So I only needs 2D drawings for making parts. I has been practicing with Atom, it's getting easier to use, even so, I prefer the old Inventor that I has but can't use on the modern msux platform. I finally figured out some of the more intricate (read as I saw what was there but didn't know what it was) details in detailing the 2Ds. I like how the 2Ds are placed on the page but am still lerning it and getting used to it. It certainly does not have the power of other CADs but is easier once one gets used to how it works.
 
Purely in the name of providing too much useless information:

The problem with importing PDF (into anything - even just importing a PDF of "text" into a word processing program) is that under the hood, a PDF does not contain, or at best only accidentally contains, anything that you would recognize as being "the contents" of the document.

It's not that it's a "strange encoding" or oddly formatted/etc. It's that PDF (portable document format) is intended as a way to send documents around, and to produce "ink on the page" identically wherever you send the document. It's a set of instructions: "make this bit of the screen/paper/whatever black, make that bit of it grey, make that spot over there white".

If you have a dimension (or any other bit of "ink") in a drawing, such as "1.2", there's no guarantee that inside the PDF file, the "1", the decimal, and the "2" are anywhere near each other in the file contents, or that the parts of the dimension "know about" eachother in any way. There's not even any guarantee that all the parts of the "1" are near each other, or even that the PDF even knows that the ink it's rendering there is intended to be a "1". There are simply instructions in the PDF - potentially scattered throughout it - that say "make this bit black, make that bit white", and when those instructions are carried out, it ends up drawing "1.2" on your screen or paper.

The fact that sometimes other software that's viewing a PDF knows that it was "1.2" is _only_ because the software that created the document, also added comments to the PDF that say "oh, and this bit of ink is intended to represent the text 1.2". That comment however is /not/ what renders, and it's entirely possible for it to not be true!

So... TLDR: PDFs really should be thought of as digital paper. If you can copy/import _any_ content out of them, it is only by the grace of the program that _wrote_ the PDF, and what you can copy out of them is not necessarily accurate to what you _see_ when you look at the PDF on-screen or printed.

And I've got to tell you that as an engineer, I loved this.

I had the concept that instead of it being a bitmap (make this bit that color) it was more like a mix of both bitmap and some standardized fonts. There seems to be about 10^23 fonts out there and it can't contain all of them, but maybe some standard fonts and the rest as bitmaps.
 
And I've got to tell you that as an engineer, I loved this.

I had the concept that instead of it being a bitmap (make this bit that color) it was more like a mix of both bitmap and some standardized fonts. There seems to be about 10^23 fonts out there and it can't contain all of them, but maybe some standard fonts and the rest as bitmaps.

Heh - "kind of" :)

PDF can optionally use some standard fonts, and software that writes PDFs can embed additional fonts/glyphs, but the kicker is that it's not _required_ to use the fonts/glyphs in any consistent way. It's entirely possible (and in some scenarios likely - for example if a "drawing" component like a line gets too close to a character) for some of the things that look like characters in (i.e.) a dimension to be characters from a font, and others to be bitmaps or vector-graphic renderings of the characters that are to appear in the output. From the PDF's point of view, standardized fonts are just ways to put specific collections of black/white/etc ink on the page. It really has no concept of each of those (shaped) blobs of ink, belonging to words/sentences or other elements of text structure as we see it.

Even worse (meaning you don't just have to worry about _missing_ data), for _display_ purposes, standardization of the underlying encoding is irrelevant, so some software that writes PDFs will rewrite the map between the font-character representations and the displayed-glyph representations, so that it can use a reduced alphabet and therefore compress more easily. The result is that if you copy/import text (even just plain text with no drawing elements, and in which the PDF is completely encoded as characters from a font), you'll sometimes find that the text that you copied, is different than what appeared in the display.

Such fun!
Will
 

Latest posts

Back
Top