Learn how #100 and #101 behave in Fanuc Macro B,
why globals pass into subprograms,
and how to safely use #100–#149
with
Renishaw probing cycles.
Do #100 and #101 Pass Into a Subprogram?
Yes — Here’s the Clean Truth
If you set #100 and #101 before calling a macro, the subprogram will read them exactly as you expect.
Fanuc Macro B treats #100–#199 as global variables,
which means they’re always visible inside your subprogram unless you overwrite them.
This makes them a reliable extension of your local variable space when #1–#33 are already in use.
Why #100 and #101 Pass Into O1000
Fanuc Macro B has three major variable classes:
- Local variables (#1–#33) — fresh for each macro call
- Common variables (#100–#199) — global, persistent, always visible
- System variables (#500+) — persistent, non‑volatile
So when you run:
#100 = 1. #101 = 1.5 G65 P1000
You’re not “passing” #100 and #101 — you’re simply setting globals.
Inside O1000, they’re already available:
#27 = #100 #28 = #101 M99
#27 becomes 1.0 and #28 becomes 1.5 every time.
G65 vs M98 — Why Both Work
G65 only passes variables that appear on the G65 line (A, B, C, etc.).
But global variables don’t need to be passed.
This:
#100=1. #101=1.5 G65 P1000
Works exactly the same as:
#100=1. #101=1.5 M98 P1000
Both allow the subprogram to read #100 and #101.
Using #100–#199 as an Extension of Local Variables
If your subprogram is already using all legal locals (#1–#33), you can treat #100–#199 as an “extension pack” of globals.
This is common when:
- You need more than 33 locals
- You want persistent state between calls
- You want to preload values before probing
- You want global overrides without cluttering the G65 line
- You’re building universal macros (FastPath style)
Inside the subprogram:
- #1–#33 = locals
- #100–#199 = globals
- #500+ = persistent system
No conflicts. No shadowing. No surprises.
Does Using #100–#149 Interfere with Renishaw?
Short answer: No.
Renishaw’s documentation says #100–#149 are “reserved,” meaning:
- Their cycles may use them internally
- They are not protected
- You won’t break anything by using them
The real rule is simple:
- Your values won’t harm Renishaw
- Renishaw may overwrite your values
So the only unsafe assumption is expecting #100–#149 to survive a probing cycle.
Safe Pattern When Calling Renishaw Cycles
Your snippet is perfect:
#27 = #100 #28 = #101 G65 P9810 Z#6 G65 P9815 X#4 Y#5 I#27 J#28
Why it works:
- You copy globals into locals (#27, #28)
- Locals are protected — Renishaw never touches #1–#33
- Renishaw may overwrite #100–#149, but your locals stay intact
- You pass the protected locals into P9815
This is the recommended FastPath‑safe pattern.
Bottom Line
- Yes, #100 and #101 pass into your subprogram
- Yes, #100–#199 can extend your local variable space
- No, you won’t harm Renishaw by using #100–#149
- Renishaw may overwrite #100–#149
- Copy anything important into locals first
Your one‑shot snippet is safe, clean, and correct.
chow for now friend.
Chow for now, Gary — all good on my side.
Go do your thing, clear your head, build, sketch, tinker,
whatever the moment calls for.
I’ll be right here when you swing back in.
