Confirmed that including the S parameter to define the speed is not needed - I added S230 to the M3 in the program and it failed first time!
I have also run the driver tests - and almost thought I had found the problem since the initial message as it started was 'pulsing too fast' ...however this almost instantly cleared and I had a stead almost completely clean line with an occasional short spike. The program f_inished successfully, so I ran it a second time to see if I could see anything on the data appearing on the screen that was of any significance - and couldn't see anything. The 2nd pass was fine too.
I looked closely at the gcode(which was edited from the original 'extended, verbose' G76 file) and remarked out a G49 that seems to have no meaning(odd....).
I then reran the video - well my iPhone - for another hopefully less crappy run.
http://youtu.be/xcP9VJCs--MThis shows the standard fail again, on the MSM screens which I find easier to view and use.
It also shows another issue which I have only seen twice before I think. The usual problem happens but the Z continues to advance at a g l a c i a l pace - the feedrate shows flashes of 5-10mm/min (when it should be 350) and eventually reaches the end point after which, all of the other movements are at a similar pace - I timed one cycle and it took about 16 mins rather than the normal 16 or so seconds.
I checked the index and it is still there happily pulsing away!
This was the point I ran the driver test to see if there was some weird clock instability.
Brett, good to know that someone is looking at the issue, let me know if there is anything else that I can look at or test to help clarify - I think I am at the limit of checking my own systems though - and most of this system also drives my mill and has run multi thousand line programs lasting for up to around 2 hours without any problems (apart from operator induced ones!).
Simon