forum.cncdrive.com

Hi,
I have been having some issues with a recurring reset trigger when taking a heavy cut. I think this is probably a problem with the machine design and I have a few thoughts on what is causing this (possibly noise). It would be very helpful if I could see exactly which input triggered the reset condition as the run screen event log is not registering anything (not even that it is in reset). I have watched the diagnostic screen while this occurs and have seen nothing change but I think it may be a very fast event.
Is there a log of events anywhere that can be accessed for troubleshooting purposes?

When the reset is triggered with an external e-stop input pin trigger or with a limit switch input pin trigger then the event is noted in the Status field,
the ext.e-stop triggered or Limit input triggered text is shown in the Status field.

In case a limit switch input pin is triggered then which pin caused the reset is not registered.
Also if a hotkey or an input pin trigger (configured on the I/O trigger page) causing the reset, those events are not mentioned in the status field.

So, you could narrow down what causing the reset with checking the status field after the event happened.
If the event was a physical e-stop input pin or limit switch input pin trigger then you will know that from the message in the status field.
If it was something else, an I/O or hotkey trigger then there will be no status message, so you will know it was one of these and could disable them to see if it resolved the issue.

Thanks for clarifying which events show in the status field. I do have a few drive and vfd alarm signal inputs which are set up to trigger the reset button so it is looking like it may be a noise issue with one of those as the drives and vfd themselves are not recording a fault. I will do as advised and disable them one at a time and try to isolate the culprit. This may be just the excuse I need to treat myself to an oscilloscope
Could an input pin signal status message or log be a feature in the future? I am sure it would be a very useful troubleshooting tool for a lot of folks

iain1mm wrote:Could an input pin signal status message or log be a feature in the future? I am sure it would be a very useful troubleshooting tool for a lot of folks

You can use a macro to do that. Save the following code to M20000.txt (or any else from 20000 to 20999) into the macros folder:

Code: Select all

AS3.Additemtolistbeginning("Trigger nnn received", 2); // Set status message
exec.Callbutton(144); // Press reset

Set the trigger function to this number (e. g. 20000) instead of the reset code. When trigger occures, your macro will run, write the messega to the status window and press reset.
You can do the same with copying to other macros and changing status message in order to display other triggers.

Aha......Simple and clever! Thank you so much for taking the time to post the code
There goes my oscilloscope

iain1mm wrote:There goes my oscilloscope

Let us know if it helped to find the problem.

This is an oldish thread but I am just revisiting it as I have learned during some recent tinkering (see thread 'remote reset trigger issue') that a macro will not run whilst G-code is being executed. This means that using a macro to record the source of an input and then trigger the reset button will not put the machine into reset when code is running. I've set all my relevant inputs back to trigger the reset button directly but this leaves me back at square one not knowing which pin triggered the reset. On the bright side it does actually trigger the reset when the machine is running! It kind of explains why my noise issue appeared to go away after implementing the macro approach. I might get my occilioscope yet! It would still be nice to have a feature that would enable an input pin trigger to show in the status field. I understand that this would not be desirable for all inputs but could a tick box be used to select inputs which are desired to record a change of state?

You could use a macroloop, that runs even when g-code is running, so you could check I/O states via the LEDs or button states via the built in functions and could write to the status field and call a reset button or whatever you want to do.
Just one important thing is to avoid executing g-code from the macro loop when there is motion ongoing, because that can cause problems, unexpected results, because then both the Cycle and the macro loop will fill the motion into the motion buffer and so the order of the movements will be unpredictible. So, do anything in macro loops except executing motion when motion is already ongoing.

Thank you. That sounds like it would work but macroloops are a little above my pay grade at the moment I shall be looking in to them though. In the meantime I have designed a hardware solution using a little circuit that runs the input signals through small solid state relays, which will then power and latch an led until I manually reset it. It will at least let me know which input has triggered, even momentarily, and can still trigger a reset condition in the software if required. A bit old school but it will have to do for me until I can learn to code macroloops.

Macroloops are no more complicated than macros.
The only difference between a macro and a macroloop is that a macro runs once when executed (via MDI or g-code or button or plugin call),
the macro loop is also a macro, but it runs in a loop. So, when the macro ends it runs again and again and again.
So, the programming language and available functions etc. are all the same for macros and macroloops.
And you can test the macro even with calling it from MDI and then if it looks to be working OK then you could simply add it to a loop in the Configuration/General settings/ Config macroloops button and you got a macroloop.