I think adding the time.Sleep(1 * time.Millisecond) won’t solve this issue. I agree with @Justin_Adie that the solution is better logic and that’s what the TinyG buffer got in it to nail this 100%. Now, I do know that this bug pops up more depending on whether you run SPJS on a Mac, Windows, or Linux. It feels like it’s the power of the machine that makes the bug less likely to be seen, but that sort of makes sense given this is a thread locking issue.
So, just because you can get through a whole job doesn’t mean the bug is fixed. When Jarrett Luft got the Grbl buffer going originally, he would never see it fail. Indeed, today, only some people see this bug. Many have no issues.
@jlauer I’m running SPJS on an OrangePi H3 4 core ARM32 CPU exclusively. Without the delays I got a few hangs at 240mm/min but ten times more at 1400mm/min. I guess the right approach is changing the logic in the buffer code, unfortunately for me it’s still Chinese, I don’t get what that threaded code does and our only hope is Justin, until then I have milled enough PCBs to keep me busy for a while
unfortunately I have plenty of spare hobby time since my mill is in pieces and my controller board still waiting for a part!
I think the majority of the issues @Mircea_Russu saw were related to a completely bizarre commit on github. literally very different to the code in my development files. looks like cloud9 tried to commit a very early stage of my recut after I had manually committed the beta for testing.
with the right code I am not seeing the pos reports back from the controller in the absence of a formal request (?). I’m not sure where the requests are being intercepted but plan to check on that tonight.
I believe the Grbl buffer drops the next pos report if it’s identical to the prior one to reduce the amount of data going back up to the browser. I bet that’s what you’re seeing.
unfortunately not. grbl1 changes the <> reports frequently (I dont recall the exact frequency) so i’d still expect reporting at least every 200ms if not more.
more likely to be something in the tinyg buffer that I failed to fix for grbl.
From what I recall, Grbl does not send position reports on its own because the Atmega 328 processor is not powerful enough. So SPJS via the Grbl buffer had to ask for reports every 250ms or so. The Grbl buffer would record in RAM what the last position report was and if the position changed it would report it up the line. If the position was the same it would drop it on the floor because no reason to transmit up the line. So, the Grbl buffer had a timer loop to constantly ask Grbl for the position. It turned on this loop when you connected. TinyG buffer does not have this because TinyG is a more powerful processor and it just sends position reports automatically when the position has changed, thus no logic was needed in buffer. Maybe that’s the reason. Just an idea.
I’ve seen somwhere in the onreturn function an if statement which called for return if the position hasn’t change. I’ve thought about commenting it out.
@Justin_Adie Now I’ve seen your question about plated vias. I thread a very thin wire (0.3mm silver plated wrapping wire) through the holes and solder both sides. My solder mask is not here yet due to the Chinese holiday. The via holes are 0.5mm wide, pad holes are 0.9mm. I haven’t found a cheap reliable method for plating vias yet, something which does not require USA made chemicals or too many steps.
I use conductive ink and a simple solution of copper sulfate and sulphuric acid (with a polymer for throw). I’m getting mixed results. Good plating but I’http://m.measuring 900 ohms between layers so the conductivity isn’t great yet. But very cheap!
I have some solder mask if you’d like me to send it. I got mine from Romania I think!
I’ve been looking to try out some silver conductive paste I got from aliexpress and some copper nanoparticle ink I got from Novacentrix that has to get sintered with laser. I’ve never found a good/easy way to plate copper through hole either. Been wondering if there might be a wire threading solution that could be helped by ChiliPeppr and some new algorithms, i.e. a wire feeder that shoves wires down the hole and crimps them or something. Or maybe it just dispenses conductive epoxy/paste/fluid from cnc dispenser.
@Justin_Adie Lol I’m from Romania. And I’ve just ordered 3x100g liquid solder mask on ali I couldn’t find anything locally for an acceptable price, only some film uv mask for about 300 Euro a roll…
@Mircea_Russu
I have updated the repo with fresh code. it is working for me except for two strange things:
move commands result in very inconsistent responses. eg.
<Idle|WPos:-0.032,0.000,0.000|Bf:15,128|FS:0,0>
G91X-0.02
[echo: G91X-0.02]
ok
<Idle|WPos:-0.048,0.000,0.000|Bf:15,128|FS:0,0>
see that an incremental move from -0.032 by -0.02 should result in a position of -0.052. but for some reason it is not.
i don’t know why this is but it is not an artefact of sjps as the controller gets the right information and just doesn’t obey. This is on grbl 1.1e - perhaps you won’t see the same in grbl 0.9j
the other issue is that sjps is reporting that it is hitting a line in a conditional that it should not. it does not seem to affect performance but i have not chased down why.
