Dose anyone has the problem to load GRBL code into new type Arduino UNO R3 board?
I had old Arduino UNO R3 with 328P DIP type board running with CNC GRBL code OK. Then I had new Arduion UNO R3 with 328P-AU SMT type board, which is also change to new USB chip CH340. To upload GRBL code to this new board is OK. However, when I use GRBL SW to run CNC program, The OLD UNO borad ( With 328P DIP) is OK, but the new UNO board (With 328P-AU) has problems.
One board can't running, Another board can run, but it will stop (Due to UNO board reset)..... So the CNC machine stopped...... Dose any one has any idea? What cause this problem?
I try to load other sketchs ( Like : Blinking, Running single motor, servo motor.........etc.) The new UNO R3 boards works fine. Just it will failed with GRBL code.....
GRBL 1.1 F and 1.1H on both official boards and clones here no problems at all.
There have been a few recent topics with people installing GRBL recently.
Maybe do a forum search and I am pretty sure you will find the answer you need.
Usually it come down to moving the folder that is inside the unzipped folder out into libraries.
Getting rid of the shell folder seems to work quite well in most cases.
I tried both 1.1 and 0.91.
The Old UNO board (DIP) works fine for both. But the New UNO board (SMT) still fails with the same symptom. I checked the datasheet. SMT type has 4 more pins (SMT 32 vs. DIP 28) the additional pins are VCC, GND, ADC6 and ADC 7. So I supposed they should be the same since they are in the same datasheet.
Let me try to keep searching for the solutions. Otherwise those new boards are useless…
Her I attached the pictures for both boards for your reference.
My post was about the drive board, ot the controller. The first picture shows a genuine UNO and second looks like a clone.
I've no comments to them other than use the one working.
Yes, and I think both boards are clone for I boutght them from the internet. As I know, most boards are made in China.
Few years ago, most of the UNO boards sale in the internet market were the same as my first picture ( controller is 328P DIP type). I bought few of them and also many MEGA328P DIP chips, so I can make circuit boards+328P chips for my applications.
Recently, I want to make a CNC by using Arduino UNO + CNC shield. It need the complete UNO boards, so I need buy more UNO boards. Then I found the majority of UNO boards in the market now were changed to use 328P SMT type with CH340 USB controller ( The DIP type is becoming more expensive and less in the market) . I think SMT type is OK ( since I will always use the UNO board with CNC shield.)
There must be something wrong with the new boards (May be CH340? or others). I will do more experiments to dig out the root cause if 328P controller is not the issue.
The experiment can be very simple, no need the CNC shield, Just connecting the UNO board with PC, upload the GRBL code , use GRBL SW to run it. ( I use LaserGRBL) and you will see if the UNO board runs well or not.
Yesterday I used another UNO board to monitor the TX/RX ports commands on another UNO board with (GRBL code). The TX/RX commands in between shows normal response when UNO board runs well. Then it stopped running (TX/RX commands also stopped) and LaserGRBL SW shows the board unexpected Reset.
I plan to try bypassing the CH340. ( By using the old UNO boards without the DIP 329P on it, so it work as the USB controller and connecting this emply old UNO board to the new UNO boards through TX/RX and reset pins.) I had tried this with with DIP type, and it works well without problem.
I ask because there are some "altered" versions out there meant for 32 bit ESP grbl.
It could be important.
Running those versions may have unexpected results.
For the UNO you are better off with the official GRBL and the official LaserGRBL
Yes, I lived in Taiwan. Using Arduino devices for few years and just start CNC related.
Continue debugging my issues.
The bypassing CH340 test failed (No 5 show in attaches), due to loading effect when I connect 2 Tx/Rx wire together. I need some buffer amp. to isolate. Plan to do it in this weekend.
Then I go back to monitor the Tx/Rx port signal by oscilloscope. (No.6 in attached) To see what’s happen to the communication signals between PC and Arduino. Oscilloscope has high input impedance so it can avoid the loading effect.
After I did this…… the CNC SW runs ok without issues and can complete the project without shutdown…… it’s not in my planning but seems no issues..
I did it twice and it worked successfully twice. So I disconnect the probes of scope to see if problem back again!
After remove the probes, it did fail again……..
This shows the communication between USB and 328p may be affected by noise/spurious/spikes/glitch…..etc.
I am thinking : Probes has small parasitic capacitance, when I connect probes to Tx/Rx ports, these small capacitance (pf) help to reduce those interference, so it works. Probes are similar to decoupling capacitor.
I didn’t have much time last night to continue. So will leave follow up work continue during weekend.If my assumption is correct, the solution will be just a small decoupling capacitor connect to Tx and Rx port (may be just Rx port is enough)
As for the root cause, will make the buffet amp. (No. 7 in attached)
To monitor both Tx/Rx signal by another 2 Arduino boards. Will also leave it in this weekend.
Will keep you updated.
Also attache Arduino UNO schematics to show the loading of Tx/Rx ports.
The capantance of the oscillscope probe is ~ 400-500 pf. I tried 400 pf and 1000pf (1nf) both are OK. So I just add 1nf capacitors to both Tx and Rx pins.
By adding the 1nf, 4 out of 6 new boards (SMD 328P-AU) work fine ( Can continue for >30mins) without stopping (Test 6-1) So it shows the decoupling capacitor can help.
I made the buffer amplifier as planned. But need change to use PNP type transistor for the normal state of these TX/Rx pins are at high (5V) . After add this amplifier (Test 4-1), I can mornitor the commands in between PC and UNO boards. The commands runs very fast, I can read last few commands after, but can't see what's the problem when the board REST and stopped. The commands just stopped...... . So I still didn't find the root cause why it was stopped.
The next I did the bypassing CH340 of new UNO boards ( Test 5-1). By doning this, 4 out of 6 boards runs well. The 2 failed in Test 4-1 were still failed in this test.
So it seems the failure is coming from the 328 TX/RX I/O port ? That is SMD tpye 328P-AU on new UNO boards?
Not sure what's happen to the 2 failed 328P-AU, it only faliled when I use them with GRBL CNC. applications. Uploading other sketches works fine.
GRBL required lots of communication through Tx/Rx port, which is different from other sketches. This may explained.
I will try some other sketches to use more Tx/Rx communication after. But will stopped here, and see if anyone has any idea or input.
It looks these boards are not stable, and I believe there are many similar UNO boards in the market. May be what I got are the boards with recycle 328P-AU chips. Who knows.....
I would like to thank you Ballscrewbob and Railroader, your input and comment make me to think more and continue to to some test. Although I can't find the root cause and resolve issues 100%. But I can use some of these boards temporary. I already order few more UNO boards with DIP socket and DIP 328P on it.
In case issues happened again on 328P controller, I can just replace them with the new one.
Still unsure why two Arduinos are needed unless the link above is relative to your project ?
Others have use the TX/RX pins with success to implement Bluetooth and pendants etc.
It could simply be you have two bad boards that were damaged somewhere along the process.
Yes GRBL is very serial intensive.
That is part and parcel of the whole GRBL scenario.
You can get "offline" shield additions to supplement that.
Those approaches tend to use an SD card or wi-fi etc.
Heads up Wifi does tend to be slower due to the amount of handshaking used.
Below my settings in LaserGrbl that have worked for all varieties of Arduino UNO
Yes, thanks for the suggestions. I can use alternative ways to do this. it's just because I don't have Bluetooth on hand, and didn't use it before. I have several UNO boards on hand, and knowing the HW interface in between. There is no harm if I connect in the way I did, please see the brief curcuit drawing attached. Use 2 UNO boards to monitor Tx/Rx commands is simpler to me.
The 2 bad Tx/Rx boards were failed from the beginning when I started to use it with GRBL code. Only connect its USB to PC without any other connections. Until I did these tests duing the weekend. So I have confience the failure is not related to thses tests.
My next plan will check the commands detail in between, see which side stop first. It won't help the solution, but just wondering to know what's happened. Also by setting LaserGRBL setting/buffered ==> setting/RepeatOnError to see the commandes result. (Thanks for reminding the setting in LaserGRBL)
