View Full Version : Generating APT with VBA for a 2D AutoCAD dxf parts??

09-05-2008, 10:16 PM
I was just wondering how you guys would go about creating APT for a 2D part. The part would be cut on a 2D plasma CNC. The geometry of this part would be done in all small line segments for the tight curves and longer line segments for the rest.

I am thinking that we would take the start and end points of each line segment then output this to a text file in a form of G-code or (APT), what do you think? If you have any VBA code examples to share as an example this would be great to get me started.


09-06-2008, 06:05 AM
I would like to help Rob but I have no clue what a APT is, my first guess was apartment but I don't think that right.:rofl:

On a plasma cutter it needs to start at one end and work to the other so some sorting would be in order. What I have done in the past is use a polyline and draw it from one end to the other and export the vertexes. That way I would know when the information was sorted in the correct order. The I would pass that information to the machine.

09-06-2008, 11:19 AM

Hi Tommy!

To the best of my knowledge APT was a very early machine programming language. Lots of shops still use it, though I am just learning about it now. Basically I would like to “using VBA and AutoCAD” extract out the vertexes just as you said, but before that you would have a few “if” statements to check what the first entity is such as line, point, or circle.

L1 = LINE/ 1, 0, 1, 1

P1 = POINT/ 4, 5.25, 0


Lets say on this part our code finds for example 6 lines In series you would print to a text file something like this:

L1 = LINE/ X, X, X, X
L2 = LINE/ X, X, X, X
L3 = LINE/ X, X, X, X
L4 = LINE/ X, X, X, X
L5 = LINE/ X, X, X, X
L6 = LINE/ X, X, X, X
GO/ TO, L1, PLXY, TO, L6
AND SO ON.....

I don't have any code as of yet, but I am searching for examples.....

09-10-2008, 02:57 AM
APT? Wow. I suppose I shouldnt be surprised that many shops still use APT, or other geometry-based languages like Compact2 or genesis. But its been so long ago that I wrote code for that, that I backed the code up onto 1.2 meg floppies!

Its doable, at least to output to APT. Going straight to G Code would be so specific to your individual application that its doubtful any shared code here would work without a bunch of tweaking, unless you are doing pretty generic stuff, on a pretty generic control.

But if I can find a language reference, something could be whiped up easy enough. Not much luck Googling for the reference, but i shouldnt be surprised because APT started falling out of favor before public Internet access was around.

But if you can give me the language structure, i could whip something up ...

09-10-2008, 05:19 PM
Great, all I have right now is a scan of the text file, I will post that later tonight as soon as I get to my scanner. So what would we do first read every start and end point of each line and place all the points in a text file? or would we just store that data in an array and read it direct?

09-10-2008, 06:42 PM
Ok here is the format of the APT, sorry about the size and quality. I will upload a text file tomorrow.

09-10-2008, 07:03 PM
Before we get into the APT, Ive gotta ask ... you say you are plasma cutting - how is your code generated now? Are you using some other CAM software that isnt up to snuff?

I ask, because Ive already got code to output file formats for both Fabriwin .prt files (geometry only), and Maker, both of which run directly inside of AutoCad or SolidWorks. Also other 'goodies' for Fabriwin <wink>

>>The geometry of this part would be done in all small line segments
>> for the tight curves and longer line segments for the rest.

You will not be generating arcs? is there a reason for this? If the arcs arent supported on your control, its probably best to dice up the segments in code, rather than manually in the drawing. You'd need to have at least some sort of Global Constant, if not a function, to determine where the cutoff point is between 'small' and 'longer' line segments.

>>On a plasma cutter it needs to start at one end and work to the other
>>so some sorting would be in order

You sound like you've done this before. Back when I programmed sheet metal, I tried to keep closed shape geometry, which makes it easier to generate toolpaths, and also to figure out what is 'inside' and what is 'outside', not only for tool offsets, but for nesting. (No, don't ask; writing nesting algorithms about killed me)

Also, having closed shapes allows you to auto-generate 'microjoints', if needed, merely by strategically leaving 'breaks' in your geometry.

So I'd start by getting all the geometry out of the drawing, checking the integrity, then tweaking the geometry in memory to match the type of geometry needed for output.

How are your parts stored? A bazillion shapes in Modelspace arranged kind-of-next-to-each-other? Is there other data that needs to be carried along with the geometry - thickness, material, etc?

09-10-2008, 08:13 PM
We are using custom code for the APT that was done many years ago. But my system is not connected to that one since those are all unix computers, mine is the only windows type. So I need some code on my end, I am using .dxf out of AutoCAD and .prt files from UGS NX.

Right now all my parts are done with only line segments and that's all I really need right now; But eventually processing arc segments will be needed.

09-10-2008, 08:19 PM
The shapes are fairly simple all in model space, approx 20-40 line segments per part though this could vary, and average part size is 24"X30" I am not sure about the material and thickness setup yet, that is we do include this but I am not sure if its in the APT itself or done by another means.....and yes all the geometry is closed paths.

The APT above is from a recent part so I would say that is the format that I would need.