Hi Chilipepprers, I've had tremendous success using the tiny g and chilipeppr but have

Hi Chilipepprers,

I’ve had tremendous success using the tiny g and chilipeppr but have continuously encountered an issue which is a deal breaker if I can’t solve it. My CNC machine stops in the middle of somewhat longer cuts. Honestly, they aren’t even that complex. I’m working with an early 2011 MacBook Pro with the latest sierra OS X . Using fusion 360 to create gcode. I always flush my queue and have also increased the amount of gcode lines to preload in the gcode options. Before I go out and buy a new MacBook Pro ( I would love to keep my existing machine), can anyone tell me if running JSON with the chilipeppr is an exercise that requires a high spec machine? Also, based on the description above, if you have a diagnosis, hypothesis as to why the machine is stopping all of a sudden midway (sometimes at the very end of a cut also)please feel free to share.

On a related note, perhaps fusion 360 is exporting some hard to digest gcode for the computer I have. Is there anyone here with experience using f360 and tiny g who can comment on this?

Best regards,

Kevin

What version of SPJS are you using? It would have helped to post a screenshot to see all your version numbers.

I had similar issues with my old laptop it was a core 2 duo, “upgraded” to an old pc that I got for free and was much better, can’t remember the specs of the pc but it wouldn’t be much newer both around 8 or 10 years old I suspect. Both running Windows.

I don’t think it’s about how old the computer is. The old versions of SPJS had a random bug where the bufffer could lock up. Only the latest version is the way to go, so my guess is you both are/were using older versions of SPJS. Now, it could also be TinyG firmware catching you up and yes, i have seen G2/G3 arcs out of Fusion360 that crash my TinyG, but that too is based on what firmware you’re using there. So knowing what version of SPJS and TinyG firmware are the most important items here, I think.

I had a similar problem. I was using shielded communication cables so I didn’t think the cables could be the issue, but it turned out to be. I had removed to much of the shielding near the connections to the tinyg to make the connections easier. Leaving that area not only unshielded, but uninsulated for a bit. Once I cut the cables back and ensured the shielding and insulation went as close to the connection point as possible my troubles went away. No clue why it only showed itself in longer programs. I was usually good up to about 90 minutes but after that it was hit or miss. Something simple to check, sometimes it’s the simplest things.

Hi again,

Sorry for the delay here. I’m in Japan. I am attaching serval screenshots for your reference. Just FYI but I am using the latest JSON server for mac OSX Sierra (I also have this OSX.) I really appreciate the help here.

Best regards,

Kevin
missing/deleted image from Google+

Here is the JSON server terminal screen.
missing/deleted image from Google+

Here are the settings in the Gcode area.
missing/deleted image from Google+

missing/deleted image from Google+

missing/deleted image from Google+

It seems your Gcode file in your screenshot is really not complex at all. If that’s the file you’re running, how many lines is it? I doubt this is the old buffer bug since your Gcode file is so small. Also, stopping in the middle of a line would then not point to ChiliPeppr or SPJS, rather TinyG. This makes me think noise could possibly be an issue. When it stops is it a crash meaning the TinyG board is unresponsive? Or can you hit the resume ~ button and it keeps moving? Does it take any commands afterwards in the serial port console?

Hi John,

Actually no, the resume command doesn’t work. The command prompt doesn’t accept input either. The tiny g is just flashing the red light. If I reset, and flush the queue then I can move my axes again but I can’t resume the job as it has lost its position.
While I’m cutting, it is quite noisy as I am using a shop vac to get rid of saw dust… perhaps that is an issue.

I have been talking to the folks at fusion 360 and they suggested using their smoothing function…

If TinyG is flashing red, it crashed. If that happened on a straight move then it’s not your Gcode. Sometimes TinyG does report an error right before it crashes, but that would come back in the serial port console only if you have the filter (funnel) icon turned off would you see that error because it comes in as JSON. I would try that. It could be electrical noise.

If you are using the limit switches try to disable them. I had the same issue and once I disabled the limit switches all the crashes stopped.

Thanks for the advice. I’ll give the limit switch idea a go. Kind of makes homing the machine difficult though.

Regarding noise, if I were to isolate the tiny g from noise/ vibration… is this basically the suggestion? If so I can certainly try.

You want to isolate from electrical noise, not vibration. So, for example, I had to twist my wires for my touch probe at one point because of electrical noise. You could try that on the limit switches.

John, what do you mean twist your wires? Btw. This definitely sounds like the solution. Didn’t realize it before but the machine is stopping as if I triggered a limit switch.

What about covering the wires with electrical tape to insulate it???
Thanks,
Kevin

Can you post a photo of your limit switch wires?

I actually don’t use limit switches. Twist your wires the way Ethernet twisted pair wiring looks

There are a few solutions for limit switch nose. Electrical tape will not solve anything. My suggestion was more to isolate what the cause was than a final solution for you. There are a few commercial solutions to isolate the noise you can try too. Twist the wires as John says, get Ferite beads for the wires, use a buffer device like a relay very close to the controller, ETC. I found it easier to just not use the switches. I usually home to the center of my work piece so it is a different place every time so no home not a problem for me.