Further optimising Raster jobs by skipping whitespace on wrapping around to next row

[cojarbi]

I did not see this before but now when you raster, gcode is generated for white spaces thus prolonging the work time since its moving the laser off in those lines. GCODE-LaserWeb (2).gcode.txt

[nathanielstenzel]

This is for raster images, right? There was a big restructuring of the code around a week ago for the status bar. It probably got lost efficiency when that was done.

[cojarbi]

Yes during raster it will do all the white/empty space with laser off.

[nathanielstenzel]

Looking at the code, I do not see a lack of efficiency from the code adjustments from around last week.

[cojarbi]

It could be me that havent noticed before. Engraving an image that has some empty space on the top creates gcode for those laser off movements. Of course user could crop the image but wondering if the code can just jump to the line where there is some power command. It does happens also if there is empty space in the middle which is also a waste of time.

[ghost]

No it creeped in a long time ago. When I added the backstroke it was still fine : see https://github.com/openhardwarecoza/LaserWeb/issues/32#issuecomment-169652035 (look at the green G,0 y moves) so sometime after that.

[nathanielstenzel]

We lost an if statement.

[nathanielstenzel]

24 G1 X195.0 Y181.4 S10 F4440 25 G0 X260.9 Y181.4 S0 ; whitespace before intensity100 26 G0 Y180.4 27 G0 X200.8 Y180.4 S0 ; whitespace before intensity10

It looks like we are not writing the last intensity and I have the feeling that we are reading one past the width of the image and getting a black spot for that reason.

[ghost]

The one past is not an issue, remember, that's the trailing 1px offset to handle the "last intensity" - we start writing 1px over, so we need to stop 1px over...

Don't mess with the current implementation in that sense.

If you want to optimize it, you need to keep track of the whitespace and do the Y move earlier, BUT remember the Y moves is now in the timer function, not the for loop.

Honestly don't think it worth the pie - the CO2 guys need that acceleration anyway.

Just crop your image so you dont have too much whitespace (there will always be anytime you dont have a rectangle image - so for example next to the ladies' heads etc...)

[nathanielstenzel]

Well, making it go only to the actual width and not the step past does make it so it will go directly to the next dot that needs darkening, but if the C02 folk need the acceleration then that makes the lack of efficiency an intentional feature and not a flaw. If you want the acceleration for the C02 folk, please close this issue now.

[nathanielstenzel]

If you do not mind losing the acceleration for the C02 folk (or if we can make a setting to turn this on and off) then try the code below. It has nice solid edges, but seems to go one dot off the right side of the bounding box.

diff --git a/i/raster/laserraster.js b/i/raster/laserraster.js index f38b2ec..299696d 100644 --- a/i/raster/laserraster.js +++ b/i/raster/laserraster.js @@ -213,11 +213,15 @@ Rasterizer.prototype.rasterRow = function(y) {

 // Can't miss the first pixel (;
 //if (px == 0) { this.lastPosx = posx; }

+

• //if we are on the last dot, force a chance for the last pixel
• if ( px == this.raster.width ) {
• intensity = -1;
• }

 // If we dont match the grayscale, we need to write some gcode...

- if (intensity != lastIntensity || px == this.raster.width) {

• if (intensity != lastIntensity) { this.moveCount++;

• //console.log('From: ' + this.lastPosx + ', ' + lastPosy + ' - To: ' + posx + ', ' + posy + ' at ' + lastIntensity + '%'); if (lastIntensity > 0) { if (this.config.useVariableSpeed) {

[nathanielstenzel]

[nathanielstenzel]

Oops. I accidentally closed it for a moment.

[Cinezaster]

Another option is post processing on the gcode that shortens moves when the laser is off and changing from line. All the lasers cnc's I know of need some extra space to move for acceleration after a sharp corner. We must be sure that the laserhead could possibly reach up to speed before starting to laser otherwise you get some darker edges where the laser starts or ends the move. This also depends on your laser settings of course.

For raster images possible speed improvements of the gcode would focus on the white space around images Possible optimisations:

• remove the 2 90° corners into one corner, at the change of the line. One corner is always faster, since it is already a 90° corner the CNC controller has to bring one axis to 0 speed anyway.
• shortening the length of movements on the edge where the laser doesn't have to burn.
• remove complete laser off moves

[ghost]

I like the post process idea: Especially from the fact that we would do same for fixing https://github.com/openhardwarecoza/LaserWeb/issues/89 - with @Cinezaster's brilliant idea in that thread too.

Just drowing in work :( - not going to get round to any major work this coming week.

Anyone else want to tag in ? (;

[nathanielstenzel]

I will take the issue rename to mean that it is okay to implement the patch with a setting to turn it off.

[ghost]

As long as it doesnt break (: - we must just keep the co2 guys in mind, and mind @Cinezaster's suggestions - he has some good points!

[nathanielstenzel]

We should have a series of configuration options. One option being for optimizing the end run. Another option being to actually add end loops or end run space. There would probably be a number of other options. We should decide sooner than later as to where these option settings would be stored or make it known if there is already a place where they are. We can then keep a score card where we check off each task for compliance with the option settings so that we know if raster images or svg or DXF or STL or gear cuts or box cuts or whatever comply with each of those option settings.

Thinking about things a little during lunch, I believe that my patch would fix borders which I believe are currently semi-busted. They do not work on return strokes if I understand correctly. I may then end up adding a 10 dot end run for each pass after the last cut pixel. For some images, it would make them slower. For some the end run plus the end optimization would be faster. I think 10 dots should be sufficient for getting things up to speed. It will at least work for now.

Cinezaster mentioned making 90 degree turns. I am not sure, but I think he means make box paths with one box inside the other. I believe that if you do that, you may have 4 diagonal lines going towards the center of the raster image. That may be worse. The loop and end run bit that I mentioned earlier in this post has to do with his comment about getting things up to speed and also to do with Peter's comment about getting the movements up to speed for CO2 laser folk.

It might be worthy to note that the smoothie firmware has a feature to adjust laser power around path ends to avoid the dark spots.

[ghost]

Smoothie is by far the superior firmware here. Grbl 1.0 (not out yet) will fix power management once and for all too. (but very soon!). Lasaurgrbl already does a great job. Then sadly it leaves marlin looking bad lol.

We can incorporate settings in #7 - that would be what i suggested all along. Put that sort of settings in your machine profiles

[nathanielstenzel]

https://github.com/openhardwarecoza/LaserWeb/commit/2fb6ef361dcfe56634a5bfe4e704887a688e446c I ended up not adding in the toggle for CO2 folk.

[nathanielstenzel]

My patch was undone, so I had to make the changes more directly.