[from __FUTURE__ import ...] LW 3d Printing integration roadmap

[jorgerobles]

There's some people very interested on 3DP on LW, and open this Issue to just talk about the chances and availability. This needs deep thinking, so, let's party! @lautr3k, @openhardwarecoza, @tbfleming, @cprezzi

It needs some heavy features, like:

• STL parsing [L]
• WebGL representation of 3d Models [TF]
• Model transforms (rotate, scale, translate) [TF]
• UI -> Workspaces (a la Eclipse?) and optimization. [JR]
• Slicer profiles [JR]
• Slicer Interfacing (Cura, Slicer) [CP]
• Cloud computing? [CP]
• Material profiles (Again) [JR]

and a good Management! (PVW)

[ghost]

Well, thats more of a [from PAST REimport ...]

1. The awesome gcode parser we had in lw1-3 - already handled even dualstrution gcode: See https://plus.google.com/+PetervanderWalt/posts/GDvLWnU7SMm I see @tbfleming 's parser also does https://plus.google.com/101442607030198502072/posts/TwRNA6CWDqH - so at least thats sorted already

2. In LaserWeb1 there was this madness: https://plus.google.com/+PetervanderWalt/posts/W544gpJYGRh - actually had 3D printing support. The sh**ty comms I had back then was the killer though...

3. And not long ago, this https://github.com/openhardwarecoza/CoPrint was based off LaserWeb3 codebase

[ghost]

Add to todo list

• Marlin support for lw.comm-server - too many users on Marlin, compared to Smoothie - to get mass penetration we'll need to accomodate those too

[ghost]

Low hanging fruit: Exclude slicing initially and just load gcode. Then most of the initial work is comms addition, and adding temperature displays to job tab, temp controls too

[ghost]

Me and @raykholo did some work on cloud slicing here http://chilipeppr.com/reprap

Workspace originally here https://github.com/openhardwarecoza/workspace-reprap Reprap Widget (Temperatures) http://github.com/openhardwarecoza/widget-reprap and Slic3r + STL preview https://github.com/raykholo/widget-stlViewer (STL preview code came from @lautr3k )

[jorgerobles]

Indeed @raykholo pong me to remember this feature :)

[jorgerobles]

I really like the Gcode load approach. But need some render skills :D

[ghost]

I love what I did here (; - this was months before I learned about icons fonts lol! Hotend and bed pics

[raykholo]

Load gCode is a good start. I completely forgot that we would need the manual control tab with temps, extrude and retract button, etc...

Cloud slicing is where we got stuck the first time... My implementation of slic3r cloud service in .NET and Azure was incredibly slow.

If LW4 is an EXE, can we package slic3r in? There is the nodeslicer wrapper. Would have to extract the slic3r folder to program files or equivalent as part of the install. How else does LW4 have to be able to be run? When we were strictly a website, this is when cloud or javascript slicing was necessary. So far I have only heard of EXE and possibly a server to be run on Pi.

I love the new context menus in LW4. I think this would be great for the plating UI - add all your STLs, and click on one to bring up the context menu for scale, rotate, muliply, mirror, delete, etc...

[ghost]

Instead of embedding a slicer, just make path to slicer configurable. Ure curaengine or slicer. Then user can install whatever they want

On Mar 9, 2017 9:32 PM, "raykholo" [email protected] wrote:

Load gCode is a good start. I completely forgot that we would need the manual control tab with temps, extrude and retract button, etc...

Cloud slicing is where we got stuck the first time... My implementation of slic3r cloud service in .NET and Azure was incredibly slow.

If LW4 is an EXE, can we package slic3r in? There is the nodeslicer wrapper. Would have to extract the slic3r folder to program files or equivalent as part of the install. How else does LW4 have to be able to be run? When we were strictly a website, this is when cloud or javascript slicing was necessary. So far I have only heard of EXE and possibly a server to be run on Pi.

I love the new context menus in LW4. I think this would be great for the plating UI - add all your STLs, and click on one to bring up the context menu for scale, rotate, muliply, mirror, delete, etc...

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

[cojarbi]

It's so close I can taste it :)

[jorgerobles]

@raykholo as far as I know there's a bunch of work done by Gina on octoprint. Maybe we could borrow her architecture for networking (as long license allows), but for Node.

[FabCreator]

If a 3d printing function is made, be awesome if you could include a SLS type! laser rastering i think is the biggest task for that?

[cprezzi]

If it's complicated to interface with a slicer from the frontend, we could use lw.comm-server (or a separate slicing server) as a bridge.

Beside of Marlin, we should consider of supporting Repetier also. I prefer Repetier firmaware over Marlin ;)

[cprezzi]

If we add support for more firmwares, I do probably need to modularize lw.comm-server, otherwise maintenace will be the horror.

[raykholo]

Slicer - Peter's suggestion is good, at least to get started. Need a way to run a terminal command - like exec in node. Let me know how/ where you think is best to implement that.

I agree we should involve Gina. She has intimate knowledge of how many times per second to send M105 :) But maybe we start with smoothie since that is already implemented in comms.

Ray

On Mar 10, 2017, at 11:36 AM, Claudio Prezzi [email protected] wrote:

If it's complicated to interface with a slicer from the frontend, we could use lw.comm-server (or a separate slicing server) as a bridge.

Beside of Marlin, we should consider of supporting Repetier also. I prefer Repetier firmaware over Marlin ;)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[cprezzi]

An own slicing/rendering/gcode generation server could probably solve some memory and performance limitations of the browser.

[cprezzi]

That could also open the door to cloud processing.

[raykholo]

I agree, and we had very high hopes for Kiri:Moto slicer which was entirely in JavaScript and ran in the browser. But closed source and obfuscated :(

However, we should not start trying to do everything. I think we focus on the 3d view and plate setup first, and invoke slic3r since this has years of development already. Eventually when the foundation is written and functional, I definitely want to branch out to multi extrusion and self contained slicing.

[arthurwolf]

A few years back, a student got curaengine to run in the browser. I've been harassing him ever since to continue, and he recently got back to it : https://github.com/Skeen/CuraJS-Engine I've also found at least two companies that are interrested in financing his work, though neither has actually done so yet. But I expect there will be more progress on this front soon.

On Fri, Mar 10, 2017 at 5:49 PM, raykholo [email protected] wrote:

I agree, and we had very high hopes for Kiri:Moto slicer which was entirely in JavaScript and ran in the browser. But closed source and obfuscated :(

However, we should not start trying to do everything. I think we focus on the 3d view and plate setup first, and invoke slic3r since this has years of development already. Eventually when the foundation is written and functional, I definitely want to branch out to multi extrusion and self contained slicing.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/199#issuecomment-285721098, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGpFcbbwpjD_2Qh4M9gLbYENifaOF5qks5rkX8WgaJpZM4MYecR .

-- Courage et bonne humeur.

[cojarbi]

I also agree into geting something rolling , this could attract many other possible sponsors or develoers that could help as further

[cprezzi]

@arthurwolf Nice info, thank you!

[cprezzi]

I'm always a bit concerned about performance and memory issues in the browser, so I do prefer to outsource those tasks to a nodejs server.

[jorgerobles]

Since we are going towards thin client version, will be better to do on the node side, but cool!

[raykholo]

I'm still not clear on what the install cases are. I am aware of the EXE, and that the User Interface can be loaded/ server to a web browser.

What are we building for? Example: if the idea is only to have installer, this is (slightly) different than if there is a Pi server that will let people load a webpage from a different device, which is (very) different than if people can also load the Ui via a browser external website (no server backing, and now we need to look into cloud slicing).

First 2 cases node server side invokes slicer. 3rd case we need cloud slicing. This is where we failed last time with the Chilipeppr STL widget.

On Fri, Mar 10, 2017 at 1:14 PM, jorgerobles [email protected] wrote:

Since we are going towards thin client version, will be better to do on the node side, but cool!

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

-- Ray

[jorgerobles]

@raykholo from the UI perspective, Cloud Slicing and Local Node spawning slicer process are the same (well, changes the url) or even Local node chooses to use local binary or cloud upon request, and then serves to UI. I prefer the latest, that does uniform callings and simplify the areas.

What are we building for? All at the same time :smile:

[tbfleming]

Chrome 57 released today. Web assembly (wasm) is now on by default, which changes everything. Before today C++ code had to be compiled to asm.js to run in the browser, which was OKish, but had some performance and memory issues. Try it out: http://webassembly.org/demo/

This is from testing computationally- and memory-intensive code I have at work:

• asm.js outperforms javascript
• wasm outperforms asm.js

Part of the vector CAM is C++ compiled to asm.js; I plan to switch it to wasm after Chromium 57 makes it into electron. This should give that part a speed boost. I plan to eventually move some of the Javascript parts over to C++ to try to take care of the existing performance problems.

CuraJS also uses asm.js and should probably make the switch to wasm. As an alternative, someone could port slic3r since it also is in C++.

[jorgerobles]

Superb! Now we have to figure how to use it :)

El 10 mar. 2017 23:23, "Todd Fleming" [email protected] escribió:

Chrome 57 released today. Web assembly (wasm) is now on by default, which changes everything. Before today C++ code had to be compiled to asm.js to run in the browser, which was OKish, but had some performance and memory issues. Try it out: http://webassembly.org/demo/

This is from testing computationally- and memory-intensive code I have at work:

• asm.js outperforms javascript
• wasm outperforms asm.js

Part of the vector CAM is C++ compiled to asm.js; I plan to switch it to wasm after Chromium 57 makes it into electron. This should give that part a speed boost. I plan to eventually move some of the Javascript parts over to C++ to try to take care of the existing performance problems.

CuraJS also uses asm.js and should probably make the switch to wasm. As an alternative, someone could port slic3r since it also is in C++.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/LaserWeb4/issues/199#issuecomment-285801577, or mute the thread https://github.com/notifications/unsubscribe-auth/ABoIYHjVqY9c_PW_L_SVvwF6p1Yd2kz4ks5rkc10gaJpZM4MYecR .