Ask Grbl CNC questions here.

Yes it has been tested with direct IO serial. See Raspberry Pi Shied by Protoneer. I strongly suggest you check your streaming source code and follow the advice I’ve already given you.

 

The Raspberry Pi is just one example. I have personally used a spare Arduino to convert the Wii joystick input to a stream of serial commands directly through IO. If you search the web, there are numerous other examples like people connecting an ESP chip to it to run Grbl via WiFi or Bluetooth etc etc etc.

The one piece of advice I mentioned following is to eliminate all other variables, like your streaming code and building on something you know that works. It’s far more likely you have been doing something wrong from some assumption you have made about Grbl or your electronics. For example, like not following the streaming protocols outlined in the wiki exactly.

 

I'm perfectly willing to accept there is a problem, if there is one, but it's not clear that there is one at all. First, given the fact that I've personally got it working with two Arduino Uno's with a joystick, along with many other people having success as well, it leads me to believe that it's not Grbl. Second, I am the sole developer of Grbl. If anyone, I know more about the source code and the issues related to it more than anyone else. Third, every time I make a suggestion, it's not been the most pleasant. I am unable to read your mind and know exactly what you have done before you tell me. At this point, it's clear that you've been working hard at this. Again, please try looking at your source code on your host controller. It's much more likely that is where problem is coming from.

 

The USB serial device in the Arduino is directly connected to the external RX and TX pins. It's exactly like what you are trying to do with your additional controller. If it's working through USB-serial, then Grbl is working just fine. Once again, there is something wrong with your setup, methodology, or streaming from your controller. Not sure why you don't think there isn't a problem on your end and insist that it is Grbl, when there are a ton of evidence that it works fine in a wealth of other cases, such as my own experience.

If you really want to look at the source code, you can. There's nothing stopping you doing so. It's all there, well-commented and well-organized. There's really not that much code. It won't take you long to find what you are looking for. Literally like a few minutes.

Once again, there is nothing in the Grbl code that will cause corrupt messages to be returned, except in the things I asked for you to check for in the very beginning. Outside of that, perhaps its what you're doing to the Grbl code when you changed it to run at 20MHz, or how and what you are compiling it with, or setting the AVR fuses. If you are using custom hardware, you have to ensure that all these other variables are in line with the assumptions Grbl was built on, as in any software project. If that is the case, then it sounds like you didn't take these into account.

 

I’m sorry that you’re giving up. But in my defense, I have also repeatedly given you my advice. Each time, it’s been clearly ignored.

Again, there is overwhelming evidence against you case that there is something wrong with Grbl. This includes personal experience and the experience of many many others, which also includes yourself. You stated that with an USB serial chip (which on an Arduino Uno is actually another AVR to behave like an FTDI), Grbl works, but your approach doesn’t work. This is a clear indication that you are doing something wrong. Speed of communication or or direct wiring changes nothing with how a serial port fundamentally works.

Also you keep asking about where to look in the code. Once again, if you had took the time to actually look, there are clear labels to the file names that denote what they do, like serial.c and report.c. If you insist that the problems are there, feel free to take a look, but I still strongly believe you won’t find what you are looking for there.

It’s indeed sad to see you go to these depths. I will say that I do openly accept help with Grbl, but the pull request code that I often receive requires complete rewrites due to important things the author didn’t account for, rejected due to being outside the scope of the project’s intent, or the code isn’t efficient/stable enough, which is a very strict requirement due to the limited space on the 328p AVR. This usually leads me to completely rewrite and insert the proper code into Grbl myself.

I’m sorry that you are having so many troubles diagnosing your comm issue on your custom setup. However, please refrain from scapegoating Grbl and myself with your issues. Grbl has been quite stable for several years and I have devoted years of my free time to this work and to helping others to get their Grbl issues sorted.

 

Still ongoing and pushing hard to get it done. The port to ARM is done, and hardware abstraction layer is also done. Close to completing the new settings method, which will have a configuration document that you stream to Grbl and allow you to configure the entire thing without having to re-compile anything.

However, most of my time has been involved with working on the 3rd order planner and, this week, I ran into a road block. My Python simulation shows that it works perfectly for 99% of cases. That final 1% is a bit of a bear to solve analytically to ensure optimal motion. I've been looking for a fast, approximate solution for it, but haven't found one yet. So at this point, I'm installing a special set of motion commands that can have Grbl trace any motion profile with a 3rd order polynomial. This is common on industrial machines like assembly line machinery and such. It allows you to test and hone in a custom motion profile for a specific task or application. In my case, it'll buy me a bit more time to test and proof out the final bit of the 3rd-order planner that I've been working on. On the plus side, I can see this being a great tool for others to use too. Particularly for OEMs and research institutions. Anyway, there still much to do, but I'm hoping to get it out by the fall sometime. Before our family gets one larger around Thanksgiving and my time that much less free.

 

Yes. Make sure your are setting your motor drivers to the below the rated current for your motors. They tend to get hot when you put too many amps through the coils.