Why is ethernet communication with shoothie directly from frontend insted of server?

[cprezzi]

The frontend communicates with serial connected boards via the node server (as middle tier), but with ethernet connected boards the communication is directly between frontend and controller board. This breaks layer logic and makes frontent implementation more complex.

@openhardwarecoza - Is there a reason for doing so?

[ghost]

The simple reason is that we had sample frontend code to work from here https://github.com/Smoothieware/Smoothieware/blob/edge/src/libs/Network/uip/webserver/httpd-fs-src/functions.js

Although the other reason to keep in the back of the mind, is that the nodejs app does only two functions: Hosting the local webserver and bridging browser to serial/usb

So for users without USB - we could host in any other webserver (gh-pages like we did with openhardwarecoza.github.io/LaserWeb2) and still talk ethernet to the Smoothieboard on the LAN - without needing to install any node locally (: Same for the ESP8266... (Can technically host the web page from SPIFFS on the ESP)

In terms of maintenance and rewriting this (and lets move that task to LW4) what I have wanted for a while now is a unified approach to the three comms methods in the browser (currently I do this clunky shit https://github.com/openhardwarecoza/LaserWeb3/blob/master/public/js/socketcomms.js#L110-L123 for example - three different sending functions... Yikes. Yeah I know that was hacked along as proof of concept and never fixed

The real way we need this to work is:

• Use the existing smoothiehappy.js library from https://github.com/lautr3k/Smoothie-Happy by @lautr3k
• Extend it to support the ESP8266 Websocket Implementation: https://github.com/openhardwarecoza/LaserWeb3/blob/master/public/js/esp8266.js
• For the serial bridge, i think we should move queue management to the browser as well (2 out of the three comms methods need it there - wifi and ethernet) and have the node app do the same as the ESP8266 - ie pure websocket to serial bridge
• Either based off Smoothie Happy (call it Grbl Happy) or integrated into Smoothie Happy - port the Grbl support. Its very similar to Smoothie's output for the most part
• Somehow integrate tinyG support https://www.npmjs.com/package/tinyg (or we can ask @cheton if we can borrow some of https://github.com/cheton/cnc/tree/f6d0bba4767912a7a813f4694af03e47c8ba2a50/src/app/controllers )

I am of course open to comment on that plan @arthurwolf @lautr3k @Cinezaster (The thing is kind of whatever we do here needs to also benefit https://github.com/arthurwolf/fabrica so that multiple projects can pull from this

I have it open as Project under LaserWeb4 here: https://github.com/orgs/LaserWeb/projects/1

[cheton]

Somehow integrate tinyG support https://www.npmjs.com/package/tinyg (or we can ask @cheton if we can borrow some of https://github.com/cheton/cnc/tree/f6d0bba4767912a7a813f4694af03e47c8ba2a50/src/app/controllers )

Sure, it's fine with me. You can find the implementation at: https://github.com/cheton/cnc/blob/master/src/app/controllers/TinyG2/

[cprezzi]

Thanks for the explanation. I remember at the beginning of LW3 I was asking why you even need an additional queue in the node-server, instead of just media bridge. :)

It makes absolute sense to have all comms at one place. I'm just curious if the performance of js in the browser is fast enough and not affected by all the GUI stuff that has to be done. W'll see...

I'll move over to LW4 dev and look if we can at least make clean layer separation.

[ghost]

Always a catch 22 I might as well mention the pros of the node based queue

• i can close browser and walk away
• performance should be better (especially since its a ping pong buffer, any latency waiting for the OK will slow down the queue)
• multiple endpoints (never really took that as far as I wanted but things like a mobile jog widget alongaide a full app, both open, talking to the same node backend

[ghost]

Thanks @cheton!

[cprezzi]

You are right with ths pros of node server. It's a real backend, which doesn't need the presence of the frontend, once it's started (like octoprint or repetier server). This design also alows to have a second (minimalistic) frontend for a moble, for jogging or job controll.

PS: My overides are also working with multiple endpoints connected :)

[ghost]

The thing is, we like to believe that ethernet and a non local install is cool. But is it really?

We have an node-electron branch already for the macosx users (terminals scare artists). Cloud based is harder to troubleshoot when it doesnt work and users hate the concept

Most of the non genuine smoothies come without ethernet. The ethernet implementation on the smoothie isnt capable of websockets on its own, so we are stuck with slow ajax. All cons...

The more i sleep on this the more i think you are right, the common queue should run through the node backend. Especially also to keep growing support for grbl, tinyg and even marlin @lautr3k @arthurwolf @wolfmanjm whats your thoughts (agendas aside)

[arthurwolf]

I can just tell you how communication needs to happen with Smoothie : ajax, with a queue, and no sending of commands while the machine is working on something. And that needs to happen without nodejs ( at least as an option ), purely in-browser, because that enables users to just use smoothieboard's web server to save the page, so they don't need to install anything and don't need an internet connection.

On Sun, Nov 6, 2016 at 10:10 AM, Peter van der Walt < notifications@github.com> wrote:

The thing is, we like to believe that ethernet and a non local install is cool. But is it really?

We have an node-electron branch already for the macosx users (terminals scare artists). Cloud based is harder to troubleshoot when it doesnt work and users hate the concept

Most of the non genuine smoothies come without ethernet. The ethernet implementation on the smoothie isnt capable of websockets on its own, so we are stuck with slow ajax. All cons...

The more i sleep on this the more i think you are right, the common queue should run through the node backend. Especially also to keep growing support for grbl, tinyg and even marlin @lautr3k https://github.com/lautr3k @arthurwolf https://github.com/arthurwolf @wolfmanjm https://github.com/wolfmanjm whats your thoughts (agendas aside)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb3/issues/173#issuecomment-258668713, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGpFYyo3IN7OIWE07oRTkugybVGwgV0ks5q7ZmKgaJpZM4KnZHZ .

Courage et bonne humeur.

[jorgerobles]

I agree with Peter. Laserweb should be a multi-tier (Smoothy, GRBL, TinyG) app, and the easiest way to achieve is doing on the "server-side", as only "server" has full access to low level functions like serial access, managing ports, etc. Not only that, but you could close your browser accidentally (or being closed by chrome tabs overflow, etc) and the data would be lost. About the access to system resources, only defunct Flash and Chillipeppr Chrome plugin solutions are "only-browser" (As far as I now).

I think packaging as an App (Electron, other ways, etc) is a must (even you close the app, could be running on second plane, as many other apps do ). Once downloaded, you could use without internet connection.

::DREAM_ON:: Looking forward (LW4, ... 5 :P), although frontend as it is, is working fine, I imagine as API/Client architecture, so settings, gcode generation, etc, would be run on the API side (node), allowing further complex programming to be developed. ::DREAM_OFF::

[cprezzi]

@arthurwolf : Would it be possible that smoothie takes the place of the backend completely? I mean, hosting the frontend webpages and the backend functions of the actual node-server (like an integrated OctoPi)?

[ghost]

It already does: http://smoothieware.org/install-web-interface just not laserweb yet

On Nov 7, 2016 9:58 AM, "Claudio Prezzi" notifications@github.com wrote:

@arthurwolf https://github.com/arthurwolf : Would it be possible that smoothie takes the place of the backend completely? I mean, hosting the frontend webpages and the backend functions of the actual node-server (like an integrated OctoPi)?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb3/issues/173#issuecomment-258768890, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr21VYlBKy68HsCXdaBWLg5KmS5LF4ks5q7tosgaJpZM4KnZHZ .

[cprezzi]

Ok. I have to look into that. The main difference I see is, that we relay on socket communication and smoothie does it by ajax. If we are able to change the communication between frontend and backend to ajax, then smoothie could be "just another" backend server. The question is, can we pack the same (needed) functionallity into that backend and is it fast enough.

[ghost]

Websocket is a heck of lot faster that ajax. Handshake Once.. Things like the DRO over Ajax is clunky

[arthurwolf]

Yep, Smoothieboard has a web server, with an ajax ( very simple ) API. There are limits : you can't request pages while it's printing, and you should limit the number of ajax calls while it's printing to a minimum.

For v2, well have a much sturdier webserver, and a websockets interface.

On Mon, Nov 7, 2016 at 8:58 AM, Claudio Prezzi notifications@github.com wrote:

@arthurwolf https://github.com/arthurwolf : Would it be possible that smoothie takes the place of the backend completely? I mean, hosting the frontend webpages and the backend functions of the actual node-server (like an integrated OctoPi)?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb3/issues/173#issuecomment-258768890, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGpFb_3u6M4gVyPlcmqKWyJv5mmpy8Iks5q7totgaJpZM4KnZHZ .

Courage et bonne humeur.

[cprezzi]

@arthurwolf : This sounds very limited and not realy usable for something like "near realtime DRO". What du you mean by v2? The new smoothieboard?

[arthurwolf]

Yep, the new board and firmware.

On Wed, Nov 9, 2016 at 2:56 PM, Claudio Prezzi notifications@github.com wrote:

@arthurwolf https://github.com/arthurwolf : This sounds very limited and not realy usable for something like "near realtime DRO". What du you mean by v2? The new smoothieboard?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb3/issues/173#issuecomment-259420214, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGpFX-9d8GaNqJivje5duduDlFzcgl0ks5q8dEkgaJpZM4KnZHZ .

Courage et bonne humeur.

[cprezzi]

Ok, so we should check again when v2 is available.