Halting after 5 min of run time.
Closed this issue · 22 comments
From a report by @qulet:
I uploaded a new improved grbl-Mega-edge code. I fired from the G-gode SD card generated in the Vectric Aspire program for the GRBL postprocessor. Unfortunately, after about 5 minutes of work, the engines stopped spinning, sending for unknown reasons was discontinued ...
It was a simulation of work as in the picture above only the motors of the x, y, z, axis, with no spindle.
The same G-code from the SD card fired from the computer on the GRBL-Panel sent via the USB cable after com8, stopped at 6876 lines ....
Well, I've had it running on my bench for over an hour now... and I can't reproduce the problem.
Did you make any modifications to any configuration files? If so, can you post the exact files you are using to build grbl?
Also, can you post your eeprom settings? (accessed from the Arduino serial monitor by entering $$ and then clicking the send button)
If you have the same software configuration as I have here; then I am wondering if you are experiencing an electromagnetic interference issue. To check that; disconnect the motors from the drivers or disconnect the drivers from the RAMPS board; and then try to run the file.
My hardware is arduino Mega, usb-serial CH340, ramps 1.4 stepstic 2x a4988 8825.lcd 2008 aliexpress shop. 12V Computer power supply. I have uploaded orginal githubb files to arduino, before I cleaned the EEprom-clear memory
[
grbl_Mega_config
$0=10 (Step pulse time)
$1=255 (Step idle delay)
$2=0 (Step pulse invert)
$3=0 (Step direction invert)
$4=0 (Invert step enable pin)
$5=0 (Invert limit pins)
$6=0 (Invert probe pin)
$10=1 (Status report options)
$11=0.020 (Junction deviation)
$12=0.002 (Arc tolerance)
$13=0 (Report in inches)
$20=0 (Soft limits enable)
$21=0 (Hard limits enable)
$22=0 (Homing cycle enable)
$23=0 (Homing direction invert)
$24=500.000 (Homing locate feed rate)
$25=2000.000 (Homing search seek rate)
$26=250 (Homing switch debounce delay)
$27=1.000 (Homing switch pull-off distance)
$30=1000 (Maximum spindle speed)
$31=0 (Minimum spindle speed)
$32=0 (Laser-mode enable)
$100=800.000 (X-axis travel resolution)
$101=800.000 (Y-axis travel resolution)
$102=800.000 (Z-axis travel resolution)
$110=2500.000 (X-axis maximum rate)
$111=2500.000 (Y-axis maximum rate)
$112=500.000 (Z-axis maximum rate)
$120=100.000 (X-axis acceleration)
$121=100.000 (Y-axis acceleration)
$122=100.000 (Z-axis acceleration)
$130=200.000 (X-axis maximum travel)
$131=200.000 (Y-axis maximum travel)
$132=200.000 (Z-axis maximum travel)
Today I started g-code without stopwatchers and after about 8 minutes this error occurred
Movie from the work of engines
https://drive.google.com/open?id=1-Ucr34yWzu96qXuGxvgPcUcV70QtU6nf
after a few minutes the diode at D10 will flash and the work will stop ...: ((((
My library GRBL:
grbl.zip
The good news is I am now able to reproduce the problem.
The bad news is I think it's a race condition...
This is not going to be simple to debug. I am going to have to set up a PC with Atmel Studio 7 (I'm normally Mac based); import grbl & get it to compile; see if I can get it to die with the debugger attached; and try to figure out where it's going off the rails.
This might take a while to get fixed... 😒
Thank you very much for your interest in the problem. There is no hurry. You are incredibly smart and share your knowledge with respect !!!!
Something is wrong with my Ramps or Arduino today I tried to spin the engines it stopped working ...
The engines are holding, but they do not receive the STP and DIR commands. The re-blending of GRBL has changed nothing. Arduino connects to the computer and can be successfully programmed so RAMPS probably got damaged ...
I doubt that it's the RAMPS, there are no active components in the part of the board that would affect this. If something is dead; it's probably either the arduino or the stepstick drivers. However; it might just be software:
I found something that might provide some insight. I've only had a couple of minutes to check this, but so far it seems to hold up:
According to this:
grbl crashes when it tries to go too fast... checking the config values you posted; for 800 steps/mm grbl can only go about 2000 mm/min.
I had thought that because the stepper ISR re-enables interrupts before finishing; it was getting re-entered and causing a total stack overrun; but it's got a "busy" flag that's supposed to prevent that... so now I'm not sure.
Anyway, try setting $110 and $111 to a maximum of 2000 and see if it works for you.
I do not give up !!!
On a marina with ramps 1.4
the engines started.
I once did EEPROM cleaning and uploaded your shared GRBL Mega-Edge. Strange but the engines moved. I have changed the settings by following the link: gnea#100
I took stepstiki and ran G-code ... THIS IS IT !!!! He works over 1,5 hour and he does not hang up. As they say, "the devil is in the details." These bad GRBL settings caused Error.
Thank you very much for your help. Now I have to connect the remaining I / O Pin and continue testing.
I give up .... I am waiting for DOC describing how to connect the peripherals so that this controller works with the machine .. !!!
I tried to activate home cycles and limits D14, D15, D19 - the massacre does not work as it should ...
I’m working on documentation as I get time (it’s crazy hot here this weekend so this is the only thing I have been able to work on) 😓
As you run into different bugs etc please do open a new issue here, so that they can be kept track of properly. 😄
I have some preliminary documentation on wiring hookup in the wiki now:
https://github.com/bdurbrow/grbl-Mega/wiki/Wiring-Hookup-for-CNC-with-RAMPS-1.4
I have some preliminary documentation on wiring hookup in the wiki now:
https://github.com/bdurbrow/grbl-Mega/wiki/Wiring-Hookup-for-CNC-with-RAMPS-1.4
Nice! Does "safety door" is the same as "panic button"/safety stop? What about sensor probe pin? (to zero Z axis).
Did you thought about adding spindle RPM display for closed loops motor drivers (this is simple PWM output from spindle controller)?
Great work!
Nice! Does "safety door" is the same as "panic button"/safety stop?
No, it causes a feed hold when triggered, and resumes operation when released.
What you want is an emergency stop function - and IMHO, on this kind of system, that should function by cutting power to the system.
Probing still needs documentation.
Also, something is odd with the spindle control... I'm not getting PWM out. Still debugging.
As mentioned earlier, this documentation is preliminary.
By default grbl (for small atmels) has on A0 reset/abort - I've used it so far and it's working as emergency stop perfectly. And on A5 probe (you are unseeing it for keypad already).
Figured out what was wrong. I've updated the Wiring Overview graphic; I'll have updated text and code soon...
Text is updated; code will have to wait until tomorrow.
Code is updated; but not everything has been tested yet (probing, mostly)...
Edit to add:
Did you thought about adding spindle RPM display for closed loops motor drivers (this is simple PWM output from spindle controller)?
Thought about - yes. Implemented yet? Nope.
I'd like to add threading & tapping support sometime... that will require a spindle encoder input; which will provide that actual RPM data... so it's not a major jump from there to showing it on one of the status screen pages.
(yes, I know about fschill's spindle sync work - I'm probably going to work off of what he's done to implement it).
😄
@zvizdic -
You shouldn't need to; look at line 305 of cpu_map.h.
#define CONTROL_RESET_BIT 2 // Pin D47 - RAMPS Aux 4 Port
#define CONTROL_FEED_HOLD_BIT 4 // Pin D45 - RAMPS Aux 4 Port
#define CONTROL_SAFETY_DOOR_BIT 6 // Pin D43 - RAMPS Aux 4 Port
#define CONTROL_CYCLE_START_BIT 5 // Pin D32 - RAMPS Aux 4 Port
I tried using a safety door pin as my hold/resume since I have one on/off switch i place (see pics)but it’s not doing anything . Also try the feed hold and it works.
I would rather have existing on/off switch doo hold and resume
Any chance for some help
Switch should be connected to control ground and pinD43 if I am right
Any chance for some help
I'll look into it this afternoon. (as I post this it's 1PM here in California... I dunno where you are though 😄)
Toronto Canada
I am stil on your first release of software is there a new release?
Thanks
OK, I think I found a problem with the safety door handling in the main grbl distribution. I've opened an issue over there; and patched my version here... it seems to be working at the moment.
There's something odd going on with updating the UI during a resume operation; I suspect that there's someplace that I need to drop a call to UITask() into that I haven't found yet.
Note that in order to resume operations, grbl expects both that the door switch has returned to normal; and that a cycle start has been issued (either on the serial port or on the cycle start input pin).