As an ex IT guy any nr of solutions come to mind.
I don´t know fanuc.
I have no idea what the "best" solution is, or if any "good" solution exists.
1. You could use arrays like part_corner_x
with a counter or id.
2. Variables.
E.
offset_var = 10
offset = cycle_nr + offset_var
3. Incremental math, like partn x counter x (1+offset).
4. Adjusting homing.
5. Adjust work co-ordinate systems, depending on nr of parts and control.
A clever guy would *always* write and read the data to a tiny text file, every cycle, before running, and after running (write ok, timestamp, part nr).
This would prevent major messes if power is ever interrupted, glitches, estops etc.
A clever guy would also initialise all major modal states, every cycle as appropriate.
This avoids major catastrophic errors of all sorts.
Things like plane, feed mode, feed override, ss override, metric, scaling, *feed*, ss, etc.
A
really clever guy might also add a tiny script that does a tiny small feed, slowly, like 1 micron.
This might not move the machine - it is immaterial.
It would take less than 0.01 secs.
And then checks the machine and co-ordinate systems data, and compares them to expected values.
A stop, estop, hold, override, limit switch, soft limits or hw estop on say power conditioning or spindle overload or whatever - will not always leave the machine in the state You expected it to.
No - It Wont.
Mostly - yes, sometimes, no.
The modals + gcode stuff have over 16M permutations - interpreted differently - handled differently - with bugs, legacy stuff, and manufacturer specific features.
It is not really important how the manufacturer /controller/firmware handled stuff.
No-one will ever state/test/debug all combos - nor do they need to.
If YOU make the machine take a given "state" - it will always respond as You expect it to.
Anecdote.
It was an experience watching my lathe take off at max hw speed towards the chuck, when given a G1 Z-10 (in mm).
It "thought" it was in feed mode of mm/rev.
But the control showed feed/min !
In certain conditions on a specific canned threading cycle, an interrupted threading op. could do so.
So the control tried its best to crash in 0.5 secs into the chuck at 500 rpm or so.
Since it was trying to feed at 10 mm / rev or 500 mm /sec.
All the above is mostly a comment on one way why/how unattended or high reliability machine running can be well done.
I tried to use pseudocode - easier to read and understand.
Esp. for newbies and similar later reading this thread.
I did a lot of similar high-availability stuff in the past, for high numbers of production systems and kit.
My recommendations are based on experiences over thousands of installs, different, serving tens of thousands of users at once, with near-perfect relative reliability (aka much better than anyone else in the field.).
My recommendation is for various ways to solve it - easy and cheap.
Anyone will write you a script, for 200$-500$, if you do a code for 4 moves (square) and ask for a working program of type 1-5.
Depending on the size of the company, the *best* option is much more complex, and expensive, and vastly better.
Use a centralised proper dB,
machine-local files for passing data (bulletproof, simple, will work with any control/hw/sw/system forever),
triggers in the dB, etc.
A small business should not even think about this. Not worth it.
I did not recommend any method - and many others are surely possible.
Readability, maintenance, reuse, portability, compatibility with other controls/versions/fw/sw may be issues.
HTH.