Closed mayhem2408 closed 7 years ago
@mayhem2408 : Can you paste your $I build info? Did you alter anything in the config.h file? How did you compile Grbl? And what version of IDE/compiler?
That is a little weird and would suggest that either the compiler is a different and doing something strange. Or, I may need to tweak the memory usage a little. For the default build, memory shouldn't be an issue. It's been tested quite a bit, but it can be reduced easily if it comes to it.
I'm not quite sure what would cause the EEPROM to get garbled like that. It doesn't make much sense to me. Did this just happen once or is it consistent and just on this particular Arduino?
Odly, the EEPROM itself is still OK because if I restart the Arduino, the settings return to normal. The only config.h settings I have changed is CoreXY enabled. I have been running 1.1e for a few days and not seen this before.
Grbl 1.1e ['$' for help] $i [VER:1.1e.20161204:] [OPT:VC] ok
Just tried it again without M4 and the same problem with just 4 lines on gcode. Also did ? and got this mess <Idle|WPos:2147483.648,0.000,0.000|FS:0,0> The Work and Machine positions are way off, but should be at 57,0,0
Really scratching my head with this one.
I'm going to try another Arduino incase this one is having memory problems.
@mayhem2408 : It could be the CoreXY build is running out of memory. It does have to do a extra calculations and retain a few more variables on the stack. Try uncommenting and reducing the BLOCK_BUFFER_SIZE in config.h to 15. It'll free up a few dozen bytes of RAM and may be enough to fix it, if it is a memory issue.
I disabled CoreXY and everything is running fine. I enabled it again and it stopped working. I then changed the BLOCK_BUFFER_SIZE 15 and the small 4 line test worked OK, but when I ran my 350000 line gcode, it stopped at around line 200 returning an error that the feedrate had not been set, which it had. I also tried BLOCK_BUFFER_SIZE 14. Same Problem.
For giggles, I rolled back to 1.1d which I'm 100% positive was working as I have run from very large gcode programs through it and it doesn't work either. I am going to try another Arduino just incase this one has developed a memory issue.
I am running Arduino IDE V1.6.8
Sorry to have wasted your time. It appears one of my Arduinos has developed a problem. I just flashed 1.1e with CoreXY and BLOCK_BUFFER_SIZE 16 onto another Arduino and it is running fine. I am running my 350000 line gcode file through it now and it is 30000 line in and still going.
@mayhem2408 : Ok. Thanks for the update. It's still a little weird to randomly have an Arduino go bad. Let me know fi you run into any other problems.
The newly flashed Arduino is still running the gcode at over 100,000 lines out of 350,000. The only difference with this Arduino is it is running completely default EEPROM settings. Can the EEPROM be reset to defaults? I noticed that going from 1.1d to 1.1e and vice versa did not reset the EEPROM.
I have just updated my EEPROM settings on the new arduino and it is now doing exactly the same thing.
@mayhem2408 : Ok that is a big (and strange) clue. I'll check the defaults and settings restoring code to see if I can spot any problems that would be caused by enabling CoreXY.
Can you verify this behavior by flashing v1.1d, then restore defaults with a $RST=*
command. Check if it's normal. Then flash v1.1e, and restore defaults. Check if it breaks?
I manually changed just my acceleration $120 and $121 from 4000 down to 1000 and the problem went away. Changed it to 2000 and it is still OK. 3000 and 4000 caused the problem. So my Acceleration settings are two high. Somewhere to start at least. My CoreXY frame can really throw the head around at high speed and because of the light weight, it can accelerate fast. I wanted the highest possible acceleration to prevent the dark edge problem. But Mode M4 has fixed that, so I will run a lower acceleration from now on. At least we know what caused the corruption.
I changed $120 and $121 on my old arduino board down to 2000 and it is working OK now too. So it wan't a hardware problem after all.
@mayhem2408 : YIKES! I forgot to check your original settings. You are exceeding the max supported step rate of 30kHz. You are actually running at 41.6kHz. I'm surprised that you were able to get Grbl to go that fast and run stable. Kudos.
So I'm going to close this since it's not a bug. It's a CPU power limit you are hitting.
I have need testing V1.1 for a little while, but not come across this and can't explain it. First I power up the arduino and connect to it with PuTTY and it responds aknologing I am running V1.1e. If I type $$, I can see all my settings are correct.
Then I type the following. G21 G90 M4 S1 G0 X0 Y0 G0 X57.2 Y0
Each returns OK, but at this point nothing else works and if I do $$ again, the settings are all corrupt.
I have tried reflashing grbl but it has not helped. Any ideas?
Below is the PuTTY output.
Grbl 1.1e ['$' for help] $$ $0=10 $1=25 $2=0 $3=0 $4=0 $5=0 $6=0 $10=2 $11=0.010 $12=0.002 $13=0 $20=0 $21=0 $22=0 $23=0 $24=25.000 $25=500.000 $26=250 $27=1.000 $30=1000 $31=5 $32=1 $100=100.000 $101=100.000 $102=100.000 $110=25000.000 $111=25000.000 $112=1000.000 $120=4000.000 $121=4000.000 $122=4000.000 $130=350.000 $131=430.000 $132=50.000 ok G21 ok G90 ok M4 S1 ok G0 X0 Y0 ok G0 X57.2 Y0 ok $$ $0=0 $1=28 $2=0 $3=45 $4=1 $5=0 $6=0 $10=0 $11=0.000 $12=0.000 $13=1 $20=1 $21=1 $22=0 $23=145 $24=0.000 $25=-0.000 $26=12 $27=0.000 $30=0 $31=0 $32=0 $100=-0.000 $101=0.000 $102=0.000 $110=2147483.648 $111=0.000 $112=0.000 $120=0.000 $121=0.000 $122=0.000 $130=-0.000 $131=-0.000 $132=-0.000 ok