Hi, I have a strange issue happen while milling a pcb. I’ve restarted the job 3 or 4 times with similar results. The job start correctly but after some time seems to head towards 0 on either x or y axis. I’ve attached a picture to try and show what is happening (the line ends because I shut down the machine when I noticed this happening).
I have tried editing the gcode to omit the first part of the job and start maybe halfway, after some time the same result.
The sdcard checks out fine, I have transferred the file back to the PC and compared the gcode file to the original and it is identical. Opening the gcode file as a simulation in LinuxCNC shows that the file should render correctly.
Has anyone come across anything similar happening? These are the first jobs I have run since upgrading to the dual endstops with the latest marlin firmware linked. I had previously run many jobs with no issues at all, even after 8-10hour long jobs.
I had that trouble too. (Didn’t really fix it though). I supposed that it coumld be radio interférences (in part from my chinese spindle + PSU), so I’d suggest first make sure the wires don’t overlap (especially long display seem problematic from what other posts with a similar problem I’ve seen)…
Thanks for the advice, I will doucle check the connections. I do run one of the 500w chinese spindles, but haven’t had any issue with it. I run all the stepper motors through shielded cable. I have probably run off 30 or 40 jobs with it on mdf, various ply, slate, aluminium and some glass, not missed a beat. Jobs varying from 10-15 minutes to several hours. Not had this issue before.
I did run one off these pcb boards a week or so ago which came out fine, although I created that one from Eagle through pcb-gcode to get the file. This latest one with the issue I created from flatcam, perhaps there’s a link? I will try to the run the previous file again and see how it goes.
Having just got the dual endstops installed I wanted to run off a couple of double sided pcb boards which are now possible.
I’ll run a couple of old files I know worked fine again and see if they show the same problem.
I might have read (or imagined) that someone had a problem with motor control and it went away when they flipped the end of an endstop wire. (I know they don’t have polarity, but seems it may have been generating a spurious stop trigger.) Since all was good before the dual endstops…?
I had this exact same issue when i was using sdcards bigger than 2gb . I once tried to use one out of my 3d printer which has 8gb. My marlin recognised it, but some time into the job just glitched out.
I have double checked all the connections, they are fine. Polarity of the endstop wiring shouldn’t matter, but checked that and all switches are wired the same.
The smallest card I have is a 4GB, I reformatted this with just a 2GB partition and ran the job on the top side of the pcb, this worked fine. I then tried the reverse side with the gcode on this new card and this exhibited the same symptoms as before. I will try and dig out an actual 2GB or smaller card to check this.
You say you have checked and verified everything, The only thing that is unchanged is your gcode, zip it and upload it here. There are a few things that can cause this.
I wouldn’t say everything, but some of the suggestions from here. I hadn’t seen this issue during the previous couple of months since I finally completed the build.
This is the first time I have used flatcam to generate the gcode, so perhaps there is a link, I’ve attached the zip of top side of the pcb job. The only thing I have changed was the speed at the start of the file.
The gcode is not how I would format it and 99% sure it is your problem. No spaces, too many decimal places, extremly high resolution per step, no speeds on each line.
Start with ESTLCam look at the gcode it produces, try to match that. 0.0001mm resolution is too high and you are probably trying to process way too much info. You also can not just change one speed it is embedded all over the file, and should preferably be on every single line.
I’ll see if I can come up with a script to reformat the output of flatcam. I much prefered the options this gives over the pcb-gcode plugin for eagle. I had noticed that linuxcnc complains about the format and needs % adding at the beginning and end of the file in order to open it correctly, but once open it looks fine.
I use Estlcam for most jobs, as it’s really easy to use and has good options for tools/speeds. It doesn’t cover most of the options that Flatcam gives for pcb milling, being able to use a fine engraving bit to cut out the tracks but also multiple passes around the tracks/pads to enlarge the isolation gap. Being able to load and overlay multiple files with a mirror option for double sided pcb really helps getting everything lined up.
I’ve got a basic script running to remove the last digit of precision in the Flatcam gcode files and add a space between the coordinates. I’ll try and get time to update it to add the speed/rate to each movement line, hopefully that might help compatibility.
As the output of Flatcam doesn’t seem to control speeds of the various movements well, I’ve written a program which takes command line parameters to add speed to all G00 movement, G01 movements which seems to correspond to actual milling movements and G00 and G01 Z commands. As there were no space characters between the X and Y coordinates I have added those in too. I’ve attached the updated gcode, it looks similar to Estlcam output now.
I will give it a try with some of the pcb gcode I have been having problems with and see if it makes a difference.
Had a similar issue with my 3D printer. Would print part of the job then try to “jump off” the y end stop then return to printing and do this 2 -3 times during a print. I too, tried shielding the cables as but the problem remained.
I changed SD cards to a new larger 8GB (was 2GB) and has been fine since. The 2GB card had been used for a while but showed no errors. I reformatted it, cleaned it with cleaning alcohol, etc, all to no avail. Why a new card fixed it I don’t know.
Thanks for all the advice, I’ve ordered a couple of new sdcards, so hopefully along with all the other suggestions I’ll run off some tests.
While looking in to the issues with gcode formatting, I’ve written a small command line (linux) utility to add speed (Fxxx) to each line, along with making sure the is a <space> between all options, probably not a good idea to use it on files with tool changes that have different speeds for each tool. Since adding the dual endstops, I though it might be useful to be able to add an X/Y offset to all the coordinates within the file, so I’ve included this option too (might have undesired effects?). It’s only ~13k so here’s a link if anyone might find it useful, drop me a msg.
After swapping out the arduino, ramps board, display for others I have laying around, the issue still remained. Reflashed the firmware and tried various other sdcards, the issue was still there. I also noticed that while running a job there seemed to be ‘clicks’ from the display unit, just like the button was being pressed.
Anyway, it turns out the issue is only present when the spindle is running at or near max speed, the higher the rpm, the more pronounced the issue. Presumably some form of EMI. Looks like I’ll have to upgrade the spindle.
