What's new
What's new

Engraving Macro

Madsquirrel113

Plastic
Joined
May 14, 2020
I am working with a Fanuc Oi control. I am trying to work up a macro around a G1025 canned engraving cycle. I am hoping to use a variable for the text to be engraved and additional variables for the location. G1025 only supports a lower left corner position for engraving. I would like to provide additional options for engraving locations.

Is there a way to have a variable equal the number of characters in another variable? For example if #101=engraving than #102=9.
 
So you're trying to set the start position (H or V) in your G1025 based off of the number of characters you have between the parenthesis?
Once upon a time I tried using a variable inside the parenthesis and it threw an error. Something along the lines of it not liking the # symbol. So i figured it would not read anything inside the parenthesis as anything but text which ruled out macros. I did not do any investigating at the time and would be interested to hear if you can use a variable with the parenthesis.
 
That's exactly what I am trying to do. I can get the logic to work based on the number of characters, but I would like to avoid counting characters. (I don't like taking my shoes off). The hope is to avoid it.

Regarding a variable in parentheses. It works, but as Vancbiker said, variables cannot contain letters. (I tried) So this would be restricted to part/ serial numbers until I figure out a workaround. Which may be writing the text in the appropriate place of the G1025. However, I am trying to avoid making edits in the body of the program.
 
I think you can do something like a loop that keeps dividing your number by 10 until it is less than 1 and count the number of times you run through the loop.

What does your G1025 look like using the variable for text? Can you post the line of code?
 
Its not very developed yet, but this is what I have checked out today. Sorry if its terrible. Again, #101 has to be a number.

O0001 (ENGRAVING)
(XY Plane Only)
(G1025 Dd Cc Ff Ee Pp Hh Vv Bb Ll Uu Aa (**********))
(pg.323 of Fanuc manual B-63874EN/09)

#101=1234 (Numbers to Engrave)
#102=1 (Tool #)
#103=54 (Work Offset)
#104=0.0625 (D, Tool Diameter)
#105=0.1 (C, Clearance Height)
#106=5. (F, Feed Rate, Cutting)
#107=1. (E, Feed Rate, Plunge)
#108=9990 (Spindle RPM)
#109=1 (P, Plane Select, 1=XY, DISABLED)
#110=0 (H, Start Pt, (1st Axis(X)))
#111=0 (V, Start Pt, (2nd Axis(Y)))
#112=0 (B, Base Position(Z))
#113=0.005 (L, Depth of the character)
#114=0.125 (U, Height of the character)
#115=1 (A, Angle of character, 1= 0deg))

G0 G17 G40 G80 G49
G#103 T#102 M6
G00 G90 X#110 Y#111 S#108 M3
G43 H#102 Z1. M8
G1025 D#104 C#105 F#106 E#107 P1 H#110 V#111 B#112 L#113 U#114 A#115 (#101)
Z1. M9
G91 G28 Z0
G91 G28 Y0
G90 G40 G80 G49
M30
%
 
Thanks for posting that. I'll have to try again with the variable in the parenthesis tomorrow and see what i was missing.

So yeah i would try something like a do while loop to work out the number of digits in your variable and then by multiplying your character size by half of your variable length you can get the offset to adjust your starting point to keep it centered(If keeping it centered is what you're trying to do)
 
That puts a damper on things. Lets say I limited it to numbers. Is there a way to count the number of digits?

Hello Madsquirrel113,
Yes. There are Macro examples I've Posted on this Forum to disassemble a number into its individual digits, from either end, and in doing so, the number of digits is a by product.

I'm not sure where to search as the Posts were in reply to others. I'll see if I can find the Macro on my Compute and Post it here.

For example, of your were to pass the #101 variable. in your example 1234, the numbers 1,2,3,4 can be isolated.

With all due respect, if you're allocating values to the variables #101 Through #115 in your program, its not good programming practice, nor is it necessary to use Common Variables, particularly when they are being passed to Local Variables in G1025. Why would you not explicitly state the values in your G1025 Call Block as follows:


G1025 D0.0625 C0.1 F5. E1. P1 H0 V0 B0 L0.005 U0.125 A1 (#101)

Also, addresses G, L, O, N, and P aren't represented in Local Variables and therefore, can't be used to pass arguments as you're trying to do with "L" in your program example and as shown in Red above.


Regards,

Bill
 
Bill,
I'm sure these are not new issues, hardly anything is, and I appreciate any help you can give me. I try not to tell my life story when I ask a question, but I can see a little background is in order. I program almost exclusively in SolidCAM. I have been doing it for 10 years now. SolidCAM has zero macro support, that I am aware of. In that 10 years I have never had the luxury of time to sit down and work out the best way to do something. I have found the first thing I can make work and beat it into the hole. This is the first year where we have had a slowdown and I decided to fit some learning time in. I picked a few projects and am writing out g-code long hand and working on macros. Primarily, some quality of life stuff.

This is precisely the 3rd bit of macro programming I have ever attempted. I am using common variables because I watched a youtube video that suggested them and after reading the pinned thread above could not see a need for the variable to persist through shutdown. I'm not aware of other criteria that would drive what variable is appropriate. Assuming that the variable is not used in G1025 directly and everything is defined appropriately in the current program.

There are two reasons that I turned all the values in the call block into variables. The first is that I intend to add a number of calculations that will change those values. I am still deciding what those will be as I go because I do not know the limits of macro programming yet. ie, not being able to assign text to a variable. For example I would like to calculate the position of H and V however it is presented on a print without pulling out my calculator. I'm considering multiple lines of G1025 and maybe also date stamping. SolidCAM doesn't do serialization and so I am considering using G1025 for serialization. Whatever I decide to do I expect the G1025 block to get fairly buried and I thought that having the variables at the top of the program would simplify editing.

Another reason that I put the variables together at the top was to allow comments to be directly next to the data input. I have an operator who doesn't like things that are "Not a Haas" another that doesn't like things that are, "not a Mazak," and another who seems allergic to using his eyes.

I will need to look at my "L" value in the morning. I did a test run this evening and everything seemed to run OK, but I did not specifically check my depth.

I can spell out the function of the letters as comments and put the G1025 at the top of the program. Directly input the values in the call block. Then use GoTo commands to skip the G1025 and come back to it later after any variables have been processed. Would that be more correct?

Any insight is helpful.

Thanks,
Tim
 
Bill,

I will need to look at my "L" value in the morning. I did a test run this evening and everything seemed to run OK, but I did not specifically check my depth.Tim

When you specify arguments in a Macro Call Bock, the associated values are passed to Local Variables in the Macro being Called.

In Argument Specification I
21 Variables, A to Z excluding G,L,N,O and P, to access Local Variable Number #1 to #26, excluding #10, #12, #14, #15 and #16 are available. As there is no L argument available, there is no Local Variable for it to access. Its use in a G65 call may not raise an Error, as its a Legal address in Macro Modal Call with G66 for when a number of repeats of the Macro are required, but your Macro will not function correctly, if you think you're accessing a Local Variable in the Macro with address "L".

In Argument specification II

Arguments A, B, C plus 10 sets of I, J and K argumnets, to access 33 Local Variables (#1 to #33) are available, but still no "L" argument address.

Unless you intend more than one program to Read, Write to and be able to modify a variable without passing it, there is no advantageous reason for using Common Variables and can give rise to unintentional modifying the same variable in another program. Common Volatile Varibels used when Local Variables would do is vastly better than using Common Nonvolatile Variables, where these Variables are often used to store important data for the operation of the Macro, but its still not good programming practice.

Regards,

Bill
 
Thank god for Haas built in engraving cycle! :D

G47 P1 (####) X Y I J and done.

I think there are some extra variables required for engraving on a cylinder however.
 
There are two reasons that I turned all the values in the call block into variables. The first is that I intend to add a number of calculations that will change those values. I am still deciding what those will be as I go because I do not know the limits of macro programming yet. ie, not being able to assign text to a variable. For example I would like to calculate the position of H and V however it is presented on a print without pulling out my calculator. I'm considering multiple lines of G1025 and maybe also date stamping.

Tim

Hello Tim,
Disregard what I said about the use of the "L" argument in the G1025 Call Block; its a legal argument for this Canned Cycle as its not a Macro Program. I first thought this was a program written using the User Macro language, but it's a Program written using software used in to write control functions, that is able to handle String Variables. G1025 is much the same as Haas's G47 and can be found as part of Manual Guide.

The issue using Common Variables at the Head of the Program to set the vales used in the G1025 Cycle, is that if any of these Variables happen to be used in Macro Programs you may run between setting them before executing G1025, the values actually used in the Call Block may not be as you expected and will be whatever they were changed to.

If you use Local Variables at the Head of the program to set the values used in the G1025 Call Block, their values will persist unless changed in the program in which they exist, or if a Reset is carried out before The G1025 Cycle is executed. Of course, depending on parameter setting, Common, Nonvolatile Variables will also be set to empty when a Reset Event is executed. If you want to protect Local Variables from being initialized to Empty by Reset, this can be done via parameter setting.

Regards,

Bill
 
Hey Gentlemen, you can name variables on a Fanuc per the below example. All system variables can be named and the #500 common variables can be named using the SETVN function. System variables already have names, see a Macro B manual. The custom naming of the #500 variables is also explained in the manual.

Paul



SETVN.jpg
 
Hey Gentlemen, you can name variables on a Fanuc per the below example. All system variables can be named and the #500 common variables can be named using the SETVN function. System variables already have names, see a Macro B manual. The custom naming of the #500 variables is also explained in the manual.

Paul



View attachment 290145

Hello Paul,
They can be named; that's been the case for quite awhile. But they can't be used as String Variables (containing Alpha characters), only Numeric.

Regards,

Bill
 








 
Back
Top