I’d like to request the /jpadie workspace detect or default to GRBL 1. I building a machine and going crazy having to do all that clicking to reconnect each time I read about a new gcode command and want to go try it.
It does detect the version from the init string that the controller sends when it is reset
And if it cannot recognise the init string it defaults to v0.9x. if you know you have v.1.1x then you can force that mode in a drop down at the top right of the grbl widget.
So I realized if I leave the firmware set to “default” (aka let it detect??) then it does say GRBL (1.1f) in the status widget after I check-mark the box, but I can’t unlock the alarm state no matter what I try. GRBL (1.1f) is correct for me.
When you say default I suspect you are referring to the serial port selector widget. This tells sjps what flow control to use. For all versions of grbl you must select grbl.
The jpadie workspace will autodetect the version if it can. It only supports vanilla flavours of grbl. If for whatever reason it does not show the correct version number in the widget then you can try sending $I to the controller to cause it to resend its version info.
If it is still failing then you can try forcing it but it is probably because you have a comms issue. So better to start again.
If the alarm state is not unlocking then this is probably because you are on default rather than grbl in the http://serial.port selector. Try again with grbl.
If it still isn’t working please post back.
It works if I open the drop-down and click grbl every time. Can this step be saved as a setting? A simple cookie in the browser that says, hey, we know the answer to this from last time he was here, let’s highlight that for him to save few clicks.
On some browsers and OS it does default on reconnect. I believe that when this doesn’t work it is because the local cookie saving is not permitted by the browser.
I don’t have a fork of the serial port selector but by all means fork it to provide for the default for other browsers and let me know where your fork is and I can load it or you can issue a pull request back to the master repo.
I use Chrome on Windows10, and cookies are permitted. What might be the cause?
I have updated the workspace to use a different method of defaulting to grbl.
Cool, much better!
Here’s what I am seeing right now… I can close the browser and open it back up and it fully reconnects using GRBL and the console comes to life. However, if I close SPJS too, it forgets again. I assume it could be SPJS’s fault in this scenario though.
Once I get my cnc system working I will feature it on my Youtube channel. I am hoping to stick to /jpadie and show that off too, so the fewer steps it takes to use it, the better the presentation.
It forgets to change the drop-down to grbl? That’s odd.
It might well forget which serial port you were previously using. If you’re suggesting a change to that use case then best if you post your suggestion to the github for that widget.
/jpadie has always identified an Arduino Uno on COM5, without fail. It just fails to select GRBL from the dropdown. Even while saying GRBL 1.1 on the status widget.
The spjs widget does set a cookie to remember the last pulldown setting you picked but I noticed it sometimes is weird so I could look into the bug but maybe somebody else could since I would only be able to look on Sunday
I’m not in a rush, Sunday would be great with me.
@jlauer
The grbl workspace passes an object to the init of the spjs widget that prescribes the flowcontroller and baud rate. Is the widget overriding this?
The widget uses that as default data for the buffer pulldown if no cookie is set. Once you’ve connected with a set buffer it stores that as a cookie for that port name so it can recall it on next browser load. So there are 2 layers to it trying to help you.
I was just taking a look at the github. Not fully traced it through as I ran out of time but at first blush it looked like it was retrieving the cookie settings for the port irrespective of whether a default buffer and baud had been set in the opts.
Which seems reasonable since different controllers may require different bauds.
Correct. The user can override the defaults at any time. Cookie overrides default from the init
So then the use case here seems to be that the cookie values are being set incorrectly. I might have time on Sunday to have a proper look if you lose your window on Saturday.
I spent some time having a look at the code and it seemed fine.