"Welding" mark in cylinder mode

[vef445]

Hi @MarkWheadon ,

Reported by a user, see attached files, they are more relevant than a long explanation.
To reproduce:
perl velPaint -cylinderZ 0 0 100 0 2400 1600 4800 image gcode_source > gcode_destination

jarron spiral grande.gcode.txt

[vef445]

This looks to me like the same problem, except that we have a large flat surface so it's a lot more visible. It's in fact not "painted" (= original speed) in front of the X axis, but just on one side.

[MarkWheadon]

I can't see the gcode to be sure, but this looks to me like the slicing doesn't have a constant 2400 velocity -- perhaps perimeters have a speed factor of less than 100%, or printing is slowed for low layer times, or it literally isn't sliced with a speed of 2400mm/min.

[vef445]

I attached the gcode (it's in between the pictures, with a txt extension). As you can see on the last example (obelisk), it doesn't seem related to slicing speeds. I've looked into the gcode for the obelisk and speeds are constant. I'm attaching it here =>
obelisk.gcode.txt

[MarkWheadon]

Ah -- right, didn't see that single line between the images!

[MarkWheadon]

This may take quite some fixing. It breaks the script with use of G0 -- which is easy to fix, it has strange ordering with the feed rate at the front, but only for some lines, which again is fixable, but it also has feed rates all over the place which, until I add code to make it insensitive to speed changes (which I do intend to do eventually), is hard to fix. E.g. this chunk of gcode from the middle of the vase has a speed of 4800 and another of 840 -- neither of which is the 2400 it's expecting :(

;LAYER:108
G0 F4800 X-75.652 Y0.000
;TYPE:WALL-OUTER
G1 F840 X-75.238 Y-7.903 Z21.803 E7868.93471

[vef445]

hum... did you look at the obelisk...?

[MarkWheadon]

Not closely, but that too is peppered with different feed speeds.

[MarkWheadon]

I think he found the work-around (switch off combing in cura). From twitter:

Patrick Wiatt‏ @PatrickWiatt 23h23 hours ago
Trying #VelocityPainting with a @lulzbot3d printer and their flavor of Cura? Be sure to turn off Combing and Z Hop in Expert Settings. AND..
turn OFF(to 0) Minimum Layer Time under Advance settings. Turning on Spiralize Outer Contour for single perimeter prints under...
Expert Settings should eliminate the seam on your prints also.

[vef445]

Hi @MarkWheadon ,

Back to this issue with more information from another user, see his email:

To go along with the file I sent, here's more info. I've determined that is a Slic3r-specific issue. I ran the same model through Slic3r Prusa Edition and it does not cause the same problems when post-processed by the Velocity Painting code. I've replicated this on more than one model.
Where it chokes on the Slic3r regular code, the analogous Prusa code looks like (input files, not post-processed):

Slic3r:
...
G1 Z32.200 X24.700 Y-24.132 E1724.73731
G1 Z32.2 F18000.000
G1 Z32.262 X24.700 Y24.700 E1727.60789 F1800.000
G1 Z32.324 X-24.700 Y24.700 E1730.51185 F1800.000
G1 Z32.387 X-24.700 Y-24.700 E1733.41581
...

Slic3r Prusa:
...
G1 Z32.200 X-24.700 Y23.462 E1722.13441
G1 Z32.2 F18000.000
G1 F1800
G1 Z32.261 X-24.700 Y-24.700 E1724.96558
...

Right after those two F1800 lines velpaint butchers the slic3r code. But it digests the Prusa code smoothly.

The gcode is attached to this message. Let me know your thoughts.
60x80 cylinder.gcode.txt

[vef445]

On the same case (and same file), the initial message I received from this user (hope this can help troubleshooting):

To add a little more detail to the question, the script toodles along and encounters lines like:
G1 Z2.757 X2.911 Y-29.557 E72.59733
G1 Z2.764 X5.794 Y-29.129 E72.85531 F1800.000
G1 Z2.770 X8.621 Y-28.421 E73.11329

and modifies them to:
G1 X2.911 Y-29.557 Z2.757 E72.5973 F900.000
G1 Z2.764 X5.794 Y-29.129 E72.85531 F1800.000
G1 X8.621 Y-28.421 Z2.770 E73.1133 F900.000

It knows that the target speed is 1800, but for some reason does not modify that line.