This might be a stupid question (and if it is, please tell me why so I can learn) but does a computer always have to be connected to the Blackbox X32 to keep a job running. My setup: Blackbox X32 connected to via wifi from a laptop Send gcode to CONTROL Start job Disconnect laptop and job stops Is this normal or is there a setting to enable the job to be hosted/saved/cached on the X32?
Yes, thats normal. Control sends the code line by line to the X32. If you dont want to use a computer, look at the Interface: INTERFACE CNC Touch It will run your code from a usb drive.
it is also possible to run a job from the X32's builtin web interface though I don't know if it will continue running if you disconnect from the web interface. I don't have one here with me so I will try to remember to give some instructions later from home.
I've had a play with the Web UI and and SD card and it looks like the job will not continue when the web browser is closed
Odd - it should continue, and even tolerate a network disconnect/reconnect. However, if there is any commands sent from a different connection (not the WebUI) the job will be terminated.
I possibly did have CONTROL open on my computer after I started the job in the Web UI. Would CONTROL have sent anything or interferred with the job even if I didn't use any of the controls in the app?
Yes. I did some bench testing today (no motors connected) and it does seem to continue. I even restarted my computer. The only issues I saw was when I connected Control and when trying to access from a different browser. The second browser didnt interrupt the running job, but there also wasnt any indication that there was a job already running. Obviously that's fine and didnt expect for it to work. Was just curious and thought I'd mention it.
OK, going to test some more then. If I start the job in the Web UI, close that tab and then re-open the Web UI using the same browser - will it reconnect to the job and show the status?
At least WebUI v3 should, even in a different browser tab/window. Opening a new tab/window while one is currently connected should disconnect it. IIRC the v2 backend does not support this.
Our included firmware haven't gone to V3 (yet!) will do soon. Web Builder's builds set to V3 doesn't load up web interface. Haven't looked into it too deeply yet.
tip, set your router to always give your BB the same IP address, then it is easy to store a bookmark for it. otherwize you have to mess about figuring what got assigned this time, easy enough with control since the ip is displayed when it connects terminal displays [07:21:07] [ $I ] [WIFI MAC:3C:61:05:11:94:F8] [07:21:07] [ $I ] [IP:192.168.1.90] personally i dont like to be any further than arms reach from the machine when starting a job, that emergency stop button got wired in for good reasons (-:
It should load the maintenance page from where you install the WebUI proper. It does not? More info here - note that it is not entirely up to date...
Will recheck, couldn't load up the maintenance page. But for us as a company that extra upload step is a pain. V2 was included inside the binary - flash and go. Instead its flash,get it on network, access maintenence page (out of band from current serial or telnet connection), upload index.htm.gz, etc. CONTROL and OpenBuilds has a very strong ethos to Ease things for users. Firmware update should be a one shot deal. New machine provision as simple as select machine from list. Simple and easy to use. So CONTROL needs to do everything for the user. Loving the things like homing masks ($44/45) vs recompile for example, our 2 axes machine profile can set that with ease. But integrating V3 so it can be used without additional steps that would be much needed. As is i'd have to set one up perfectly, dump the ESP and use that as an image in our flashing tool to have it all ready to go
OK so did a quick check. Just to get back to you on it: Web Builder > Set Network Tab > WebUI to "v3" Ticked on Telnet server. WebSocket and HTTP was already ticked. (CONTROL uses Telnet) Set Y Ganged (our default motor config) and Generated binary. Flashed onto BlackBox (Standard ESP32) Connected, setup wifi SSID and AP > Reset (While I have it here, we seem to need a reset before it connects?) It came up: Code: [16:43:21] [ ] ets Jun 8 2016 00:22:57 [16:43:21] [ ] rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) [16:43:21] [ ] configsip: 0, SPIWP:0xee [16:43:21] [ ] clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 [16:43:21] [ ] mode:DIO, clock div:2 [16:43:21] [ ] load:0x3fff0030,len:1184 [16:43:21] [ ] load:0x40078000,len:12784 [16:43:21] [ ] load:0x40080400,len:3040 [16:43:21] [ ] entry 0x400805e4 [16:43:22] [ ] [MSG:Warning: Failed to initialize SD card] [16:43:22] [ ] [MSG:Warning: Failed to initialize SD card] [16:43:22] [ ] GrblHAL 1.1f ['$' or '$HELP' for help] [16:43:23] [ ] [MSG:WIFI STA ACTIVE, IP=192.168.0.69] [16:43:32] [ ] [MSG:WIFI AP SCAN COMPLETED] Both IP and IP/?forcefallback=yes results in 404
Running the WebUI without a SD card mounted is not meaningful. However, it should not result in the 404. While checking around I found a "bug" in the CMakeLists.txt that causes Web Builder builds to not mount the embedded file system, resulting in the 404. I'll fix this and post here when done, hopefully this will help. A workaround is to create a www directory in the root of the SD card and copy the WebUI index.html.gz file to that. FYI index.html.gz is first searched for on the SD card, then the writable file system in flash (littlefs) and finally in the read-only embedded file system in flash. Yes. There are a number of settings that requires a hard reset. When such settings are changed in the WebUI you will be prompted to restart. In the next core version I will include a 0/1 flag in the settings enumeration ($ES response) that can be used by senders to prompt for or suggest a reboot.
Just a test bed so yes didn't insert an SD for our use case we'd prefer shipping V3 preinstalled (flash or littlefs) The less we have to let users prep (like prepping SD card) the better. Out of box experience. Still good for users who wants to play around / customize etc Yay! Of course thats the one we really want, no extra upload steps needed if Web Builder could include it already. Existing firmware tools keeps working, we just release updated images after testing Thanks for your time and looking into this! .
I have now updated the CMakeLists.txt used by the Web Builder, I'll commit the change to github when the fix is verified. To preinstall ythe WebUI replace embedded/index.html.gz with the version you want and recompile. Note that this will disable the maintenance tool so updates will not be as easy. Preinstalling the WebUI in littlefs might be possible but I do not know how to do that - perhaps by ripping the littlefs data from a running firmware and load it into the storage partition?
Yes, dumping it out is quite possible. Not a bad approach actually, and good point on keeping the maintenance tool. Making it a better midway option between flash and SD. Doesn't change very often either so the extra bit of manual work to extract it wouldn't hurt too much either. Good ideas thanks!
Confirmed that fixed the issue, littlefs mounts, maintenance page loads up as expected, upload of index.html.gz ran without a hitch and V3 web interface is up and running Thanks!
