PDA

View Full Version : Programming Tools used to write code



richards
04-05-2005, 01:18 PM
During the process of releasing the Doors.Exe program (which started as a Linux project), I've had many inquiries about the programming tools that I use to write programs that generate SBP files. For Linux users, the answer is simple: Do a full install of RedHat Fedora Core 3 and you'll have all the tools that you need.

Windows XP is a different situation entirely. On April 1st, when I thought I could spend a few minutes to compile my program to generate an EXE file, I learned that my existing tools (2 Borland compilers and 2 Microsoft compilers) were not going to work. Either they produced an EXE file that wouldn't work on Windows XP or they generated a file that would be too large to email. After a little head scratching, a little hand wringing, and a few hours searching the Internet, I found the combination of programs that works well for me.

If any of you are interested, send me an email and I'll send you a list of the programs that I use that closely approximate the Linux environment that you can download without cost from the Internet. (You will need a fairly high speed connection because the total size of the files is more than 100 megabytes.)

-Mike
miker@xmission.com (mailto:miker@xmission.com)

paco
04-06-2005, 11:46 PM
SB code too can be used a to write a parametric code for machining door (and other stuff too)... Yes, only SB code!

20
...this one use a V tool bit (any) and a profiling tool bit (flat end; any). It have 13 parameters to enter about this door; such as V tool angle, stepdown, groove depth, profiling bit diameter and again max stepdown, material thickness, door width (X) and height (Y), stile width, top arch height, X and Y offset of door int material blank and a "auxiliary" safe Z for low Z rapid traverse... I plan to add some more; tabs, groove width, use of other shaping tool bit... nesting (joke!)...

21
Ted's code is quite capable of VERY interesting things... and readily available to all; no need more than SB documentation and a text editor...

Oh and YES, the corners are sharp...

22
Still, Mike's door.EXE and it's code is quite COOL to have (and to use) to learn C... Thanks again Mike!
I'm willing to share too; if interested, mail me.

More later...

8-)

mrdovey
04-07-2005, 11:40 AM
The variety of approaches is interesting. I've been using C to produce a lot of my SBP code - sometimes as pre-run code generators to generate a complete cut files that are run after the C program has been executed, sometimes as runtime code generators that are invoked from within a SBP program to generate a temporary SBP file that is subsequently invoked by the main SBP file, and sometimes as programs that generate SBP files and then invoke the SB executable to perform the cut.

The easiest approach for me has been to define C macros like:

#define M2(x,y) fprintf(fp,"\tM2\t%.4lf,%.4lf\r\n",(x),(y))

and then write C code that strongly resembles SBP code like:

M2(cur_x = r * cos(a),cur_y = r * sin(a);

when I'm ready to produce PRT activity. This approach allows me to bring full use all of the C language constructs to bear on part programming needs, as well as the development of a library of reusable C functions to do things like retrieve operating parameters from the SHOPBOT.INI file as:

old_xy_move_speed = sb_parm("VS",1);

to retrieve a move speed that I'm about to change but will want to restore later.

It definitely makes the part programs run faster. Here's a picture of a box and lid I cut yesterday with a part program originally written as C:


23

alabama_davo
04-07-2005, 11:44 AM
When you cost out the time you spend with all of the codes and parameters and figuring and nesting....I have recovered the COST of DoorBot more than 25 times and look to do this 25 more and 25 more etc...My ShopBot is far too expensive to sit in the shop and collect dust while I mess around re-inventing the wheel. The reason I bought DoorBot is because this IS NOT A HOBBY and I like to use deposit slips far more than withdral slips if you know what I mean. Mike I cannot figure out the software, probably my skills. Thanks for the opportunity and I hope you keep making it better. The older I get the less I want complications with my business.
Thanks

mrdovey
04-07-2005, 12:34 PM
Dave...

You've put your finger on an interesting aspect of the ShopBot and CNC tooling in general. Nearly everyone has (at least slightly) different interests and strengths.

A steadily increasing portion of my business has come from non-local sources via the Internet; and has been a mix of off-the-shelf products and custom projects. The box shown in my earlier post came about because I wanted a combination shipping container and storage box. I spent about twenty minutes evening before last putting the code together, and ended up with a program to generate "egg crates" of whatever size and pocket configuration I wanted.

Having produced a solution to one problem, I'm about to start contacting some of the local manufacturers to see if any would be interested in buying specialized shipping containers in quantity. The program I've written may produce what they want; but even if not, I have a sample to put under their noses and a headstart on what they might want.

I'd like to suggest that the software is another tool whose skillful application can lead to increased business activity - and that if you see it only as a hobby activity, you're overlooking something very fundamental to CNC.

...Morris

mikejohn
04-07-2005, 12:46 PM
Dave,
From what I've read on this Forum, DoorBot is a very good programme, but it does only make doors.
Morris' approach can have many and varied products.
As Morris almost said, 'horses for courses'


...............Mike

stickman
04-07-2005, 12:48 PM
Morris,

What material did you cut the box out of?

Jay

mrdovey
04-07-2005, 01:05 PM
Jay...

The box pictured was cut from a piece of scrap 3/4" MDF - but I've been wondering if I might want to sacrifice a piece of cherry for a box for my own use.

...Morris

bruce_clark
04-07-2005, 01:07 PM
Dave,

I agree with you 100%, IF all you want to do is press a couple of buttons to make things. BUT, if you look at this section of the Forum's heading, it is "Developers".

Yes, things like what Mr. Dovey is doing may be complex, but he may be one of the only people in the WORLD who do can do something like that. Sure, someone could spends HOURS in a CAD/CAM program drawing that part, but then Mr. Dovey only has to punch in a few numbers and his program is DONE. So, if you were competing with Mr. Dovey making boxes like the one pictured adove, YOU would be the one writing "widthdral slips" while Mr. Dovey was making "deposit slips".

Mr. Dovey's complex of routines today may be Mr. Dovey's BoxBot(c) of tomarrow, just as Mr. Mason's cabinet door spreadsheet turned into the DoorBot program.

As for DoorBot, I think it is a GREAT package if your business is making MDF cabinet doors. You get software AND support which is something that is not always available with free software.

To me, what things like what Mike Richards is doing (giving to the ShopBot community) and Mr. Dovey's "know how and show how" and Paco's ability to do the same thing as Mr. Richards, but using ShopBot language is what make the ShopBot community so great.

Bruce
PS I am kidding about the BoxBot copyright.

alabama_davo
04-07-2005, 01:09 PM
Hey Mike, I bought the software to make doors...and make them well. I just got a Motorola V600 ($350) phone and it takes pictures, video, has games, works ok as a paper weight...guess what? Crappy phone! Poor reception lots of dropped calls, bad idea, should have stuck to my 10 year old Nokia.
I want the KISS principle and that's it. I like to walk into my shop and be productive in 10 minutes and making sawdust, if not I consider my ShopBot a VERY expensive hobby...

richards
04-07-2005, 01:11 PM
Dave,

Addressing the time factor of coding, parameters, etc., that's exactly why programs are written. It takes time to write the program - once. After that, a program does all of the tedious, non-productive work for you. Some projects, such as cutting doors, lend themselves to 'canned, off the shelf software', since only a few parameters need to be changed from door to door. Other projects are better handled with the traditional methods of AutoCAD, PartWizard, etc., mainly because of their complexity or large number of parameters per part.

My greatest frustration last July when my alpha was installed, was the time it took to design a part compared to the time it took to cut the part. The Alpha is FAST, but I'm a slow designer. I could see that unless I was cutting many multiples of a part, that I would have to find a faster way to design the part. Sometimes canned software is available, sometimes it isn't. When you find something that works for you the problem is solved and parts are cut productively.

Sorry about the difficulty of the software. I'm known for writing code that requires a lot of 'head scratching'. (If you could live for just a few minutes inside the head of a left-handed programmer, would walk away in bewilderment wondering how us left-handers can do anything requiring logical thought.)

Why not try Bruce Clark's excellent front-end to my Version 2.01 doors program? The pre-release version of Bruce's program, that I tested this morning, blows away the best of the commercial software that I've seen to date - and it doesn't require any deposit or withdrawal activity at the bank.

-Mike

mrdovey
04-07-2005, 02:53 PM
There's another advantage to the "component library" approach...

I'm planning to use the same box software (less the rectangular pocket function) to machine a storage box with some odd-shaped custom pockets: one to match a pistol, one to match a magazine, and a grid of round hole/pockets to hold ammo. The box hasn't been laid out yet, but the large pocket will look like:


24

I'll probably cut the 10" x 6" box out of walnut or cherry and line the pockets with heavy felt. When done, I think I'll put a photo on a web page with an offer to produce the boxes for $250 each (I think that won't be considered unreasonable by prospective customers, and should provide a reasonable return :-)

...Morris

richards
04-07-2005, 03:46 PM
Morris,

Your April 7, 2005 - 11:40 am post finally opened my eyes. (My oldest son, Eldon, often makes brilliant observations about me, such as: "Dad, why do you always pick the hardest way to do things?".

Your programming example using the #define statement illustrates that very fact. Even though I've used that concept since 1977 in almost every other project, for some reason this time it eluded me. I can hardly wait to get back to the shop and rewrite some code for a new project that I'm working on.

(And to think that some of you thought that the doors program was my reason for living - when it is really just a toy that I like to play with - albeit a somewhat functional toy made useful by Bruce Clark.)

-Mike

mrdovey
04-07-2005, 04:02 PM
Mike...

<geek mode>

Well, actually it's a trade off. If you code this as a macro, you generate a fprintf() call every time you code M2(), which will be fast but bulkier than absolutely necessary.

If you coded an m2() function, you minimized the amount of executable code with a very slight cost in execution time.

I'm sufficiently lazy that I coded a whole set of macros and stuffed 'em all into a header file.

</geek mode>

As long as the program works as intended, it probably isn't terribly important how you got there. (-8

...Morris

jsfrost
04-07-2005, 04:59 PM
Moris,
I think I see a market for your "ShotBot" program. Let us know when it's done.

Jim

Brady Watson
04-08-2005, 11:56 AM
As said before, there are some things that a CAD/CAM package just cannot do efficiently. CAD/CAM packages out there are akin to Swiss Army knives...they do a lot of different things fairly well, but not as well as a purpose-built tool, like a regular screwdriver, bowie knife or pliars, for a given application. The computer is just a tool...and so is the software. The ability to make your own tools is no different than the cavemen of eons ago...one could say that making your own tools is one thing that seperates you from the animals, or in this case, something that gives you a competitive advantage over another machinist.

Making your own dynamic/flexible tools within the context of botting, saves you coulntless hours of time in the future. Doorbot is just one example for doing doors. For example, Wes is catering to those who are not programmers, but want all the advantages of a flexible/dynamic interface for create a multitude of doors. We programmers and hackers do the same thing that Wes does day in and day out for various applications that suit the way WE work as individuals. So making your own software to generate code will help you to make parts not possible using conventional CAD/CAM. It will allow you to tell the maching EXACTLY how YOU want it to move, and in turn, will probably be more efficient than any other means if you are going to make these types of parts in different sizes or high quantities.

I think that some feel that making your own program to do XYZ is a waste of time..."Why spend hours programming when I can buy ABC and keep that machine running?"...Well in very few cases that is a valid point. By creating your own routines, you are saving time in machining the parts on the back end, AND in many cases, creating parts that are either impossible to easily design in CAD/CAM or too expensive to design because the software to do it is out of reach.

Programmers are ALL lazy...it goes along with the territory. So if PartWizard can do something in 2 minutes, we'll run it in there instead of making an individual program to do it...Where it makes sense, or there are a lot of difficult moves to take into consideration, a custom program is probably the way to go. Think about ProjectWizard and Bill's Boxmaker...He spent some time making it so you could do many different sizes of boxes. To do just one that interlocks, may have only taken 5% of the time it took to make the program. BUT...he now has THOUSANDS of different boxes at his fingertips by just plugging in numbers. I'd say it was time well spent.

Not sure if anyone uses Rhino, but I often generate RhinoScript within VB to parametrically create 2D and 3D designs. From there I can save the output and toolpath as necessary. It's pretty neat because you can, let's say, create an X and Y 'leg' of your part, tell Rhino to mirror it, join it and export it in one shot.

-Brady

srwtlc
04-08-2005, 12:29 PM
Morris,

I make a lot of those gun boxes, here (http://www.talkshopbot.com/forum/cgi-bin/discus/show.cgi?tpc=31&post=20537#POST20537) and here (http://www.talkshopbot.com/forum/cgi-bin/discus/show.cgi?tpc=31&post=22623#POST22623). How would you go about getting the outline/pocket for the various guns? I currently have 10 different models. If the person or officer has some modifications (sights, grips, etc.) then there's a variant for that model. At present I either get the gun or a plastic replica and do a outline in CorelDraw. A probe would work also, but I don't have one.

Brady Watson
04-08-2005, 12:46 PM
Scott,
It took me a total of 2 minutes to save the gun pic above, convert it using the FC command, create a toolpath and preview as shown below...Hats off once again to Bruce for doing such a great job on the BMP converter.


25

-Brady

srwtlc
04-08-2005, 03:32 PM
Brady,

But you have to first get that perfect or close to perfect bitmap representing the shape of the gun. If the bitmap isn't right, then the gun isn't going to drop in nicely. Besides, cutting the whole surface and the pocket along with the wall quality (stepped) wouldn't be acceptable in this situation. Time to cut would be much longer also. Then there is the problem of various knobs, buttons, levers, and cylinders that need separate pockets within pockets. There are times that I just can't get my hands on the gun (understandable) and sombody elses attempt at a .bmp or .jpg seldom if ever fits. I like to at least have an original scribe of the gun with a stylus giving at least 1/16" to 1/8" offset sent to me in those cases.

Scott

P.S. Do you know of some good in depth learning tutorials for Rhino? I've done the flash light and rubber ducky thing
, but would like something more.

Brady Watson
04-08-2005, 04:07 PM
Scott,
I know what you mean about getting the tolerances closer. In that case, your best bet is to trace a photo out in CAD. You should be able to pull a pic down off of the net of just about any pistol or rifle. If you know at least one dimension of the gun, then you can scale it until it matches that dimension. I have done this several times with great success. Acme TraceArt is a great way to do this as well for only about $80. Corel has one too that isn't too bad.

I have found that the best tutorial is creating something that you want to build....and hacking your way thru until you get it right. The problem with the tutorials is that they don't address what YOU want to do in the software...but they are good for introducing you to the tools and how to use them. Now that you have done the flashlight and duck, you can apply that to what you want to make.

I really like Rhino for it's rendering abilities. You could digitize that gun pocket for instance, and then create the rest of the box easily in Rhino, render it and show a customer for verification. I find that it really fills the gap between what the customer wants...and what you need to do on your end, to ensure that you are both thinking the same thing. Additionally, it is really great for seeing how assemblies will fit together and for spoting potential caveats along the way.

It took me a little less than 10 minutes to copy the pic above into BobCAD, trace it out, export as DXF, pull the DXF into Rhino, make the box and gun recess and render as shown below...


26


-Brady

srwtlc
04-08-2005, 05:39 PM
Brady,

I have found that the best tutorial is creating something that you want to build....and hacking your way thru until you get it right.

Yeah, now that you mention it, that's how I learned my first cad program after being a deisel & heavy equipment mechanic. And then came Vector and I had to do it again.


Scott

mrdovey
04-08-2005, 05:56 PM
Scott...

I like your boxes - you've done some nice work there!

As Brady suggested, I took a digital photo and imported it into DesignCAD where I traced it, deleted the imported image, and saved the traced line as a drawing file and again as a jpeg. I pulled the jpeg up in PaintShop to floodfill and shrink for posting here.

I have the probe but haven't ever used it. It just seemed less hassle to snap a jpeg picture.

Brady...

I've just got to admire how well you've learned to use the tools! I'm still hoping to catch up with you someday!

...Morris

Brady Watson
04-08-2005, 07:47 PM
Namaste Morris...I've learned a thing or two from you on this crazy board!

-Brady

mrdovey
05-11-2005, 11:34 PM
I've been trying to figure out what to do with the rest of the sheet of MDF I bought to make the shipping/storage box prototypes shown in my earlier post.

This weekend I decided to see how many different box designs could be cut from the remainder. I'm going to build compartmented boxes and if I like the result, I'll cut a lid - and if I still like it after that, I'll produce it in hardwood. It's turning out to be an interesting relaxation.

Here are boxes with 3, 6, and 7 compartments...

27
Morris

Brady Watson
05-11-2005, 11:50 PM
Morris,
They look great! One question....Do they exist in the physical world in that pic, ir is that a rendering? Hard to tell....

-Brady

paco
05-12-2005, 12:26 AM
I would guess this is a good picture on a sunny day!!

8-)

Still, the inside corners look p'etty sharp... Very cool parts Morris!

mrdovey
05-12-2005, 01:25 AM
They've been rendered by my PRT96 and were shot on a scrap of 1/8" hardboard - nothing but the worst of materials here.


The top three pieces were cut with a 1/8" down spiral - which seems to help the edges and cavity bottoms come out just a bit cleaner.

The bottom piece (a lid for the box posted earlier) was cut with a 1/2" straight bit.

Paco, the photo was shot on a dark, rainy day in a shop with no windows and only two (incandescent) lights. Any credit for picture quality belongs strictly to the camera - which would seem to be smarter than the photographer. The "rendered" appearance is produced (I think) by the lossy JPEG compression.

I'm thinking of cutting the same cavity pattern into the tops for a contrasting veneer inlay to make 'em a bit more interesting.

jf_allie
05-12-2005, 02:26 PM
Morris,

Maybe you could use colored wood paste for your inlay on your MDF versions of the boxes. I'm even thinking bright colors...

jf_allie
05-16-2005, 02:58 PM
Mike,
Why not put your list of Windows programming tool up on this thread... you wouldn't be imposing at all. After all this is precisely what this thread is for.

By the way, here is a link to a free C interpreter that makes learning and using C slightly less painfull for the novice:
http://www.softintegration.com/

richards
05-30-2005, 12:30 PM
Jean-Francois,

Here is the list of tools that you requested. Note that the tools make my Windows computers act more like my Linux computers. There are other tools available, some of which are excellent; but, these work and they are available online at no cost.

Editor:
Crimson Editor found at www.crimsoneditor.com (http://www.crimsoneditor.com). Cedt370r.exe (This is an excellent little editor that has all of the functionality that I need and is easy to use. In fact, you recommended it in an earlier post - Thanks! There are LOTS of editors available. Other Shopbotters recommend and use other editors. My requirements are very modest with an editor. It has to allow multiple files to be opened at one time so that I can copy and paste between the files. It has to have adjustable tabs. It has to have C/C++ syntax highlighting. Anything else is a bonus. The Crimson editor meets my needs and has a lot of extras that I don't need/use.)

Minimalist GNU for Windows:
Website: www.mingw.org (http://www.mingw.org)
Files: MinGW-3.1.0-1.exe and Msys-1.0.10.exe
After downloading the two files, run MinGW first (program suggested defaults work fine) and then run Msys (when prompted enter C:\MinGW). When you are through, you'll have the Msys icon on your desktop. Click on it and you've have a UNIX/Linux sytle terminal window waiting to do your bidding.

Assuming you have a folder named C:\c_programs, you would use the editor to create a source file (hello.c - for example) in that folder, and then, in msys, go to that directory:

cd /c/c_programs

compile the file:

/c/mingw/bin/g++ -Wall -o hello.exe hello.c

And then run Hello.Exe from either msys or the Command Prompt.

Be sure to create a Makefile to handle compiling - it really makes (no pun intended) life less stressful when you have a header file and lots of source files in your project.

mrdovey
05-30-2005, 04:54 PM
Mike...

If the version of make provided with mingw doesn't have suitable defaults built in, you might post a minimal makefile here. Writing makefiles can be a bit intimidating for new users.


...Morris

richards
05-30-2005, 06:48 PM
Morris,

Listing a sample Makefile is probably a good idea. It takes a little space and listing a file that's not sbp code might offend non-programmers, but I've had to pull arrows out of my back before.

Here's four sample files: (1) Makefile, (2) Header file, (3) Source file 1, (4) Source file 2. Although no one would ever break things up in this manner, it might be useful as a pattern for larger projects. (It's the pattern I used to write the 'doors.exe' file.)

# file name: Makefile
# date: 30 May 2005
# purpose: sample makefile
CC=/c/mingw/bin/g++
LINK=-lm

OBJS= \
..hello.o\
..hello2.o

hello: $(OBJS)
..$(CC) -Wall -o $@ $(OBJS) $(LINK)

compile:
..$(CC) -Wall -c $(OBJS)

clean:
..rm -rf *.o
# end of makefile



/* hello.h */
#include <stdio.h>

void Hello(void);
/* end of hello.h */



/* hello.c */
#include "hello.h"

int main(void) {
..printf("Hello from main()\n");
..Hello();
..return(0);
}
/* end of hello.c */



/* hello2.c */
#include "hello.h"

void Hello(void)
{
..printf("Hello from Hello()\n");
}
/* end of hello2.c */



Sorry about all of the '..' characters, but I couldn't figure out the correct way to format. The '..' characters represent a tab character. If anyone has questions, please email me.

-Mike
miker@xmission.com (mailto:miker@xmission.com)

wayneo
05-31-2005, 02:43 PM
Have you guys found a "vi" like editor that runs in windoze? I have found that if you know "vi" commands pretty well, you can do some amazing editing, like global search and replace/delete, etc. I have used MKS tools in the past, but think there must be some "vi" tools that are freeware or shareware...... It is hard for us old UNIX folks to get used to windoze!

Any pointers/tips appreciated....

Wayneo

paco
05-31-2005, 02:58 PM
Hi Wayne!

Have you heard of VIM (www.vim.org (http://www.vim.org))?

...I'm not sure what you meant by "vi"; I assumed... something!

wayneo
05-31-2005, 04:36 PM
Hi Paco,
Yes, I have VIM for UNIX on my SUN workstation @ work. I hate to give up all my years of learing "VI" and be constrained to use "NOTEPAD" in windoze. There is so many "VI" look-alike's out there, I was hoping to avoid having to dig through the pile.

Trying VIM is a good suggestion!

Thanks,

Wayneo

richards
05-31-2005, 11:15 PM
Wayne,

Paco's suggestion was correct.

Morris Dovey said, "I've been using GVIM, also a free program, and have set it up for syntax coloring of .SBP files. VI (even improved) isn't my favorite editor, but I couldn't find a Win32 version of nedit - which /is/ my favorite.

I've set up my system so that the FE command executes GVIM (default) or if there're parameters started and ended with a dollar sign, requests the system to execute the parameters between the $'s - a hacker's delight!" in his November 26, 2004 post.

-Mike

rgustav
08-24-2005, 08:46 AM
I like using cygwin on my windoze boxes. http://cygwin.com/ Totally free, works like a charm. Basically a mini-distro that runs on windoze, comes with shells, all the command line tools, compilers, can even run X. Sometimes I forget I'm running windoze.