This is not an issue but an invitation to use a webUI dedicated to grblHAL

[karoria]

Hi @terjeio @phil-barrett
I have developed and hosted an open-source webUI compatible to grblHAL. It is almost fully functional now. I invite you to kindly use it and give your suggestions for improvement. The project is hosted at https://github.com/karoria/grblTouch
Waiting to hear from you.
Cheers!
Ravi

[karoria]

Hi @terjeio @phil-barrett
Pinging again to know if you have tried my new webUI. I want to know if it runs out of the box to your setups or I am missing something obvious. I have modified readme which describes keyboard shortcuts as well as added screenshots. I have tested it with teensy4.1 driver with my customized PCB board and it works like a charm. Once I know I am on right track, will add more functionalities to it.
If you feel, you can encourage users to test it at suitable place on wiki.
Best,
Ravi

[terjeio]

Be patient - I will check it out when I get time to do so.

[karoria]

Ok. Thanks.

[terjeio]

It works for me albeit with the UI widgets far too large. This is with Win10 and Firefox and Edge browsers. On my stone age tablet it is not usable, but I did not expect it to work on that anyway...
Are you targeting a specific browser on a tablet or a phone?

IMO by default you should use the IP address from the loaded document to connect to the websocket port, and perhaps issue a warning if connection fails. For grblHAL it would perhaps be nice if you add a Stop button that sends the stop command 0x19, this is not as harsh as a reset.

[karoria]

Thanks Terje for providing initial impressions of grblTouch. The thought process behind this UI is as follows which will answer your questions:

1. This UI is made for touch screens (with full screen occupation. There is a shortcut key "F" for toggling full screen). It is not meant for typical PC use. This should give a user experience like HMI of industrial machines. When opening this UI in standard PC, it should obviously look too large because the UI is designed to use 100% of horizontal and vertical viewport. So, it will always fill the available screen, whatever size it is of.
2. No specific browsers are targeted, so it should work on all browsers. However, I prefer chrome or chromium (for raspberry pi) as I test the UI in chrome dev tools.
3. For some mobile/tablet browsers it may not work out of the box, specially for vertical scaling (as in landscape mode of mobile browsers take too much space for taskbars). That will be resolved in new updates.
4. The primary and only means of communication is websockets for this UI. So, there will not be feedback of initial lines just like USB serial. So IP configuration should be static and known to user to make the connection.
5. I was not aware of 'stop' 0x19 command. I will surely include that. Can you please elaborate its working? I mean when it should be used?
6. My aim to make this UI is to make a HMI like UI where as an SBC like RPi4 with 7 inch touch screen and its case can be mounted on the machine (and should be configured to start in kiosk mode with webUI autostart) to free up the need for PC for operating purpose, which can be kept at safe and dust free space for only programming purpose and files can be transferred or deleted by FTP (I use FileZilla FTP client). This is my present setup and it is really neat! I also use a small chinese generic wireless keboard as pendant for all keyboard shortcuts (mentioned in readme.md). This makes life easier.

There is a known bug (I don't know if it is of webUI or firmware) where if a gcode file is running and you reload the webpage, the machine goes in "Idle" state with only spindle moving and all axis goes standstill. The webUI makes a new websocket connection upon refreshing the page but it should not change the state of machine. Can you throw some light on this?

[terjeio]

4. Where do you intend to have the app stored? If in the www folder of the SD-card then you can get the IP address used for opening it (from the document object?). Then there is no need to configure the app, and it can be opened by the IP address in the browser. The WebUI does that.

5. The stop command is a "soft" version of reset that does not reinitialize everything like reset does. E.g. homed status is preserved.

There is a known bug (I don't know if it is of webUI or firmware) where if a gcode file is running and you reload the webpage, the machine goes in "Idle" state with only spindle moving and all axis goes standstill. The webUI makes a new websocket connection upon refreshing the page but it should not change the state of machine. Can you throw some light on this?

I have made a workaround for handling this scenario that relies on the webui issuing an [ESP...] command, typicall requesting the firmware details - IIRC [ESP800] as a http request. I suggest you do the same. Note that this only works if a web client started the job initially - as a safety measure jobs are terminated if a new client takes over control. Note that you can only send real-time commands if a connection is restored and there is a job running.

If you add a bit more info in the main page of your repo I can link to it from the webui plugin. Intended target, hardware requirements, screenshots...

[karoria]

Hi Terje. Thanks a lot for multiple inputs. Please bear with me as I am up to intermediate level in html, css, js. I am a mechanical engineer by academics ;)
Trying to grasp your points. Following are my comments:

4. Where do you intend to have the app stored? If in the www folder of the SD-card then you can get the IP address used for opening it (from the document object?). Then there is no need to configure the app, and it can be opened by the IP address in the browser. The WebUI does that.

Yes, in www folder in SD root. I still don't understand, how I get IP of controller. I can only get IP of the client PC through document object AFAIK, as javascript actually runs there. Server part is enquired by websockets. Still, I will read more on this. If you use DHCP, then yes, you need to only enter the server IP which you know. Still, I will give it a thought to make it automatic.

5. The stop command is a "soft" version of reset that does not reinitialize everything like reset does. E.g. homed status is preserved.

Noted. So it is better option to stop a program in midway also. I hope it retains the position info without need of homing.

I have made a workaround for handling this scenario that relies on the webui issuing an [ESP...] command, typicall requesting the firmware details - IIRC [ESP800] as a http request. I suggest you do the same. Note that this only works if a web client started the job initially - as a safety measure jobs are terminated if a new client takes over control. Note that you can only send real-time commands if a connection is restored and there is a job running.

I think I can request firmware details like $I or $$ via websockets only. It is already working. I just don't show it in the console on the webpage. You can use console of dev tools to read the feedbacks from controller. You can enter commands like $$ in the MDI field itself and press the button besides it. The safety measure of terminating jobs when new client takes control is unnecessary as per me. Let 2 or 3 clients simultaneously send single character commands. GRBL itself has all the safety measures required. I request you to open up those strict settings so that such refresh events can't go wrong. My point is, there cannot be 2-3 clients sending gcode lines at a time, but they should be able to send all single character commands. If you feel, this is not good for mass, then please inform me the workaround, so that I can check this at my own risk.

If you add a bit more info in the main page of your repo I can link to it from the webui plugin. Intended target, hardware requirements, screenshots...

It is already added in my readme just a day after I informed you about the repo. Please visit the repo now.

[terjeio]

I still don't understand, how I get IP of controller.

This? document.location.host

I hope it retains the position info without need of homing.

I depends, if in motion then not - if not in motion then yes. Feed hold followed by Stop is your friend.

I think I can request firmware details like $I or $$ via websockets only. It is already working.

That will not work since the SD card "owns" the input stream. You have to send a http request with an ESP command before sending any requests on the websocket stream, IIRC it has to be sent before opening the websoket stream? The job running from the SD card will be terminated immediately otherwise.

The safety measure of terminating jobs when new client takes control is unnecessary as per me. Let 2 or 3 clients simultaneously send single character commands. GRBL itself has all the safety measures required.

grblHAL has the safety measures in place as there can only be one input stream in full control at any time. Other connected streams may send real time commands only. If a non-webui client connects it wants to be able to send commands, this is why I terminate the job and accept input from the sender. I am not in a position to change senders that would allow a job to be temporarily suspended and then resumed... I am all ears if you have a better idea of how to handle this.

I request you to open up those strict settings so that such refresh events can't go wrong.

I have done a bit of work in the websocket daemon code for this already, but it will still only accept one connection at a time. Allowing more than one will be tricky unless you allow intermingling of commands or limit it to real-time commands only. You can give it a try? I guess maintaining a linked list of active connections is the way to do it. And you have too keep track of the connection that owns full control, and perhaps also add some mechanism for delegating it if that connection is closed.

My point is, there cannot be 2-3 clients sending gcode lines at a time, but they should be able to send all single character commands.

This is acceptable, but still has to be coded for.

[karoria]

Noted. Still not convinced about the overly-safe procedures but I will play with the code. Can you just feedhold the machine, instead of reseting it while switching clients? I am considering a case where a 5 hour program has run for 3-4 hours and the page reloads and program stops there. It will be painful to get back right.

[terjeio]

Still not convinced about the overly-safe procedures

It is an intrinsic feature of the grblHAL stream handling and not coded for explicitly. It is possible to allow for real-time commands from more than one client and I use that for the MPG mode that some drivers supports. The websocket and telnet implementations can be expanded to support multiple clients. But what to do when the client in full control disconnects? Give full control to the second that connected? Inform it about it? Ask the clients for who wants to be in control? Leave none in full control and wait for one to (re)connect? ...?

Can you just feedhold the machine, instead of reseting it while switching clients?

Possibly, something for you to try?

I am considering a case where a 5 hour program has run for 3-4 hours and the page reloads and program stops there. It will be painful to get back right.

For web clients this is possible if you follow the procedure I outlined above. The WebUI with the grblHAL ESP32 driver even tolerates a network disconnect/reconnect. AFAIK neither is possible with the Grbl_ESP32 port...

[phil-barrett]

I downloaded it onto an android tablet but it does not look like what I see on the PC. I noticed it uses Java, maybe that is a problem for my tablet? (older Samsung Galaxy S2 running Android 7).

Also, how does GrblTouch connect to a Grbl board?

[karoria]

Still not convinced about the overly-safe procedures

It is an intrinsic feature of the grblHAL stream handling and not coded for explicitly. It is possible to allow for real-time commands from more than one client and I use that for the MPG mode that some drivers supports. The websocket and telnet implementations can be expanded to support multiple clients. But what to do when the client in full control disconnects? Give full control to the second that connected? Inform it about it? Ask the clients for who wants to be in control? Leave none in full control and wait for one to (re)connect? ...?

Can you just feedhold the machine, instead of reseting it while switching clients?

Possibly, something for you to try?

I am considering a case where a 5 hour program has run for 3-4 hours and the page reloads and program stops there. It will be painful to get back right.

For web clients this is possible if you follow the procedure I outlined above. The WebUI with the grblHAL ESP32 driver even tolerates a network disconnect/reconnect. AFAIK neither is possible with the Grbl_ESP32 port...

Will you please help me to make that code to feedhold instead of reset?
For your other suggestions, I will look at it.

[karoria]

I downloaded it onto an android tablet but it does not look like what I see on the PC. I noticed it uses Java, maybe that is a problem for my tablet? (older Samsung Galaxy S2 running Android 7).

Also, how does GrblTouch connect to a Grbl board?

Hi Phil, thanks for onboarding. This is a webUI. It (www folder) should be copied to the sd card mounted with grblHAL controller PCB, after some basic modification of initial settings in app.js. Then you have to type its IP Aaddress in any web browser in a LAN connected pc/mobile/tablet. THE UI should open in the browser itself. So it hosts a webserver from sd card itself. Your client has to connect via IP address only.
The connection uses websockets to connect to grblHAL.

[terjeio]

Will you please help me to make that code to feedhold instead of reset?

Going into feedhold is, I believe, easy, replace this line with
system_set_exec_state_flag(EXEC_FEED_HOLD);

To get back to streaming from the SD card you have to trap cycle start like I do in the tool change code and then restore the neccesary pointers to read from the SD card when the cycle start is trapped. Then you will have to check how senders handle a connection when a feed hold is active... And perhaps trapping and acting upon a cycle start from the control signal input is a bad idea? It should be blocked?

[karoria]

Thanks Terje. Will give it a try when I am free.

[karoria]

I downloaded it onto an android tablet but it does not look like what I see on the PC. I noticed it uses Java, maybe that is a problem for my tablet? (older Samsung Galaxy S2 running Android 7).

Also, how does GrblTouch connect to a Grbl board?

Hi Phil, thanks for onboarding. This is a webUI. It (www folder) should be copied to the sd card mounted with grblHAL controller PCB, after some basic modification of initial settings in app.js. Then you have to type its IP Aaddress in any web browser in a LAN connected pc/mobile/tablet. THE UI should open in the browser itself. So it hosts a webserver from sd card itself. Your client has to connect via IP address only.
The connection uses websockets to connect to grblHAL.

Hi @phil-barrett,
Have you got it working?

[karoria]

For grblHAL it would perhaps be nice if you add a Stop button that sends the stop command 0x19, this is not as harsh as a reset.

@terjeio I have tried 0x19 stop command in my new update but came to know that it doesn't stop spindle. So, in short, I can't use it to stop the program. Is this normal? or I am missing something?

[terjeio]

or I am missing something?

I fixed a regression where the spindle was not stopped on 0x19 in late january, which build are you using?

[karoria]

or I am missing something?

I fixed a regression where the spindle was not stopped on 0x19 in late january, which build are you using?

Thanks for reply. I am sure my build is older than january. Will update it.

[karoria]

This? document.location.host

Hi @terje, document.location.host works. Thanks for your valuable input. So in my next release, there will no need to configure ip inside app.js file.

[karoria]

Hi @terjeio @phil-barrett

I have just released a major update for grblTouch. Following are the improvements:

1. calculator is added and activated by touching/clicking on work coordinate. It has some nice buttons to make work zero easy.
2. Folders/directories in files on SD card are not supported. They will be highlighted in yellow in files table on RUN tab.
3. Necessary accessory states are displayed.
4. Necessary pin states are displayed.
5. Some improvements in keyboard shortcuts.
6. Program line number is displayed if it is set to on in the firmware.
7. Program run time is displayed.
8. SD memory details are shown at the bottom of files table.

I am running my webUI for production use, so it is extensively tested for teensy4.1 driver. Now I can say, it is full fledged UI and nothing else is required if you use it with raspberry pi with 7 inch touch screen. Startup scripts for starting chromium browser in kiosk mode can be used so that when the machine starts, it displays UI in full screen. Chinese cheap mini keyboards are a great companion to this UI as a wireless pendant.

I welcome any suggestions from your side. Use of "stop" command instead of "reset" will be done after some time, as my machines are having old firmware now. When I will find time, I will change both firmware and software UI.

Here is the link to repo for your ready reference https://github.com/karoria/grblTouch.

Waiting for your valuable feedbacks.

Cheers,
Ravi