Closed Tom-Nelson closed 6 years ago
I just did a simplistic test to see if it is easy to replicate, no luck:
One major risk/problem with current implementation is that I don't wait for an Ok response before sending the next line. With some commands this might be a problem, e.g. anything that reads/writes from eeprom.
Hi Gerrit, I must admit I'm a bit puzzled by this. I ran a test using this code
G90G1X39F500 G90G1X40F500
Now when I run it, the monitor shows [image: Inline image 1] Which looks absolutely fine, but Here's the work co-ords before [image: Inline image 2] and after I run it [image: Inline image 3] and I get this message in the Status window (note - tried in multiple times hence multiple error message - every time it stops at X=25. Which is why I though there was some array or counter somewhere set to 25 lines [image: Inline image 4]
Unfortunately the images did not arrive at Github :-(
Here's the image again, hope it come through this time
I think we are back to the core problem with my terrible implementation of macro stream to Grbl, reference Issue #61. The commands after 25th would have had to wait for room in grbl's buffer.
Thanks for the feedback. I suspect macros are seldom more than a few lines long so I can understand that this is a pretty low priority item. I'll close this issue since you probably already have macro handling on a to-do list.
Hi Gerrit, Not so much an issue as a question. It looks to me like the maximum length of a macro is 25 lines. This is probably fine 99% of the time, but I have a probing routine that runs just over (Murphy's law!). Longer macros can be created and saved, the full content appears in the user.config file, but when they execute they just stop at line 25.
I'm fairly comfortable digging around in vb.net so if you could point me in the general direction to tweak this, it would be much appreciated