Ok, I tried again forgetting the touch plate. I homed X & y, unplugged power to the board and manually moved the bit down to the copper board. Then I plugged the power back in and loaded the gcode for my carve. V1CNC shows X0 Y0 Z0, Repetier-Host shows the same. I start my gcode which begins with:
Estlcam generated this gcode but I went on ahead and put F480 in there but it didn’t seem to make a difference.
I tried sending G00 Z2.0000 F480 by itself and z moved to 2.00 but for some reason it ignores it when I run the full gcode. I also tried changing it to G01 Z2.0000 F480 and it worked by itself but not in the full gcode. I really appreciate everyone’s help but this is sure getting frustrating. I think I’m going to hang it up for the night. Maybe a new day will bring fresh insight. Thanks everyone.
I took a look at your two files. The difference is that you use a G92 on the backside file but you do not for your frontside file. This is likely the root of your issue. If you are using the homing sequence you first listed, you don’t want a G92 in the file. A few other things:
Consider lost steps: I don’t think lost steps are playing a role here, but one of your comments made me think it is a possibility. The three most common reasons to lose steps are 1) loose grub screws on the connector on the Z stepper, 2) using a feedrate for Z that is too fast, and 3) mechanical interference like the lead screw not being lubed, or the Z axis/router rubbing. None of the feedrates I see listed here are too fast for a 4-start lead screw, but they might be if you use a 1-start lead screw.
Make sure you are reading the coordinates from Marlin: If you have an SKR Pro, place your display in Marlin mode. Only the coordinates displayed by Marlin are important. You can ignore any other coordinates.
Consider running from the SD card: I don’t think Repetier-Host is playing a role in your troubles, but you can test the situation by running your jobs from an SD card and not use Repetier-Host at all. Repetier-Host can insert some g-code based on settings or based on the start/end code sections the user authors. I would put your homing code in a file and run it from the SD card as well. Make sure there is a newline at the end of any file. If not, the last line of the file will not be run by Marlin (at least that was true in version 510).
Run homing tests: Create a file that has a single line: G1 Z0 F200. Make sure there is a newline after this line. Do some repeated tests where you home your machine and then run this file. Every time, after you run this file, the bit should just be touching the top of your stock.
And repeating, if you use the homing code you first listed above that leaves the bit 5mm above the stock, you don’t want the G92 in your g-code.
Robert, I did as you said here and ran it from a separate file and it seemed to work. I created a new gcode from Estlcam and commented out this line ;G00 X0.0000 Y0.0000 Z0.0000 F, ran the file and it worked only the alignment was slightly so I had to do a tiny adjustment on my end stops and start over but its working now. I have some repairs to make in some places but its not too bad. Sometimes the bit wouldn’t lift up high enough when moving the the next engraving and drag accross other traces. Its odd that it didn’t return to zero but just stopped after the last carve. Repetier-Host also locked up and I had to go to the task manager to close it. I still don’t completely understand why it worked this time. Here is the gcode that worked:
[Clear Back Traces_R_Flipped.gcode|attachment](upload://8lixImI1
My guess is that your board is uneven. This is a common complaint/issue I’ve seen when reading about cutting circuit boards with a CNC. One thing I noticed reading your g-code file is that your clearance height is only 0.5mm. That is how far the router is being lifted when making non-cutting moves, and that is tiny compared to what I do for wood. You should be able to increase the clearance height to avoid dragging the bit across the copper.
I’m pretty convinced it was the g92… shouldn’t send a g92 x0y0z0 unless the bit is actually at 0,0,0… but that won’t fix the problem with a wavy PCB. I use bCNC as a sender, because it can do surface leveling adjustment by probing a grid over an object and adjusting the input gcode to compensate. It makes the z follow the contours of a warped PCB, and can be used for stuff like engraving curved surfaces without a 4th axis. I’m not sure what other software can do this… I actually stumbled on bCNC looking for options for an rpi sender, and was pleasantly surprised with it’s capabilities when I went to make my first PCBs.
The clearance plane is where it performs G0 XY moves. I thought your gcode was set to 2.0. it also goes to 0.5 quickly before plunging. So it goes to the right XY at 2mm, then zips down to 0.5mm and then does a slower drop to DOC at the plunge rate.
Re-reading the code, you are right. So, the question is why is he cutting through his traces? He wrote:
wouldn’t lift up high enough when moving the the next engraving and drag accross other traces.
I don’t know if increasing the clearance plane to more than 2mm will help, or if this is some sort of artifact with using bCNC and its surface leveling, or ?
Well, I found one issue. I was watching the z stepper motor as it was cutting and it would move every now and then. I discovered there were a couple of loose screws holding the motor. I fixed that and started on my last circuit board. I used the V1 screen to lower Z to barely touch the board, then I unplugged/replugged the Rambo 1.4 board and started Repetier-Host on a new copper board. It was raising up 2.mm this time and everything seemed to be going fine until this happened.
I checked my gcode in Repetier-Host and I didn’t find anything in Engraving 129 showing z to go that deep so I’m not sure why this happened. I copied the gcode from Engraving 129 to a text file but I don’t see a way to upload it here. Also, I let it keep cutting after it did that and it started cutting lines over some of the other traces that weren’t in my svg file. So, scrap circuit board #4.
Here is a pic of the svg file from illustrator.
Two ways. Put it in a .zip file and upload that, second is to use 3 back ticks (typically beside the “1” key on most North American keyboards) and just paste the text, or at least the relevant portion of it. Put another 3 at the bottom afterwards.
Third option is to put it on Google Drive and link it, I guess, but I don’t like to do that myself.
The forum accepts g-code files, so if you rename your text file with .gcode, you should be able to upload it. And as Dan indicates, you can put any kind of file in a .ZIP and it will upload (provided it does not violate the size limits).
I doubt your problem is a g-code issue. I can think of four things that might be the root cause:
Electrical noise that is scrambling the incoming g-code.
Mechanical issue that is causing the Z axis to lose steps
Just gonna put this put there that this isn’t the best way to zero the coordinates, particularly if you have something like repetier-host running.
A much better way would be to send the gcode: G92 X0 Y0 Z0 which will tell Marlin that the current set of machine coordinates are the zero point. This will preserve any squaring that you did either with endstops of use of hard stops to start the machine against so that it’s in a known good square condition.
Did you stop the job when the machine started cutting too deep, or did it just do that once, and then continue normally? That looks like the job did not complete, so I’m guessing the former.
Grub screws. Always a suspect when this kind of thing happens, if the Z axis coupler can spin on either the motor shaft or the lead screw, all bets are off as far as accuracy. This is always a troubleshooting step, if not the first troubleshooting step.
Wiring. I skipped the step of overheating drivers, since you specified the RAMBo board, which does not use the drivers that shut themselves down when they overheat. So the next thing to look at is the wiring from the drivers to the motors. Any possible loose connection between the board and the motor can cause some weird stuff to happen with the motor, and it can be entirely intermittent. Check all of the connections for any possible motion or loosemess that could cause a loss of onnection.
Firmware settings. Are you using V1 compiled firmware, or did you compile your own? If you did, what do you have Z maximum speed and acceleration set to? It may well be worth checking what these are set to, in case it was changed either deliberately or accidentally. If the acceleration is set too high, the machine might skip steps instead of lifting the (rather heavy) router at full speed right away. Same with speed, but that’s usually not a problem for 2-3mm movements (lift, and then plunge to cutting depth) If you have the 12864 LCD iunstalled, you can check these. I don’t know what the commands are off hand to check from Repetier-host, or a serial terminal. These can be reset to V1 defaults (If you’re using V1 firmware) with M502 which will re-load all of the compiled defaults back into current state. These can then be saved (so that they’ll be the same next time) with M500
It only cut that deep on that one trace. I let it run for a while longer until it started destroying other traces by cutting in the middle of them. I looked at the Estlcam file and found that I had multiple tool paths on some of the engravings, but not on the ones that were getting ruined.
