01Copy the whole block, not just the code you suspect
The control leaves the cursor on the block it could not interpret. Careful: with look-ahead active the cursor can sit one or two blocks past the real fault, because the interpreter runs ahead of the motion. Write down the complete line and the two before it. The problem is often not the G code that catches your eye but an address at the end of the same block.
02Decide whether it is an unknown code or bad formatting
If the block contains a G or M that does not appear in the code list in the programming manual for your series, it is a code problem. If the G exists and you use it every day (G01, G90, G54), it is formatting: a letter repeated twice in the same block, a value with no decimal point where the control expects one, a stray sign, an odd character that crept in when the file was edited off a USB stick. Fixing formatting takes minutes; fixing a code that calls an option you do not own is a different story.
03Check which modals were active when it got there
The control's modal display shows the active G code of every group. The classic clashes: a move programmed with a canned cycle still open and no G80, a plane change inside cutter compensation without cancelling with G40, rigid tapping called without closing the previous mode. If it does not fail when you start from the top of the program but does fail when you start mid-program, it is definitely modal.
04Confirm the option is installed on that machine
Custom macro, high-speed and surface machining cycles, C-axis functions, on-machine probing: those are all purchased options. The control's system screen has a list of enabled options (the screen name changes between series; look for the option list or system configuration). If the function is not listed, the code will never work no matter how you rewrite it: either you change the programming strategy or the option gets bought.
05Compare against the post processor that produced the program
Open another program that does run correctly on that same machine and compare the header and the way cycles are written. If the failing one has a different style, a different post generated it or somebody edited it by hand. A post pointed at the wrong machine is the number one cause of PS0010 in batches.
06Dry run it before going back into production
With the block corrected, go back to the start of the program, put it in single block with the spindle stopped and the axes clear above the part, and let it read through the area that failed. If it passes cleanly, you are done. If it stops on another similar block, the problem is systematic in the post and it has to be fixed in the CAM system, not at the machine.