Hello Everyone,
I would like to share with you the setup I made lately for my CNC3040 and ChiliPeppr, I’ll ask a question at the end I hope your answers will help me take this setup to the next level.
I’m running GRBL 0.9j from an Arduino Pro Mini which has no serial to USB chip, I connected Arduino’s Tx/Rx pins to Rx/Tx GPIO pins of Raspberry PI with a logic level conversion, I configured the PI to automatically start SPJS and of course I’m controlling my CNC3040 from ChiliPeppr … that was my setup until last night.
The new setup … last night, I decided to remove the Raspberry PI and use ESP8266 model to connect Arduino Pro Mini to Wifi, ESP8266 is running esp-link firmware (https://github.com/jeelabs/esp-link ) which bridges serial port to Wifi, the firmware accept network connection on port 23. To allow ChiliPeppr and SPJS to communicate with the Wifi model I installed Virtual Serial Port on my PC from (http://www.hw-group.com/products/hw_vsp/index_en.html), now the setup works like this:
ChiliPeppr communicates with SPJS, the later communicate with the Virtual Serial port. All three are running from my PC.
Virtual Serial port communicates with esp-link running on the ESP8266 through the network.
esp-link communicates with GRBL running on Arduino Pro Mini through serial Tx/Rx pins.
I executed several gcode files (15 – 20 min each) without experiencing any issues and all jobs ran smoothly, please check the video.
The setup is working great so far but I believe there are unnecessary components, theoretically ChiliPeppr can talk directly to esp-link so there is no need for SPJS and Virtual Serial Port, my question is how difficult it is to add this feature to ChiliPeppr? And if I want to develop this feature which part(s)/widget(s) of ChiliPeppr I should start looking at? http://www.youtube.com/watch?v=xiF7-V7ZH0Q
that’s really great… no raspberry pi needed! So, pretty much you have the chilipeppr machine and a completely wireless machine it is talking to? that’s great!
well, @jlauer can give you the real info, but I believe SPJS is handling all the complex buffering that needs to be done. Running without that would mean that the buffering would have to be done on the CP side, so I’m not sure if that is going to be possible.
That is a pretty amazing setup. I bought 3 ESP’s the other day so I could do similar experimentation. You beat me to it! I think you could indeed try to have the browser talk direct to the ESP and skip over the virtual serial port. The problem you’ll run into is trying to fill the measly Grbl buffer of 128 characters effectively. I tried this approach early on and you’ll get a lot of stuttering. However, it could be workable enough that you’re ok with it. Some gcode files will be nicer than others if the gcode file has lots of long moves like the one you’re showing in your video. If you do a gcode file from vcarve you’ll hate life. So, I say you should go for it. I think what you should do is fork the Serial Port JSON Server widget and possibly extend it or make an alternate workspace that has an ESP widget in place of the SPJS widget in CP.
Oh, also, the other thing SPJS does is reflect messages back to other end-points so you can have a tablet showing your DRO while your laptop sends the file. You’ll lose out on that re-broadcasting capability. Also, SPJS reprioritizes pause/feed hold commands to the front of the line. You’ll have to implement all that logic yourself in Javascript. Just look at the SPJS source code in the buffer_grbl.go to see what it does.
Thanks, I’m thrilled by your words
I believe a better approach is to make SPJS talk directly to ESP to get rid of the Virtual Serial port, I’ll look into this later, I still need to do some hardware changes and further testing.
One other idea could be to go direct to ESP from ChiliPeppr and add some buffering inside ESP. How much memory is available inside ESP to buffer up commands? Then for the re-broadcast aspect we could simply use WebRTC to a larger degree as that allows peer-to-peer data connectivity and thus a tablet showing DRO could just connect to the main browser to get data. This is sort of needed anyway since there’s no way to retrieve the whole Gcode file by a secondary browser today.
According to ESP datasheet, there is around 50 KB of internal RAM available for the user application, this is when ESP is operating in Station mode, I believe you can easily allocate 10% of that for buffering.
but for the first shot, awesome!