Thought I would give Chilipeppr another shot today as I’d quite like to get back to a more graphical controller for my CNC with a TinyG V9 (running the released G2 firmware).
After many hours of playing around I am horribly disappointed. Two very major problems keep cropping up.
Firstly, most of the time I can’t even get a job to start. I press play, and it streams across the first 1000 lines instantly, then continues to send across 50 lines at a time, but the machine never starts moving and none of the lines are executed. The devices basically stops responding at this point and I have to restart the tinyg and serialport json server before I can control it again. Any idea whats up with that?
When I do get a job to start, it runs mostly fine, but then just stops somewhere near the end but not actually at the end. Again same situation, the device is no longer responding and everything needs restarting before it will talk to Chilipeppr again.
Something is clearly very wrong in the streaming side of things, but this is all over a pretty stable network wired to the Raspberry Pi 2 running SPJS. Its not like this is my first rodeo either, but I honestly can’t make head nor tail of whats wrong with this.
Just to make sure it wasn’t my TinyG or some other part of my setup I switched back over to Fabmo Engine and everything’s working perfectly. Is there some magic setting somewhere for v9 (besides the ?v9=true on the workspace url).
Glad you’re doing ?v9=true. That’s a first step. 2nd, are you using an actual v9 board? Or a Due? When you say you hit play but nothing works, were you able to jog fine before that? What is your config script doing? Did you set one up in the cog wheel icon in the SPJS widget?
Hey John. Yeah using an actual v9. I setup the configuration script and I can jog around before hand no problem at all, got my job nicely setup and ready to go then hit play and besides the number of sent lines ticking ip nothing else happens. No console errors either.
You know, we’ve been debugging some new controllers/ firmware (smoothie, some marlin) in chilipeppr and the symptoms you’ve described are identical to what we’re dealing with, the cause of which I believe to be the SPJS buffer needing some work.
But Tinyg should work fine, and the v9 = true was my only advice for you. Double check your SPJS and firmware version.
I’ve tried using the latest from the updater app, as well as a compiled version of what’s in edge 90 branch from the g2 repo. Same result in both cases. Now streaming to the v9 is a little different since it has the two serial ports on the same usb bus so maybe there’s some issue in spjs with that?
Yeah, there’s a stream port and an immediate port, but I’ve never been particularly attentive to which one I select. I don’t have a v9, I briefly had a due + g shield driving a frame and could jog around fine but don’t think I ever ran a job. And my 3040 has a v8. So I’m not the most experienced in the v9 realm. I think John has used it a lot though, and @sszafran has spent a lot of time with G2 on the due.
There is a buffer for tinygg2. Are you using that?
The work was never completed in CP to use both ports. Instead all commands are still just sent on one port, which is why feedhold is still sluggish on G2 which is why I went back to v8.
Yeah I was using the g2 buffer. Perhaps I will take a look at writing a proper v9 implementation of spjs. John, how much work do you think it would be to add a non streamed mode where the whole buffer is sent across first and spjs just sends to the hardware on its own?
Well, that’s what SPJS does. It’s just that it keeps everything in RAM cuz that’s all I ever got around to. Today’s limit compiled in is 200,000 lines which was just a number I picked that I thought was safe. You could let RAM go way higher in an unbounded way by not using channels like I do and instead using a fifo queue that you dequeue on your own. Or write it to disk and then read off of that. Not sure that would solve anything for you though. If you are getting a pause on your job it’s because the send/recv is getting out of sync which doesn’t make sense to me since that is debugged to all living hell and works great. Only thing that could happen is if an r:{} doesn’t come back from your firmware like SPJS expects cuz EVERYTHING pivots off of that r:{} coming back which lets SPJS know it can then send in another line.