search

LaserWeb / deprecated-LaserWeb1

Deprecated: use http://github.com/openhardwarecoza/LaserWeb3 instead
186 stars 45 forks source link

Bug in raster with smoothie specific gcode #82

Closed ghost closed 8 years ago

ghost commented 8 years ago

@cojarbi has an issue on smoothies specificly.

@cojarbi, please add screenshots, result photos, saved gcode, etc that would help us see what it is

cojarbi commented 8 years ago

Bellow youll see picture and gcode for the default setting in LW when connect to smoothie. Also for comparison the standard render without being conected, same default settings.

default connected to smoothie defaults not connected

GCODE-LaserWeb Default Settings Smoothie.gcode.txt

cojarbi commented 8 years ago

Here is a picture of some test done yesterday. All of them showed bad renders as above. Different setting in speed and power were applied. 20160121_225643

ghost commented 8 years ago

Pull and test please

cojarbi commented 8 years ago

Same result on render. Do you want the gcode?

ghost commented 8 years ago

no wait, sorry ignore that last commit from fix viewer

ghost commented 8 years ago

I'm tired enough that I am chasing my tail...

Revert https://github.com/openhardwarecoza/LaserWeb/commit/2984c57db144fbfa6971bcb7dbc68f1209da2277

cojarbi commented 8 years ago

I'm lost then. I'm in the office cannot run the test till night. Running laserweb from here

ghost commented 8 years ago

Found it!

ghost commented 8 years ago

@nathanielstenzel - i figure you may appreciate the discovery of the issue:

  1. The gcode and viewer code BOTH had mistakes:

1.1 The Gcode writer was using map 0-100 -> 0.1 (which doesnt do decimals - which you had identified already) - Fixed in https://github.com/openhardwarecoza/LaserWeb/commit/73291423f915c4ee986a8316bb8206b7364ec54f 1.2 The 3D Viewer had a math.round which was taking the decimals in smoothie gcode and rounding it to either 1 or 0! (so 0.1, 0.2, 0.3 all became 0 (white) and 0.5, 0.6, 0.7 etc all became 1.0 (black) - Fixed in https://github.com/openhardwarecoza/LaserWeb/commit/a6e67ac92dc4a519068b42bfa392abb9b12d9456

Thats why the testing never reflected any improvements when you changed the map to a divide - we had to squash BOTH first

I introduced the math.round very early on in the project https://github.com/openhardwarecoza/LaserWeb/commit/2f1bb5e9d606d909ce53ba0d5a7c6331cdd9089f#diff-681a90cbc63da7ac6566acc75887b718R271

I copy pasted the line.e statement above it to get line.s line.e had a round function. S didnt mind a round function except when we got to smoothie, due to the decimals!

nathanielstenzel commented 8 years ago

Yes, I very much appreciate that fix in the other location. I was working with Ariel and only getting anywhere with speed adjustments of which increasing speed decreased reliability of reaching the required burn for light portions. That should make Ariel's next test go right. If it does, there is probably no need to do the adjustment that I was thinking of for making the white speed lower than black speed when desired. Of course, some of that testing was on gshield, but that is another story with another load of bugs and incompatibilities to consider.