August 5, 2016 at 12:28 pm #15678
Hey! Hopefully someone with a bit my experience with CNC’s can point me in the right direction to solve my problem. I followed the guides on the site using estlcam and repetier and was able to generate the gcode and make 2 successful cuts. But for whatever reason I have to stop and restart the cut before it accepts the g code properly like 5-10 times. Sometimes as soon as I hit print it just starts moving in one direction, (sometimes angled slightly) and other times it seems like it’s heading to home (but of course there’s no endstops to set home) and then other times it starts perfectly. I’m not even trying anything complicated, just a 50mm square with holding tabs.
Issue prevalent on both, Microsoft surface 3 and my laptop, with fresh installs of arduino estlcam and repetier. Also I’ve personally never had any luck with repetier with my 3d printers, is there any program like pronterface for CNC?August 5, 2016 at 12:51 pm #15683
You can use pronterface if you would like.
Can you zip up your gcode and post is so we can give it a look.August 5, 2016 at 7:02 pm #15717
Heres some gcode it was doing it on. https://drive.google.com/open?id=0B7KlDZWHLDTmeVp3NzFPOV9FbXc
is there a special way to load NC files into pronterface? or just rename them .gcode?August 5, 2016 at 7:34 pm #15719
You need to zip anything but pictures.
You can just have estlcam save them as .gcode, it is a setting by where you select marlin. You can rename them with no issues as well.August 6, 2016 at 2:16 pm #15735August 6, 2016 at 4:05 pm #15739
It drifted up because you told it to lift the z axis 15mm in your start gcode (and you should open with g91 and close with g90, I’m pretty sure). Why the z move? That is what the clearance plane setting is for.August 6, 2016 at 6:03 pm #15744
The 15mm lift isn’t in the start. It’s in the end of the gcode, to just add some security that my bit is clearing my material.
The starting g90 was set by Estlcam’s marlin setting. But my understanding I should be using relative positioning because I’m working from where I set the bit, not from a static origin(ie home position)August 6, 2016 at 7:31 pm #15749
Sorry I didn’t catch tat part, thought it was all under start. Well the gcode looks good. A few possibilities I guess. Is your home is not being set correctly. I reset my arduino before I start a cut to make sure it is zeroed out. I see it in the code but maybe it isn’t taking?
Try setting the spindle at 0,0,0 reset the adruino and run the code again. This has got to be something simple we are overlooking.August 7, 2016 at 8:31 am #15757
Are you manually moving the carriage in between cuts, and zeroing out at home? If repetier/pronter thinks the carriage is away from the intended starting point, it’ll truck along in a straight line to wherever it thinks it should be. Even in relative positioning mode, it should be remembering that relative origin.
Your current Gcode starts off with a G90 (absolute positioning) and then:
G00 X0 Y0 Z0 (move to last set home)
I would expect your starting gcode to roughly say:
G91 ; Relative postioning mode G92 X0 Y0 Z0 ; Set that we are currently home, all measurments are from here. G00 .... ; Your first move
Then the Gcode should go off as planned, unless I’m way off base.
Hope this helps,
–Edit, I think I understand your desired behavior better.August 7, 2016 at 4:52 pm #15775
Matthews gcode seems to put me on the right path. I did have to make one tweak of G90 instead of G91, for some reason g91 sends my carriage to the -xy position you assume it was looking for home whereas g90 assumes wherever it started from is 0x0 and goes about its day. Seems backwards to me but hey its cutting like I expected it to now lol
Thanks for the help!August 10, 2016 at 2:06 pm #15910
Glad it helped, and thanks for the feedback on G90. Have fun!
You must be logged in to reply to this topic.