Hello world[]

Feel free to ask questions or discuss the code and style on this page. Tom Haws 04:51, 1 May 2008 (UTC)

CAD Standard[]

I did get the script to draw a vehicle and place that along an alignment. It only drew one wheel track though.

If you want to use the National CAD Standard then I would use something like C-ROAD-TURN-??? or C-ALGN-TURN-???.

More info on the Standard is at:

One enhancement would be to be able to go in reverse as the newer versions of AutoTurn can do. Also, it would be nice to link up a DXF or DWG file with some blocks already defined.

Turning in reverse would be nice. I don't know when we will get to that, but it's certainly on my mind. Tom Haws 15:29, 28 September 2008 (UTC)

Reverse Curves, Turning in Reverse, Overhang Paths[]

  • Hey, Tom. First of all, a GREAT BIG THANKS for this excellent LISP Routine. A couple of months ago I was trying to model a path for a rather complicated turn for a WB-62 which involved a bit of weaving with a reverse curve along the path. Templates proved to be useless so I did a search and found Turn.lsp. Since the path used by the routine is for the left front tire, turns to the right obviously just use the minimum turn radius for the outermost front tire as shown in AASHTO's Green Book. However, for a reverse turn to the left, the right front tire becomes the outermost tire and the radius of the path of the left front tire has to be reduced by the distance between the two front tires to approximate the radius. No big deal at all, but this might be something to consider when tweaking future releases.
  • With the current release, overhang paths can easily be seen by having the routine plot a whole bunch of vehicles along the path. However, having the routine draw polylines along the overhang paths would also be nice.
  • The other day, I taught one of our engineers how to use the the routine and he asked me if there was a way to model a path in reverse. So, as already commented upon, that would be a nice addition as well. To make a long story short, we accomplished the reverse modeling which was required for our purposes by simply mirroring the entire generated path along the front and rear midpoints of the last instance of the vehicle generated by the routine. In other words, we considered the last instance of the vehicle to be the point at which the vehicle stopped completely (on a curve, no trailer), whereupon the steering wheel would be turned all the way in the opposite direction before reversing. So the mirroring was a perfect solution given that we were able to see that there was enough room to back up for a few yards then straighten out and move forward again.
  • Again, MUCH THANKS for a GREAT routine. Kevin 00:40, 15 October 2008 (UTC)
Kind words! Thanks for the feedback. I really like your thoughts. I am intrigued by your method of achieving reverse modeling, and I hope it is an encouragement to others. Tom Haws 03:00, 15 October 2008 (UTC)
Yes. TURN works identical forward or reverse. The math is the same. Simply turn your vehicle around at the start of the path. You will find that in short order the vehicle does a jack-knife and heads forward. Tom Haws 18:06, 16 March 2009 (UTC)
Also, I am working (very slowly) on a version that will be easier to improve, and it may provide real-time video game driving thatwill enable better reverse modeling. I need programming help!!!! If you know any young CAD-sters who want to learn AutoLISP, send them my way! The pay is heavenly. Tom Haws 18:06, 16 March 2009 (UTC)
Absolutely! There are a lot of firm’s out there like us who would prefer to use a program like turn.lsp rather than forking out $1500+ for a swept path software that we’ll only use a few times per year. Darcy
Consider the invitation extended, folks. Tom Haws 19:15, 16 March 2009 (UTC)
I’m slightly confused on doing the reverse path. I’ve created an SU-30 truck and I ran the path forward. Then I essentially left the vehicle where it “stopped” and ran the program again on a path that would represent the truck backing into the space. The output looks sort of weird so I’m unsure. I see what you mean by “jack-knife”, but in terms of a truck backing up is this accurate? Darcy
Yes. It's accurate. TURN.LSP is like driving a slot car or shopping cart (trolley). Consider pulling a shopping cart (trolley) from the front versus pushing it from the front. If you can't imagine it, go to the store, turn a cart (trolley) backwards, and try pushing it. The steering feedback is crazy! It's an unstable situation, not anything at all like hopping in your car, locking the steering wheel and running in reverse on a big field. Try adding a trailer to your car and then running in reverse with your steering wheel locked. Nope. Won't work. Jack knife (conflict between vehicle segment bodies) in short order. Tom Haws 19:15, 16 March 2009 (UTC)
Would it be accurate to run the truck in forward from the parked position to the end of the first (forward) path? Darcy
I believe it would accurately show what's possible if steered carefully. Tom Haws 19:15, 16 March 2009 (UTC)
Hi, Darcy. It's funny that you should mention running the truck forward from the parked position to the end of the first forward path as I have actually done exactly that on a couple of occasions. I found the results to be accurate, although I did take care to make certain that the last instance of the truck generated along each path was aligned. Kevin 00:32, 26 March 2009 (UTC)

To do[]

I believe that for the survival and growth of this application, the code must be refactored into smaller functions with local variables and carefully structured arguments and return values. Here's a list in greater detail of where I would like to go with this: Tom Haws 04:34, 2 November 2008 (UTC)


  • No global variables unless required for persistence in the current drawing session between runs. Tom Haws 04:34, 2 November 2008 (UTC)
  • All information passing between functions to be via arguments. Tom Haws 04:34, 2 November 2008 (UTC)

Improve data formats[]

There needs to be an elegant, compact way for the path calculating functions to communicate with the input and and output functions. This is through good data formats. I think a good name for each data type is important, and I would like to get opinions on the names in bold. Tom Haws 04:34, 2 November 2008 (UTC)

Proposed scope of the program:

  • The main imperative of the application is to plot variable segmented vehicles along paths, forward and backward, checking for jack-knifing and steering exceedances. Tom Haws 06:46, 2 November 2008 (UTC)
  • Time modeling (acceleration, steering response time) is secondary and dispensable Tom Haws 06:46, 2 November 2008 (UTC)
  • One-dimensional model. Can't track sliding; sliding is a failure. Can't handle grade variations other than longitudinal and cross. Can't handle grade variations due to offset tracking. Tom Haws 06:46, 2 November 2008 (UTC)
  • One-driving model. Tiller (back-end-steering) trucks solve the main problem addressed by this application. This application isn't needed in the case of a tiller truck. Tom Haws 06:46, 2 November 2008 (UTC)

Things the vehicle data format must hold:

  • Any number of vehicle segments Tom Haws 06:45, 2 November 2008 (UTC)
  • For each segment, the front driving wheels and (?) centroid or front hitch (tongue?) point Tom Haws 06:45, 2 November 2008 (UTC)
  • For each segment, the back axle(s) and wheels and (?) centroid Tom Haws 06:45, 2 November 2008 (UTC)
  • For each segment, any back hitch (is hitch the right name for both front and back connections?) Tom Haws 06:45, 2 November 2008 (UTC)
  • For each segment, any number of other arbitrary points to be modeled Tom Haws 06:45, 2 November 2008 (UTC)
  • For each segment, the maximum allowable angle left and right with the front wheels or preceding vehicle segment Tom Haws 06:45, 2 November 2008 (UTC)
  • For each segment, the maximum allowable centripetal acceleration for tipping and slipping Tom Haws 06:45, 2 November 2008 (UTC)

Things the driving data format must hold:

  • A directional guide in either timed steering (for real-time driving) or geometric tracking format.
  • A forward/backward/speed indicator Tom Haws 06:45, 2 November 2008 (UTC)
  • A longitudinal and cross grade indicator representing the entire path width at the current front of the vehicle Tom Haws 06:45, 2 November 2008 (UTC)

Things the path data format must hold (The path data can be conceptualized as the child of a marriage between a vehicle data set and a driving data set):

  • The entire path in memory, possibly allowing for a drop-once-plotted or drop-beyond-limit economization of a long path Tom Haws 06:45, 2 November 2008 (UTC)
  • The actual state (coordinate or angle value) of every vehicle parameter at every path representation point Tom Haws 06:45, 2 November 2008 (UTC)
  • Time/speed coordinates Tom Haws 06:45, 2 November 2008 (UTC)
  • Centripetal acceleration at wheels Tom Haws 06:45, 2 November 2008 (UTC)
  • Radial (Tangential?) acceleration at wheels Tom Haws 06:45, 2 November 2008 (UTC) (What was I thinking?) Tom Haws 04:19, 17 January 2009 (UTC)

Implement a logical code separation such as Model/View/Controller[]

It's common these days to conceptualize programming using the Model, View, Controller paradigm. Tom Haws 04:34, 2 November 2008 (UTC)

The model is the way we represent vehicles, paths, or other information inside our program. On other platforms, the model might be in database form. It seems obvious to me that in LISP, the data model should be a LISP List, possibly exchanged in a LandXML file format that we might need to coordinate with Nathan Crews and the other folks at LandXML. Tom Haws 04:34, 2 November 2008 (UTC)

The view is the way the program looks to the user. Namely, the prompts, windows, and total interface. I suppose it might also include the CAD objects the application creates. The MVC paradigm suggests that the code for the View should be modularize independent from the Model and the Controller. I'm not sure how this works, but it suggests to me that, for example, we wouldn't want to be calculating parts of paths or vehicles in the same area of code where we are prompting or plotting. Tom Haws 04:34, 2 November 2008 (UTC)

The controller is the engineering logic of the application. For this application, it's the path calculator and any limit error (jack-knife, trailer conflict, skidding) checking. Tom Haws 04:34, 2 November 2008 (UTC)

Starting Version 1.2[]

I am starting version 1.2 at home (offline). Tom Haws 04:35, 17 January 2009 (UTC)

That's great, Tom! I'll be looking forward to it! Your routine has become a great resource for me and I want you to know how much I appreciate your work and generosity. Kevin 20:17, 17 January 2009 (UTC)

I am going to keep version 1.2 at Turning path tracker (AutoLISP application)/version 1.2 development Tom Haws 04:36, 19 March 2009 (UTC)

Matt Miller questions[]

I have recently loaded the two lsp files (Turn and BuildVehicle) onto my personal workstation in the first step of providing it for our office. A coworker of mine has had a problem arise that I did not. He is required to load the lsp applications each time he opens a drawing where mine have only been loaded the first time and each drawing can use them fine. Have you had this problem and do you know any way to help? Also, once he reload the turn program, his instructions that he follows are different then my turn instructions (select block, select polyline, etc.) and we are using the same lsp. Last, as an fyi, we are both using Autocad 2007. I appreciate any help you can provide me. Thank you. Matt Miller

Perhaps your workmate loaded TURN using Appload and added it to the Startup Suite. Perhaps you loaded it by dragging it or didn't add it to the Startup Suite. Tom Haws 23:28, 2 March 2009 (UTC)
I think you may not be using the latest version. The latest version has only one file (TURN.LSP) and one command (TURN). Can you check? Tom Haws 23:28, 2 March 2009 (UTC)

Kevin's library and insights about wheel width[]

I've already created a complete vehicle library using TURN.LSP. My library consists of blocks for: A-BUS, BUS-40, BUS-45, CITY-BUS, MH, MH-B, P, P-B, P-T, S-BUS-36, S-BUS-40, SU, WB-40, WB-50, WB-62, WB-65 and WB-67. These are all of the vehicles listed in AASHTO's Green Book with the exception of vehicles with more than one hitch. With TURN.LSP version 1.1.3, Stephen Hitchcox made and listed the following revisions: Various, including Centre of Wheels used instead of Outside of Wheels (vehicles steer on the centroids of the wheels, not the rims), "Set-out" point added at Front Left wheel. However, even though "vehicles steer on the centroids of the wheels, not the rims", AASHTO's Green Book shows the minimum turning radius as tracking along the path of the outermost edge of the left front wheel. This can also be seen in Appendix-C (See pages C-10 through C-16) of the NCRP Review of Truck Characteristics as Factors in Roadway Design. Therefore, any blocks created using TURN.LSP which represents standard AASHTO vehicles must take this into consideration while responding to data input prompts. In other words, if AASHTO's Green Book shows a truck with a body width of 8 feet, shows the outermost sides of the wheels as flush with the outer edge of the truck body, and shows the minimum turning radius as tracking along the path of the outermost edge of the left front wheel, then the TURN.LSP block wheel has to be centered on the edge of the truck body because TURN.LSP tracks on the centroids of the wheels. So for a truck with a body width of 8 feet and wheels shown with the outermost sides as flush with the outer edge of the truck body, then the distance from center of wheel to center of wheel must be input as being 8 feet as well. In this case, the end result is a block which looks a little odd because the wheels are centered on the edges of the vehicle body as opposed to having the outer edges of the wheels flush with the outer edge of the truck body. This is how my blocks were created and testing has shown the generated paths to correspond nicely to AASHTO's paths. I'll get with you sometime this weekend, Saturday or Sunday through your "Contact" page on your website. 02:09, 6 March 2009 (UTC)

My blocks were created such that the path of the left front wheel tracks along the outermost edge of the wheel in order to remain faithful to AASHTO. Additionally, the "GETTING STARTED" section of the TURN.LSP routine states, "Axles should be the "centroid" of any group of multiple axles". My blocks also conform to this specification. Every effort was made to make certain that my blocks were created accurately while remaining faithful to both AASHTO and the TURN.LSP block creation instructions. Having said that, you are welcome to have the blocks. I offer them to you FREELY but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. (That was a copy/paste from your website, by the way.) Anyway, I wouldn't revise your code to conform to AASHTO exclusively, but maybe you might consider adding a prompt that asks something like,"Is this a Custom vehicle or an AASHTO Standard?" Then you could add some code which would place the turning point on the rim of the wheel instead of the centroid and reduce the number of data input prompts relating to axle width and distance from center of wheel to center of wheel. All you would really need here is one prompt asking for distance from outer rim to outer rim. (Note that the outer rims of the wheels for Passenger Car (P) are not collinear with the edge of the vehicle body so this prompt would still be necessary. If all of AASHTO's vehicles had outer rims of wheels collinear with the edge of the vehicle body, then no prompt would be necessary at all.) Also, I THINK, but I'm not certain that there may be a minor error in the code which creates Layers. Next time I run the routine I'll check and let you know. I believe that one of the layers representing one of the paths may be improperly labeled as being for a right wheel when it is for a left wheel, or vice versa. I think I saw this but really need to double check to be certain. Anyway, that's it for now. Make sure you test the blocks. Again, MUCH THANKS for all of your hard work and generosity.

Kevin 08:45, 7 March 2009 (UTC)

Another suggestion from a former user of AutoTurn[]

I just found out about and used Turn.lsp for the first time yesterday. I really appreciate the fact that someone has finally come up with a free utility of this type. I have worked for two companies in the past that have spent over $1000 for AutoTurn. If I could make one suggestion for Turn.lsp, it would be for the graphics of the tracks and vehicle outlines to be made into a block when they are placed, instead of individual elements. This would make it easier to delete the graphics if, for instance, you wanted to modify the steering path and run the routine again. I am a draftsman and not a programmer, so I don't know how easy or hard it would be to add this function. Thanks! Wpshort 02:53, 20 May 2009 (UTC)

I bet we could make them into a group without too much trouble. Tom Haws 04:01, 20 May 2009 (UTC)

Question about the exact placement of tires[]


I've used your software to help me study a car traveling down a s-curve ramp. I'm trying to place additional cars along the axle paths to show the car moving along the ramp. Your instructions say "to offset the centerline to half the width of the car to show the wheel paths". Will this represent the outermomst edge or corner of a wheel then? Or should the offset be to the end of the axles and represent the centerpoint of the tires?



Hi e. I wrote up and posted some quick start instructions on how to use the routine on Eng-Tips forum located here Turn.lsp Issues. Also see #Kevin's library and insights about wheel width above. Hope this helps.
Kevin. 00:46, 10 June 2009 (UTC)

Memory Issues?[]


I recently discovered Turn.lsp (1.1.10) and we've just begun using it. Seems like a great, easy to use tool - thanks for your work. A second person here has begun using the program, just this morning, and is getting a lot of "Fatal Error - Out of Memory" errors. She's running an HP Core2 Duo 2.4GHz PC with 4GB of RAM, which should be more than sufficient I would think. I was wondering if you had encountered any issues similar to this? I recognize this could be a number of things, but seemed rather coincedental with running Turn. Thanks for your help, 15:34, 13 July 2009 (UTC)TJ

No. I haven't heard anything like that before. And I don't know any reason why Turn.lsp would cause that. It's not that demanding a program. I'm glad you like it. If you know any budding programmers that want something to practice on, send them this way. Tom Haws 15:42, 13 July 2009 (UTC)


Hi Tom. I've used the older version of your program on a few projects and had good results! Can you give me a brief description, though of what layers are created through the process for version 1.1.7? Thanks for any help! Dave Powers

I think that the source code has the layers clearly marked. Look for TURN-SETLAYER in the source code on the article page Turning path tracker (AutoLISP application). Tom Haws 23:31, December 9, 2009 (UTC)

Blocks for Brazil[]

I have blocks[]

I'm from Brazil. I'm an user of the Turn.lsp. I've seen in your website that you're wanting some vehicle blocks to use along with Turn.lsp. I've the AASHTO 2004 vehicle library in Metric units and Imperial Units. I also have the brazilian DNIT vehicle library. My metric library is working very well, I've been using it for quite some time. I haven't used the imperial library but I guess it's fine too. -Daniel

Eu quero blocos[]

Gostaria que me enviassem os blocos dos veículos tipo utilizados no Brasil, e como usar o TURN.lsp no sistema métrico de unidades. Natal

Natal, eu não tenho os blocos que vc requere. Mas o Daniel pode tal vez compartir com vc. Tom Haws 16:35, March 10, 2010 (UTC)

Blocks for Brazil and Metric Blocks[]

Hi, I've posted on the link below a file with a Metric Vehicle Library with AASHTO Vehicles, Brazilian DNIT vehicles and some old RAS-K-1-1988 vehicles.

Unfortunately the yousendit link will only last 1 week or 100 downloads

No link abaixo é possível baixar o catálogo de veículos em metros. Com veículos da AASHTO-2004, do DNIT-2005 e alguns da norma RAS-K-1-1988, adotadas no DER de Santa Catarina.

O link só vai ficar ativo durante 1 semana ou 100 downloads.

Para aprender a usar o Turn.lsp basta ver o vídeo neste link .

Daniel R. Queiroz -

You can upload the file directly to this wiki. Could maybe one of you two do that and maybe edit the article? I don't know that I will be able to get to it any time soon. Tom Haws 17:16, March 10, 2010 (UTC)

BuildVehicle, Left Turns, Custom Vehicles[]

I am trying to build my own vehicle, a fire truck. However, I cannot get BuildVehicle to run. I can run Turn.lsp and can use the generated vehicles.

Is buildvehicle built into Turn.lsp?

Yes. It is now an option of the TURN command. Tom Haws 04:21, August 19, 2010 (UTC)

I type BuildVehicle into the command line and it tells me it is an unknown command. I have also tried "BV" where it then gives me a blank command line and then I am back to a new command line.

It is now an option of the TURN command. Tom Haws 04:21, August 19, 2010 (UTC)

Am I suppose to create a separate buildvehicle.lsp? I have tried "messing" around with that option and trying to separate the part of the code that begins the buildvehicle, but that has yielded unsuccessful results as well.

Thanks for your time and help!,

Lisa 22:56, August 17, 2010 (UTC)

Can you tell me where you downloaded the program and where you saw the instructions to type BV? I hope to check it out for you. Tom Haws 01:05, August 18, 2010 (UTC)
Thanks again for the help.
I originally downloaded version 1.1.10 off the %29 and I was revisiting the website to learn how to build my own vehicle. I saw the instructions to type BV in the "getting started" section of the code. This a copied and pasted expert from the code:
Second, load and run BuildVehicle. It will ask you for all of the parameters

for your vehicle, and draw a unique attributed block. You can build a library
of vehicles for future use. BuildVehicle.lsp runs using "BV" or "BuildVehicle"
from the command line. Axles should be the "centroid" of any group of multiple

Lisa 12:36, August 18, 2010 (UTC)
I may have had a break through... I was just "messing" around with the Turn.lsp and found that if I just do the g for generated vehicle and then type in a name for new vehicle and go from there... then I am creating my own block for a vehicle correct? I think this is what I needed... am I correct? it's silly that it has been there the whole time right in front of me if this is it! ha!
New question: We noticed in a response to someone else, if you have a counterclockwise turn that you woulod have to do something more involved. We have a continuous turning path that consists of a series of left hand and right hand turns since the left hand turns would be counter clockwise, do I have to something different than just using the standard Turn.lsp program prompts?
Lisa 13:14, August 18, 2010 (UTC)


1. Yes, I am the father of TURN.LSP, but sometimes I don't feel I know much about it. Bear with me.

2. You found what I hoped you might find. I hope you or I can get a chance to revise the instructions accordingly.

3. I never did, to tell the truth, quite understand the left and right turning problem described. I am pretty sure all he was pointing out was that the blocks have their insertion point at one side or the other. The funny thing, though, is I thought it was all based on the centerline. You can tell I don't get into using or programming it as often as perhaps I should. In any case, there is no difference between a left turn and a right turn as far as the modeling goes, if that's what you were wondering.

Tom Haws 04:06, August 19, 2010 (UTC)


TURN.LSP tracks along the path of the FRONT LEFT tire when modeling. You must therefore manually draw the path of the front left tire as a polyline; the routine then uses that polyline to generate the model. AASHTO's Green Book shows turn radii as tracking along the front left tire as well, but the minimum radius for vehicles are always shown turning to the right (clockwise). So when you draw a path that is turning to the right, you simply make certain that the radius is greater than or equal to the minimum turning radius as listed by AASHTO. However, when you turn to the left (counterclockwise) the right front wheel is now the outermost tire. The problem here is that the routine tracks along the LEFT front tire, not the RIGHT front tire. The minimum turn radius for a left turn and a right turn are the same, however the minimum turn radius is always for the outermost tire. For a right turn, the minimum turn radius is for the left front tire; for a left turn, the minimum turn radius is for the right front tire. Imagine two concentric circles. The outermost circle would represent the minimum turn radius regardless of whether or not you are traveling clockwise or counterclockwise. However, as already stated, the lisp routine always tracks along the LEFT front tire. Therefore, if you wish to turn to the left you have to figure out what the minimum turn radius would be for the front left tire. You cannot use the minimum turn radius as listed by AASHTO because it is for the outermost tire which, for a left turn, is the right front tire. So for a reverse turn to the left, where the right front tire becomes the outermost tire, the radius of the path of the left front tire has to be reduced by the distance between the center of the two front tires to approximate the radius. (This is not exact due to how wheels sit in relation to the axle as a vehicle is turning.) However, I have noticed that any discrepancy is negligible and not even noticeable. So the answer is: for right turns, make certain that the radius of your turn is greater than or equal to the mimimum turn radius as listed by AASHTO. For a left turn, subtract the distance between the the center of the two front tires from the minimum turn radius as listed by AASHTO and make sure that the radius of your turn is greater than or equal to the result. So if you have a vehicle with 8 feet between the center of the the two front tires and AASHTO shows a minimum turn radius of 45 feet, then your polyline representing the path of your left front tire needs a minium radius of 45 feet for a right hand turn and a minimum radius of 45 - 8 = 37 feet for a left turn. REMEMBER, the routine tracks along the LEFT front tire when generating a model. Always draw your polyline for the left front tire and place the center of the left front tire of the vehicle block on the end of the polyline before running the routine. If you use the routine to create a vehicle block, you will see that the resultant vehicle block will be created with a small circle right in the center of the left front tire. The center of that circle needs to be on the endpoint of your polyline and your vehicle needs to be parallel with the starting line segment of your polyline.

IMPORTANT: The above instructions for a left turn should only be used with the AASHTO vehicle blocks provided for download on the main article page. They were created to ensure proper modeling given that the LISP routine tracks on the centroid of the left front tire and AASHTO shows turn radii as tracking along the outermost edge of the left front tire. See #Kevin's library and insights about wheel width above for futher clarification. (Note that the distance between the center of the two front tires as referenced above can be measured directly from the inserted block.) Additionally, see quick start instructions I posted on Eng-Tips forum located here: Turn.lsp Issues. My user name there is "Civilisfun".

A NOTE REGARDING THE CREATION OF CUSTOM VEHICLES. If you create a custom vehicle that is not AASHTO, you must know what the minimum turn radius is for your custom vehicle. The minimum turn radius is determined by the steering mechanism of the vehicle. This is why some cars can make tighter turns than others. Therefore, if you create a custom vehicle, you can't just put in any radius you want because the lisp routine will track along any path you create, regardless of whether the path is drawn properly or not. You could put in a super small radius and the routine will still track along it. You MUST have a minimum radius for your vehicle, determined by the vehicle's steering mechanism, and not use a radius which is smaller. I have created a couple of custom vehicles and not known the minimum radius but was able to make a good guess based on similar vehicles with similar wheel bases as shown in AASHTO's Green Book. If you don't have access to your custom vehicle's minimum turn radius, you'll have to make an educated guess.

CLARIFICATION OF HOW TURN.LSP TRACKS. In order to clear up confusion as to how TURN.LSP tracks, note that it always tracks along the path of the center of the FRONT LEFT tire when modeling. Below is some text copied directly from the LISP routine for reference purposes:

GETTING STARTED At minimum, all TURN.LSP needs from you is a front left wheel path polyline and a BuildVehicle block. Draw the path for the vehicle as the route taken by the front left tire. A future version of this program might add path by centre or by right side of vehicle, to suit other driving standards. Note: Place the vehicle at the start of the path using the centre of the FRONT LEFT WHEEL, which should be marked with an "x" type figure. Rotate the vehicle to the approximate correct starting angle. 1.1.3 Various, including Centre of Wheels used instead of Outside of Wheels (vehicles steer on the centroids of the wheels, not the rims), "Set-out" point added at Front Left wheel.

I would add one minor note to the above, however. Notice that is says, "FRONT LEFT WHEEL, which should be marked with an "x" type figure." This is actually incorrect. The marking is not an "x" type figure, but a small circle.

P.S. Hi, Tom. I deleted my old email address and my IP address has changed but you can leave messages on the talk page for this IP if you like.

Kevin 01:00, August 25, 2010 (UTC)

I think that makes sense. Thanks for the explanation, Kevin. Tom Haws 03:51, August 25, 2010 (UTC)
My Pleasure, Tom! Kevin 04:20, August 25, 2010 (UTC)


I have tried to use turn.lsp in intellicad/Carlson Civil suite and in ProgeCAD free version. Neither worked. Has there been any discussions on making turn.lsp work in these intellicad based products?

I have written some lisp in the past but at a basic level. Just wanted to learn from others input on this before I dig to deep into it.

Thanks for putting this source code out there for all to use! --Michael K.

I would be pleased to mentor you. And I would be pleased to help you get it working in ProgeCAD. It should work for Bricscad. And I bet that getting it to work for ProgeCAD wouldn't be too tough.
Feel free to write more. Maybe we can connect screens and phones and I can look in at what you are doing and seeing. Call now or later. 480-389-4583 Tom Haws 20:51, August 22, 2010 (UTC)

Here is the error I get from ProgeCAD 2009 Smart and ProgeCAD 2010 30 day trial:

Command : ._layererror: rejected function
(COMMAND "._layer" "t" (CAR LAYER) "on" (CAR LAYER) "u" (CAR LAYER) "m" (CAR LAYER) "c" (CADR LAYER) "" "l" (CADDR LAYER) "" "")
(FOREACH BASENAME (QUOTE ("TruckBody" "TrailerBody" "HitchPath" "TruckBackLeftTirePath" "TruckBackRightTirePath" "TruckFrontRightTirePath" "TrailerBackRightTirePath" "TrailerBackLeftTirePath")) (SETQ LAYER (TURN-GETLAYER BASENAME)) (COMMAND "._layer" "t" (CAR LAYER) "on" (CAR LAYER) "u" (CAR LAYER) "m" (CAR LAYER) "c" (CADR LAYER) "" "l" (CADDR LAYER) "" ""))
(LOAD "C:/Install/turn/turn-1.1.11.lsp") 03:12, August 23, 2010 (UTC)Michael K.

I commented out the entire MakeLayer function and where it was called. Then I made the layers manually and ran the lisp successfully in ProgeCad and Carlson/Intellicad. I will let you when I clean up the MakeLayer function for Intellicad. Mjkane22 04:30, August 23, 2010 (UTC)Michael K.

Michael, does the following snippet run and return "1" in your flavor of intellicad? (vl-load-com)(vl-prin1-to-string 1) Tom Haws 04:55, August 23, 2010 (UTC)
I don't believe any intellicad runs Visual Lisp programming. I saw post that said to stick with straight lisp or change to VBA.
Mjkane22 16:01, August 23, 2010 (UTC)Michael K

That was my understanding. But now BricsCAD runs Visual Lisp. And now AutoCAD is deprecating VBA. Go figure. Tom Haws 22:51, August 23, 2010 (UTC)

Metric and Imperial Trucks[]

I am a new user of the Turn routine. I have been able to get some truck blocks to create a path at metric scale, but others create a path for a imperial scaled truck. What am I going wrong?EnaidKrut 01:42, October 30, 2010 (UTC)Enaid Krut

I'd have to see the conditions that the different results happen under. if I had to guess, it would be the (newish) autocad "insert units" settings that may be at play. ie, this can be at variance with the live units in a drawing. so, the user should check what their units settings are, and what their insert units settings are. if they are in an imperial drawing, using imperial units, but the insert setting is for metric, the scale might be out by 25.4. Please check this. we could add a line at the beginning that would check this, or that could temporarily override it. -TURN.LSP developer Stephen H.
I have opened a drawing, and using units dialog box, set the insertion scale to 'metric' . I have been inserting the truck blocks supplied with the turn lisp routine via the 'ddinsert' command. The one truck block that does insert and has metric text 2.6m for the width of a truck (not imperial text 8.5 ft) and generates a path has been named "VEHICLELIBVEHICLELIBBUS-40" but the block chosen for insertion is called "VEHICLELIBBUS-40". I have tried to duplicate this condition in a new drawing but it is not working. Can it be the 'turn.lsp" version I am using. Currently I have 'turn 1.1.7' but could be mixing the various turn lisp routines downloaded.EnaidKrut 16:53, November 2, 2010 (UTC)Enaid Krut
Enaid, It sounds like you are attempting to use the blocks available for download on the main article page in a metric drawing. These blocks were created in imperial units for use in drawings that are also in imperial units. The blocks were not created for use in metric drawings. You might need to either create your own metric blocks from scratch, or try converting the existing imperial blocks to metric. There is a website with lisp routines which convert imperial to metric and metric to imperial HERE with instructions. I've never tried this but it is worth examining. Also, you could try just inserting the blocks normally and scale them by the appropriate scale factor to convert to metric. Keep in mind, however, that the blocks were created in feet, not inches. Kevin 17:19, November 6, 2010 (UTC)
If you use "-dwgunits" in AutoCAD you can convert the drawing to other units automatically. Follow the prompts, and yes, scale objects in current drawing.. You then need to edit each of the attributes to the correct metric defaults as it uses these numbes for drawing the lines. (multiply the feet numbers by 304.8 to convert to mm.  TvH 01:24, October 1, 2014 (UTC)

Where to put TURN.LSP?[]

To where in the Audocad program do I copy the TURN.LSP software. I did a search for *.LSP files, and found I am lost. Thank you. -David S.

David, I suggest two possible ways to use turn.lsp. Option 1: Put turn.lsp anywhere you'd like, then drag it with your mouse from Windows Explorer into the drawing area (this works with AutoCAD) to load it in any drawing. Option 2: Put turn.lsp anywhere you'd like, then use APPLOAD to add it to your Startup suite if you want it loaded in every drawing. There are other, possibly better ways to do it, but they are more involved. For example, option 3 is to create yourself a folder named something like AutoCADUser, add that folder to the Support Files Search Path, create in that folder a text file called acaddoc.lsp, and inside acaddoc.lsp, write the following "(defun c:turn () (load "turn") (c:turn))", and put in the same folder the turn.lsp file. Tom Haws 02:35, October 30, 2010 (UTC)
Unless you know what you are doing or need a different approach, I would recommend just sticking to dragging the file into your drawing. Does that work suitably for your purposes? Tom Haws 02:35, October 30, 2010 (UTC)

How to model two trailers?[]

I was wandering if you could created 2 trailers of a truck. In Australia this is a common vehicle being a B-Double having 2 hitches. -Rudy

The only way to model two trailers is in stages. You would have to model what you can in the first stage, and then use the path created by the first stage as the front path for the next stage. I realize there's a complication with this in that the hitch may not be on top of the rear wheels. I'm afraid that is currently a limitation of TURN.LSP. Tom Haws 01:14, September 7, 2011 (UTC)

Trouble running TURN.LSP[]


not sure if i am missing something, but all i get is a shading or anything>Any ideas what i am doing wrong

Cheers87.127.17.99 13:58, March 16, 2012 (UTC)rob

Rob, you are trying to run TURN.LSP and you don't understand the results you are getting? It may help you to know what to expect if you open the TURNTEST.DWG to see how the results look for the templates. It may also help if you look at the youtube video rustysilo posted Tom Haws 21:35, March 16, 2012 (UTC)

Confusing results[]


I am having a problem of using the Turn.lsp. We download the version 1.1.12. The instructions that we come across do not match with the instructions in Youtube Tutorial which is Automate Turn.lsp for Quick Turning Paths.

I first select the centre of the front left wheel then the initial midpoint of back axle. The path that I have obtained is different than the one shown in Youtube Video.

I would like to see the turning path as it shown in Youtube Video (calculation steps, swepth width, etc.)

Thanks for your help


What are you seeing that is not what you expect? Do you need to tell it to skip fewer calculation steps between plots? Tom Haws 15:27, April 25, 2012 (UTC)

I only see a single path line. I have already change the number of calculation steps but it has not change at all.

In Youtube Video, the axle lines are also shown. I download the turn.lsp from the link below:

Is it the final version? Or is there any other .lsp that I can find?


It has been so long since I've interacted with TURN.LSP that I downloaded it and tried it this morning for you. It draws a lot of stuff. Maybe I can post a Youtube video of the steps I followed. Tom Haws 17:06, April 25, 2012 (UTC)
I'm uploading the 8 minute video. Watch it when it's ready (in about an hour maybe) and let me know if it helps. Tom Haws 18:11, April 25, 2012 (UTC)
In my test that I show on Youtube (it's ready now) I get the source code from this wiki page. Tom Haws 01:26, April 26, 2012 (UTC)

I am very grateful for your help. Your video has been very useful to me.

But I still have questions?

1)Could this turn.lsp can work with metric system?

2) I drew the turning-path with your turn.lsp however, the turning path does not satisfy me much.

In order to check my turning-path with yours, could you give me your e-mail so that I can send my road and vehicle?

Also, the attached file is in the below link:


1) Metric should be just fine, since the program is unitless.
2) I opened your drawing, but I'm not sure what to do with it. You need to answer the following questions at least: a) How does your trailer steer (what does the front axle of the trailer do?), since there are two axle groups? b) what is the path you want to try to follow with your vehicle (you need to draw the path so you can follow it)?
-Tom Haws 14:45, April 27, 2012 (UTC)

a) Those are the rear axle of the vehicle body.

b) I just showed on the drawing and here is the new link:

Thanks again for the help

Missing function[]

I am using AutoCad 2012. It says the file is loaded correctly but then when i attempt to draw the line i get this error message( ; error: no function definition: TURN-SETLAYER ). Has anybody ever seen this and how do i fix it?

I've have general trouble with the lisp environment in AutoCAD 2012 unrelated to TURN.LSP. Have you searched in your downloaded file for (defun TURN-SETLAYER... ? Have you checked the command line for errors when you load the file? Tom Haws 01:21, July 17, 2012 (UTC)

Turn.lsp Instructions[]

Hey, Tom. I finally got around to creating an official set of instructions for running Turn.lsp with the vehicle blocks I donated. I left you a an email at with specifics. Kevin-- 23:30, August 9, 2012 (UTC)

Tom, I see you already posted my PDF on the main page. Thanks for the quick response. I made a few additional edits to the article to clean it up a little and to clarify a few things pertaining to the AASHTO blocks and PDF instructions. I think the PDF instructions will clarify a lot for users who have had trouble using the routine in the past and will make things much easier for new users. Thanks. Kevin-- 03:24, August 10, 2012 (UTC)


Hi, I have Carlson Survey Embedded Autocad 2010. The tutorials and instructions for this program are not designed for my platform layout. I don't have an app button and the commands are all "unknown". The Customize User Interface is where I believe I need to load this program but going about doing it also leads to difficulties. There are no .lsp files I can find. I've gone in circles going through different instructions and haven't got anywhere. Any help with the direction to go would be greatly appreciated. Thank you.

We may want to discuss this over Skype. You can add hawsfamily and contact me. Or you could phone me at 480-201-5476. Tom Haws (talk) 17:12, November 8, 2012 (UTC)

Twin Steer trailer modelling[]


Just discovered TURN.lsp. Never had experience of using lsp in CAD before, although did once get to mess about with AutoTurn.

I was wondering if turn.lsp could be used to model the path of a trailer with a rear steering axle? I'm currently managing the build of my own wind turbine project and would like to verify the entry point of the bade delivery through some tricky turns.

Any thoughts? I understand that this may not be possible. Everything has it's limitations.



Hi, A.F.
Turn.lsp currently only supports modeling paths of vehicles with either no trailer or one trailer; in other words, one hitch. It sounds like you're asking about a vehicle like a fire truck with two steering mechanisms. If this is indeed the case, then the answer to your question is "no". If you're talking about a vehicle with "only" a rear steering mechanism, please see "Reverse Curves, Turning in Reverse, Overhang Paths" at the beginning of the talk page. That should clarify any questions you have. Kevin 02:33, April 21, 2015 (UTC)

Intellicad compatibility: measure, layer issues[]

With regards to measure, the measure function in Intellicad creates a point at the beginning of the polyline, whereas in AutoCAD it does not. This was fixed with an IF statement to determine whether the user is running Intellicad. 

A "-" was added to layer in order to use the command line version. 

I will try to get this added to the source code. More hopefully later. Tom Haws (talk) 18:50, October 22, 2015 (UTC)

My summary is below: Tom Haws (talk)

  1. (command "._undo" "g") does not work. Have to use (command "._undo" "group")
  2. (command "layer") does not work. Have to use (command "-layer").
  3. MEASURE command puts a point at beginning of polyline. Have to change code to skip that point.

-Tom Haws (talk) 20:58, October 22, 2015 (UTC)

I fixed these issues and released version 1.1.14 here and at Tom Haws (talk) 15:58, October 23, 2015 (UTC)


Do I have to keep my units the same as the turntest.dwg?

It is set to decimal inches and the AASHTO blocks are set to decimal feet, so I'm a little confused.

I had to import the P (passenger) block into the turntest at 1/12 scale to get it to work, and then run it.  Everything is 1/12th of the size it should be though so I don't know how to use this.  If I scale everything in the turntest.dwg by 12, then the lisp doesn't work.

thank you 23:02, December 16, 2015 (UTC)Tyler

Mainly I want you to know I see this and your comment at Youtube. Sorry for the delay. I am not sure what you need to do, but I wonder if you are checking the calculation step and plotting step after you scale things. Try closing and re-opening the drawing if this is confusing to you. Tom Haws (talk) 23:52, December 16, 2015 (UTC)

Based on your comment here and on YouTube, you are using the turntest.dwg drawing and it is set to inches. The vehicle blocks were created in feet drawing units, not inches. So if you insert them into a drawing with the drawing units set to inches then they will come in 12 times too large because there are 12 inches in a foot. If using the AASHTO block library provided here on the main page, insert them into a drawing that was created with the drawing units set to feet. Don't use turntest.dwg, use your own drawing set to feet. 00:08, January 18, 2016 (UTC) Kevin

Bow-Ties being drawn for trailer along path.[]

I am attempting to use Turn.lsp on BricsCAD v14.  It seems to run witout generating any errors.  However, the rectangle representing the trailer on the path, is always drawn as a bow-tie.  Obviously two of the points are being reversed.  Note that the vehicle block itself is being drawn correctly.

If I use the provide TurnText.dwg and the provided vehicle, it works properly.  But, if I add a vehicle I define, or one from the provided library, the trailer is always drawn as the bow-tie.  The bow-tie behavior is the same if I start a new drawing from scratch and whether I define my own or use one from the provided library.

Cadcoke5 (talk) 03:12, April 4, 2017 (UTC)Joe Dunfee