Writng to a gcode file fails silently if the file exists and is in use
Hi @kjk2002
Thanks for posting! While I do not have access to the Mach3 software, I found that I was able to trigger an error message in the posted code itself when re-posting a program from Fusion with an identical name and output location as an open g-code file in Microsoft Word - Word must lock the file in a similar way to Mach3. This message, however, will only be immediately visible upon posting from Fusion if you have "Open NC file in editor" flag enabled in the Post Process dialogue:
Do you have the "Open NC file in editor" flag enabled? If so, you should see the "sharing violation" error message below in the code when the NC editing program opens;
Error: Failed to open output file 'C:\Users\claussp\Desktop\1001.nc' (sharing violation). Code page changed to '1252 (ANSI - Latin I)' Start time: Tuesday, August 22, 2017 9:22:34 PM Code page changed to '20127 (US-ASCII)'
While I agree with the fact that it would be nice to see this error message in Fusion (as you would not see the error message at all if "Open NC file in editor" is disabled), the error message is shown in the posted code due to a current limitation of the post engine. The Javascript post processor is where the code file is actually created and written to the desired output folder on your local hard drive. Because this is done in the post, Fusion does not know that the file is in use elsewhere because it is not actually Fusion writing the replacement file - it is the post processor script instead. Because the simple post script cannot pull up a Fusion error message, it shows the error in the code output file.
I also tested this behavior by opening a posted program in the Otherplan application - a controller for the Othermill machine. This program did not lock the file in the same way as Word did and edits to the Fusion CAM programming were allowed to post with no warnings. This is due to the fact that the post processor simply outputs the code file - if the code file being overwritten (with the same name and saved in the same location) is not locked by the application it is open in, it will use the version of the code that has been opened or imported into it until that file is exited - Fusion cannot push a code update to a machine controller, it can only create new code that can then be uploaded.
I did find that, when the original file was open in Otherplan and I posted code changes from Fusion under the same name and output location, the new file showed the code changed when "Open NC file in editor" was enabled. This did not change the code in Otherplan - I believe that some controller programs use an "import" function rather than truly opening a local filepath, so the program in Otherplan will always be the program I explicitly opened in Otherplan.
If Mach3 is locking the file when it is opened there, enabling the "Open NC file in editor" flag should allow you to see this error sooner rather than later, as it will only be shown in the post. Please let me know if you have any questions - I am happy to help!
