Basic featureset

[kaosat-dev]

This PR will add all the basic features, unit tested, nothing fancy:

• restructure code base for better overview/maintainability
• modify code to use no framework (Three.js etc) specific data structure
• add basic unit tests & test files to avoid future regressions
• add travis CI integration for CI

DO NOT MERGE YET !

[ghost]

@tbfleming fyi, Mark starting work on porting the gcode viewer to reGL

[tbfleming]

I can't wait :)

[tbfleming]

It'd be nice to remove the A axis transform from the parser; that type of transform is better off in a vertex shader. I'm thinking of bringing in jscut's heightmap preview for mill ops. I'll need XYZA values to extend it to 4 axis.

[tbfleming]

I ported a temporary gcode parser from jscut to help me debug cam. It can only handle what the mill cam currently produces.

[kaosat-dev]

@tbfleming by XYZA values do you mean essentiall encoding things as vec4 ?

Also for the temp parser, I am guessing its this one ? : https://github.com/LaserWeb/LaserWeb4/blob/c7ddfa66330bd7d1d0db0471d05ef94cb46c6681/src/lib/tmpParseGcode.js

I finished a first , very rough pass of the "port" of this parser, but I still need to refine the needed output format (amongst other things) .

[tbfleming]

That's the right file.

It returns a 1-d array which looks like this: [x,y,z,g,f, x,y,z,g,f, x,y,z,g,f, ...]. In the future it will also need a and s in that array.

This type of packing aids the CPU's memory cache.

[tbfleming]

g must be 0 or 1. The real parser needs to convert curves to lines.

[kaosat-dev]

Ok , cool, that makes sense, thanks for the infos, that is a nice way to pack things indeed!
Wish I had see your parser earlier, btw, nice & clean , functional & straight to the point!

[kaosat-dev]

a few extra questions @tbfleming if you do not mind :

• you seem to be using a single object (array) approach (single giant buffer) vs multiple ones approach that seems to have been chosen in more recent versions of the gcode parser : there is an upper limit to gpu data size, so what shall we use ?
• will you be doing colors / line styling on your end, or should I provide a color buffer (assumed to be "same size" , as the positions)
• the current/old parser I based code on seems to have a ton of 'special cases' etc: keep or no keep?

Somehow I feel like these are questions that should have been asked at the start, in order to avoid me spending time on dead ends, but at the very least it was a bit of GCODE refresher.

[tbfleming]

This code, which is not part of the parser, reformats the data for the GPU: https://github.com/LaserWeb/LaserWeb4/blob/ee9db9f0adc3b43aebb931cacfd4738bf0163a00/src/components/workspace.js#L100

There will eventually be two versions of this; one for the existing display and one for a display which looks like this: http://jscut.org/RenderPath.html

Right now the draw() function (below the code in the workspace.js link) feeds the entire array to the GPU. If we hit a GPU memory issue, then we change draw to send the data to the GPU in chunks.

It already colors it based on the g value: https://github.com/LaserWeb/LaserWeb4/blob/ee9db9f0adc3b43aebb931cacfd4738bf0163a00/src/draw-commands/index.js#L118

I don't know what the special cases are; I haven't looked closely at that code.

[kaosat-dev]

• Would it not make sense to provide the data without the need to reformat ? it can get quite large, and having to realocate + reiterate over the array would mean "double" memory allocation. (of course if you use arrays to arraybuffers as you cannot 'push' to arraybuffers (not dynamic size), you still have a cost, but might be less ?
• that jscut demo is awesome!
• colors: cool, btw I think it makes sense to expose the color 'settings' (what color for what gcode) as uniforms , so that they are settable, but that is already nitpick, will add PR at that stage
• would you be ok with putting the G value first ? ie [G,x,y,z,f,a] this way indices don't break when adding any extra parameter, and having the 'type' of Gcode first feels more natural

[ghost]

This was the Håkan Båstedt commits
https://github.com/LaserWeb/LaserWeb2/commits/gh-pages?author=HakanBastedt

On Nov 17, 2016 5:22 PM, "Peter van der Walt (Gmail)" <
[email protected]> wrote:

It used too. But this (image worth checking out in comment on commit
LaserWeb/deprecated-LaserWeb1@77c7a92
be6159b8e8) was before the Håkan Båstedt optimisation round, not sure
if its been dropped yet. But, yeah, might be worth keeping...
Different T just had different line colors. Purple for T0, blue for T1

On Nov 17, 2016 5:18 PM, "Todd Fleming" [email protected] wrote:

Does the old visualizer do anything with e & t?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHVr2zR38t9BElQ8FV5Xit3YYuxF90QLks5q_HAGgaJpZM4KqN0G
.

[tbfleming]

I didn't realize RepRap switched to T from the old hack (different letters for different extruder motors). In that case, it would be easy to keep E and T and add them to the visualizer.

[kaosat-dev]

Ok, in that case if that is ok with you guys, the new order would indeed be :
[g,x,y,z,e,f,a,s,t] ?

[tbfleming]

yes

[tbfleming]

The visualizer and temp parser now use [g,x,y,z,e,f,a,s,t].

[kaosat-dev]

Cool thanks @tbfleming ! I think I'll be done with a first pass of this , this week, I have found a few good candidates for replacing all the THREE.js arcs => G1/G0 codes.
Btw do you have a small example GCode that has a ton of arcs by any changce ? (unit tests)

[tbfleming]

I don't. jscut, LW4, and 3d print slicers only produce lines.

[tbfleming]

I just moved the gcode previewer to draw-commands/GcodePreview.js. components/workspace.js has the call to parseGcode. workspace will eventually pass the parsed gcode to both previewers.

Do you have any multi-material 3d printer gcode samples? I'll add multi-material to the previewer and temp parser.

[kaosat-dev]

@tbfleming I have one sample generated for the Ultimaker3 (dual extrusion).
Should we perhaps create a repository with sample gcodes so that any repo that needs them can just import it ? Otherwise I can always add it to this repo (but as usual, it is quite large at 1.3 Mb)

[ghost]

I like the idea of sample files repo

On Nov 20, 2016 6:38 PM, "Mark Moissette" [email protected] wrote:

@tbfleming https://github.com/tbfleming I have one sample generated for
the Ultimaker3 (dual extrusion).
Should we perhaps create a repository with sample gcodes so that any repo
that needs them can just import it ? Otherwise I can always add it to this
repo (but as usual, it is quite large at 1.3 Mb)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHVr2zbQzjo0aB3_6n9-SZ-GdSCHSiJ_ks5rAHedgaJpZM4KqN0G
.

[tbfleming]

I like the idea of sample files repo

Me too

[kaosat-dev]

@openhardwarecoza & @tbfleming done : https://github.com/LaserWeb/lw-sample-files

[tbfleming]

Ditto :)

[kaosat-dev]

Neat ! that was fast ! :)

[ghost]

On your topic of G2/G3 breaking up into sections, I came across https://github.com/chamnit/preGrbl/