Question of the Day... 1

[Shadowspawn]

Here's my delima: I've just taken a new job with as lead designer and defacto HNIC of the CAD department, responsible for legacy operations as well as bringing operations forward with newer technology and methodologies. Much of our input data from customers has changed from point data and drawings to the occassional drawing and translated CAD data (iges, some stp).
This company is heavily in bed with GRIP, going back roughly 35 years. There's oodles of grip routines to automate much of the processes that exist here, but there's <10 grips that are used regularily in the CAD dept. None are documented, and maintaining them is adhoc at best.
Additionally, file permissions and security is essentially non-existant (I can write to anybody's file and save it to their directory!). CAD standards are nothing more than the 'understood to do but not written down' variety. There's no use of UDF's, standard parts, sketching, and no customization beyond grip (seed parts included).
Next week, I have a meeting with the new Director of Engineering, and one of the things he wants to know is what I think of the existing operations, and what recommendations I could make for improvements and going forward.
This is a great opportunity for me, but I've only been on the job a month and don't really understand what's going on yet as far as the daily operations go and how to do my daily responsibilities, much less have the time to rebuild the CAD department from scratch. What would you do in my position?
All thoughts welcome...

Regards,
SS
CAD should pay for itself, shouldn't it?

 

[ugiismart]

I would first try to get rid of poor documented Grip programs... Best thing is to convert them into Ufunc with a good documentation , actually UIStyler dialogs helps the user to survive even with a poor documented Ufuncs...

I know a CAD/CAM operations manager who holds UG V15 just because of an old GRIP program , the owner of the code retired and the program has no documentation but it works! On the other hand , since it handles Manufacturing operations and there was a radical change on V16 , the code does not run for the new versions.

One of the solution to handle these kind of codes might be to contract them as a GRIP replacement project to a professional firm and outsource it. This way is beneficial from either time , money and well documentation. There are some firms on the net dealing with such GRIP to UFUNC conversions like

http://www.ugsoftstore.com

Regards ,

 

[Shadowspawn]

ugismart,
Thanks for the input. I'm familiar with grip, but not the the extent that this place uses it. I'm in a position to suggest migrating to a newer and more functional language, and am inclined to do so. I just need to know more about how dependent we are on grip (and from what I can see, very...).
This facility is a forging shop, that relies heavily on the CAD files for it's operations. Some form of automation is needed (the more the better), so now the questions becomes what language to choose. What would you pick and why?

Regards,
SS
CAD should pay for itself, shouldn't it?

 

[Xwheelguy]

SS,

I'd also approach your superior and try to get a feel for what he might be expecting or favor. You may wish to have an estimated schedule for updating/converting the legacy GRIP programs you described above so the two of you can review it and set up a realistic schedule/timeline.

If it were me, I'd really push for getting things updated and documented correctly, should time permit.

You're already aware of my lack of programming knowledge, so I won't offer any language advice.

Tim Flater
Senior Designer
Enkei America, Inc.

http://www.enkei.com

 

[cowski]

Well, if it ain't broke - then improve it, but it is not necessary to throw it away and start over.

No file security/permissions? that's broke and needs to be overhauled. Grip programs that are not documented? Document them and use them, if they work why redo them in a new language? A case can be made if you can introduce usability improvements or added functionality.

They don't use UDF's, standard parts, or sketches?

I've only been on the job a month and don't really understand what's going on yet as far as the daily operations go

Sounds like you need to get familiar before you start retooling the department. Just because you used certain UG features in your last job does not necessarily mean they will work well in this one. The goal is to improve the workflow for the department, not to make them work the way you are used to.

Do you make a lot of custom forgings? standard parts may not be a viable option. Do the forgings have features in common? UDF's may be a great thing to implement.

CAD standards are nothing more than the 'understood to do but not written down' variety.

Is the company ISO certified (or seeking certification)? If so, be careful what you write down. It may become a standard that you will have to prove you are following, and cost you money if you are not (the joy of audits). I'm not advising you to NOT write them down, just be careful.

I'm in a position to suggest migrating to a newer and more functional language, and am inclined to do so.

What language(s) are you familiar with? Which ones integrate well with the version of UG you are using? Is there anyone else in the department that knows how to program and what language(s) do they know? What is the cost of moving to a new language (compiler(s), training, programming and testing, training users how to use the programs you create, and do you have a UG api license to work with)?

You need to tread carefully, build the trust of your team members who work for you. Develop an incremental plan of improvements (and discuss it with your boss - builds trust with him), what one thing can you do that will have the least impact on the workers (shortest learning curve) that yields the biggest reward (productivity gain)? Implement that one first, it will help to build the trust. If you try to change everything at once, they will view you as changing things for the sake of change. You need to win over the folks that say "but we've been doing it this way for years and it works just fine". Once they see the benefits of your suggestions (after you are familiar with day to day operations and have carefully weighed the options, of course) they will be more open to the more radical changes.

 

[ugiismart]

SS,

As far as I understood , you are complaining about the GRIP programs that they are not structured well and less of documentation. Well, the improvement and preparing the documentation would 've been ok. but what about the time and efforts , do you think if they worth for a program that is dying over the decades in of every new release of UG.

GRIP is dying , Yes , the every effort you make will be non-sense in near future. UGS stopped reflecting improvements into GRIP language starting from V16 , that means the new features added to UG will not be available in the GRIP world. Even your running codes might be useless like we'd faced in manufacturing.

I strongly advise you not to waste time with GRIP ... if the codes are small and clear enough to understand ,yes, I would consider to make them running , but for the larger ones that is written with so many GOTO 's believe me in order to understand the code itself you might require help from Criptology experts to solve and understand the struggle.

regards ,
US

 

[Shadowspawn]

Cowski,
I'm not necessarily advocating trashing everything and starting over, but if a more suitable language would be better all around then wouldn't it be prudent to do so? I'm positive that no std parts, udf's, sketches, etc. are used. In their place, they import some v13 parts (or copies thereof) and position them where they want. The entire process of developing our product, under the existing conditions, involve multiple (5-8) new part files being generated and we only deliver 1 file for tapes and cmm data. There is little or no associativity included into the models. There is no centralized control over anything that I can tell... multiple copies of the same part in different folks directories, no std directories for controlling grips, (I've found no less than 13 copies of the same grip routine in different directories).
Part of the reason I was hired was to manage the CAD shop and get it into shape. So knowing the aforementioned noggin fodder, where do you think I should start and how far should I go?

Regards,
SS
CAD should pay for itself, shouldn't it?

 

[cowski]

Let me preface this by saying that I have never been in a leadership position that affected a whole department. But in the projects that I have been in charge of or have advised on I quickly learned that 'just because you can do something, doesn't mean you have to do it'.

That said, I stand by my previous post. If you can improve something take it as far as you, the users, and your boss feel comfortable. But change for the sake of change rarely has positive consequences.

 

[ewh]

"...change for the sake of change rarely has positive consequences."

Amen to that!