Has anyone sent any gcode from pycam to their ShapeOko? I’m trying my very first 3d cut today. I tweaked things in pycam for quite a while until i got what I think is pretty good in the OpenSCAM simulator. I went out to the garage and tried a test cut from chilipeppr - it starts out ok but then about a minute into it, the bit starts cutting very odd patterns.
When looking in OpenSCAM, there should be a zigzag pattern the entire length of the material (about 7 inches) for the first layer with no changes in Z at all, and no big motions in Y. But when I send the code, the zigzag starts and then about a minute in I start seeing a straight movement in Y… and then some more back and forth, then some very odd motion and ramping in Z which shouldn’t happen at all.
My guess is there is something incompatible with this gcode and grbl. Anyone ever seen this?
I’m running the job right now on a TinyG and it looks ok. It’s a pretty cool design and it seems to me ChiliPeppr is showing you pretty much what OpenSCAM tells you it should look like. I’m 10 minutes into the job and it looks good.
My luck with PyCAM was ok after getting used to it. At first I was not using it right. I do not know the last time that PyCAM was updated or what version you are using. I think I was using a Linux RPM package that I installed 6-12 months ago.
I suspect that the odd PyCAM movement may be from G00 or G01 or G02 commands that have multiple X or Y or Z coordinates after them. Perhaps the additional lines are supposed to have the G## command before them, but the G## is being excluded for some reason. Reviewing code from Easel and MakerCAM and PyCAM reveals that only PyCAM excludes the G## command when it is the same as the last G## command.
@jlauer thanks so much for running it for me. U da man. This must be something incompatible between grbl and pycam gcode output. I know grbl has issues with long lines, but I didn’t see anything in there that concerned me (at a glance). @Jarret_Luft any issues you can think of? One thing I found in a forum was someone suggesting semicolon comments might have problems in grbl. Not sure if that is the case or not, but I’ll try running another version of the file with the semicolons replaced with “(”.
Frank, it was hard to tell from that video what line it started going awry on. Keep in mind yellow checkboxes simply mean “Sent to SPJS”. It’s the black and green lines to look at. Just use the Gcode widget to figure out status of lines, not the Serial Port Console. What was the line that went black checkmark just as Grbl went awry? It’s probably 3 or 4 lines prior to that where the issue is because black means “Went to serial buffer of Grbl” which has room for 128 bytes. The line that went awry would be being executed which means a few lines prior to the black checkmark.
Well, I ran it again, and I can’t see anything significant about the lines around where it went awry. I did try changing the preload setting that Jarret suggested, but the problem still occurred (although now in a different spot). It certainly seems like maybe somehow grbl is skipping over some lines or discarding them or something.
Could there be something wrong with the number of decimal places in the gcode?
Try pre-uploading 20,000 lines, which of course your file is only 5,000 lines. Does that change where this happens? What was your other preload Jarret suggested?
