New Versions of Cura-Plugins 'TweakAtZ' and 'RetractWhileCombing'

[pm_dude 27]

Robert, are you referring to the slicing progress bar under the save icon? It shouldn't steal the focus.

If the slicing is blocking your inputs that have been reworked a little on 15.01 version to be released. Some users had issues with Cura locking while the slicing was starting to update.

I need to start using retract while combing more. Nice feature chart Stefan! I definitely need to take example on your updates

Would be nice if updating plugin settings would not restart the slice since it doesn't need to. The plugin should just require the output version of the slice and provide an updated one afterward. That would save A LOT of time... Adding that to the to do list on my side .

 

[IRobertI 520]

Nah, it's a new progress bar that pops up for the plugin specifically that is doing it.

 

[pm_dude 27]

Ho.

 

[Dim3nsioneer 557]

Hmm.. The top of the file is still incorrect when using TAZ4 with cura 15.01.RC-7. This is what I'm getting which is confusing the printer:

 

;FLAVOR:UltiGCode

;TIME:<__TIME__>

;MATERIAL:<FILAMENT>

;MATERIAL2:<FILAMEN2>

 

Daid told me that the bug was not yet fixed but should be by now (means for the next version)...

 

[pm_dude 27]

Yes is was resolved for RepRap marlin but don't know if it will be for TAZ4

https://github.com/daid/Cura/issues/850

 

[Dim3nsioneer 557]

I haven't actually tested printing with it yet but I wanted to put this here before I forgot about it. That progress bar, that's quite annoying. Not visually, it's great to have it, but because it steals focus from the input. I start typing in "12", I'm about to hit another number and BAM, focus gets stolen and I have to wait for it to finish. Not sure if that's up to you or daid to fix though

Also, nit pick: The manual doesn't mention how to actually install the plugin, you might want to include that for the newbies.

 

The hijacking of the focus is actually done by some code in Cura and not by the plugin itself. However, this part is also a 'crime' I commited.

To put it in words from a well-known small green guy:

 

Meditate on this I will... :mrgreen:

 

Good catch about the install procedure; it's indeed missing...

 

[Dim3nsioneer 557]

Yes is was resolved for RepRap marlin but don't know if it will be for TAZ4

https://github.com/daid/Cura/issues/850

 

AFAIK all plugins are affected the same way... :?:

 

[Dim3nsioneer 557]

Also, nit pick: The manual doesn't mention how to actually install the plugin, you might want to include that for the newbies.

just updated.

 

[inventabuild 5]

Please add the ability to change Fill Density (%) at a given height or layer.

 

[DidierKlein 729]

Hi and welcome,

There is a plugin called SwapAtHeight that can do this

 

[Dim3nsioneer 557]

Yes, please use the SwapAtHeight plugin. The TweakAtZ will never be able to do this as the change has to be made in Cura (sliced twice). That's exactly what the SwapAtHeight plugin does.

 

[Dim3nsioneer 557]

Hi Stefan,

The Retract while comping plug has an ALT layer number but doesn't support "Print one at a time" mode.

The layer number probably doesn't add the layer count of the previously printed objects since the layer number reset per object in the gcode.

Would it be possible to add support for that?

 

Are you sure it's not working? I tested it with my new development version where I didn't change anything for catching the layer numbers and it worked flawless with in 'print one a time' mode...

Maybe it's with some special settings? An example would be nice... :-P

 

[pm_dude 27]

My use case was with 2 objects of 100 layers each and setting the tweak at layer 150 (like seen from the layer view). Since the second object never reach layer index 150 it wont insert the tweak settings.

 

[Dim3nsioneer 557]

I see. This would have worked with older Cura versions. I don't know when it was changed from unique layer numbering to repeated layer numbering. So you would have to put in 50 now to get the result; however, you would get it on both objects.

I would consider to implement a object number selection as soon as Cura saves that object number. I don't want to introduce a numbering which Cura doesn't support.

 

[pm_dude 27]

Cura show every layer as individual ones but the gcode save every object individually with a new layercount for every objects. All that is needed is to not follow the layer index and count the layers instead. I'll add it to SwapAtZ soon so I'll be happy to share the code too.

 

[Dim3nsioneer 557]

Agreed. But I want to follow the gcode as closely as possible. It's bad enough that Cura (still) has a different numbering in the gcode and in the layer view of the GUI.

btw: the layer view still counts through all the layers and does not restart at 1 (which should be 0) for a new object...

 

[Dim3nsioneer 557]

There are new versions available:

RetractWhileCombing was updated to version 15.02 (download see https://github.com/Dim3nsioneer/Cura-Plugins/wiki/Retract-While-Combing-plugin).

The new version mainly offers an option for enabling retraction on the first and on the last layer.

The TweakAtZ was updated to version 4.0.1 (see https://github.com/Dim3nsioneer/Cura-Plugins/wiki/Tweak-At-Z-plugin). It is a pure bugfix. The bug is within the code for tweaking the print speed. The bug resulted in every G1 command written twice in the gcode. This is mainly cosmetic. It will not affect the print result but lead to increased gcode file sizes. The new version will also be bundled with the next Cura version.

 

[aviphysics 9]

Yes, please use the SwapAtHeight plugin. The TweakAtZ will never be able to do this as the change has to be made in Cura (sliced twice). That's exactly what the SwapAtHeight plugin does.

 

What about just stripping out all the fill, including the zigzags that are used to maintain vertical thickness?

[Dim3nsioneer 557]

Hmmm... that would be a new scope. So far, the TweakAtZ always did one thing: changing print parameters. It never changed paths...if that's what you mean.

 

[pm_dude 27]

What about just stripping out all the fill, including the zigzags that are used to maintain vertical thickness?

There is no clear difference between normal infill and zigzag infill. The only thing we could do is remove toolpaths smaller than x length. That could be done. It would be another plugin

 

[aviphysics 9]

There is no clear difference between normal infill and zigzag infill. The only thing we could do is remove toolpaths smaller than x length. That could be done. It would be another plugin

 

I just figured that it would destroy all the infill sections between two heights. Would still need to generate paths and fix the extruder position, to be ready for the next path, but that doesn't sound too terrible. Pretty sure those zigzags are marked as infill in the gcode, so they would get deleted along with the infill.

 

[pm_dude 27]

I just figured that it would destroy all the infill sections between two heights

 

What do you mean?

The repathing is not that hard unless the section of infill follow a complex shape that would require aditional combing to avoid exiting the surface.

[aviphysics 9]

The transition path could just be turned into a retract move.

[Dim3nsioneer 557]

That progress bar, that's quite annoying. Not visually, it's great to have it, but because it steals focus from the input. I start typing in "12", I'm about to hit another number and BAM, focus gets stolen and I have to wait for it to finish. Not sure if that's up to you or daid to fix though

Good news for you, Robert (and anybody else who was annoyed by the additional progress bar)!

From next Cura version on, plugins can use Cura's standard progress bar with an additional label. First plugin to do so will be TweakAtZ which will be included in an updated version for that purpose.

 

[pm_dude 27]

@Dim3nsioneer, do you think it would be worth looking at caching the slice result prior to post process plugins? This way we could change plugin settings without needing to re-slice the model.

I know where the cache could be made but don't know if the plugin settings are triggering the update using the default procedure.

That could make quite a nice speedup.