Ho.
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)...
Yes is was resolved for RepRap marlin but don't know if it will be for TAZ4
https://github.com/daid/Cura/issues/850
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:
Good catch about the install procedure; it's indeed missing...
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... :?:
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.
Please add the ability to change Fill Density (%) at a given height or layer.
Hi and welcome,
There is a plugin called SwapAtHeight that can do this
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.
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
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.
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.
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.
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...
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.
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?
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.
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
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.
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.
The transition path could just be turned into a retract move.
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.
@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.
Recommended Posts
Top Posters In This Topic
43
10
8
3
Popular Days
Jan 13
10
Jul 1
8
Jan 20
5
Feb 9
5
Top Posters In This Topic
Dim3nsioneer 43 posts
pm_dude 10 posts
DidierKlein 8 posts
aviphysics 3 posts
Popular Days
Jan 13 2015
10 posts
Jul 1 2014
8 posts
Jan 20 2015
5 posts
Feb 9 2014
5 posts
IRobertI 521
Nah, it's a new progress bar that pops up for the plugin specifically that is doing it.
Link to post
Share on other sites