The problem is: sometimes, randomly, the CNC cut a corner of the path (for example, the blue path in the picture).
When the issue occurs, the error is limited in a portion of the work and after that, the CNC goes on in the right path and at the end of the work, the CNC is in the right position.
The issue happens sometimes, in a random z-quote and in a random corner of the profile.
What do you suggest to solve the issue?
PS. The machine is new
Is that it in the toolpath display? If it is, how can it be random when it is in your toolpath file? Are you regenerating the toolpath over and over for each object instead of saving the toolpath file and re-running the file? Just trying to understand where is this is being random. Also, what CAM tool are you using to create the toolpath?
I’m uncertain, based on the image of the toolpath, whether it’s the CAM software generating the undesired movement or whether it’s happening because the controller board on the machine is misinterpreting the gcode program.
If it’s the latter, switching out the USB cable for a nice shielded one is a good start. I’ve also had trouble with a similar machine because my spindle power cable ran too close to the USB cable. If that’s the case, I recommend running them farther apart.
If it’s the CAM software, please let us know which software it is and the settings you’re using for the toolpath.
-No, sorry, the image is just a graphical elaboration of the program made by for the discussion of the problem. The blue path is made by me with paint :).
-The program (toolpath) is made with “Easel”, online, and the gcode is saved on the SD card in .nc format. I’ve just added the start and stop of the spindle and a z quote to avoid contacts with the sample.
-Each time I mount a new sample, I re-run the same program. Sometimes the result is perfect (as the program), sometimes a issue occours. the cnc cut a corner in random way. For example in my last 5 samples:
thanks, It’s the latter. The program is saved in the SD card that’s in the control board, then a wire flat wire to the controller (no USB cable). Maybe I can try to insulating it with a ferrite core.
So; If this is being run off the SD card then it’s either:
An issue with the SD card itself: Try swapping for a different one.
Interference reading the SD card: As you suggest, try insulating and checking the routing of the ribbon cable connecting it to the controller. Also make sure the cable is firmly plugged in.
Bugs in the controller itself? What sort is it? Does it have the latest firmware? etc.
I’d try swapping the SD card first. It really looks like something is making the machine randomly skip a section of lines / commands in the.nc file, and then continuing from after the skipped section.
@easytarget , you’re right that’s the “control board” I have.SD mounted on it.
-already tried on swapping. No results.
-also tried on putting a transformator 1:1 on the high voltage plug to cut electrical noise from the grid. No results.
On going:
try to put a condenser on the power source +48V DC line, on the controller.
-try with ferrite core on the flat wire of the control board.
-check for a firmware update. Someone who knows, any suggestions about how to do it?
Can you tell us what your original uSD cars is and what your 2nd swapped in uSD card is?
I don’t know how many times I’ve had guys having problems with rPi’s and tell me they swapped out the uSD only to find out they put another junk uSD card in it. My go-to uSD is:
SAMSUNG 32GB EVO Plus Class 10 Micro SDHC with Adapter 80mb/s
In picture, from the right:
-Adapter and uSD included in the product, 1 GB, No logo.
-uSD I’m using now, 4GB, nologo, is the one I always use for my 3D printer (Longer mk5 pro), that always worked well.
-SD Sandisk, I’ll try next, as improvement.
Please try that Sandisk SD card! Plenty of people here on this forum have suffered with cheap SD cards that do not work well, especially when combined with other budget components.
Another thing you can try is sidestepping the offline controller and sending your code directly via USB… (Assuming you have a laptop or other PC you can get near the machine)
Use UGS (or similar) on the laptop to load, view and send the code. Unplug the offline controller, connect to the main controller via USB and see if the problem persists.
This will help you narrow down if the issue is in the offline controller side, or somewhere in the main control board.
-Tried the Sandisk SD card, the issue occured.
-Unplugged the control board (with the SD cage) and tried with the PC connected by USB, (software Candle). I’ve carved three samples with no issues.
I’ll try to carve more samples… Let’s see if the problem is effectively on the control board .
Noname cards can work and can not work. Some I found worked ok until I put more data on the card.
Some have been found to be faking the reported size and in reality being far less than that.
Also, a speed class 2 isn’t really what you’d want if you’re having possible performance issues.
This happening around corners makes a lot of sense for slow cards being a problem…
I have no direct knowledge of Easel, but a web search shows that Easel does not implement G2/G3 arcs, but rather interpolates arcs with lots of straight G1 commands that will magnify any sd card performance issues a lot.
I’m going to suggest that changing CAM tool to something that supports arcs will improve results no matter what. There are many options. Here are two.
Kiri:Moto is browser-based free, open source CAM that produces arcs.
FreeCAD produces arcs as well. Its Path workbench, while flexible, takes more setup to get started than Kiri:Moto.
Hi to all, I deduce the problem was the SD card. After the substitution with a good quality SD, the issue seems to be solved.
I used a SanDisk Ultra 16GB, class 10, A1, HC I.
It is important to ude good quality SD. As first attempt, I tried using another cheap SD (working well with my 3D printer), and the failure was still present.
)