Help! I have a Lead 1515, Meshcam v8.49, and Openbuilds Control. I cant get my lead machine to cut my 3D meshcam gcode file without "Alarm 1- Hard limit triggered" errors. It seems the Openbuilds Control does not like the gcode generated by meshcam, however when I run the openbuilds "HelloWorld" gcode, it cuts without issues. Before sending a Meshcam generated file, I delete the "tool" line in the meshcam gcode. it starts fine but quickly the motors seem to skip a bunch of steps which then throws off the file's original start position and leads to the errors. 1. Are there some settings I need to change in OB Control to get this all to work or is Meshcam simply not compatible with the Lead 1515? 2. Which 3D gcode packages are fully compatible with my 1515? Thanks everyone!
Incompatible GCODE would raise different errors: Grbl v1.1 Interface · gnea/grbl Wiki (For example "G-code words consist of a letter and a value. Letter was not found." or "Numeric value format is not valid or missing an expected value." and "Unsupported or invalid g-code command found in block.") Hard limits means your limit switches triggered: either for real (as in carriage crashed into it because the gcode file contains moves that does not fit on the machine's working envelope or the working coordinates weren't set/zeroed correctly) or - if it happens randomly and nothing was near the actual limit switches, the most likely cause is EMI: See docs:blackbox:faq-emi [OpenBuilds Documentation] Any Grbl 1.1 compatible CAM, some examples here docs:software:overview [OpenBuilds Documentation]
Once you have your Hard Limits issue sorted: If you are up for helping to beta test this: GitHub - OpenBuilds/OpenBuilds-MeshCAM-Postprocessor It's mostly untested but let me know if you encounter any issues with it (include serial logs and sample gcodes of any weird issues)
Thanks Peter! The switches were physically triggered because the machine lost its place after the x motors skipped several steps, and then thinks its somewhere else. It thinks its on right side of the print, when its actually on the left side near the limit swtches. I do remember when I tried running the file for the first time it got about half way thru then it stopped due to the switches. Now, it triggers a lot sooner, so it seems the file got corrupted. I just ordered a bunch of Ferrit Cores to see if this helps. I went to the github file, but Im not sure what Im supposed to do with it. Is this supposed to be downloaded or pasted onto the gcode or meshcam? I didnt see any download option, but Id love to help with the beta testing.
Check your acceleration and max rate settings in Grbl Settings - if set too high you can stall the motors. Also check Shaft Couplers on the motors - loose grubscrews can cause them to slip. Green button top right has a Download Zip option. Those are Post Processors. Refer to MeshCAMs help/docs how to install Post Processors, sorry I don't have a copy at the moment
I downloaded the OB post processors files and added to meshcam. Produced the gcode file and its clean of unneeded gcode, much better results so far! I'll tighten up my machine and try to run the file again tomorrow. Thank you
I added the ferrite cores to all the wires and tightened up the machine. I tried the file again today and although it progressed a bit further it still came back with errors. I suspect it the g-code from meshcam. Im going to try to produce gcode from sketchucam and see if I get any errors or the motors skipping steps. Since the "Hello world" from OB Cam prints without flaw it may very well be a problem with meshcam.
Screenshot the errors, serial log of the section leading up to it, and include the gcode file please - so we can check it out for you. If its the gcode, we can still edit the Post to make it more and more compatible... Note that its a lot lower down the list of tips (at position 6) than say spacing router power cable away from low voltage signal cabling - have you done the basics (1-5) too? docs:blackbox:faq-emi [OpenBuilds Documentation]
Hi Peter, here is the data you asked for. I screenshot the error message, the serial log at the error, and attached the gcode file from meshcam. I also ran the gcode from Sketchucam and did not have any problems. I would prefer the power of meshcam so it makes sense to try and figure this out. Thanks
Absolutely, we would love to add it to the list of supported CAMs too - very happy for your help in testing it all so we can get to that point for the good of everyone So looking over the errors, it didn't do any unexpected moves before the Hard Limit - so it still appears the Hard Limit is caused by a "false" trigger - ie some sort of electrical interference inducing spikes into the limit switch wiring, causing the firmware to think it saw a Hard Limits switch being hit. Tell me a little more about your setup? Do you have Dust extraction? Do you run a router or a VFD spindle? Is you stepper motors wiring or router/spindle power cable in proximity to the Limit switch wires (both inside one cable chain for example?) You can try a test run with Hard Limits disabled (CONTROL > Grbl Settings tab > Scroll down to $21 Hard Limits > Set to Disabled > Save on the toolbar > and Reset when prompted) With Grbl no longer checking for a Hard Limits signal, see if it otherwise completes - that will confirm the issue is electrical in nature If that confirms it, we revisit the EMI FAQ page where we have a detailed rundown of mitigation strategies
"Do you have Dust extraction? Do you run a router or a VFD spindle? Is you stepper motors wiring or router/spindle power cable in proximity to the Limit switch wires (both inside one cable chain for example?)" Yes - Dust extraction, Yes - Router, Yes - router/limit switch in same cable chain. Ive been running the file with router/extractor off, but still errors. As I watched the machine, it seems it misses steps, with a a bit of noise included. The error then proceeds as the machine has lost its position and runs into the x switch. I removed the router cable from the chain, same result. I tried running 2 different files from Meshcam, same result. The curious thing is files generated from sketchucam and Openbuilds cam, cause no errors. Wouldnt the EMI also interrupt the machine while running those files? Im glad you got the file to work on your machine, have you followed all those emi procedures? Maybe I should match your setup? Ive included pics of my setup.
That's the key thing to mention If it hit the switch, it's a valid Hard Limits (it did hit the switch) If it was nowhere near a switch it would be a false Hard Limits alarm (did not hit a switch, thus a false trigger - thus EMI) So, not EMI then... We just got to sort out your skipping issue Always X skipping? A stuttering noise just before it runs off? - Check wiring: docs:blackbox:faq-identify-motor-coils [OpenBuilds Documentation] - one of the 4 wires coming loose intermittently? Or a whining noise? - Check Grbl settings - lower acceleration and Max rate as test runs - MeshCAM might be pushing a bit harder on feedrates
I would say its always "x" because thats the switch that is always triggered. Here's video of the issue:
A recheck (or redo) of the X wiring would be best then, an intermittent issue indicates the order is correct, but maybe somewhere a terminal is loose or a wire inserted under instead of into the cage in the terminal.
Please also post a Grbl Settings backup, just so we double check that for you too: OpenBuildsCONTROL > Connected to the machine as usual > Grbl settings tab > Backup Grbl Settings button on the top toolbar
I saw another user here, KAX, has had the same exact issue as me: "Is MeshCam compatible with the LEAD Machine? I have a new LEAD machine running the OpenBuilds CONTROL software with the CNC xPRO V4 Controller Stepper Driver. I have tried saving the gcode to almost every file type that MeshCam allows and the Control software keeps generating errors because it sees gode that it does not like. Are there any good desktop CAM software packages that work with the LEAD Machine?" There is definitely an issue here that needs to be resolved, my previous machine was a Shapeoko and I never had issues with Meshcam. Can you send me the grbl file from your machine, just as a comparison to make sure I dont have some weird setting. Id like to check my settings against yours before I start messing with motors. Im going to swap the x motor with one of the y motors, and see what happens. As far as I can tell the wiring is correct, all the wire colors match up. What isnt adding up for me is that OB cam and sketchucam gcode works fine, driving me nuts!
Addressed already... Which we fixed in our Post already (back in the days people tried the LinuxCNC or Mach posts as we didn't create one yet) Your only error was really switches being hit ^ you already confirmed that. Its not a mystery And why did it hit the switch, because of the very clear skipping noises. So no, not at all similar to the quoted post I am not in the office today but can confirm your supplied Gcode file ran fine. SketchuCAM/OBCAM tests: supply the test files too, how many runs have you done? Regarding your Yes i also don't doubt the Order. As mentioned: More likely something loose. We see that often enough that we have a dedicated FAQ page for that the noise is tell tale!
So I double checked all the connections, replaced the x motor wiring, swapped the z motor with x motor, and still had the same issues. Different motor, different wire, same error. We can eliminate the wire, connectors, and the motor as the source for the error. You tested the meshcam file on your machine and said it had no problems, if thats the case it isnt the meshcam file either, must be something specific to my machine. Perhaps my settings or the black box??? Could you send me your machine setup files please? Thanks
We have different machines (I have an old Ox - runs the same BlackBox with Grbl 1.1 controller, same softwarev (CONTROL), but very different steps-per-mm, acceleration, etc specific to the machine) so it wouldn't work on yours But try lowering your Acceleration and Max rate values of the axis that skips, to about half their current value and please do another test Grbl v1.1 Configuration · gnea/grbl Wiki and Grbl v1.1 Configuration · gnea/grbl Wiki
The original acceleration was 3000, I lowered that to1500 and the file printed fine! Im going to experiment and see what is the ideal rate is. Sorry I took all this time to figure it out. Thanks for all your help Peter, I really appreciate it.
Treat yourself to an INTERFACE CNC Touch and plug it into your BlackBox's AUX port Checkout https://docs.openbuilds.com/interface for the documentation for this product Sitting pretty on an Interface Mounting Kit (Borrowed photo from Instagram:newvintageamps to show it mounted to a LEAD1515) Demo video:
