ahoeben

Writing .hvs instead of .gcode is not something that can be done in a Cura profile. It can be done with a plugin, but writing plugins isn't for everybody; there's no guide or tutorial to follow for this exact usecase.

The file you posted looks like a normal gcode file to me. The only thing that makes it a little special is the very first line of the file. Could you try the following: * slice a file with Cura * save it as a .gcode file * rename it to .hvs (make sure it does not become .hvs.gcode!) * open the file in a text editor (eg notepad) * as the very first line, insert the following: M911 3DP-310F * save the file and try to print it

Your printer definition is incomplete; it does not have an extruder definition. Cura creates one in the background, but apparently there's something conflicting with my code when it does. I'll fix future versions of my plugin to be robust against this.

What printer definition do you use for your Lulzbot Taz? It is not a printer that ships with Ultimaker Cura. The reason I ask is that while your logs pointed me to what is going wrong, it is strange that it is not going wrong for the printers that do ship with Ultimaker Cura. I'll make future versions robust against this issue, but there may be an issue with the printer definition you use. About static text: You can type any text instead of {machine_nozzle_size} or other replacement patterns.

Have you tried printing at a lower temperature? Lower temperatures normally cause less stringing.

@Scotty-G, could you post a link to your cura.log file (Help -> Show configuration folder, cura.log is in the folder that opens)? For your printer that supports multiple filament diameters, I would set up two different printers in Cura, one for each filament diameter. Then you can just add a different static text to your custom prefix for each printer/material diameter if you want.

Please try the 4.5 beta. It has some changes in it that could fix this issue.

@imcarterschmidt could you check the Cura 4.5 beta, with that plugin enabled? A third party component in that plugin has been fixed/updated by UM, which hopefully fixes these performance issues.

I'm not sure if I love or hate that trick with the Cyrillic S. Probably both 😉

Now I'm curious. What did I do?

Perhaps if you post a link to a working .hvs file, we can have a look if writing to or converting to that format can be easily supported.

An updated version of Sidebar GUI (4.0.7) has been posted to the Marketplace, which adds compatibility with Cura 4.5, fixes a couple of bugs and adds a toggle to switch between perspective and orthographic projection. Subtle changes. Edit: See the shiny new web-based Marketplace: https://marketplace.ultimaker.com/app/cura/plugins/fieldofview/SidebarGUIPlugin

Aww, thanks for mentioning me 😉

What is happening is that the model is broken/unsuitable for 3d printing. I'm guessing the model has infinitely thin walls, ie the walls show white on one side and blue-ish on the other (in sketchup; did I guess correctly?). All walls need to have thickness to be printable, or Cura will get confused about being inside the wall or outside the wall.

The model probably has a small hole or gap that is throwing off Cura. It needs to be "repaired". If the hole is small enough, perhaps the Mesh Tools plugin "Fix small holes" works. If not, you could try Meshmixer or Netfabb or another tool that comes up when you google "3d model repair".