I tried bCNC (a python based CNC milling interface) and now for whatever reason http://chilipeppr.com/jpadie does not want to stay connected to the grbl. Really…can I even get a break?
So you used bCNC and then stopped and now cp won’t stay connected?
The persistent disconnects are something I was seeing that, in the end, blocked my progress. Interesting that you see it too. What does the verbose output of sjps say when this occurs? It would probably be wise to add some debugging code to grbl so that you get a notification when a reset event occurs. My thinking is that sjps is at fault and forces a reset on the arduino. Putting a small cap between reset and ground might solve the disconnect issues.
I think the better solution is to rewrite the bit of sjps that establishes the connection. Instead of just setting the port it should check whether the port is already set correctly and then attach without pulsing the reset.
@Justin_Adie your progress was halted by failure to stay connected? Good to know. Not good that it happened, but good to know. Did the problem happen after a change of spjs or arduino firmware of sorts? Since Chilipeppr is online, do we even know the last time it was updated?
@NathanielStenzel I had been noticing a disconnection event (which then halted the milling and lost coordinates) literally every time I milled, but not when I was autolevelling. I have never successfully completed even a small milling job with this kit.
i thought it may be browser overload so tried different browsers. But then tried sjps in verbose mode and realised that the disconnect appears to be happening between the arduino and sjps. the disconnect would not be terrible if SJPS didn’t try to reset the port when it connects back to the arduino (as the arduino resets on port reset and thus loses coordinates; if the arduino was not forcibly reset then the coordinates may still be in the machine and that would give us another diagnostic point - hence my comment about leaving a cap (1uF) between reset and ground to override the reset pulse.
Anyway I then updated the USB firmware and it still happened (this is with an Uno - there are different problems with a Mega 2560 and I have not tried with a nano).
All this was with both 0.88 and 0.94 of SJPS. 0.94 has adjustments made for grbl 1.1 and code that I helped on. 0.88 had no involvement from me (so is probably more reliable).
The one thing that I have not done is roll back to grbl 0.9j and sjps 0.88 and use the grbl workspace. There were too many other bugs (for me) in the grbl workspace for it to be usable. My workspace leaves the 0.9j version of the grbl widget largely untouched so this maybe the next diagnostic step would be to try 0.9j on the jpadie workspace with 0.88 sjps. always logging the diagnostic output from sjps ideally.
Ugh. I can no longer remember why I updated my grbl firmware. I wonder if I should have left it in an ancient firmware version.
I removed G64 and M7 from the gcode header. The bCNC program does not them. Now the gcode runs in bCNC. Any idea if Chilipeppr and SPJS could have had trouble with the commands? I figure if GRBL handled the two commands oddly that maybe the bCNC and Chilipeppr/SPJS could have had different bad reactions to the result. I have no clue though. I did not feel like trying Chilipeppr on the modified code since it takes 45 minutes to run.
Can you post the code as revised? It may be possible to run it at a v fast feed rate with the controller board disconnected, capture the output of sjps and then compare the input and output to see whether anything is going wrong in the comms.
I am aware of certain M commands causing issues in certain circumstances now that you come to mention it. This is a bug in the sjps flow control for grbl.
IIRC I fixed it in my fork of 1.94. But in doing so caused some other issues as I was also trying to improve flow control.
I will take another look and see whether I can reverse the changes so that only the M command issue is fixed. I may also be able to fix this in CP rather than grbl.
In fact better still would be to analyse whether grbl really needs sjps to be altering the gcode on the fly. Probably not. But I will need to test.
The content is really trivial. The G07 line is the one that was recently changed.
G21
G17 G90 M3 S3000
G0 X0 Y0 F1500.000000
G0 Z0 F400.000000
G1 X0 Y0 F1500.000000
G1 Z0 F1500.000000
(start object)
G1 F1500 X0.00 Y0.00 Z0.50
X6.50
X6.75 Z0.25
X7.00 Z0.50
X10.25
X10.50 Z0.25
X13.25
X13.50 Z0.50
X14.00
…
For Chilipeppr, I never was really sure of what the problem was. It would get a great deal into a cutting job before messing up. In bCNC, the mess up was pretty immediate.
my mistake. the error with certain M commands was in the 3d viewer code. that is fixed in my workspace. But I will probably import Daniel Chote’s new fork of that. I did flag the error to him and John some months ago but I don’t know whether they implemented the fix. @Daniel_Chote @jlauer
with the same code, if the controller is messing up then the culprit is more likely to be the comms between the controller and the server. the only way to debug this is to recompile grbl with echo turned on, launch SJPS in verbose mode and capture the output. if you then posted it or sent it to me (the captured output) I can write an algorithm to compare the commands.
if you make all the federate commands 2000 and increase the value of the federate limits in the $settings, then the job should finish quickly (obviously disconnect the drivers…) and we would still have all the debug data.
I will try to get around to checking the code against Chilipeppr. As I said though, it takes a while for Chilipeppr to mess up.
sure. that’s why a fast air-job and capturing the data makes sense.