Closed Aviian314 closed 6 years ago
chamnit
commented
6 years ago Ran your gcode program on an Arduino with the current Grbl v1.1 build. No errors, except the M6 tool change line, which is expected. I used the stream.py script to run the job.
Please share your Grbl $$ settings, $I build info output, and list any changes you've made to the config.h or other source files.
swarfer
commented
6 years ago UGS has the facility to filter out lines, and to change the precision of numbers sent to GRBL. make sure both of those things are turned off! (except maybe for the M6 command since GRBL will not understand it anyway)
In Fusion I have noticed that the lead-in and lead-out radii are often very small and it is those tiny arcs that cause errors. These arcs are often vertically oriented which may contribute in some way to the problem. IIRC the default is bitdiam/10. you should increase those radii AFTER you have told UGS to behave itself.
You can also try my post processor https://github.com/swarfer/GRBL-Post-Processor which seeks to minimize/remove these arc errors and will also not emit tool changes and will not use G28. (but the UGS settings must also be correct)
Aviian314
commented
6 years ago @chamnit Could this be the result of some hardware issue such as static electricity? bad ground? Could the USB cord laying close to my laptops power supply brick induce interference? It's just really strange that it only occurs at the beginning on the first pass and nowhere else. If it was a consistent problem, any of my previous questions would make more sense to me. Is there a way to sniff the Arduino's receive buffer to see what is actually received by the Arduino?
I have a spare Arduino that I flashed to GRBL then ran the code on it over and over and I couldn't get it to error.
[VER:1.1f.20170417:SKIPPY] [OPT:VMP,15,128]
$0=10 $1=255 $2=0 $3=3 $4=0 $5=0 $6=0 $10=115 $11=0.020 $12=0.002 $13=0 $20=0 $21=0 $22=1 $23=3 $24=25.000 $25=750.000 $26=250 $27=1.000 $30=1 $31=0 $32=0 $100=40.000 $101=40.000 $102=188.976 $110=8000.000 $111=8000.000 $112=500.000 $120=500.000 $121=500.000 $122=50.000 $130=540.000 $131=540.000 $132=100.000
@swarfer If UGS was modifying the files or Fusion was putting out some bad lead in/outs, would that cause the intermittent errors I've experienced? The code works perfect in some cases but not in others. Homing limit switches combined with G28 is extremely useful. I highly suggest using that.
swarfer
commented
6 years ago Re-reading what you said I am now thinking you have noise in the wires rather than arc errors. It also may be the USB cable is causing transmit errors. Cheap USB cables are not good.
Fusion does not put out -bad- leadins/outs, they are just very small and so the need for extra precision in the co-ordinates arises so that the start and end radii are within limits. If UGS were to limit the precision then the tiny arcs get broken, but this would be consistent so is not your problem.
I agree that homing switches are useful, but they do have be set up correctly, and the wiring has to be RIGHT. Home switch noise is the biggest cause of questions on this forum (-:
User cspwcspw posted the other day about the disparity between the sensitivity of the microcontroller pins and the real pulse speed needed for reliable switch sensing. The microcontroller is much too fast in this case and the slightest noise can cause a limit trigger. He used Smidt triggers . There are also good solutions in the Wiki that use optocouplers.
chamnit
commented
6 years ago Usually USB errors manifest as timeout and disconnects, rather than corrupting data, but it's not outside the realm of possibility. I would systematically isolate components of your CNC to figure out where the problem is coming from. Usually power spikes from your spindle and bad grounds are the source of these types of issues.
chamnit
commented
6 years ago You should be able to sniff the receive buffer by attaching another Arduino to the RX and ground pins and opening up a serial monitor. Another way to do it is to enable the echo option in config.h, but this will often break GUIs because they aren't expecting the extra messages coming back.
langwadt
commented
6 years ago would be easy to add up all the received bytes in the rx interrupt and do the same in the sender, then all that is missing is way to read back the value so you can compare
Aviian314
commented
6 years ago The difficulty in isolating parts is the intermittent nature of the event. I guess I'll have to test it a lot as is to determine some basic statistics on how often it errors (a lot more than it should). Then slowly remove things from the equation until the errors hopefully stop happening. Can someone suggest a different GCode sender to aid in this? It doesn't have to be feature rich, just something that works.
The config.h file has been mentioned a couple of times. I haven't personally compiled anything. Inventables' Easel program uploading the latest GRBL to my machine as part of setup. If isolating components / grounding things better doesn't solve the problem, I'll look further into this option.
The "Arduino" hosting the GRBL code is part of the Inventables X-Controller so I'm not sure how easy it will be to hook up to the Atmega's Serial lines due to it being on a custom circuit board. I'll have to crack it open and look. I hope they left terminals for those on the board.
chamnit
commented
6 years ago @jhndrx : Before you go and do anything to your X-controller try non-obtrusive tests. Also try calling Inventables customer support. They are pretty good at making sure you are taken care of, especially when you are using one of their products.
Also, check to make sure that you are using a version of UGS that supports Grbl v1.1. UGS 1.09 seems like an old version. You probably should be using UGS Platform. Although I've heard some versions of UGS Classic do support v1.1
Aviian314
commented
6 years ago @chamnit Obtrusive tests are most definitely going to be last resort. The downloads page of UGS sports 1.0.9 as the latest. Then at the bottom they say UGS Platform is part of Nightly builds. I thought that it meant that UGS platform wasn't fully ready/stable yet. I now see where they state the stable build the nightly build is based on. I'll make this the first thing I change.
109JB
commented
6 years ago I am not familiar with the XController, but the description you have given is very similar to the errors I encountered when using an arduino Nano for Grbl. The Nano uses a CH340G USB to serial chip and that is what I determined the problem to be on the Nano. As I said, I am not familiar with the xcontroller, or what USB to serial chip they use but it could be related. The types of errors I discovered could be duplicated on a Arduino UNO with the atmega 8U2 USB chip, but far less frequently, and not at 115200 baud. The WIKI has a brief description to the problems encountered under the heading "USB to Serial Transmission Errors". The wiki description has a link to the long issues thread covering the issue. The issue can't be corrected on a ch340 equipped Arduino, but its effects can be lessened. Below are some things you can try:
1 Set your GUI to perform status updates less frequently. I use 0.1 or 0.2 second updates and sometimes turn them off alltogether.
Again, I don't know if this is your problem, but thought I'd throw it out there.
Aviian314
commented
6 years ago I tried sending the same script as originally posted and I couldn't manage to get it to error again (no mods to software or hardware). UGS 1.0.9 appears to be the last officially released version. 2.0.0 is still in development. For software that is highly recommended by a lot of people, the documentation is rather lacking. 1.0.9 appears to use character counting since it sends several commands so errors are just skipped over. Version 2.0.0 appears to send one command at a time and waits for a response allowing it to freeze when an error occurs. This works around the error issue. I will consider this closed since I cant seem to replicate the issue easily. However, of course this does not solve the underlying reason why.
With some digging, I've determined the X-Controller uses a FT232RL for USB to serial communication. I use the same chip for my homemade "Arduinos" and with one loaded up with GRBL 1.1, I continued trying to reproduce the errors to no avail. I guess there are just days it doesn't want to cooperate.
vanepico
commented
3 years ago I've just been chasing errors myself and think I have found the cause, and in the spirit of helping the community out I thought I would post in this thread as it shows up prominently on google.
I had a stepper motor which used 9600 steps/mm, and I was attempting to run this at 500mm/min. This equates to trying to run the motor at 80kHz. Whenever I attempted to move it at 500mm/min it would appear to reset the GRBL board. The maximum speed I was able to do on a single axis without the board restarting was 250mm/min or 40kHz. For now I have set it to maximum of 125mm/min and I am hoping I will not have any problems when multiple axis are run simultaneously. In fact I believed my problem was being caused by lack of motor torque, so I put a 3:1 pulley drive on which is why I had to have ~9000steps/mm, otherwise it was ~3000. Hope this helps someone.
In case you were interested, my setup is a unimat 3 micro lathe with 1mm leadscrews.
CAD/CAM: Fusion360 Sender: UGS v1.09 From Laptop CNC: XCarve Controller: latest XController using Grbl 1.1 Router and vacuum are on a 20 Amp circuit. Laptop, controller, and other non-motor items are on a separate 15 Amp circuit so the motors of the router and vacuum shouldn't be an influence.
Error Code Reference:
I've encountered numerous errors that ruin my carves and I can't pinpoint what's causing it. I can run a .nc file and it will error out on some commands, stop the script and resend and it will run error free. It's to the point that I can't do a single carve without it messing up on something. I feel like the messages are getting garbled at some point either during transmission or inside the grbl controller. I say this because "G1" commands aren't listed under error 33 but they are triggering that. Also the Error 35 I have is on a command that does work in other instances and it clearly has an "IJK" component.
I've copied the relevant data from UGS into excel files (from start of carve until when I stopped). You can see the exact same set of commands will work one time and error another. I have noticed an odd pattern about these errors. They only occur near the start of the carve. This typically ruins the first loop around a multiple depth contour and then the rest of the loops are perfect.
3) 2F Downcut.txt (my .nc file) error.xlsx worked fine.xlsx
You can see in the image below, that at the bottom right, once it reached the beginning of the arc, it didn't perform it and instead shot straight left. This was again repeated at the bottom-left where it went straight up.
During the same carve, I had another set of errors that when ran another time it ran perfectly fine.
3) 2F Downcut.txt (my .nc file) error2.xlsx worked fine_2.xlsx
The following picture shows a similar event to the first one. It didn't complete the small arc around the corner of the piece therefore cutting short into the material on the first pass. The rest of the passes went as they should have.
The last picture from a different carve (no data) is where I've drilled holes and the first time I ran the script in the stock it worked perfect, I then ran the script again on my waste board (mounting holes for double sided piece), the first pass looped backwards and then the rest of the cuts went fine. (Again, errors on the first pass and no other).