laserweb / lw.comm-server Goto Github PK

Z work offset keep incrementing by 10mm every time a homing is performed.

Hello,

I was wondering if anyone could share any examples or tutorials for using Laserweb's API since documentation is pretty scarce?

I'm hoping to be able to connect to the server with python, but I am open to other languages.

Electron_bundler branch is way past master. Can they amend? @cprezzi

I'm comming to the point where I need to integrate lw.comm-server into LW4 and need some help how to start. I still have no clue how the react/Redux stuff works. Especially where I have to place my Code and how to access the gcode or save/lose Settings.

@openhardwarecoza, @tbfleming : can one of you give me a Quickstart?

I am working on another frontend where I intend using lw.comms-server as well.

In this frontend, I want to obtain the Smoothie config file and then parse it.
In my old project CoPrint, i used (which should not be used) MSD to access the Config file from SD over nodejs-fs: See https://github.com/openhardwarecoza/CoPrint/blob/9b602c256c2fab10158bd9033d4c14ab33bbdccc/server-smoothie.js#L192-L205

Of course that being the wrong way, i am now trying to do the same over Serial. using Smoothie command 'cat /sd/config' works beautifully, but instead of getting the file as a whole, i am getting each line as a seperate event. This makes parsing it much harder

I almost have to do

if ( data.indexOf('alpha_steps_per_mm') === 0 || data.indexOf('beta_steps_per_mm') === 0 || data.indexOf('gamma_steps_per_mm') === 0 || data.indexOf('x_axis_max_speed') === 0 || data.indexOf('y_axis_max_speed') === 0 || data.indexOf('z_axis_max_speed') === 0 || data.indexOf('acceleration') === 0 || data.indexOf('z_acceleration') === 0 || data.indexOf('endstops_enable') === 0) {...}

for each value i want to work with... yikes.

@cprezzi any ideas how I can go about reading the file using 'cat' and get it in ONE event?

Hi @cprezzi
Could we add ARP network discovery to the server? I've been asked by @DouglasPearless (a DarklyLabs developer) to check candidate machines on local network. I've suggested https://github.com/TheThingSystem/node-arp-a so we can send that addresses to frontend via server like USB devices are done.

Branching off from #2 (comment)

Hi,

I've run on a somewhat serious issue due the folder App being far away current version (8 months!)
I've been refactoring the binaries build chain, decoupling lw.comm-server from electron (at least for WIN and OSX, cannot get LNX working on multiple travis file)
Then the version bundled was way back because nstatic was serving the inner lw.comm-server app instead the new UI (I've patched the APP using travis and overriding the folder with the newer)

I would suggest to not to include APP on the comms, but make a build script to download and compile first time if folder does not exist (for users not using the bundled version)
For example using travis to automatically build the app folder and being able to download from Github Laserweb4 Releases (not binaries, just LW4 containing the app.zip)

Also, I would like to have the option to not to run nstatic or be able to change the path where is served, the builder can choose another app folder. That could lead to having an UI updater without changing nor the builder nor the server.

@cprezzi, @tbfleming

Please test TinyG and discuss issues here!

I am running the comms server from a Raspberry Pi and home made Arduino stepper shield. When LW connects to the serial port the Arduino does not restart and give the GRBL FW version which is how most program ID the firmware.

How does the comms server ID the firmware?

Morning

I integrated Electron-Builder into lw.comms-server itself

1. Basically, I copy laserweb4/dist to app/lw4 (we can later remove your test/app and replace it with lw4's html)

2. I created a ./build/ directory to contain the icons/bg (hardcoded paths/filenames which electron expects to be what they are: http://electron.rocks/electron-builder-explained/)

3. Then in server.js at the very bottom we handle the electron gui

4. Lastly, in package.json I added two more scripts, and the build{} json for Electron-builder

I tested briefly and it didnt seem to break your normal workflows (lw4 start-all, and standalone lw.comm-server)

I also tested the built electron app and comms seem to be running.

electron-userland/electron-builder#974 used to be an issue, but as of this build its no longer an issue. I suspect the bug got fixed somewhere in one of the dependencies and now just work (: Yay

Looking at the files in app/, it looks as if they have been generated from some other files - if yes, where is the actual source code?

@jonbev

Okay, so, the way we currently build LW4 binaries with Electron-builder is:

1. This repo (lw.comm-server) has a branch, Electron_bundler, that has a couple simple npm scripts in package.json

See https://github.com/LaserWeb/lw.comm-server/blob/electron_bundler/package.json#L40-L51

The manual instructions are on https://github.com/LaserWeb/lw.comm-server/blob/electron_bundler/README-ELECTRON.md

(Might be worthwhile doing a manual build on your machine to familiarise yourself)

Once the manual run works on a machine, if you have push permissions to the LaserWeb repos (you do now (: ) - then its as simple as running 'npm run nightlylinux' on the linux box, and 'npm run nightlywindows' on a windows box. Note I use git-scm which comes with bash - so it might not work in windows cmd. I use https://git-scm.com/downloads - once installed it adds a Open Git Bash context menu to all folders. I use that as my primary CLI interface for everything on windows lol)

2. The process also gets the /dist/ built fresh from the LaserWeb4 repo - the readme tells the whole story:
   (pull LaserWeb4, run npm run bundle-dev to let Webpack build the /dist/, then copy that /dist/'s content to lw.comms-server(Electron_bundler branch)'s /app

Dropdown behind input

Splitting off from #2 to encourage some more creative thinking without depending on firmware changes

Just wanted to log a place for install steps for Armbian 3.4.113 for lw.comm-server

Edit hosts - to add device ip address before localhost
sudo nano /etc/hosts
replace 127.0.0.1 with IP_address of device
save

Clone Git
sudo git clone https://github.com/LaserWeb/lw.comm-server.git
cd lw.comm.server

Copy over missing files after clone to lw.comm-server folder
config.js, firmwareFeatures.js, grblStrings.js, lw.comm-server.service, server.js, package.json

Install dependencies first
sudo npm install electron mime-lookup mime-db --unsafe-perm --build-from-source
sudo npm install serialport debug dotenv ajv-keywords 7zip-bin --unsafe-perm --build-from-source
npm install

Got this far and server loads but unable to connect to it from web interface.

    ---- LaserWeb Comm Server 4.0.115 ----

Use http://192.168.0.103:8000 to connect this server.

• Updates:
  Remember to check the commit log on
  https://github.com/LaserWeb/lw.comm-server/commits/master
  regularly, to know about updates and fixes, and then when ready
  update accordingly by running git pull

• Support:
  If you need help / support, come over to
  https://plus.google.com/communities/115879488566665599508

hope i'm almost there.

I did my best to get as much info as a can this error happens with node v6~8
at first i was getting stopped by serialport missing problem build rebuilding it before running install worked for that now just getting build run problems
laserweb is nice but the only platform that I want to run it on is a pi inside my K40

electron_bundle error.txt
electron_bundle NPM log.txt

Set Zero produces error:undefined. It looks like there are 3 bugs involved.

1. Funny characters in addQ()
2. Stock grbl doesn't understand A0
3. Error replies from grbl get mangled

I'm thinking of dumping clipperjs and switching entirely to boost.polygon to help solve performance issues. This will probably have the biggest impact if I also switch from asm.js to Wasm. Electron 1.6.x (current release) is based off Chrome 56, which doesn't support it. Electron 1.7.x beta is based off Chrome 58, which does.

sudo apt-get install --no-install-recommends -y icnsutils graphicsmagick xz-utils

is required before npm run dist for a successful build on Linux.

As Per: wiki/Multi-Platform-Build

@tbfleming For the check size function in the jog tab I need the bounds of the actual gcode.
Can I use your get-bounds.js for this? If yes, how do I have to use it?

This would be the server part of LaserWeb/LaserWeb4#49

A way for the UI to store and retrieve settings from the server. This way the user could easily set up different clients because the settings would already be available on the server that it connects to.

PS: Personally I'd be more than happy if this was a just a single "save slot", I myself don't have any use for multiple sets of machine profiles and settings on a single server, but perhaps others do?

@cprezzi @openhardwarecoza I have been able to successfully compile the windows exe following the process outlined, but the latest LW4 features from dev-es6 do not come through.

I also tried checking out dev-es6. as opposed to dev-comms and performing an electron compile, but this also does not bring across the latest LW4 fixes etc.

I notice we are up to 4042 for lw.comm-server but the electron_bundler branch shows 4036.

Any help to get this compiled would be much appreciated.

Just did Home Z 😢

C3D with SmoothieWare CNC latest version

trying to install on a raspberry pi like soc (odroid xu4) running ArchLinux causes some build fails because serialport 4.0.7 is outdated.

is it possible to update the implementation of serialport to 6.x.x so I can unignore node?

Similar to what is present in LW3.
Perform scan to find the IP address of all instances of a wifi-enabled smoothie/grbl device on the network.

We have some users with multiple machines and finding all instances of a smoothie firmware is important.

Hi. I've observed some growing differences on electron_bundler and master. I've patched electron_bundler but if you could, please take a look to try to ammend branches, or we have to find a new configuration pattern to binaries.

firmwareFeatures.js is not added in the dockerfile, this causes the app not to start.

change to Dockerfile:3

ADD config.js firmwareFeatures.js grblStrings.js LICENSE lw.comm-server.service package.json README.md server.js version.txt /laserweb/

Also npm start doesnt seem to work and is actually not even used in the systemd unit.

change to docker_entrypoint.sh:5

nice -n -20 node server.js

Also it would be good to have some info on how to build and run the docker image in the wiki. Just some stuff like using --cap-add=SYS_NICE and --device=/dev/ttyUSB0

Upon issueing the "reset" command, it will always happen that Smoothieware closes the port (since its USB stack is in software, not like with Grbl where mostly its on a seperate ftdi/ch340/silabs). However, now a) LW keeps trying to talk to the port, and b) sometimes keeps the port open in windows so the subsequent re-enumeration fails.

In this case, we now need to switch to comms tab, disconnect, then manually replug the USB to get enumeration after reset to work.

Resetting from software is convenient during that initial machine setup / after certain console commands

We can extend this functionality to a proper "reset" ws-event if you like? Then we can have:

• A 'reset controller' button on comms tab, just like pronterface has always had
• switch case to handle firmware differences
  ('reset' for smoothie + disconnect port immediately after sending (or after receiving "Smoothie out. Peace. Rebooting in 5 seconds")
  (ctrl+x (ascii \030 aka port.write("\030") for grbl and tiny)

If it detects Grbl, but the version is too old, please let it log the error accordingly, something like "You are running Grbl 0.9 (Show actual version string) : This application needs at least Grbl 1.1. Please update the version of Grbl on your controller, then try again" or something like that? Right now if you connect to Grbl0.9 it just closes the port (so you have to use putty or something like that to check what version is actually installed, after taking a minute to realise thats why it closed it)

Not exactly sure when or why this happens, too random to put a finger on it yet. But has always been an issue for me:

1. Sometimes randomly machine disconnects (I'll blame Smoothieboard's known usb noise issues for that)
2. Reconnect: machine is not moving because smoothie was reset, but i think LW queue is "active" just waiting for an OK back
3. As is usually after a fuckup like loosing comms to your machine, your first action tends to need a jog: so you hit jog to start moving.
4. And viola lw.comm-server resumes sending the queue when it gets the OK back from the Jog commands (or i think thats why) and starts running. Endmills break, curses are uttered and days are ruined

@cprezzi @jorgerobles @openhardwarecoza
I am unable to build LW today following the normal process.
It appears there is an error that now occurs during the lw.com-server build at the command:
./node_modules/.bin/electron-rebuild

I created fresh clones and ran the complete build process.

Can anyone verify the builds are currently working and if so, what could be causing this for me. I am building on mac.

Run http://smoothieware.org/console-commands#config-get for the laser_module parameter (if true, its a laser) also could probably check for extruders if found, is a 3d Printer. Check for a Spindle config, its a mill... etc

On Grbl we can check for Laser Mode (if found its a laser. If not its a mill)

Then in the frontend (@jorgerobles) we can hide laser ops and "laser test" etc and any other instance of "laser" if its not a laser

Minor possibility, but stupid example (testing by thinking like a user)

1. If i connect to say com1 (onboard serial port - nothing connected) - we actually report "Machine connected" - which is not true (: . Port was opened yes, but machine did not connect

2. In lw3 I differentiated between "Port Openend" and "Port connected" - but that wasnt good enough either, the description was too similar to really indicate that there is a difference between a port opening, and a port actually connected (ie talking, getting replies back that we expect)

Hi,

I've got a report from github about a package named hoek to be upgraded. https://github.com/LaserWeb/LaserWeb4/network/dependencies
That package goes inside serialport.

First draft of the communications design (by Peter van der Walt):

websocket -> listSD -> runs a http://smoothieware.org/console-commands#ls, (try and get results recursively? even if it means manually going deeper) -> Returns ws event to frontend with array of files.

Frontends displays list of files with a PLAY button
Play button sends ws event to lw.comm-server: to http://smoothieware.org/console-commands#play

On plastic materials, I have better results using Laser Raster mode than I do with Laser Fill Path. This is because Laser Raster mode starts at the bottom and scans up the image line-by-line in one pass. Laser Fill Path does not behave this way; instead, it fills areas piece by piece. This causes lines to appear at the junctions of the various "start" and "stop" points, because the material has cooled while other areas are engraved.

I'd love an option within Laser Fill Path that makes it behave more like Raster mode - start at the bottom and scan to the top in one pass.

@cprezzi Sorry for being so vague. Was doing a cut with latest github source, and suddenly lw.comm-server stopped working, throwing an error related gcode length (I closed accidentally the log)
The problem is not arised with the latest binary release. :/

Is is possible to inject macros into the serial stream server side?

I will be running the comm server on a Raspberry Pi and would like to use the OSMC remote to jog around (using macros) and as the abort, feed hold, start buttons.

As LaserWeb/LaserWeb4#369 @gerwinbrunner

@cprezzi I've tested patch on electron_bundler
At https://github.com/LaserWeb/lw.comm-server/blob/electron_bundler/server.js#L2843

logFile = fs.createWriteStream(path.join(electronApp.getPath('userData'),"logfile.log"));

I've no commited this, as don't know if thas to be other considerations about branches master & electron

Once compiled to exe we dont have stdout logging anymore...

As of [email protected] we now have custom buadrate support for linux. This will allow buadrates on linux of 250k and maybe even ones that are faster. I'd love if people here could give it a try and let me know if it work for them. I'm most curious about all the flavors of linux that run on embedded devices.

This would also solve some of the windows issues your windows users are undoubtedly having and some memory leaks on linux and OS X.

To prevent conflict if the port is already in use by another server.
I had LW app running on one user and then loaded the app again from another user on the same machine issued the error but clicking on it did load the app. Maybe at this point or somewhere in the setting have tje option to change the port

Splitting off from #2 - to avoid the discussion drowning in that one

1. I have a rather urgent need to work on this for a non-LW application too
2. This task falls under my new dayjob at OpenBuilds - which means I will have about a week to work on this uninterrupted. Yay
3. If I work on this I may be able to take some of the stress of the other team members

So... Off to start thinking about this. Now that we have comms in the backend for ESP I am considering replacing websocket with a telnet implementation instead. That has proved to work well in a benchtest earlier this week.

Open to thoughts though @cprezzi @DarklyLabs

Pitfalls

I am aware of the conns that we cant then just host LW somewhere and connect to an ESP on the LAN.

But as time has gone on, I honestly believe LW will be only an Electron app. Thats definitely the way to go for distribution, update, code signing, and all the other things we have to think about (speaking of code signing - https://mspoweruser.com/microsoft-just-added-the-best-way-of-preventing-installation-of-bloatware-in-windows-10/ is a particularly worrying thing. We may need to start signing with Authenticode and just get into the windows store if thats where its heading in the future). It also solves some of the cross platform issues. Its not like one can run a laser shop without at least one PC in the shop.... So I dont think ending up with a solution that requires the application to be installed somewhere, is a big issue. server.js can even be run on a SBC (Pi) without the GUI if thats needed

Hello!

I´m trying to install the lw.comm-server on my RPi 3B but are having some issues.

When following the guide on the Git page for manual install (

https://github.com/LaserWeb/lw.comm-server/wiki/Manual-Installation-(RasPi)

I get the following issues:

**Issue #1 **
when installing Node 6.x I do not get the most up to date npm version.
The version I get is v1.4.21, and that is far to old as stated in the guide.
I found the solution for this I think on the following page:

https://stackoverflow.com/questions/44095985/why-can-i-only-install-an-outdated-version-of-npm-on-debian-ubuntu

So I started with a fresh copy of the Rasbian 4.14.50-v7+ again and this time issued the command:

curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash -
sudo apt-get install -y nodejs

This worked and the current version installed is:
pi@LaserWeb:~ $ npm -v
5.6.0
pi@LaserWeb:~ $ node -v
v8.11.4

All good for now right?

Well, lets see Issue #2:

Issue #2.

Git cloning the lw.comm-server.git was no problem, but what comes after is a problem i think:

cd /home/pi
git clone https://github.com/LaserWeb/lw.comm-server.git
cd lw.comm-server
npm install

npm WARN deprecated [email protected]: The major version is no longer supported. Please update to 4.x or newer
npm WARN notice [SECURITY] debug has the following vulnerability: 1 low. Go here for more details: https://nodesecurity.io/advisories?
search=debug&version=2.3.3 - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.
npm WARN notice [SECURITY] debug has the following vulnerability: 1 low. Go here for more details: https://nodesecurity.io/advisories?search=debug&version=2.2.0 - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.
npm WARN notice [SECURITY] debug has the following vulnerability: 1 low. Go here for more details: https://nodesecurity.io/advisories?search=debug&version=2.3.3 - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.
npm WARN notice [SECURITY] debug has the following vulnerability: 1 low. Go here for more details: https://nodesecurity.io/advisories?search=debug&version=2.3.3 - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.
npm WARN notice [SECURITY] parsejson has the following vulnerability: 1 high. Go here for more details: https://nodesecurity.io/advisories?search=parsejson&version=0.0.3 - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.
npm WARN notice [SECURITY] tunnel-agent has the following vulnerability: 1 moderate. Go here for more details: https://nodesecurity.io/advisories?search=tunnel-agent&version=0.4.3 - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.
npm WARN notice [SECURITY] debug has the following vulnerability: 1 low. Go here for more details: https://nodesecurity.io/advisories?search=debug&version=2.6.1 - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.
npm WARN notice [SECURITY] debug has the following vulnerability: 1 low. Go here for more details: https://nodesecurity.io/advisories?search=debug&version=2.6.1 - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.

> [email protected] install /home/pi/lw.comm-server/node_modules/serialport
> node-pre-gyp install --fallback-to-build

node-pre-gyp info it worked if it ends with ok
node-pre-gyp verb cli [ '/usr/bin/node',
node-pre-gyp verb cli   '/home/pi/lw.comm-server/node_modules/serialport/node_modules/.bin/node-pre-gyp',
node-pre-gyp verb cli   'install',
node-pre-gyp verb cli   '--fallback-to-build' ]
node-pre-gyp info using [email protected]
node-pre-gyp info using [email protected] | linux | arm
node-pre-gyp verb command install []
node-pre-gyp info check checked for "/home/pi/lw.comm-

server/node_modules/serialport/build/Release/serialport.node" (not found)
node-pre-gyp http GET https://github.com/EmergingTechnologyAdvisors/node-serialport/releases/download/4.0.7/serialport-v4.0.7-node-v57-linux-arm.tar.gz
node-pre-gyp http 404 https://github.com/EmergingTechnologyAdvisors/node-serialport/releases/download/4.0.7/serialport-v4.0.7-node-v57-linux-arm.tar.gz
node-pre-gyp ERR! Tried to download(404): https://github.com/EmergingTechnologyAdvisors/node-serialport/releases/download/4.0.7/serialport-v4.0.7-node-v57-linux-arm.tar.gz 
node-pre-gyp ERR! Pre-built binaries not found for [email protected] and [email protected] (node-v57 ABI) (falling back to source compile with node-gyp) 
node-pre-gyp http 404 status code downloading 
tarballhttps://github.com/EmergingTechnologyAdvisors/node-serialport/releases/download/4.0.7/serialport-v4.0.7-node-v57-linux-arm.tar.gz
 
node-pre-gyp verb command build [ 'rebuild' ]
make: Entering directory '/home/pi/lw.comm-server/node_modules/serialport/build'
  CXX(target) Release/obj.target/serialport/src/serialport.o
../src/serialport.cpp: In function 'int getIntFromObject(v8::Local<v8::Object>, std::__cxx11::string':
../src/serialport.cpp:90:52: warning: 'v8::Local<v8::Int32> v8::Value::ToInt32() const' is deprecated: Use maybe version [-Wdeprecated-declarations]
   return getValueFromObject(options, key)>ToInt32()>Int32Value();

So, it cannot install the serial port since the git does not exist.

Any ideas?
I´ve tried to install mulitiple times with a fresh rasbian image, but with no luck.
Starting to lose my mind/patience.

Thanks in advance.

Motivated by https://plus.google.com/107113996668310536492/posts/4Y41g21bByK

In LW3 we had https://github.com/LaserWeb/LaserWeb3/blob/master/server.js#L506 and https://github.com/LaserWeb/LaserWeb3/blob/master/public/js/socketcomms.js#L120-L124 and https://github.com/LaserWeb/LaserWeb3/blob/master/public/index.html#L72

(:

But seeing as we are continually evolving (: - so I am wondering about future enhancement:

https://www.npmjs.com/package/usb-detection + event to say "new device detected"

Users often plug/unplug after starting the application

Quite regularly we get users who are trying to run two lw4 instances, or for example have lw3 open, then run lw4.

CMD and Electron both popup a generic EADDRINUSE error. Wondering if its possible for us to catch the error and rather print our own error message explaining to the user that an instance thats already open needs to be closed or something to that effect

1. Connect to Smoothie
2. Start a Job
3. Click the Feedrate Overides
   3.1) Get pissed at 1% being too small an increment (make it +10% please - practically speaking i cant see why anyone would do 1% increments during a job. When shit starts chattering you want to adjust the feed FAST! you dont have time for hundreds of clicks. ) )
   3.2) Lose connection to your machine because of the overlapped write, break endmill, ruin material. Realise its last material you had on hand. fuck

I briefly mentioned this to @cprezzi and he mentioned @tbfleming might anyway be revamping this for his new UI work, but i figured let me write up what i kinda need (using lw.comms-server in another frontend more config orientated) and see what you guys think before i forge ahead with my needs and this never makes it into lw.comm-server (;

Right now - my old legacy way of doing that has stuck inside lw for too long, has been to send individual websocket events for position, queuecnt, etc - very inefficient. in the frontend we have to listen for various named ws events...

I propose we convert to a single object that gets sent over as a single websocket event. Data binding to a single object and then just updating UI when a key changes is more efficient and easier to debug:

Here's what i have so far

var statusjson = {
  machine: {
    overrides: {
      feedOverride: 0,
      spindleOverride: 0
    },
    position: {
      work: {
        xWpos: 0,
        yWpos: 0,
        zWpos: 0,
        aWpos: 0,
        eWpos: 0,
      },
      machine: {
        xMpos: 0,
        yMpos: 0,
        zMpos: 0,
        aMpos: 0,
        eMpos: 0
      }

    },
    temperature: {
      t1temp: 0,
      t2temp: 0,
      bedtemp: 0,
    },
    firmware: {
      type: "",
      version: "",
      date: ""
    },
    configuration: {
      x_steps_per_mm: 0,
      y_steps_per_mm: 0,
      z_steps_per_mm: 0,
      x_acceleration: 0,
      y_acceleration: 0,
      z_acceleration: 0,
      x_max_rate: 0,
      y_max_rate: 0,
      z_max_rate: 0,
      x_axis_length: 0, // Max lenght of axes: Used for soft limits in grbl and smoothie - also maybe useful to autodraw grid size
      y_axis_length: 0, // Max lenght of axes: Used for soft limits in grbl and smoothie - also maybe useful to autodraw grid size
      z_axis_length: 0, // Max lenght of axes: Used for soft limits in grbl and smoothie - also maybe useful to autodraw grid size
      x_homing: 0, // 0 = none, 1 = min, 2 = max
      y_homing: 0, // 0 = none, 1 = min, 2 = max
      z_homing: 0, // 0 = none, 1 = min, 2 = max
      x_home_invert: 0, // 0 = none, 1 = inverted
      y_home_invert: 0, // 0 = none, 1 = inverted
      z_home_invert: 0, // 0 = none, 1 = min, 2 = max
      x_dir: 0, // 0 = normal, 1 = inverted
      y_dir: 0, // 0 = normal, 1 = inverted
      z_dir: 0, // 0 = normal, 1 = inverted
      x_current: 0, // grbl-lpc and smoothie
      y_current: 0, // grbl-lpc and smoothie
      z_current: 0, // grbl-lpc and smoothie
      tools: {
        bed: true, // not really scoped to configure from here... but rather used in frontend to configure showing options related
        e0: true, // not really scoped to configure from here... but rather used in frontend to configure showing options related
        e1: false, // not really scoped to configure from here... but rather used in frontend to configure showing options related
        laser: false, // not really scoped to configure from here... but rather used in frontend to configure showing options related
        spindle: false // not really scoped to configure from here... but rather used in frontend to configure showing options related
      },
    }
  },
  comms: {
    connectionStatus: 0, //0 = not connected, 1 = connected, 2 = playing, 3 = paused, etc?
    runStatus: 0,// 0 = init, 1 = idle, 2 = alarm, 3 = stop, 4 = run, etc?
    queue: 0,
    controllerBuffer: 0, // Seems like you are tracking available buffer?  Maybe nice to have in frontend?
    interfaces: {
      supportedInterfaces: ['USB', 'ESP8266', 'Telnet'],
      ports: portsList,
      activeInterface: "",
      activePort: "" // or activeIP in the case of wifi/telnet?
    },
  },
  logEntry: "String" // In electron we lose the cmd log - can we also emit the log lines here?
};