UG Shop Docs 2

[bme0319]

My company is a contract manufacturer of medical implants using UG CAM. We're looking to streamline our programming tasks.

Is anybody out there using UG Shop Docs. Currently we define tools in UG CAM for manufacturing purposes and then seperately type-up a "tool sheet" in Excel for use on the shop floor. This sheet describes the attributes of each tool and gives a basic description of what it's going to do, along with any special instructions.

It seems like UG Shop Docs provides a basic platform for this type of thing, but how customizable is it? We'd like to be able to enteer the info in one place only. Is anyone out there using Shop Docs for this purpose and if so, does anyone have experience customizing it or know of any useful resources?

Thanks
Paul P.

 

[Jcamsystems]

Hi Paul,
You probably know this already but shop docs, clsf output and UG post processing all rely on the manufacturing output manager, which uses TCL. For post processing you’ve got a nice front end call Post builder to give you a start with writing a UG post processor but generally even with this you need to get you’re hands dirty with TCL to most anything but basic stuff. For clsf and shop dosc there only one way to do it and raw code it with TCL. I’m currently re-writing a new CLSF output format specifically to interface with our non UG post processors. The neat thing about this is that all of the tooling information that is defined within the CAM part is passed through to the NC tape. We do an awful lot of automatic tool probing prior to use via this information and control system macros. One of my next projects is to butcher that out of the box shop docs styles and generate something more useful for the machine tool operators i.e. contains all of the information that has been already defined within the UG CAM part in the same way as we are passing all of tooling information to our post processing application. Is this the sort of thing your trying to do?

 

[kukelyk]

im just making to our company the customized shopdocs, but there are a lot of problems, what i (or we?) have to solve, in the "UG CAM" or in the "NX internal variables" topic you may find some of them... if you send a mail, i will send a html file, what the nx generated with my template..

----
kukelyk

 

[kukelyk]

...
koborangyal<at>freemail.hu


----
kukelyk

 

[bme0319]

Thanks for the info guys. Yes, Jason that's exactly the sort of thing I'm trying to do. Do you know if UG offers any resources or training for TCL? Do you know of any other than UG? We'll probably end-up having someone come into our shop to take a look at customizing it for us.
Thanks again for your time.

 

[bme0319]

Hi guys,

What about UG tool libraries. Are you integrating UG a UG tool library with Shop Docs?

 

[kukelyk]

still not..

----
kukelyk

 

[kukelyk]

does anybody knows which TCL(scripting language) release supported by UG/NX3 shopdocs?
b'cos some TCL commands make the shopdoc creation process go wrong...

----
kukelyk

 

[Jcamsystems]

Paul,
We’ve been down this route. Believe it or not UG don’t offer must support in the area of TCL or customisation of the manufacturing output manager. There isn’t really any documentation and to be honest the UG applications chaps don’t really step out of the post builder arena, so you’re on your own, unless you’re got direct contact the NX developers who obviously know what their doing . If you want to do this sort of thing for yourself, I suggest you ask UG for a Post builder course. This will give you an idea of how the manufacturing output manage works and includes a taste of embedded TCL. A good place to go for a deeper understanding of TCL is Well House Consultants, they presents a very good course and it will help you a lot with some of the advance features that you will need to customise your shop docs. If you want to take this offline I could suggest to you some other resources that could do the job for you.

 

[Alchemeidus]

Paul,
There are actually a few ways to get around this. First you can extend the tcl interpreter to output the tooling directly to excel, access, etc. from UG post. I have done this with Access & Excel.

The other way is to use GRIP to output the tool list on a drawing.
This can be done one two ways:
1. GRIP can read the posted output.
2. Create Env variables when you postprocess. Using ::env( ) then when you run the GRIP Program and add them to the drawing delete them by setting them equal to ''

I assume that you have learned how to show your tool information in the posted program already. If not here is some sample code I used for a custom cls file, you should be able to adapt it:

proc TOOL_INFORMATION {} {

global mom_tool_name
global mom_lib_attr_value
global mom_libref
global mom_tool_catalog_number
global prev_tool_name

if { $mom_tool_name == $prev_tool_name } {
# MOM_output_literal "\$\$ NOTE: Path uses previously loaded tool" ; # Commented out
return}

if { $mom_libref != "" } {
MOM_ask_library_attributes LIBRARY_TOOL $mom_libref Type SubType Descr Holder HolderDes
set lib_descr [string toupper $mom_lib_attr_value(Descr)]
MOM_output_literal "PPRINT/ LOAD $lib_descr"
} else {
set lib_descr [string toupper $mom_tool_name]
MOM_output_literal "PPRINT/ LOAD $lib_descr"
}

set prev_tool_name $mom_tool_name
}

 

[derekkarp]

i'm quite new to Unigraphics. But my company needs a post badly. We've hired outside companies to do this, and results are very bad. I've been working on a post at home, using the post builder in UG. I have it almost worked out as far as the tool paths, correct codes, and 4th axis working properly. There is one thing that i'm really interested in doing with it though. We have a laser to measure our tools. As of now, we are having to hand-write a program to select the tool, change to that tool, call up the next tool, then measure the tool. there is alot of room for error here, as some of our programs have up to 60 tools. I know excatly what i want, but, i'm not fluent in tcl. Has anybody done this type of thing before? I'm sure its not too complicated. But, this could mean a promotion, even a raise!! hahaha......so any help would be appreciated.

 

[kukelyk]

aah
the nx supports only the base tcl commands, the tk commands, what i need, are not known by the interpreter..

does anybody knows the posting process deeply?
i need information about toolpath, such as the bottommost Z coordinate, and the machine time, what i could compute from the length of the path and the feed..

any idea?

----
kukelyk

 

[looslib]

Try asking these questions on the UGS bbsnotes nx.cam forum. Being an internal system, UGS developers will see and answer the questions.


"Wildfires are dangerous, hard to control, and economically catastrophic."
"Fixed in the next release" should replace "Product First" as the PTC slogan.

Ben Loosli
CAD/CAM System Analyst
Ingersoll-Rand

 

[jelmerra]

It is possible to call an external tkversion from postprocessors/process assistants or shopdocs. For instance you can create your own splash window or user interface. I think UG it self is still at 8.1 or there abouts.


For the bottom z-coordinate there is a preprogrammed set of procedures available called stroke-limit.

cycle times can be fetched by your own tcl or with a preprogrammed set of procedures for a tool list.

If you are running NX 3 or 2 you should have those tcl files with your installation under postbuilder.

 

[kukelyk]

thanx
you bring back the hope for me, i started to lose my heart
if all this true..

It is possible to call an external tkversion from postprocessors/process assistants or shopdocs.
>could you tell me how?
For instance you can create your own splash window or user interface.
> i made it already
I think UG it self is still at 8.1 or there abouts.
>yes, all nx versions..
or the bottom z-coordinate there is a preprogrammed set of procedures available called stroke-limit.
>TCL procedures?
cycle times can be fetched by your own tcl
>but how can i read the internal CLdata?
or with a preprogrammed set of procedures for a tool list.
>what ???

.. those tcl files..
>stroke limit? or what?


----
kukelyk

 

[kukelyk]

i found stroke limit in the documentation, but it tells G22 and G23 codes.. im confused :-/

----
kukelyk

 

[jelmerra]

Sample code for splash window with ugwish:

# calling the splash window with a brief explanation of the Process Assistant
set jr_wiz_path [MOM_ask_env_var UGII_CAM_WIZARD_DIR]
set dir [MOM_ask_env_var UGII_CAM_AUXILIARY_DIR]ugwish.exe
exec $dir <<$jr_wiz_path [MOM_ask_env_var UGII_CAM_WIZARD_DIR]intro.tcl $jr_wiz_path

I tend to communicate with these external tcl things with tempory files. The above code shows the use of arguments for communication to the external tcl file (backward communication does not work because the sytem already running is not called back by a dos command).

I tend to generate the shopdocs during the postprocessor run you will have all Ct and axis travel data available. Hopefully the above explains my references to postbuilder commands.

 

[bme0319]

Hi guys,

Thanks for all the good info. We are currently looking into a product called WinTool. WinTool handles tool crib inventory and tool libraries. It also claims to be able to hand that info off to UG, Vericut and Esprit (all the packages we have).

http://www.wintool.com/Loesungen-E/Tools/tools.htm

 

[kukelyk]

yes, Jelmerra, i do the same, but i thought, that i will generate nc files under shopdoc,
where i can select the needed post in the splash window..
but there is still the problem,
the part_gif is only the current view,
and the path_gif is only one operation,
but if a program consist of more than one operations, the gif will not contain all paths,
because it refreshes the screen after each operation..

----
kukelyk

 

[lewimt]

To calcualte tape length add this to your end of program block:

MOM_output_literal "#3006=1(PTP file size = $ptp_size bytes [format "%5.1f" $ptp_feet] feet)"

You can use this to calculate the machine run time:

MOM_output_literal "#3006=1(TOTAL Machine Time: [format "%.0f" $mom_machine_time] MINUTES)"