grblHAL / core

grblHAL core code and master Wiki
Other
310 stars 76 forks source link

is there anyway to reset settings to default? clear EEPROM, Factory reset, ETC? #334

Open crackinx opened 1 year ago

crackinx commented 1 year ago

I messed some stuff up trying to get sensor-less homing to work and am now locked out of IOSender because it is waiting for "MPG mode" to be disabled and have no clue what it means. I do have access to the console from cncjs, but don't know exactly what I changed to be able to change it back. At this point setting everything back to "flash fresh" is my best bet, but have no clue how. Any help would be great, Thank you!

karoria commented 1 year ago

Same issue here. I have fresh started some days back and iosender is waiting to disable MPG mode. Actually grblHAL hangs when you issue "$$" enquiry for settings.

crackinx commented 1 year ago

Same issue here. I have fresh started some days back and iosender is waiting to disable MPG mode. Actually grblHAL hangs when you issue "$$" enquiry for settings.

So i figured out the issue, if you can get to the console chage the auto-report interval back to zero. that;s what was locking me out of IOSender.

karoria commented 1 year ago

I am using webUI for my machine and autoreport interval setting doesn't seem to work for me for $$ crash. Can you confirm sending $$ from console doesn't crash the controller?

crackinx commented 1 year ago

I am using webUI for my machine and autoreport interval setting doesn't seem to work for me for $$ crash. Can you confirm sending $$ from console doesn't crash the controller?

$$ does work for me, that was never part of my issue. The auto-report interval was what was locking me out of IOSender and was able to reset the settings from there. I am however locking up once I try to run a file, sometimes it only gets 2 seconds in and sometimes it makes it anywhere up to several hours. I don't have anything hooked up to the controller other than motors, limit switches, and probe at this point and the problem persists. I am replacing the controller at this point to rule that out.

karoria commented 1 year ago

Thanks for confirming. Your machine's random behaviour might be due to EMI. Any floating inputs? If your machine can run for hours without spindle turning on, then it is surely EMI issue.

crackinx commented 1 year ago

Thanks for confirming. Your machine's random behaviour might be due to EMI. Any floating inputs? If your machine can run for hours without spindle turning on, then it is surely EMI issue.

That's my next step, I'm going to "air cut" with the spindle off and see what happens. Just not sure how to fix the issue if it is in fact that.

EDIT: it's been running motion for well over an hour now with no lock up. Seems it is EMI so I ordered some shielded cable for the VFD, hopefully that solves the issue.

terjeio commented 1 year ago

is there anyway to reset settings to default?

$RST=* resets all settings back to default, send $HELP COMMANDS for info about other options.

...am now locked out of IOSender because it is waiting for "MPG mode" to be disabled and have no clue what it means

When the sender sees real-time reports arriving at startup it assumes that a MPG is in full control. The latest edge versions of the sender now attempts to figure out if this is due to auto reporting beeing enabled and takes full control if so.

Seems it is EMI so I ordered some shielded cable for the VFD, hopefully that solves the issue.

VFDs are notorious for causing EMI that trips ut controllers. Did the controller crash (did not respond to commands) or did it enter ALARM mode/terminate the job due to corrupted input?

crackinx commented 1 year ago

is there anyway to reset settings to default?

$RST=* resets all settings back to default, send $HELP COMMANDS for info about other options.

...am now locked out of IOSender because it is waiting for "MPG mode" to be disabled and have no clue what it means

When the sender sees real-time reports arriving at startup it assumes that a MPG is in full control. The latest edge versions of the sender now attempts to figure out if this is due to auto reporting beeing enabled and takes full control if so.

Seems it is EMI so I ordered some shielded cable for the VFD, hopefully that solves the issue.

VFDs are notorious for causing EMI that trips ut controllers. Did the controller crash (did not respond to commands) or did it enter ALARM mode/terminate the job due to corrupted input?

it locks up and does not respond to commands, requires a hard reset to bring it back.

terjeio commented 1 year ago

it locks up and does not respond to commands, requires a hard reset to bring it back.

Ok, that would be close to impossible for me to debug. It could be a USB stack failure or something else. A good quality USB cable is a must. Proper grounding and normally closed (NC) limit switches with shielded cables may also help.

crackinx commented 1 year ago

it locks up and does not respond to commands, requires a hard reset to bring it back.

Ok, that would be close to impossible for me to debug. It could be a USB stack failure or something else. A good quality USB cable is a must. Proper grounding and normally closed (NC) limit switches with shielded cables may also help.

no worries, i've confirmed it 100% at this point. I ran it through an 8 hour file without the spindle going and it didn't lock up on me at all. I have shielded cable coming for the spindle power, I'm trying to get sensor less homing working right now too so the limit switches won't even be a concern.

crackinx commented 11 months ago

So I'm still having the lock up issue, after having grounded everything, shielded cable, several different usb cables including a shielded Nintendo switch one, and even a different comouter. What I notice is it happens over time the receive buffer slowly fills, once that is full the planner buffer fills, once that is full it locks up

terjeio commented 11 months ago

What I notice is it happens over time the receive buffer slowly fills, once that is full the planner buffer fills, once that is full it locks up.

That should not happen. Do you have Agressive buffering enabled in the App: settings tab? If so, does the lock-up happen with it disabled? And are you using the latest version, 2.0.43? It vas released two weeks ago.

crackinx commented 11 months ago

I'll give that a try, I've tried it with both cncjs and iosender the issue happens in both.

EDIT:agressive buffering in NOT enabled.

crackinx commented 11 months ago

So the new iosender made it through the file with no lock ups. Could have been luck as it does happen sometimes, so I'm going to run some more stuff and see what happens.