Closed Robin2g closed 4 years ago
fra589
commented
4 years ago Hi @Robin2g,
I agree that the problem seems to come from grbl-Mega-5X... Which command is causing Grbl to freeze ? Can you post the result of $I and $$ grbl commands ?
@++; Gauthier.
Robin2g
commented
4 years ago These are the outputs you requested
==========
$i [VER:1.1n.20200424:] [AXS:5:XYZAB] [OPT:VNMH,35,255,0] ok
===========
$$
$0=0
$1=0
$2=0
$3=0
$4=0
$5=0
$6=0
$10=254
$11=0.000
$12=0.000
$13=0
$20=0
$21=0
$22=0
$23=1
$24=2147483.648
$25=2147483.648
$26=255
$27=2147483.648
$30=1
$31=0
$32=0
$100=250.000
$101=250.000
$102=200.000
$103=500.000
$104=500.000
$110=500.000
$111=36000.000
$112=36000.000
$113=36000.000
$114=-200.000
$120=-0.056
$121=-0.056
$122=0.000
$123=0.000
$124=0.000
$130=-0.000
$131=-0.000
$132=-0.000
$133=-2147483.648
$134=-0.000
ok
==========
But it gets stranger still ...
The above results are from a Mega clone as that is what I want to us with my RAMPs shield. (Note that the shield is not connected to the Mega). This morning I also uploaded Mega-5X to a genuine Mega and on it all of the Gcode "G" moves cause error 9 to be reported. However the $$ from the genuine Mega does not have the strange floating point values as shown above - it has nice regular values such as 100.
Many thanks
...R
fra589
commented
4 years ago Hi @Robin2g,
It look like your Mega clone have a corrupted flash memory... Probably by another software used before on it.
grbl-Mega-5X cant work with those strange floating point values. When the EEPROM is corrupted like this, Grbl can have completely unpredictible behavior.
You can use the $RST=* command to clears and restore all of the EEPROM data used by Grbl.
With default parameters, the error 9 is normal behavior. Indeed, by default and for security reason, Grbl is in Alarm mode when powered on because it is unable to know the position of its axes. So in this mode, all GCode commands are locked as long as the homing ($H command) has not been performed or the $X command is issued to unlock the alarm lock.
@++;
Gauthier.
Robin2g
commented
4 years ago Thanks Gauthier, the $RST seems to have fixed it.
I don't recall ever reading about that sort of problem - I would expect it to be highlighted near the top of all the GRBL documentation.
In the meantime I have been adding an extra axis to a 3-axis program that I wrote a few years ago and I think I will just work with that. It uses Python to do the GCode parsing and the Arduino program is very short - it just moves the steppers based on numbers sent from the PC. I'm sure it is not nearly as good as GRBL, but it's mine.
Again, many thanks ...R
When I send commands to regular GRBL on an Uno with the minicom terminal program all works as expected. And the simple GRBL python program to send Gcode from a file works.
But when I try the same thing with grbl-Mega-5X on a Mega some of the Gcode messages work (i.e. produce an OK or an error response) but then it happens with another Gcode message that there is no response at all and the Mega has to be restarted. The problem seems to arise irrespective of the content of the Gcode message.
This is also causing the CN5X program to get stuck
I am using Arduino IDE 1.8.6 on Linux Mint
This is very frustrating - what am I doing wrong?
...R