I have not had this issue before. I try to open a file and it hangs at the attached Checking screen forever and I have to force quit cut control.
MR1_DrillHoles.nc (1.2 KB)
I figure something is wonky with the gCode but I appreciate any help.
Which cam software a did you use?
I’ve made made my CC hang up when testing what G codes worked with the software. Otherwise I’ve seen it hang for a minute when loading bigger, 45,000 line or more, programs.
I did a quick read through of your program and I don’t see any codes that would make it hang. The tool number T32705 is oddly big, but the software really doesnt pay attention to the tool numbers beyond reading that it’s there. You may try changing it to something in the 1 thru 5 range and see if that helps.
Another small thing I haven’t run across on the MR1 is an underscore in the program. Granted it’s in a comment, (MR1_DrillHoles), but it can cause errors on older industrial controls in my experience.
Also, I’m curious what post processor you used as well. I don’t see anything wrong with its format while reading through, but the knowledge could come in handy later.
Mine hug up and required a force close to resolve. It happened when I loaded my program into CC. I immediately noticed an issue in the code so I opened notepad, made the change, saved, and it hung when I tried to reopen/reload the program into CC.
After the forced close it loaded in no problem. I haven’t tried to hang it again but I suspect opening a file thats already loaded or opening the same file after an edit/save like I did might have something to do with it.
I forgot all about this happening when I was testing G codes. When I left the file open in the editor a couple of times that it would hang when reading the file. It wasn’t every time, but probably every other time or thereabouts.
I removed the Tool number and it loaded fine. So it clearly didn’t like that line. I have not tried to change the tool number to a single digit.
I design in Fusion360 at the desk and output to a google drive. I do not have it opening the gcode after post processing so not a file locking issue.
I don’t have this issue with the Plasma but then again that table doesn’t do tool numbers if memory serves.
As for the underscores, sorry, that dates back to my programming days when spaces were evil. But that should not be a problem here.
I did get this to load but it would be nice if the large tool number was not an issue. We are using large tool numbers because we are using a coding system to ID material, tool number, collet size, etc. Makes it easier to setup the machine without needing to look at the original design.
Thank you all for the help.
I’ve programmed a bunch for older Okuma 3000 controls, they don’t like a lot of characters, so I understand that lol.
I just haven’t tried underscores on the MR-1 yet, so I wasn’t sure if that could have had something to do with it. Glad the T# change got it rolling though.
I have mine set to use underscores in the file names fairly consistently. Anything that I don’t specifically name (I also don’t use spaces) is named by my CAM and its set to always use underscores, so far that hasn’t cause any issues that I’ve been able to identify. Also a coding habit lol