III .RESULTADOS
3.3 Resultado de la tabla de contingencia
The discussion directly above (re OPSTOP records) brings up an important point; rather than us designing dedicated sequences for every possible CL record (which would be a never-ending chore), we have instead designed 3 simple ‘generic’ sequences to allow you to…
• handle any CL record that you may ever encounter, and/or
• ‘trap’ and output code whenever any variable is updated (typically by data coming in from the CL file).
Giving you the ability to handle these conditions yourself frees us at Ground Support to spend our time developing other features, rather than being bogged down by continual addition of an unending list of dedicated sequences and conditions.
These 3 sequences are very handy – they allow you to handle many unusual situations. In a nutshell...
Upon is used to set any variables, output any desired code, or execute particular post commands whenever a particular [variable] is updated.
UponRec and Cycle let you handle non-standard or custom records in the CL file.
(Similar to Upon, you may use these sequences to set any variables, output any desired code, or execute any post commands.)
All three of these sequences can be used to override PostHaste's 'default' manner of handling any variables or incoming CL records.
The sections below discuss the details pertaining to the Upon, UponRec and Cycle sequences.
Upon
You can use the Upon & UponRec sequences to output a sequence of blocks whenever a particular variable is updated by the CL (incoming tool motion) file. It can be used as in the following example:
Upon [Work]
G[Work]
X[H] Y[V] Z[D]
end
The variable after the UPON (in this case [Work]) is called the “trigger” variable.
In this example, when the [WORK] variable is CHANGED, it “triggers” this sequence to be executed. By default, if the value of [Work] has NOT changed, then no action will occur. Also, even if the value has been changed, the action will NOT occur if the next line or sequence to be output already has that variable in it - because PostHaste expects that sequence to handle it instead.
Important note: Standard Upon sequences (those that do NOT use the Every or Unique modifiers) are not executed immediately – they are output (only if needed) just before the next sequence is output. In other words, the post waits until it is time to output the next sequence (whatever it is) before it executes the Upon sequence(s). We do this to prevent 'double output' of particular codes. A good example of this is what happens if you use Upon [Cool]...
It is common that the coolant status would be different (on vs. off) when using different tools. It is less common that the coolant setting would change in between cutting operations using the same tool – but since you may want your post to handle that situation, you might include an Upon [Cool] sequence like this:
Upon [Cool]
M[Cool]
end
If the post output that sequence immediately, then you would get an extra (unneeded) coolant command (M8 or M9) just before a tool change is output, so the post 'waits' until it has to output the next sequence and then checks that sequence to see if the 'trigger' variable (in this case, [Cool]) is in it:
If the [Cool] variable is in the upcoming sequence (as it usually is in the ToolChange sequence), then the Upon [Cool] sequence is not output.
If the [Cool] variable is not in the upcoming sequence (as it isn't in a typical RapidCode sequence), then the Upon [Cool] sequence is output.
In this example, the Upon [Cool] sequence would be output before rapid moves (if the coolant status has changed), but not before a typical ToolChange sequence (because a typical ToolChange sequence contains a [Cool] variable).
The Every, PreScan and Unique modifiers
As discussed above, the standard Upon sequence is only executed...
when the value changes AND
the upcoming sequence does NOT include the trigger variable.
There are, however 3 modifiers that you can use with the Upon sequence to change that behavior: Every, PreScan and Unique. Using any of these 3 modifiers will result in the Upon sequence being executed immediately (that is, without checking the next upcoming sequence for the existence of the trigger variable).
Use the Every modifier if you want to force the output of the sequence every time the variable is updated - even if the value has NOT been changed (in other words, every time the CL file [or your template] updates the variable – even if it is updated with the same value that is already stored in that variable). Do this by adding the word 'Every' before the variable as in this example:
Upon every [Work]
...
...
End
(Remember - the capitalization of the letters in commands and variable names doesn't matter.
However, the NC “words” ARE case-sensitive, so don't put “g0” in a sequence if you really want
“G0”.)
The PreScan modifier is used when you want to output code (or set variables or execute post commands) when the post is in its 'prescan' phase – which it does under certain conditions. (The post knows when it needs to do a 'prescan' of the CL file, so you don't have to worry about that yourself.)
Upon Prescan [Tool]
!0 O[Val1] T[Tool] M6 G0 X0 Z10 M0
G1 Z1 F.75 M0 Add 10 to [Val1]
end
Note that the PreScan version of the Upon sequence has rather limited usefulness – the trigger variable can only be one that is actually read from the CL file in its (limited) prescan phase: [Tool], [Depth], [ILevel] or [RLevel]
The Unique modifier will cause the Upon sequence to be output only when the value of the trigger variable is updated to a unique (or 'new' one) – that is, only when the variable is set to a value that it has never been set to before.
Furthermore, the Unique modifier requires the use of a letter to 'format' the variable to (the B in the example below). This allows you much more control over what happens, because all of the letter formatting options can be used to determine what qualifies as 'unique'. For example, if the letter B (the one associated with the trigger variable) uses the MOD 360 (modulo) modifier, then a
[RotAngle] of 390 degrees will result in the same output as 30 degrees, so even though the variable value is different, the Upon Unique sequence below will be output only on the first one.
This can be used to...
o create tool lists (because you don't want to add a 'repeated' tool to the list), or...
o create 'rotary axis indexing subroutines' as in this example:
Upon Unique B[RotAngle] Create the indexing subs in file # 1.
File On 1 Only o[RotAngle]
M11
G90 G00 B[RotAngle] M10
G10 G55 x999.999 y999.999 z999.999 M99
File On Main Only
end (end Upon Unique B[RotAngle])
The Relate option for 'Upon ... Unique' sequences:
Sometimes, you need to have 2 different values (variables) in your post related to each other. A good example of this would be to relate the [Work] variable to the [RotAngle] variable so that corresponding
work offset (G54, G55, etc.) value is output according to the side of the part that you are currently machining. (Of course, some CAM systems output the [Work] data in the CL file whenever an indexing motion takes place, but some do not. The Relate option gives us a way to handle problems that arise when the CAM system does not already give us properly 'related' data in the CL file.)
The example below relates the [Work] variable to the [RotAngle] variable, so that whenever a particular face of the part (B angle) is accessed, the post automatically updates the [Work] variable* so the same [Work] value (G54, G55, etc.) is always active* whenever that face is being machined.
Whenever a "new" B angle is found, calculate a new [Work] offset value and RELATE it the RotAngle for each face:
Upon Unique b[RotAngle] RELATE [Work]
Add 1 to [Face#] << Increment the 'face counter' and
Set [Work] to [Face#]+53 << calculate the related [Work] value.
end
* Please note that the Relate function causes the [Work] variable to be automatically updated - not output!
The actual outputting of the G54, G55, etc. would be controlled in some other area of the post. In the case of example above, it would probably be output in an Index or ToolChange sequence (because that's where B axis indexing moves are typically output). The Relate function (in this case) simply makes sure that whenever the [RotAngle] variable is changed, the post will automatically change the value in the [Work]
variable to 'keep the work offset in synch' with the [RotAngle] changes.
(Note: The [Face#] variable in the example above is a 'user defined' variable that has been created with the Rename function. See section 4.1.26 for details on using the Rename command.)
UponRec and Cycle
These are similar to the Upon sequence, but these are triggered when the post reads a particular CL record.
These let you...
- handle 'user-defined', non-standard or special-purpose CL records and cycles.
- override the way that the post handles any CL records.
Before we get into explaining all of the details, let's just take a look at a quick example...
If you want to output an 'optional stop' (typically M1) code whenever an OPSTOP record appears in the CL file, you would simply add this to your template:
UponRec OPSTOP M1
Comments (Note - the Comments line isn't required, but might be a good idea...) end
In the simplest form of an UponRec sequence (as shown above), all you need to do is to make sure that the word following UponRec matches the actual name of the record that is coming in from the CL file.
The above is the simplest form of an UponRec sequence, as there is no actual numerical data being passed in from the CL file.
Here are some more examples that show how to handle records that pass numerical data...
Excerpt from CL file:
...
ETHEL/10.01, 20.02, 30.03
CYCLE/FRED, 1.1, 2.2, 3.3, 4.4, 5.5, 6.6, 7.7, 8.8
GOTO / 1.000, 2.031, 0.000 GOTO / 2.000, 0.844, 0.000 GOTO / 3.000, 2.031, 0.000 GOTO / 4.000, 0.844, 0.000 CYCLE/OFF
...
Excerpt from template file:
...
UponRec Ethel [Val8] [Val9] [Val10]
G67 X[Val8] Y[Val9] Z[Val10]
end
CYCLE FRED 3 [Val1] [Val2] [Val3] [Val4] [Val5] [Val6] [Val7] [Val8]
G88 X[Val1] Y[Val2] Z[Val3]
G89 X[Val6] Y[Val7] Z[Val8]
G67 X[H] Y[V] Z[D]
G67 X[H] Y[V] Z[D]
end cancel ...
... When you run PostHaste with the above CL data and template sections, this code will appear:
...
G67 X10.01 Y20.02 Z30.03 < This line is from the ETHEL record/sequence, G88 X1.1 Y2.2 Z3.3 < These are from the FRED cycle.
G89 X6.6 Y7.7 Z8.8 <
G67 X1. Y2.031 Z0 <
G67 X2. Y0.844 <
G67 X3. Y2.031 <
G67 X4. Y0.844 <
G80 <
...
Note: Even though the "ETHEL" and "CYCLE/FRED" records are adjacent to each other in our example, there is no additional relationship between them. (Much like it was in the original "I Love Lucy"... :-) You can use UponRec and Cycle sequences to "trap" CL records BEFORE they get to the post's "standard"
processing. This lets you overrride PostHaste's processing of any standard records. Examples:
• …to prevent LOADTL records from being processed by the post's internal tool change routines, use an "UponRec Loadtl" sequence: your UponRec sequence will take precedence over the ToolChange sequence (and therefore prevent the ToolChange sequence from being output).
• If the "CYCLE/DRILL..." data in your CL file is NUMERIC ONLY (in other words, it does NOT follow the normal text conventions for drilling cycles [FEDTO, RAPTO, etc.]), you can process them by using a "Cycle Drill" statement in your PostForm file. This will prevent the post's standard DRILL sequence from running and causing errors due to the non-standard portions of your
CYCLE/DRILL records coming from the CL file.
As you may have noticed from the examples above, the template file is not case-sensitive when it comes to CL record names - the terms LOADTL and LoadTl are identical as far as the template is concerned.
Note - Make sure that the name of the record you use in the UponRec line is spelled exactly the same as the actual name of the record in the CL file.
Using variables with UponRec or Cycle to handle the incoming values
First of all, you probably noticed in the examples above that the UponRec and Cycle lines include some variables, such as [Val1], etc. These variables store the specific values that are read from the incoming CL record.
Matching variables to values.
For best results, the number of variables in the template should match the number of values coming in from the incoming CL record. If, however, there is a mismatch, NO ERROR MESSAGE WILL BE
GENERATED.
• If the number of variables is LESS than the number of values provided in the CL record, then all of the variables you have specified will get set according to the values, and the "leftover" incoming values will be ignored.
• If the number of variables is MORE than the number of values in the CL record, then the extra variables will get set to zero.
By the way, "what's a VARIABLE and what's a VALUE?"
The term "variable" refers to variables in the Postform file, such as [H] or [Tool] or [Val3]. (This is true throughout this manual, so we're telling you nothing new here.)
The term "value" refers to a single numeric value (for example, the X position or a tool number) coming in from the CL file.
Cycle (using variables)
Use the CYCLE sequence to format a custom point-to-point (a.k.a. 'drilling') cycle. This means that you want to process a series of GOTO lines that follow a particular record in the CL file. Each GOTO will be interpreted as a point, just as in all other standard cycles (such as DRILL, PECK, TAP, etc.), until the CYCLE/OFF statement is reached.
Except for the following special conditions, all of the rules that apply to standard drilling operations also apply to the CYCLE sequence - so you may want to review the "Canned Cycle" section of the manual (and especially the 'Advanced canned cycle control' information in section 5.2.2.4).
The minimum requirement for a CYCLE sequence is just the word CYCLE followed by another word - that word being one that is not a standard APT cycle (such as DRILL, PECK, BORE, etc.) as in this example:
CYCLE FRED ...
...
end cancel (NOTE: The "cancel" is optional.)
You may also use up to 10 variables (or none at all), as well as the "Force?" option - as shown in the example below.
NOTE: If you use variables, then you MUST include the number of non-repeating 'first hole' lines immediately after the custom cycle name (the number 0 in the example below):
CYCLE FRED 0 [Val1] [Step] [RLevel] [...] Force? Y
If you mistakenly omit the 'first hole' number, then you will probably get an error message when you run the post like "the number of setup lines in the CYCLE line exceeds the number of lines in the cycle". This is because PostHaste will interpret the internal value of the variable [Val1] (which happens to be 190) instead of a valid number.
If you're not clear on what that number does, then again, please review the section entitled "Advanced canned cycle control" (section 5.2.2.4).
More UponRec and Cycle examples
Here is a use of UponRec (combined with a Convert command) to process incoming APPLY records in a 'non-standard' way:
Convert 'APPLY / LASER' to 'APPLY / 1' Set Val1 flag for laser.
Convert 'APPLY / PUNCH' to 'APPLY / 0' Ignore: Apply / Punch Uponrec APPLY [Val1] (Val1 = 'laser on' flag.)
if [Val1] = 1
G25 e5 Replace 'e05' with '(LASER OFFSET)' M44
M45 endif end
Similarly, the Cycle sequence can be used to process any APT-CL CYCLE records that do not match the standard cycles that PostHaste recognizes - like the example below which processes a CYCLE / WELD record:
Cycle WELD
G89 G99 X[H] Y[V] Z[D] R[RLevel] F[FRate] d[Dwell]
end cancel