Closed phil-barrett closed 3 years ago
phil-barrett
commented
3 years ago Setting it to:
#define BLOCK_BUFFER_SIZE 512 // Uncomment to override default in planner.h.
seems to prevent the strange behavior. Until we know more, people should use this setting.
[edit] One of my long test jobs has been running for 5 hours now so I am cautiously optimistic that 512 prevents the problem.
terjeio
commented
3 years ago Does the same happen with the test branch?
Note that the buffer size does not need to be a power of 2 as it has been changed to a circular linked list for speed. Increasing the size will increase processor load significantly for many fast and short moves, this could be a likely reason for instabilities? Or does the problem show up with "normal" gcode that does not fill the buffer to capacity?
It is as expected that "ok" is received early since it is returned when the motion has entered the buffer, not when it is executed by the step generator.
phil-barrett
commented
3 years ago The test branch builds but does not connect via USB or Telnet. ioSender says "waiting for controller on Com22" (or IP address). It does respond to a terminal app so I set $14=78 because I was running on a bare Teensy. If I do a reset and unlock, ioSender exits and then when I restart, it will connect via USB or Telnet.
Tested a 1024 planning buffer - same issue (though error 33 instead of 36). Tested a 750 planning buffer - same issue (error 36s). Tested a 500 planning buffer - no errors
Through the wonder of binary search, I determined that 707 has no errors, 708 does. 708*planning block size is some magic number?
An aside - I do like the new Settings. Will send my thoughts on that in a bit.
phil-barrett
commented
3 years ago Ah, it is not a magic number. Increasing max speed and acceleration on X and Y causes the errors to happen with smaller planning buffer sizes. With X and Y set to 5000 mm/min max rate and 100 mm/Sec^2 acceleration, I have to back planning buffer size off to 500 to get it run without errors.
By the way, here is the test code I am using - Arc heavy. concentric circles as arcs fr5000.zip
terjeio
commented
3 years ago Closing this as it may have been fixed by switching to Teensyduino 1.54. Reopen at the new repo if still unresolved.
I have been chasing a weird ethernet problem with a new Magjack I am using on a new breakout board. I thought it was communication corruption - getting error 36s on GCode comments and such. Also, aggressive buffering was behaving strangely - it would give OKs far ahead of the actual machine operations and then never update but, at the same time, the 3D display was in sync. It took me a while to realize that I had
#define BLOCK_BUFFER_SIZE 1024 // Uncomment to override default in planner.h.in config.h at line 203.When I commented it out, the problems went away. The odd aggressive buffering behavior from the large planning buffer also happens when using USB.
Main branch build, Nov 03 code base. Using T41U5XBB_map.h. Ethernet enabled and nothing else. $i: