Inkscape Turnkey plugging different render results in Laserweb

[cojarbi]

I see both gcode the same, the only diference i see is the power setting from decimel for smoothie to round number for ramps. turnkeyramps.gcode.txt turnkeysmoothie.gcode.txt

[ghost]

Right, so finally took a look at this, but I dont see any difference when viewed in the 3D viewer?

[cojarbi]

The smoothie file does not render at all the square, star and some letters. So it will only render arcs not straight lines

[ghost]

Weird,

if i load the smoothie file you sent:

and then the ramps

I see no different (except the filename top left lol)

Are you sure you sent the right files?

[cojarbi]

Jajaja.  Look very closely. The first image does not render the square and the star.  The second it does in red.  Also happens with arcs in the letters

Ariel Yahni

On Jan 12, 2016, 08:38, at 08:38, Peter van der Walt notifications@github.com wrote:

Weird,

if i load the smoothie file you sent:

and then the ramps

I see no different (except the filename top left lol)

Are you sure you sent the right files?

---

Reply to this email directly or view it on GitHub: https://github.com/openhardwarecoza/LaserWeb/issues/52#issuecomment-170913969

[ghost]

Can you give me the original SVG too? (: Guess I'll have to install the plugin too

[ghost]

Looking at the plugin's source https://github.com/TurnkeyTyranny/laser-gcode-exporter-inkscape-plugin/blob/master/turnkeylaser.py

Theres only two f (self.options.mainboard == 'smoothie'): statements, where they divide laserpower by 100: So that SHOULD be the only difference between the two

[ghost]

How does the job run by the way? (i.e only viewer issue?)

[ghost]

Diffing the files show only the power (S) param difference

Now, I recall you made that mistake before, so let me ask:

You DID have the smoothie plugged in when viewing the smoothie, and a ramps plugged in and select when viewing the ramps??? REMEMBER the UI adapts HOW IT BEHAVES according to the board connected/selected!

So for example in the viewer I do: (And I really do hope you read the code links I always post for you)

if(typeof line.s === 'undefined'){ opacity = 0.3; } else { if (firmware.indexOf('Grbl') == 0) { opacity = line.s / 255; } else if (firmware.indexOf('Smooth') == 0) { opacity = line.s; } else { opacity = line.s / 100; } }

https://github.com/openhardwarecoza/LaserWeb/blob/master/i/gcode-viewer/gcode-parser.js#L288

So if you have a Marlin workspace active it takes whatever S parameter is in the Gcode, and renders it on the viewer as S / 100 (aka 0-100% gets mapped to 0-1 which is also the range three.js wants for Opacity

If you have a Smoothie, it doest do the S/100, it does S=Opacity since smoothie is already in 0-1

So = moral is, this also shows you if your try running a smoothie generated gcode on a ramps box, the S param will be all wrong and WE WANT TO SHOW THAT IN THE UI BEFORE RUINING a job

So, no bug (: Just user error...

To recap: If you have no board plugged in we expect S0-100 If you have Grbl, plugged in, we expect S0-255 If you have a smoothie plugged in, we expect S0-1

So if you load a S0-1 file while we expect 0-100, guess what S1 means? Yip 1% and you wont see anything on the viewer :|

Working as designed