Which MCF file simulates the Fanuc canned cycles better ?
I have noticed that it cannot simulate the G98/G99 modes of the cycle. I checked also the subprogs that emulate the controller's build in macros. They don't use the #5003 variable (current workpiece coordinate in Z).
I edited the OG81.prg and put something like #27=#5003 (CSE understands that) but this must be "remembered" by the CSE when the cycle is being defined (like in real controller). So when the sub runs again for the second hole position the Z position could be other at I level (G98) or at R level (G99).
N100 G0 G43 X10. Y10. Z50. H1 (I Level = 50)
N101 G81 G90 G99 X10. Y10. Z-5. R3. F500 (R level = 3)
N102 G98 X-10. Y30.
N103 G99 X40. Y-27.
Line 101 is simulated correctly.
Line 102 not correctly. It stays at R level and goes to next hole (collition when there's obstacle).
Looks like the "logic" of the CSE is wrong. I don't believe I can fix that with the subprogs.
Here's an abstract from Fanuc manual. It states clearly that Initial Plane (I) is registered when invoking the canned cycle and it cannot be changed during the cycle. So CSE has to register somehow the Z position before cycle call (should also register X and Y for G18/G19 planes) and "remember" till G80.
G80 cancels I and R values.
from my view CSE simulation works as intended.
G99 and G98 set the internal Fanuc variable #4010.
This variable will be used inside the cycles. (e.g.)
My short test shows as I would expect it (maybe I do have a wrong understanding of the Fanuc Manual)
I'm using NX 10.3.5 MP11and Basic.CCF, FanucFamily.CCF sim05_mill_5ax_fanuc.MCF (not 100% sure for the last).
From the screenshots you sent it looks like it is NX 11.
Of course it doesn't really means the NX version is the problem. However, which CCF and MCF files you used ? (they all look the same, I don't have MachineConfigurator to check)
Thanks anyway for your quick test and reply.
I haven't compiled a file to send to support.
We also have a problem with simulation of G98 in cycles.
Using G68 with drilling cycles the #27 (retract plane) value is in machine coordinates not the current rotated/cycle coordinates. depending on the value this causes overtravels.
I found this in 9.0.3 checked this in NX11 which has the watch variables and confirmed this. Result the same using NX9 or NX11 CCF MCF etc.
I have tested in NX10.0.3 and do not see any problem. I am using one of the OOTB operations and manually edit the posted NC code. Simulation did what I expected . If you have cases which do not work please get in contact with GTAC.