Improve graphic visualization (specifically with tiling)

[amoineau]

Hi, I have two suggestions I would really like to see implemented to improve QoL :

Don't superpose tiles when using the tiling feature

Currently, when using the tiling feature every tile is displayed on top of each others, which makes the graph completely unreadable. Would it be possible to have the graph to be displayed "as is"?

Form color

Would it be possible for the forms to be drawn using the layer / tool color? This would allow for a much better understanding of what is going to happen and immediately notice if a form is not matched with the correct tool.

[svenhb]

Currently, when using the tiling feature every tile is displayed on top of each others, which makes the graph completely unreadable. Would it be possible to have the graph to be displayed "as is"?

Because all XY coordinates of all tiles are in the same range... No idea at the moment how to improove that.

Would it be possible for the forms to be drawn using the layer / tool color?

Should be possible - will check

[amoineau]

Because all XY coordinates of all tiles are in the same range... No idea at the moment how to improove that.

I see :/ Do you think you will have time to look into it in a near future or does it fall in the "not worth the effort" category ? ^^'

Should be possible - will check

That would be a nice addition, thank you !

[amoineau]

I just wanted to specify that hiding the shapes that are not on the current tile could be a solution too. If it's simpler to achieve.

[svenhb]

I just wanted to specify that hiding the shapes that are not on the current tile could be a solution too. If it's simpler to achieve.

I need a good reason / context / switch: why to hide figures in the 2D view that are programmed in G-code. What is your command to move to next tile - maybe that's a starting point to seperate the tiles.

[amoineau]

I see, the command I run between tiles is (^3 $CP1000). It tells the conveyor to move forward 1000 mm. But maybe to avoid depending on a specific, per person, command, you could add your own 'empty' command that just mark the end of a tile ? It's really just an idea thrown like that.

[svenhb]

I added the suggested features: https://github.com/svenhb/GRBL-Plotter/releases Note new option:

[amoineau]

Wow thank you, I'll try that today !

[amoineau]

Once again, it's some really nice work :

• The 2D view figure color is great, thank you !

• The display of tiles is a real improvement... with some limits ^^'
• Always seeing the original shape, instead of it folding, is obviously the big improvement !
• When the shapes of the second+ tiles are being processed the fact that the pink cursor is on the "real shape" plan and the black one is on the "machine" plan is actually really cool because you keep the best of both world : "where is the head IRL, and what am I drawing (or at least about to draw) ?".
• The big problem I see is that the green drawing is happening on the machine plan. Which makes things as messy as before after the first tile and go against the idea above, it's quickly impossible to follow what as been done, what is about to be done and even where is the head.

(Here I chose a very hollow file with only two tiles just to keep the readability, but imagine 6 very busy tiles ^^).

It would be amazing if the green tracing happened on the "real shape" plan. Do you think it would be remotely possible ? That way we would have every possible information with complete readability !

I'm sorry to ask so much of you, I would understand if you wanted to keep it there. I just feel like the tile feature would be so neat and complete with that. (I hope I am not the only one using it because it would be a shame)

[svenhb]

It would be amazing if the green tracing happened on the "real shape" plan. Do you think it would be remotely possible ? That way we would have every possible information with complete readability !

I understand the problem, but not your suggested solution. Perhaps: Within the working area you want only to see the figures of the actually proccessed tile?

[amoineau]

I made the worst paint edit in hope that it would be clearer than words x) :

I wished the green tracing that overwrites the processed shapes, would actually overwrite the shapes (even after the first tile). Right now the green lines are all stacked on the "machine" plan.

I don't know if this is any clearer, don't hesitate to ask again ! ^^

[amoineau]

The drawback would be that the black cursor would be moving alone in the machine plan, but hey, you can't have it all ;)

[svenhb]

Like this? https://github.com/svenhb/GRBL-Plotter/blob/master/GRBL-Plotter_Setup_1611_20190906.exe

[amoineau]

I got this :

(The exterior of all sails has been processed on both tiles)

The green tracing doesn't stack on the machine plan but it doesn't seem to appear elsewhere either :( And in the areas I circled there are some artefacts, but maybe it is not related to the changes.

[svenhb]

Can you try to hide the limit area? I think it's a problem with the red grid.

[amoineau]

I got a similar result (with a bonus glitch) :

Is that what you wanted me to try ?

[svenhb]

How does it look, if you simulate the path?

[amoineau]

It's much better but it tends to draw green lines where they shouldn't be :

This time it seems to have done it only once (Edit : twice actually), but the first time I tried I had lot of green lines linking shapes between them. (didn't get a capture because I didn't know everything disappeared when done ^^')

[svenhb]

This means:

• with simulation all figures are marked correctly one by one tile by tile? (don't look at the "glitches")
• on real process it only marks the figures within the working space

Is this correct?

[amoineau]

Yes, I will try with a file more than two tiles long just to make sure. Edit : I tried on a 12 tiles file and it worked well in simulation, same problem with real process.

[svenhb]

Good to know, will try to fix it

[amoineau]

Thank you ! Good luck ^^'

[svenhb]

Try https://github.com/svenhb/GRBL-Plotter/blob/master/GRBL-Plotter_Setup_1611_20210907.exe

[amoineau]

I'm running the tests but for now the thing I noticed is that the dark green lines representing the pen path are slightly broken :/

[amoineau]

It worked on that file !

Edit : I tried other files and it worked as well. Apart from the pen up path being weird they are also some intense glitches with the light green tracing. The worst of the glitches seem to disappear at the end though ^^

[svenhb]

Little improovement with pen-up path: https://github.com/svenhb/GRBL-Plotter/blob/master/GRBL-Plotter_Setup_1611_20210908.exe

[amoineau]

Hi, sorry I am on a business trip since yesterday, I'll check it next week. Thank you again :)

[amoineau]

Hi ! I finally got time to test it and it seems to be working well, thank you :)

I showed the previous version to the people who are going to use the machine and they found it confusing that the graphic doesn't shift left into the machine limit when moving to the next tile... I know we are straying further and further from the original purpose of your software but do you think it would be hard to offset the visual after each tile ?

What they want would be to always have the current tile inside the machine limit (and that way the black cursor would stay on the graphic). I'm really hoping they will be satisfied after that so you can close this issue :/

[amoineau]

Hello, did you consider my request ? I would understand if it was a no ^^'

[svenhb]

What they want would be to always have the current tile inside the machine limit (and that way the black cursor would stay on the graphic).

I tried to implement, but you have to live with strange behavior of the progress path. You need to wait until the next release - perhaps next weekend.

[amoineau]

Ok sure, It's really not a pressing matter ! I simply wasn't sure you saw my last messages considering I took quite some time to answer yours last time, you might have moved on ^^ Thank you.

[svenhb]

Improoved behavior of progressed path display: https://github.com/svenhb/GRBL-Plotter/blob/master/GRBL-Plotter_Setup_1_6_2_1.exe

[amoineau]

Hello, I tried it this morning and the shifting of the shape is working but the "pen up path" tracing doesn't follow and the pink cursor seems to get stuck :

A more minor problem, the "interactive shapes" keep their original position :

When I click on a shape it selects the shape that was originally there, as you can see in yellow.

[svenhb]

Too much work to change it, perhaps I disable pen-up path and selections during streaming

[amoineau]

understandable

[amoineau]

Hello sven, would it be possible to have the option to toggle the shifting feature made in 1.6.2.1 ? Considering that it comes with some considerable drawbacks for now it would be great if the operators could choose between shifting and no shifting.

[svenhb]

Check new release: https://github.com/svenhb/GRBL-Plotter/releases Perhaps a bit improovement of behavior if "Move the tiles" is enabled.

[amoineau]

Ok, I'll try that as soon as I can, thank you.

[amoineau]

I tried it and it seems to have two problems (which might be the same) :

• When I don't use "Moves the tiles to 0;0", the light green tracing representing what has been done stays on the first tile even when doing the second one. However I recall that at some point you succeeded in making sure that this tracing followed the current progression in this configuration.
• When using "Moves the tiles to 0;0", after shifting, the light green tracing disappear for the previous tile and the one for the next tile is drawn on the first tile instead of the "0;0 area" ( which looks even weirder since the tile is shifted left, in the negative positions) :

Here we can see the green light tracing for the first tile is missing and is currently being drawn on the current position of the first tile.

Apart from that, having the option to switch between both mode is really great and everything else seems to be working very well !

[svenhb]

Hard to understand, perhaps you can make a short video? With my test data it looks as expected.

[amoineau]

Short video will be hard, the files are rather long to process and i'm really not well versed in video capture with what I have at work. But I will try to make step by step captures to explain better. In the meantime here is the file if you want to try it and see if you get a different result than my previous screenshots :

dxf-sample-amoineau.zip

Maybe some settings are interfering with each other, in my config and not yours...

Here is my config if it can help : GRBL-Plotter_amoineau.zip

[amoineau]

When I start, the first tile is processed normally :

When the first tile is finished, the green tracing is perfect :

Then the graph is shifted to the left, as expected, but the green tracing drawn until then disappears :

Now we are processing the second tile, and the green tracing is being drawn correctly, albeit one tile to the left :

At the end of the second tile we have this :

[amoineau]

Does this help you understand ?

[svenhb]

Does this help you understand ?

Yes

Then the graph is shifted to the left, as expected, but the green tracing drawn until then disappears :

that is intentional, otherwise each tile needs to get a seperate "processed" path.

Now we are processing the second tile, and the green tracing is being drawn correctly, albeit one tile to the left :

this looks wrong and is different to my intention and tests - the green path should appear in the work area of the current tile...

[svenhb]

Perhaps you can also show your tool-table "laser_pen_default.csv"?

[svenhb]

I edited the last release: https://github.com/svenhb/GRBL-Plotter/releases

1.6.2.3

• DXF Import add DXFText (before just DXFMText)
• Bug fix tile shift offset of processed path

[amoineau]

Then the graph is shifted to the left, as expected, but the green tracing drawn until then disappears :

that is intentional, otherwise each tile needs to get a seperate "processed" path.

That's understandable, and really not a problem indeed, considering we already know on which tile we are when using this mode.

[amoineau]

Perhaps you can also show your tool-table "laser_pen_default.csv"?

Sure :

[amoineau]

I edited the last release: https://github.com/svenhb/GRBL-Plotter/releases

Thank you ! I will try to test it today.

Edit : I can't test it today because I have no board available, and after today I'm on sick leave until the 15th...

[svenhb]

Here is my config if it can help :

BTW,, to reduce G-Code size and communication load, I would use just 2 decimals

and enable "Remove very short moves" with perhaps 0.5? Should be accurate enough in this dimensions.

[amoineau]

Thanks for the advice !