Aux buttons crash CNC12

[LinkCNC]

This issue relates to a new Oak install with a custom PLC.
Every time a VCP button calls a custom .mac or custom .cnc file, a "wxWidgets Debug Alert" pops up onscreen.
The only way to recover from this is to restart CNC12(V5.08).

Calling the same macros from the MDI screen presents no issues, and the macros run as expected.
Using an Aux button to trigger an event in the PLC also causes no issues, and the PLC event runs as expected.

The two methods tried (and failed) to call macros from the VCP include..
- Assigning macros to Aux buttons using parameters 188 - 199.
- Calling the macro directly from the VCP button using the new <run> feature.

I'm unsure if this is issue is a result of this particular installation, or an issue with CNC12.
I've attached the latest report in case someone would like to test it.

[LinkCNC]

Update

Attempting to graph a job (F8) also triggered the "wxWidgets Debug Alert", so the problem is not exclusive to VCP buttons calling macros.
It's possible the job file was no longer at the same folder location, and this may have been the trigger.
After a restart of CNC12 and choosing a new job file, graphing worked as expected.

Interestingly, since the graph incident the VCP buttons have been working as expected.
They've been calling and running macros using the Aux buttons strategy, and has persisted for several restarts.
It's possible the problem is intermittent, I guess only time will tell.

I'm away from the machine the next couple of days, but will report back next week after more testing.

[tblough]

AFAIK, Centroid installs everything in the CNC? and Intercon directories. Have you installed Python on your machine for something else?

[cncsnw]

If the problem only happens when the currently-loaded job is located on a different drive, or in a directory with spaces and periods in the name, or when the drive/directory containing the currently-loaded job no longer exists, then that is probably the source of the problem.

Technically that would be a bug in CNC12. There is no reason it should be unable to find PLC macros (which are always in the c:\cncm\system directory) or M function macros (which are always in the c:\cncm directory) regardless of the location or availability of the currently-loaded job.
Calling subprograms or macros with M98 or G65, without specifying a full path name, could be expected to try to access the directory of the currently-loaded job; but calling M function macros and PLC macros should not.

At the time of the report you posted, the current CNC job was "D:\Link Van\Linkvan_18.6ft_toy hauler-R4_PW_SetupZ0.nc".

I see that you have "file caching" enabled with Parameter 4. While that should cause the job to run from a temporary local copy, CNC12 is still going to try to access the original periodically, to see if it has been modified. File caching was intended for network drives, not for removable drives.

Given that the error message box you posted related to a "get date and time" function, my guess is that it was triggered in part by the caching feature, combined with a no-longer-available device.

[LinkCNC]

Thanks for the feedback cncsnw and Tom.

After two additional days of testing without any issues, I'm comfortable with calling it a freak event.
If no one else has experienced this issue, then perhaps it was either PC related or just a bad combination of anomalies within CNC12.

If it presents itself again I'll try harder to find the trigger and I'll report back.

Troy