Contract Programmer >> I know you've seen this before...but I'm actually good :)

[goooose]

Contract Programmer >> I know you've seen this before...but I'm actually good

Yes gentleman, another one has popped up. I'm throwing my hat in the ring of contract programmers hoping to differentiate myself from the others who have posted similar threads before me. A quick what/when/where/why/how...

What I can do...Mills-2-5 axis (3+2 or 5 sim), Lathes 2-5 axis (3+2 or 5 sim) + sub . Ive worked with Fanuc/Haas and Mazak...transitioning to others will not be an issue.
When I can... I am currently transitioning from F/T grunt and P/T contract programmer to just F/T contract programmer, still have the 9-5 now so by contract is still P/T
Why...I'm a programmer, my blood is that green stuff from the matrix....Ive spent enough time infront of the machines to know where I want to be
How....well you send me a model and a print, then I send you a program, a setup sheet and an invoice...and then you pay me for the beautiful code you got.
Where..... I program where I am and send then to where you are...

Ok, but being serious now...Im about to dive in to this contract programming, Ive yet to decide on software (its between 2 right now), but that shouldn't matter to prospective clients, or will it?, Im really trying to gauge interest and thought Id start on this board first. Do many of you outsource programming? Have you had good results with the programs you've got back? Does the software its programmed in matter to you? Any other suggestions would be appreciated.


PS I dont like hotdogs enough to cook them all day so the cart is out
PSS Please John Weldon dont swear at me

 

[jamesu229]

Which program creates the code does not matter, good effecient cutter paths do. If you are after work in the aircraft industry, they are beginning to request that you use catia. I have run purchased programs, good and bad(mostly bad), so if you are good, you will get a lot of work.

 

[zero_divide]

Which program creates the code does not matter, good efficient cutter paths do. If you are after work in the aircraft industry, they are beginning to request that you use catia. I have run purchased programs, good and bad(mostly bad), so if you are good, you will get a lot of work.

The reason most of programs like that are bad is that usually programmer needs some knowledge of tooling/clamping/machining/workholding and a million of other things about any particular shop before he even starts doing anything.
Especially in aircraft industry where developing workholding and fixturing some times take more time than actual cutting.

Good luck to Gooose.

I probably would still go with MasterCam as its the most popular software and your clients will likely want to see/verify you program before they press the green button.
Plain G-Code is not very helpful in that matter.

 

[Philabuster]

Just playing Devil's Advocate for a moment (I have thought about contract programming for 15 years), but what happens when something goes wrong and you send the client a bad program? "OOPS, my bad" is not going to get the machine fixed. Who is responsible for the damage? The client or you? Do you simply email the code and say hope it works, but double check everything just in case? This has never been something I could resolve enough to attempt at doing it.

If you are making code for people who otherwise cannot make programs for themselves, they are less likely to actually know what is going on and just push the green button and see what happens.

Watching the simulation on MasterCam (or other CAM) can never capture what happens after the program goes through the post processor. I suppose that's why they invented Vericut software.

Good luck Goooose.

 

[358Mustang]

Just playing Devil's Advocate for a moment (I have thought about contract programming for 15 years), but what happens when something goes wrong and you send the client a bad program? "OOPS, my bad" is not going to get the machine fixed. Who is responsible for the damage? The client or you? Do you simply email the code and say hope it works, but double check everything just in case? This has never been something I could resolve enough to attempt at doing it.

If you are making code for people who otherwise cannot make programs for themselves, they are less likely to actually know what is going on and just push the green button and see what happens.

Watching the simulation on MasterCam (or other CAM) can never capture what happens after the program goes through the post processor. I suppose that's why they invented Vericut software.

Good luck Goooose.

Any new program needs to be proven. That is the machinist's job.. Now him being a contract programmer I do not know. I wouldnt pay for the program if it was junk though. He would at bare minimum need to fix the code.

 

[Roooster]

Oi, Goooose, having too many 'o's was my idea!

 

[Heavey Metal]

The prolem with ''good'' code is that it is slow.

There is a real need for programers that can be on site in order to make optimal code during the first of a part run when the fixtureing and bugs get worked out.

 

[wheelieking71]

How many people roll with the first posted code for any given part? Sometimes I post operations several times before I like the tool-path. Does that make me a bad programmer? NO, it makes me picky. I cannot see how contract programming could possibly be a good idea. How could it be possible to successfully program anything for a strange shop who's tool-crib you have never been in? Do you just program with what you believe is the ideal tooling, and if they don't have it, ohh-well? Will the customer be expected to adjust feeds and speeds? Will you request a complete list of their tooling? will you have to create, and save tool-cribs for each customer? Are you familiar with machine differences? do you know how hard you can lean on a Kennemetal 3" 5 insert shoulder-mill in a HAAS VF0, vs. an Okuma MB-56V? (just an example)

How long have you been programming? How will you handle when a client comes back to you and says: "this program runs too slow".

I almost tried this myself about 1 month ago. I shyed away because it just seemed like a bad idea. All I see is a never ending "loop" of tweaking. We all know how long it can take to tweak code to perfection. I don't care how good a programmer is, I would be willing to bet 75% of the code posted will have fault found with it. And you will be doing allot of rework. Unless you have some kind of clause that states you don't rework programs. At which point you just talked yourself right out of work.
Or you provide never ending support, at which point you price yourself right out of work.

I dunno Gooose? Maybe I am missing something? But it sounds like a terrible idea to me?

There are just too many variables prohibiting success unless you are physically there.

What happens when you put a 1" indexable drill next to a 3/4" boring-bar in a lathe, and the drill is 1" longer than the boring-bar (but you don't know that!), and they don't cut clearance into the jaws. After the drill does its thing, and the boring-bar is almost to bottom of its first pass, the jaws get a-hold of that drill? That's just one example, there are millions of possible scenarios that will make you look bad.

 

[dstryr]

Contract programming locally is where you will find your niche. Go and talk with a few machine dealers. Basically they will get you doing turn key installations for their customers on new machines.

 

[Rich L]

Here's a thought on the positive side of your idea -

Surely you will have T's and C's (terms and conditions) on your contracts and waivers of liability on the use of your product. I know that getting folks to agree with them may be a problem but at least one of them should be that all of your programs be verified through some dry run. I believe you need to get formal about it. If you are really good, then I think your reputation will allow these conditions. Another approach is to be physically there, if you can, when your programs are executed. This would not be too unlike having a contractor in-house. In my industry (aerospace) this is very common and the in-house contractor is more or less part of the team. There may be blame but no liability other than possibly unpaid time for a rework.

There are all kinds of situations, experiences, and attitudes that may foil this approach, but it's a thought.

Cheers and good luck,
Rich

 

[wheelieking71]

yea, I wasn't trying to pee on your parade. But, WOW! I can't imagine it would work. Especially not long distance. On a local level? Maybe?

The benefits of a contract situation are sure attractive though! And you would certainly have FAAAR less overhead than a machinist.

 

[goooose]

Which program creates the code does not matter, good effecient cutter paths do. If you are after work in the aircraft industry, they are beginning to request that you use catia. I have run purchased programs, good and bad(mostly bad), so if you are good, you will get a lot of work.

Can you tell me what was bad about those programs. Was it inefficient tool paths, bad speeds/feeds, poor documentation?

How many people roll with the first posted code for any given part? Sometimes I post operations several times before I like the tool-path. Does that make me a bad programmer? NO, it makes me picky. I cannot see how contract programming could possibly be a good idea. How could it be possible to successfully program anything for a strange shop who's tool-crib you have never been in? Do you just program with what you believe is the ideal tooling, and if they don't have it, ohh-well? Will the customer be expected to adjust feeds and speeds? Will you request a complete list of their tooling? will you have to create, and save tool-cribs for each customer? Are you familiar with machine differences? do you know how hard you can lean on a Kennemetal 3" 5 insert shoulder-mill in a HAAS VF0, vs. an Okuma MB-56V? (just an example)

How long have you been programming? How will you handle when a client comes back to you and says: "this program runs too slow".

I almost tried this myself about 1 month ago. I shyed away because it just seemed like a bad idea. All I see is a never ending "loop" of tweaking. We all know how long it can take to tweak code to perfection. I don't care how good a programmer is,I would be willing to bet 75% of the code posted will have fault found with it. And you will be doing allot of rework. Unless you have some kind of clause that states you don't rework programs. At which point you just talked yourself right out of work.
Or you provide never ending support, at which point you price yourself right out of work.

I dunno Gooose? Maybe I am missing something? But it sounds like a terrible idea to me?

There are just too many variables prohibiting success unless you are physically there.

To retort some of your points...

sometimes I post operations several times before I like the tool-path....this is why we save good tool paths and repost them to new geometry.
Do you just program with what you believe is the ideal tooling...no, we use standard tooling except for when its unavoidable.
Will the customer be expected to adjust feeds and speeds...no, during the initial job quote the favor towards speed vs life is discussed.
Will you request a complete list of their tooling....a brief run down is all that's needed, but of course more info is better
will you have to create, and save tool-cribs for each customer...yes
do you know how hard you can lean on a Kennemetal 3" 5 insert shoulder-mill in a HAAS VF0, vs. an Okuma MB-56....yes, obviously we need to know the make/model of machine we are programming for.
How long have you been programming...approximately 13 years
How will you handle when a client comes back to you and says: "this program runs too slow....reprogram to run more aggressive and revisit the initial conversation about tool life vs run time.
We all know how long it can take to tweak code to perfection....perfection in production and perfection in prototyping are two different monsters
I don't care how good a programmer is, I would be willing to bet 75% of the code posted will have fault found with it...I'll take that bet!


Some look at contract programming like a 'get rich quick scheme'. The same way some guys think 'all i need to do is throw a cnc mill in my garage and ill make millions!' a lot of guys see contract programming the same way...'all I need is a seat of mastercam and ill make millions!'. This is where the amateurs are separated from the pros. A good programmer knows the value of good documentation to communicate with the machinists, and good verification software. The extra software is not cheap, the extra documentation not easy to create, this is where most fall short.

I think its just a matter of getting shops to see how 'good' programs can actually make them more money. Instead of having spindle downtime cause your guys is off programming a part, or when he finally does make some code its terribly inefficient ..why not pay someone who can make your machines do what they are meant to do and leave the responsibility of keeping the machines running to your machinists?

Thanks for the feed back thus far gents and if you have more questions fire away.

 

[dstryr]

I agree with everything you said. I've done some contract programming and the main key is the documentation. Most of the time the problems caused when using contract programs is the guy loading up the machine with the wrong tooling.... Call out a 1/4 bull nose endmill with .010 radius and the setup guy puts in a .020 radius.

What software do you use GOOOOOOOOOOOOOOOOSE?

 

[goooose]

I agree with everything you said. I've done some contract programming and the main key is the documentation. Most of the time the problems caused when using contract programs is the guy loading up the machine with the wrong tooling.... Call out a 1/4 bull nose endmill with .010 radius and the setup guy puts in a .020 radius.

What software do you use GOOOOOOOOOOOOOOOOSE?

Contract programmer or not, loading the wrong tool can't EASILY be stopped.

Software...I prefer Esprit just because it does so much really well and it gets along great with SolidWorks (my assumption as most commonly used CAD) I also know MasterCam really well, which I know is the most widely used CAM and why I thought about using it in case shops want the actual part file instead of just code/documentation.

haha ya lots of oooooooo's!

 

[Edster]

Programming for someone else is a complete pita!

I got a customer from one of our machine salesmen. They bought a brand new vmc and didn't know how to program it. I have the exact same machine so it was easy for me to write there programs. Problem is they didn't have a clue about tooholding, tooling, or feeds and speeds. They worked with different materials than I was used to and without being there I couldn't tell what the machine was doing. They didn't want to buy any tooling I recommended either. They would get a job and needed the program asap. They also expected me to do tweaks and edits to the program asap. Problem was I run my own shop and couldn't always accomodate them. The dumb@sses would also send me some impossible to read prints via fax that would just piss me off.

The final straw was when they thought they could just pay me whenever they felt like it. I was doing all the thinking for them and they try to string me out like I was just another supplier that didn't matter. One time I refused to do any more programs until they squared up. It was actually kinda satisfying having them beg for me to write a program after they strung me along with excuses for so long.

Anyway I will never again write programs for anyone else, but if thats what you want to do then good luck to you.

 

[goooose]

Oi, Goooose, having too many 'o's was my idea!

My join date was Nov 2007, yours Jan 2008...so you copied me!!! (I beat you by 2 months and 1 'o'!)

 

[zero_divide]

My join date was Nov 2007, yours Jan 2008...so you copied me!!! (I beat you by 2 months and 1 'o'!)

I bet gooooogle beat you all.

 

[annoying]

The prolem with ''good'' code is that it is slow.

There is a real need for programers that can be on site in order to make optimal code during the first of a part run when the fixtureing and bugs get worked out.

But isn't that most always the case with software generated programs? Or maybe dependent on software?

do you know how hard you can lean on a Kennemetal 3" 5 insert shoulder-mill in a HAAS VF0, vs. an Okuma MB-56....yes, obviously we need to know the make/model of machine we are programming for.
Will the customer be expected to adjust feeds and speeds...no, during the initial job quote the favor towards speed vs life is discussed.

So do you use axial thrust and HP numbers? or mainly Spindle HP? Do you know conversions for Haaspower to real and usable horsepower? Sorry, I could help but throw that in there. How about machine rigidity itself? Especially considering wear and tear on a half neglected machine gonna destroy tools faster due to vibrations, excess backlash, etc.?

How will you handle when a client comes back to you and says: "this program runs too slow....reprogram to run more aggressive and revisit the initial conversation about tool life vs run time.

Can I ask again about those unpredictables?

We all know how long it can take to tweak code to perfection....perfection in production and perfection in prototyping are two different monsters

Most certainly, however, are you thinking of doing programming for production? In my opinion, one would absolutely have to be on site to achieve perfection for production.

Oh, but then again, I have never used software to generate a machine program.

Anyway, I have refused to buy anything because I never did like anything I've seen, really. Programs cluttered with extra digits and spaces and numbering every line is annoying to me. But, most of all, what little I've seen a machine running a software generated program, I spent the whole time each time thinking.... wtf?... why did it?... where the?.. then why didn't it?... well that's stupid.... why the extra moves?.... and most of all, damn that's too slow.

But don't get me wrong, I can't speak of all software, only a bit, but I know I had to look like a dog staring with his head tilted to one side trying to figure something out. The first ever I had seen was from mastercam. Place I was working just had to get the software and they toyed with it a while, mostly the supervisor did as he had prior experience with it. He had some toying part runs and thought he'd have the main CNC guy and myself come and see. We just looked a bit, then looked at each other and walked away unimpressed. Now I know that it was probably not optimized, but still.....

Now I know on prototypes and short runs with complex features it would be tits to have good software, but on more simple geometries and such, do people really think they are ahead with it? I know someone that uses another software and seems to do okay with it. But, if it were something halfway basic, I'd guarantee I'd have it programmed and done before he could get the program to the machine. Yet, he still refuses to learn G-code, even though it is so simple.

Anyway, nuff of that. I personally can't believe a software generated program could be worth a shit for production stuff, if that is also on your list. there are too many possible ways to reduce time to ever make it practical. Always better moves, better feeds, better paths, whatever.

I want to rapid x y and z all together. Is that an option with software? I honestly don't know, just aint seen nobody do it that way.
When it matters, I want the spindle on and all three rapid to where it almost crashes into the part. I want coolant coming on along the way and just come out right as the cut starts (no waiting, no excess). If there is to be a tool change at the cycle start, I don't want the z to be anywhere above or below the tool change position. If the first tool is the same as last, I don't want the z all the way up to the ceiling. I want it just a few inches up so its there before y.

Is this possible for me to get? Without being there and taking part in the setup, will you be able to predict all possible time saving moves? I'm just curious. I'm mostly curious what can be done with software. I do expect I am more likely to make errors with my finger programming, but does software ever make errors? I'm only curious. Can I follow instructions you provide, to a tee, and just hit the green button? You know some will want to do that, correct? So I tell you it looks like some moves can be changed to save time, how would you know what or where?

Call me curious or call me annoying. Just seems it could really suck to pull it off. Having changed things for the ease of operators (and idiot proofing), I could not imagine trying to do it from afar, even after I was there and did all setup, fixturing, etc. my self. to not be there for changes would bother me.

Just my thoughts

 

[Bobw]

Hey Annoying.

I've finger CAMed and I've CAM CAMed. I'll take the CAM CAM over the finger CAM any day.

Take a for instance, you finger cammed out a program taking 6 passes at .060 a pass, then you realize the
saw guy cut the parts just a bit long and you need to take 7 passes now, that's easy to add with finger cam,
but.... Time constraints say you still want to run 6 passes, now you are editing your ass off or playing with subs or
some other non-sense, all of which can lead to fat finger errors. With software, you just click, change the WOC or
# of passes, post and send, a whole 30 seconds, and you don't have to worry about FAT FINGER errors.

Once you get all the cutting down where you want it, then you can go into the program and make all rapid adjustments and
whatnot.

Any complex contour or 3D sufacing, you're miles ahead with the CAM. Just the time alone to first part. You can be making
good parts with inefficient code while you are tweaking the program to make them faster.

As for "contract programming", We've been approached a few times, and decided the liability and BS wasn't worth it.

 

[rekloki]

One of my favorite things about my position, being in a small(ish) shop owned by my father, is that I am the programmer and the first run machinist. I have a unique position of being able to know first hand what issues or problems any of MY programs have. Alternately, being in this position also limits my time. We have one other person who helps with the programming, but he is a contract programmer who has a 9-5, and therefore has limited time to combat errors that may crop up. So a job might sit for days or weeks waiting for a fix. Most of the time I must take time away from what I have to do to try to figure out what is wrong. My programs are usually fixed within a few minutes, copy/paste only the fixed code.



I have also thought of doing the contract programming route. Alas, I have zero time. Even while home I am programming. I should be programming now...