|
|
Multiple Part Setups (Multiple REF)
Most parts need to be machined from multiple directions. With 4-axis and 5-axis machines, this can often be implemented by rotating the machine to the required orientation. However, when a part needs to be machined from different directions using a 3-axis machine, the part has to physically placed on the machine table multiple times, in different orientations. We refer to that process as Multiple Setups. For each orientation, the part is placed on the table, the machine home is calibrated, and the relevant procedures are executed.
In GPP2 terminology, the part setup on the machine table is represented by the REF UCS specified by the user when running the post-processor. The REF UCS defines the base machine coordinate system (zero, or home position, and most importantly the machine axis orientation) with respect to the part. Therefore, changing the part setup on the table is equivalent to defining a new REF UCS.
The user interaction within Cimatron only allows the definition of one REF UCS. It is recommended that a single posting process be limited to a single setup of the part. If some procedures need to be executed using a different part setup (i.e., different REF), then a second run of the post-processor is needed, creating a separate G-Code file.
However, some users prefer to generate a single G-code file covering the entire machining of the part, including changing the part setup between procedures (at least when an orientation change is required). Other users like to use "multiple homes" on the machine, each home used for machining at a specific area or orientation. All these users need to change the REF UCS in the middle of the post-processor run (between procedures).
To achieve this, use the GPP2 system flag SET_REF_BY_ORIGIN. It allows changing the REF UCS in the middle of the run to be the current procedure ORIGIN UCS. The change can only take place in the ORIGIN CHANGE block, meaning it can only be done in the first procedure that uses a given ORIGIN UCS (the block is only invoked when the ORIGIN is changed).
To define a new REF UCS, the EX2 program must set the GPP2 system flag, SET_REF_BY_ORIGIN to TRUE_, inside the ORIGIN CHANGE block. GPP2 only tests this system flag after the execution of this block. GPP2 will respond by setting the REF UCS to the ORIGIN UCS. All subsequent motions, including the connection for the current procedure, will take place according to the new REF UCS.
Another, more advanced, way is to change the REF_UCS at run-time, and support multiple REF output. By setting the appropriate UCS position and orientation values to the *_REF variables, and after that setting the SET_REF_BY_VARS system flag to TRUE_, the REF_UCS would change accordingly.
Note: For standard use there is no need to ever use these variables in the post. They are to be used ONLY if REF_UCS really needs to be changed.
Usage example: By copying the TP*_ORIG values to the corresponding *_REF variables and SET_REF_BY_VARS system flag as TRUE_, the current TP UCS would become the new REF_UCS.
Note: All 9 *_REF variables must be set before SET_REF_BY_VARS is used. Do not assume anything on the previous value of any *_REF variable (for instance, the X/Y/Z_REF variables are not necessarily at 0,0,0).
Several side effects of the REF change are listed below:
-
The next connection (of the current procedure) will use the tool change scenario, even if the tool has not been changed. This is the safest connection scenario (and suitable here, since the machine head was probably moved aside to allow the new part setup).
-
RTCP (M5_RTCP_M128) is turned off (in case it was on). This is only relevant to intelligent 5X machines.
-
The Output UCS is reset (to the new REF) in case it was different. This is only relevant to intelligent 5X machines.
-
All system vectors (like HOME, CURPOS or ORIGIN) are recalculated to conform to the new REF UCS.
-
The machine simulator does not support multiple part setups. When using multiple setups, machine simulation cannot be used!
Note: Changing the REF UCS in the middle of the run is a delicate and very advanced action. It is best used with 3-axis machines only.
|
