I used pyinstaller to create a linux executable that can be downloaded, gunzip’ed, made executable, and run (see the link). I built it in the cloud because I don’t have a linux box handy and I can’t readily test it. It does start up and spew the standard stuff to the console window, so I’m at least 80% confident it’s working. Please let me know how it goes if you give it a try.
4 Likes
Running on Linux would be great!
So far, I’ve tested on Raspbian Stretch and ended with the error:
./webcontrol: cannot execute binary file: Exec format error
When I tested on Linux Mint 19.2 in a VM, it ran but the G-Code, Actions, Settings, Boards sub-menus showed but nothing happens when one is selected.
Ok… thanks… I’m not surprised about the rpi not working… I’ll work on it.
Hmm… well, I can access the web interface and settings, actions, etc. all seem to work. Do you see any errors in the terminal when you try to access it?
I would expect that this is CPU type dependent, so the linux version will run on
any x86 system, but not an ARM system like a Pi
the original WebControl is Python, and you can probably run the docker image
that was made for the Pi on a x86, but the way he’s converting it to a package
is probably introducing the CPU dependency
David Lang
Me either, but ‘planting the seed…’
There’s an exception, here’s the contents of the terminal screen.
WebControl-linux-Mint-log.txt (1.5 KB)
I’ve poked at getting a macos version going with pyinstaller, but suspect that the pathex strings and hiddenimports in main.spec will need to be adapted. Would you share your Linux main.spec for me to learn from?
I see the problem… I didn’t bring the firmware over and it’s choking on the same spot again.
I don’t know if using pyinstaller to create the application is the best, but the build process worked right away (didn’t have to change anything from the Win10 spec file). Is there a ‘better’ way?
I updated it. Just redownload the file (I didn’t make a new release) and let me know if it works. Thanks
1 Like
The change removes the exceptions, but the issue remains. Looking further, remote sessions work correctly, rendering the board and the sled cursor. Clicking one of the menus on the local session opens the expected result on the remote session. The local webpage jog controls work, but that’s all. The local browser is Firefox 69.0, the remote browsers Safari and Firefox.
I need clarification.
So that’s good…
So selecting Actions on local brings up the actions modal on the remotes… correct? If so, that’s good.
Are you saying only the local jog controls work (i.e., no remote jog controls work) or that the only thing that works on the local is the jog controls and the menus, etc. don’t work?
Sorry for the confusion, the only thing that works on the local is the jog controls and the menus, etc. don’t work.
wow… that’s weird… so, on local, when you click Actions, it doesn’t appear on the local but does appear on the remote?
1 Like
That’s right - ‘spooky action at a distance’? 
Well, the ‘spooky action’ was expected (it’s designed to do that)… but I also expected local action as well.
I loaded my copy of Firefox 69 (windows 10 though) and can access the linux-based webcontrol (running in the AWS cloud). Can you possibly press ctrl-shift-i and see if there are any errors reported on the screen? If not, maybe I can get a desktop gui running on the cloud server.
There’s an issue with the 3D renderer that’s causing firefox to choke on linux. I’ll look into it more. Were the ‘remotes’ running inside VMs as well? Wonder if its a VM issue.
I think this is a VM issue the more I dig into it.
This is the ‘Errors’ pane from the ctrl-shift-I console:
WebControl-linux-Mint-Firefox-java-errors.txt (3.2 KB)
FWIW I’ve stood up Fedora and Centos VMs
No, the remotes were in regular desktop OS.
Just tried browsing from the Mint VM to a WebControl-v0.903 instance running from a WIN10 desktop machine. The Mint browser 's jog controls work and the menu choices from Mint appear on both WIN10 and Mint. The Mint browser doesn’t render the board or sled curso, but it does display the sled position and Controller Messages…
I’m pretty sure it’s a webgl issue with running inside a VM… there’s no hardware acceleration in VMs usually, so webgl may not work. There may be a way to configure software-based rendering in a VM, but performance will suffer… so the 3d view may not work well.
You probably right, browsing to a Docker/WebMCP instance from the VM has the same display issue.