Z movement and Nunchuk problems
Re: Z movement and Nunchuk problems
mstrens thanks. I done all but nunchuk is still dead. Now what? Try to buy a new one (nunchuk)?
Re: Z movement and Nunchuk problems
msterns Great work, got mine working!
But not with the suggestions, did some debugging myself and got always value 15 for bufferAvailable[0]
So added the equal sign, not knowing if that is ok BUT now it works even touchscreen move (did not do anything before).
com.cpp line 393: if (bufferAvailable[0] >= 15) { // tests shows that GRBL gives errors when we fill to much the block buffer
But not with the suggestions, did some debugging myself and got always value 15 for bufferAvailable[0]
So added the equal sign, not knowing if that is ok BUT now it works even touchscreen move (did not do anything before).
com.cpp line 393: if (bufferAvailable[0] >= 15) { // tests shows that GRBL gives errors when we fill to much the block buffer
Re: Z movement and Nunchuk problems
which version of GRBL and which processor are you using?
If you are using an original version of GRBL on an arduino with a avr328P, then the size of the planner buffer is limited to 15 or 16.
Here an extract of the code of planner.h
// The number of linear motions that can be in the plan at any give time
#ifndef BLOCK_BUFFER_SIZE
#ifdef AVRTARGET
#ifdef USE_LINE_NUMBERS
#define BLOCK_BUFFER_SIZE 15
#else
#define BLOCK_BUFFER_SIZE 16
#endif
#else
#define BLOCK_BUFFER_SIZE 36
#endif
#endif
Did you activated the line #define BLOCK_BUFFER_SIZE in file config.h. Normally it is not.
Here an extract from the normal config.
// The number of linear motions in the planner buffer to be planned at any give time. The vast
// majority of RAM that Grbl uses is based on this buffer size. Only increase if there is extra
// available RAM, like when re-compiling for a Mega2560. Or decrease if the Arduino begins to
// crash due to the lack of available RAM or if the CPU is having trouble keeping up with planning
// new incoming motions as they are executed.
// #define BLOCK_BUFFER_SIZE 16 // Uncomment to override default in planner.h.
So, normally the max buffer size should be "36" for a STM32 GRBL.
The test with "if (bufferAvailable[0] >= 15) {" checks the remaining free space in the planner buffer.
When GRBL is "idle", the value should be 36.
If it remmains fixed on 15, there should be an issue.
Note, in order to let GRBL send the remaining free space in the buffer, a parameter must be activated in GRBL.
Normally this parameter is automatically sent by the ESP32 at power on just for security.
It is parameter $10 and it should be set on "3"
Can you send the command $$ to GRBL in order to get the config and check that this parameter is really 3?
If you are using an original version of GRBL on an arduino with a avr328P, then the size of the planner buffer is limited to 15 or 16.
Here an extract of the code of planner.h
// The number of linear motions that can be in the plan at any give time
#ifndef BLOCK_BUFFER_SIZE
#ifdef AVRTARGET
#ifdef USE_LINE_NUMBERS
#define BLOCK_BUFFER_SIZE 15
#else
#define BLOCK_BUFFER_SIZE 16
#endif
#else
#define BLOCK_BUFFER_SIZE 36
#endif
#endif
Did you activated the line #define BLOCK_BUFFER_SIZE in file config.h. Normally it is not.
Here an extract from the normal config.
// The number of linear motions in the planner buffer to be planned at any give time. The vast
// majority of RAM that Grbl uses is based on this buffer size. Only increase if there is extra
// available RAM, like when re-compiling for a Mega2560. Or decrease if the Arduino begins to
// crash due to the lack of available RAM or if the CPU is having trouble keeping up with planning
// new incoming motions as they are executed.
// #define BLOCK_BUFFER_SIZE 16 // Uncomment to override default in planner.h.
So, normally the max buffer size should be "36" for a STM32 GRBL.
The test with "if (bufferAvailable[0] >= 15) {" checks the remaining free space in the planner buffer.
When GRBL is "idle", the value should be 36.
If it remmains fixed on 15, there should be an issue.
Note, in order to let GRBL send the remaining free space in the buffer, a parameter must be activated in GRBL.
Normally this parameter is automatically sent by the ESP32 at power on just for security.
It is parameter $10 and it should be set on "3"
Can you send the command $$ to GRBL in order to get the config and check that this parameter is really 3?
Re: Z movement and Nunchuk problems
I am using CNC Shield not GRBL32 version so above post is not for me I guess? Is there a way to check nunchuk controler? I had checked inside controler when connected and there is also 3.3V. I am electronic "idiot" unfortuantely 
Re: Z movement and Nunchuk problems
msterns the setup in use:
CNC nano shield V4 (with 3x TMC2130 configured by an extra "slave ATmega328 mini" = very silent running)
MAIN Processor ATmega328p NANO V3 5V@16Mhz
GRBL 1.1f standard configuration: grbl-1.1f.20170801
The buffer size was not changed = untouched => 15 = maximum for 328p
When receiving commands it lowers, not fixed 15 = funtioning correctly
Response of $$ for $10=3
Grzegorz what CNC shield do you use, what is the processor in control?
If it is a 328p, my change might work for you aswell.
CNC nano shield V4 (with 3x TMC2130 configured by an extra "slave ATmega328 mini" = very silent running)
MAIN Processor ATmega328p NANO V3 5V@16Mhz
GRBL 1.1f standard configuration: grbl-1.1f.20170801
The buffer size was not changed = untouched => 15 = maximum for 328p
When receiving commands it lowers, not fixed 15 = funtioning correctly
Response of $$ for $10=3
Grzegorz what CNC shield do you use, what is the processor in control?
If it is a 328p, my change might work for you aswell.
Re: Z movement and Nunchuk problems
I am using CNC Shield not GRBL32
Wysłane z mojego SM-A750FN przy użyciu Tapatalka
Wysłane z mojego SM-A750FN przy użyciu Tapatalka
Re: Z movement and Nunchuk problems
Mega, clone.
Wysłane z mojego SM-A750FN przy użyciu Tapatalka
Wysłane z mojego SM-A750FN przy użyciu Tapatalka
Re: Z movement and Nunchuk problems
When GRBL runs on a AVR328P you can try reducing the value (e.g. 10 instead of 15)
com.cpp line 393: if (bufferAvailable[0] > 10) { // tests shows that GRBL gives errors when we fill to much the block buffer
com.cpp line 393: if (bufferAvailable[0] > 10) { // tests shows that GRBL gives errors when we fill to much the block buffer
Re: Z movement and Nunchuk problems
Hi Gents,
Its me again with same problem. I had changed Arduino Mego for original one, I have new nunchuk and this s...t doesn't work at all.
I am using cnc shield from Romain and original arduino Mega. What I'm doing wrong? Any help please?
Its me again with same problem. I had changed Arduino Mego for original one, I have new nunchuk and this s...t doesn't work at all.
I am using cnc shield from Romain and original arduino Mega. What I'm doing wrong? Any help please?