randyinla
-
Posts
196 -
Joined
-
Last visited
-
Days Won
2
Content Type
Forums
Events
3D Prints
Posts posted by randyinla
-
-
1 hour ago, gr5 said:
The error might actually be in the GUI and not the plugin (the gui might refer to the bottom layer as layer 1 might that might be considered a bug).
I wouldn't say the gui has a defect. End users want to see the first of something labeled as "1" not "0". The code has to start at 0 due to the way Arrays are 0-based in the programming language. The defect is that the plugin must subtract 1 from the number entered so it can insert the change into the correct layer in the code. It's a common thing that has to be done on almost every interface to anything.
-
I'm a sr. software engineer. I've already created my own post processing extension over the weekend (calling it SpeedChangeByLayer) that changes print speed or fan speed per layer, not by z-axis movements. Started with the ChangeAtZ script, removed everything except print/fan speeds, then yanked out everything dealing with trying to find/calculate the z-axis movements and restructured the code & storage structure. Instead, it now looks for the ;LAYER:xx comments, inserting the start of the change just after the proper layer (subtracting 1 from the Cura gui layer number, which ChangeAtZ does not do) and the reset just before the next ;LAYER:xx comment. Currently, my code is messy as hell but works perfectly for a single layer. Can insert multiple instances of it to affect multiple layers. Also, the percentage change for print speed is always is a percentage of the original speed, not of the instance before it. ie.If 1st change = 50% & 2nd change = 20%, the 2nd is 20% of the original speed, not 20% of 50%. Not sure if I'll submit it or not. I want to change the fan speed to work as a percentage instead of having the user enter the PWM number from 0-255 and also need to tweak the fan speed routines so it can work across a span of layers. "Start speed change at layer 10 for a total of 5 layers". Currently, that only works with the print speed. Since the print speed change is a %, like changing the speed from the machine's panel during printing, I can always reset it back to 100% at the end of the layer(s). With the fan speed, it can be different on each layer as in, "ramp up to 50% speed over 10 layers" in Cura. So I have to first scan the entire layer for a fan change, M106 or M107, store it, then reset the fan to that speed at the end of the layer. It's like moving the existing fan speed to the end of the layer, getting it out of the way so you can override the layer with your setting from the extension. (Keep wanting to call them plugins, but technically, they are extensions working under the post processing script)
-
I create most things I print in Solidworks and add a little chamfer to the build plate edges for that very reason. Will have to play with horizontal expansion on the first layer now.
-
Supposedly, printing infill before outer walls creates stronger walls, though the infill shows through the outer wall. If I'm more concerned with strength over looks, like with a bracket or some other utility part that needs to be strong, I'll opt for infill before outer walls.
-
I, too, usually uncheck the infill before walls checkbox on most prints.
-
Quote
@randyinla: I don't think you can blame Ultimaker for any errors or unclarities in this plug-in, because (if I understand correctly) these plug-ins were/are built and shared by users, not the company.
Oh, I wasn't blaming Ultimaker at all!😲 I think the plugin developer, developing specifically for Ultimaker-created gcode, should be more on top of where it inserts changes into Ultimaker gcode. I simply suggested/wondered if the ";LAYER:xx" comments (generated by Cura) were not initially inserted by Ultimaker/Cura way back when the TweakAtZ (now called ChangeAtZ) plugin was first created and that if so, now there seems to be a better marker to search the gcode for layer changes. I do have some rather old gcode on my U2 memory card. Maybe 6 years old. I can take a look at those to see if they have ;LAYER:xx comments or not.
I hadn't thought about the extensions not being saved before. I've only used them for this print. Makes sense to include them in a profile of some sort.
-
This plugin started life as TweakAtZ and though it has a new name, it's still ChangeAtZ, so it makes sense that it would scour the code looking for commands that include Zx.xx and insert there. However, perhaps Ultimaker didn't insert the ;LAYER:xx comments in the gcode back when the plugin was first created? Perhaps the plugin needs to change its code scouring methods? I setup the plugin to go off of layer numbers, not height in mm, but I understand what you are saying. Perhaps the plugin still calculates the mm height off of the layer number and then looks for the Zx.xx, but it's still inserting the command in the wrong layer regardless. In the screenshot, I really need it to be layer 22, but have to set it to layer 21 because regardless how the plugin looks for the right place to insert itself, it ends up being placed in the next layer in the code. I open the saved gcode in a text editor and manually move things around and get rid of all the M117 display commands (don't need the display to tell me it changed something and require me to hit the button to dismiss).
I assume the ";LAYER:xx" comments in the gcode designate the beginning of each layer. If so, then that "Z5.75" line was about 22 lines from the end of a layer that contains 2,379 lines, putting the ChangeAtZ command at the end of the layer as well. Could it be Ultimaker inserts the Z5.75 line to change the z axis for the NEXT layer and the next 21 lines or so are head movements to go to the start of the next layer? Point being that not only is the 1-based indexing of the gui compared to the 0-based indexing in the gcode putting the ChangeAtZ command 1 layer too late, but if it looks for the z line in that layer, (which in my case is happening at the end of a layer), then that makes the ChangeAtZ command pretty much 2 layers late for everything, not just my speed changes (unless it uses different methods for insert other types of changes. I have only tried the speed changes).
By manually editing the code so the ChangeAtZ command happens at the very next line after ;LAYER:21 and the reset speed command at the line just before ;LAYER:22, the speed changes happen precisely where I expected them to be when the print is actually printing.
But yes, in any case, I now have the speed changes where I want them and have a better understanding of M220 commands and where to place them so they work as I think they should. Makes me want to write a plugin just for this use case just for me 🙂 "ChangeSpeedForLayer". Ultimately, it'd be awesome to run the layer head movement animation on the Preview page and pause it right were I want a change, then be able to grab the line of gcode that movement happens at and insert there. Unless the gcode is generated when clicking the "Save to File" button, which means it wouldn't be available to the Cura gui yet. Would be a good feature for Cura to add. Pause the layer preview playback, right click on the head in the layer view and select, "Insert speed change" and/or "Insert fan speed change" for tricky bridging passes. Much better than trying to make it conform to the master settings list. Doing it this way, Cura could then take into consideration speed changes and calculate a proper time for the print. Having the post processing plugin add speed changes makes the estimated time useless. My print is estimated at 6hrs 33min, but actual print time is closer to 7+ hrs.
-
To reset the speed back to 100%, "M220 S100" works. Strange the ChangeAtZ plugin uses "M220 S-1.000000" when it (seemingly) does nothing on the machine.
-
I moved all of the M220s to start the line after ;LAYER:xx and reset the speed on the line before the next ;LAYER:xx
;LAYER:21 M220 S20.000000 . . movement n stuff . M220 S-1.000000 ;LAYER:22
The M220 S20.000000 worked perfectly! I'm so happy about that.
But the reset of "M220 S-1.000000" didn't do anything. The display still shows the speed as 20%. When I look up the M220 command, resetting back to 100% is "M220 S100", not "M220 S-1.000000". I'll update the reset for the next round of printing.
-
Here are maybe 40 lines just before what I posted above, the line just before the ChangeAtZ comment has a "Z5.75":
M204 S500 M205 X25 Y25 G1 F900 X163.48 Y192.879 E132.41651 M204 S5000 M205 X30 Y30 G0 F18000 X69.127 Y193.557 G0 X67.224 Y192.722 G0 X66.07 Y191.563 G0 X65.26 Y190.196 G0 X62.585 Y179.072 G0 X55.077 Y173.949 G0 X52.41 Y173.548 G0 X50.858 Y173.019 G0 X49.491 Y172.124 G0 X48.392 Y170.917 G0 X47.632 Y169.481 G0 X46.816 Y164.215 G0 X46.47 Y160.419 G0 X46.22 Y156.616 G0 X46.064 Y152.826 G0 X46.002 Y149.016 G0 X46.037 Y145.207 G0 X46.141 Y142.121 G0 X45.09 Y135.08 G0 X44.847 Y135.322 M204 S500 M205 X25 Y25 ;TYPE:SKIN G1 F1800 X44.339 Y135.277 E132.43174 G1 X42.733 Y135.219 E132.47972 M204 S5000 M205 X30 Y30 G0 F18000 X42.483 Y135.469 G1 F2700 E126.97972 ;MESH:NONMESH G0 F600 X42.483 Y135.469 Z5.75
Is it safe to just move the M220 command to happen directly after the ";LAYER:21" line and then the reset of M220 S-1.000000 just before the next ";LAYER:22" line?
(funny how there's not a "gcode" code language option when inserting code)
-
I, too, am trying to get ChangeAtZ (currently 5.1.1) to change speed at a specific layer for one layer. Finding out that the gcode layer numbering is zero-based while the layer view in Cura is one-based was mind blowing! I read through the github code and see it was originally TweakAtZ. After so many updates, bug fixes, name change, supported Cura changes, no one thought to have the plugin automatically subtract 1 from each layer. Thank you for the clarification gr5.
While looking through my saved gcode, the M220 commands are almost at the end of each layer. Aren't the commands read from the file sequentially? If so, wouldn't the speed change happen right at the end of the layer instead of the beginning? Or does the gcode get read in layer by layer, analyzed by the machine, and then executed sequentially?
Here, you can see the ChangeAtZ M220 command, setting the speed to 20% just before the start of layer 22. Each layer takes approximately 1-1/2 minutes to complete, so there are plenty of head movement commands before those M220s are found.
;ChangeAtZ V5.1.1: executed at Layer 21 M117 Printing... ch@L 21 M220 S20.000000 G0 F18000 X46.393 Y137.572 G0 X46.166 Y141.396 G0 X46.037 Y145.207 G0 X46.002 Y149.016 G0 X46.064 Y152.826 G0 X46.22 Y156.616 G0 X46.47 Y160.419 G0 X46.816 Y164.215 G0 X47.261 Y168.032 G0 X47.966 Y170.22 G0 X48.903 Y171.554 G0 X50.149 Y172.617 G0 X61.29 Y177.478 G0 X64.765 Y185.875 G0 X64.721 Y187.866 G0 X64.976 Y189.419 G0 X65.624 Y190.91 G0 X66.619 Y192.189 G0 X67.909 Y193.19 G0 X159.666 Y194.545 ;TIME_ELAPSED:2658.809868 ;LAYER:22 -
Pro Ultimaker Tip:
When printing in white material, don't assume some of it got caught in the front fan because you see a little bit in there when you open the cover. It MIGHT just be the white wire going to the fan! I didn't realize what I had cut out until it was too late. 🥴 Don't forget to wear your reading glasses!
My cover had popped open during printing, got caught on part of the print and caused the steppers to skip, ruining the print. When I aborted, everything stopped but it didn't go through the normal abort procedure. The head just stayed there melting my print. So I turned it off/on. I had to bend the cover a bit to get the magnets to properly align with the two long screws. In doing so, or when the cover slammed into my print, the sensor wire must've come a bit loose. I got the dreaded, "There is a problem with the active level sensor." message. Thanks @leliep for the images. It really helped me tear everything down and thread it all back together again. I got lucky re-soldering a tiny wire to the trace on the front-facing fan's circuit board! Both Active Leveling & the front fan are operational again! 😃
-
1
-
-
I used to have this issue when I first started using my U2 a few years ago. My settings evolved over the years and I eventually have come to the point of setting my Line Width to 0.015mm narrower than the nozzle, so .385mm for a .4mm nozzle or .235 for a .25mm nozzle, Wall Thickness between multiples of that (.77 for 2 walls, 1.155 for three etc.) and multiples of the nozzle width (.4, .8 or 1.2 etc.), and I make sure to print hot enough so the walls melt into one another better. I also turn on the Outer before inner walls shell parameter. Since you are only experiencing this on small holes, maybe try playing with the Horizontal Expansion parameter? That allows you to increase/decrease hole sizes while also decreasing/increasing outer dimensions. I imagine increaing the holes this way will have zero effect on the distance between the walls, but it's worth a try. I haven't been able to force a fingernail in between walls for a few years now. Good luck!
-
I bought a spool of HydroFill from AirWolf3D but have yet to try it out. It was formulated specifically for ABS prints.
-
I tried setting separate speeds for my 2nd core yesterday (printing text using a different color and smaller nozzle) and noticed it didn't seem to print slower for that material at all. I set it to 15mm/ps for all line types and it screamed through that part of the print just as fast as the other material, which was set to 30mm/ps. Using Cura 4.1 on an U3Ext with the latest firmware from a few days ago.
-
Here's the print core holder I'm creating. It will screw to the back right side of the U3Ext. The shelf is more a roof to sit above all of the print cores to help keep things from falling into the open shafts. Figured giving it sides was better than just a flat cover so I could have an extra place to put things. So far, my shop magnification glasses fit perfectly. Made a drawer insert with labels for each nozzle that sits directly under where the Solex will live. I'll upload this and my other tool holder models to YouMagine when I'm finished.
I re-edited the text using 2.8mm Helvetica and am about to try re-printing the label bar with the 0.25mm Solex in the left core and a regular AA 0.4 in the right. Crossing fingers...
-
On 5/19/2019 at 1:39 PM, ctbeke said:
We'll be adding more functionality to this application over time. In Cura you're also able to see the status of the printers and queue. We'd love to hear your feedback!
I'd love to be able to see my U3Ext camera remotely. I haven't been able to see it for a while in any app. Not sure when it stopped working because I didn't touch my machine for about 1/2 year and upgraded to 4.0 a few weeks ago and 4.1 yesterday.
-
1
-
-
That sounds like a printer firmware issue, not a Cura issue. Cura slices your model and sets paths and other params, but I don't think it changes how the machine deals with temp changes during a print.
-
On 6/1/2019 at 3:42 AM, Carla_Birch said:
I found that when i updated to 4.1 that all my materials profiles i had made for filaments went, reinstalling the past 4.0 version they come back.
Same for me. I found multiple materials listed in a file named "custom" and a single material in Cura listed as Custom but just one material. Seems I always lose something; print profile/machine setting or material when upgrading to a new release.
-
That's awesome, GR5! Thank you! I'll get on this when I get home tonight. I pulled the clear thumb lever off of my AA 0.8 and am using that for now, even though I haven't put the Solex back into the machine yet.
The thing I'm trying to model and print out is a print core holder for the side of my U3Ext. I noticed right away the geometry is ever so slightly different on the Solex than the original print cores. Designing a holder that would accept either was challenging and fun. They both easily glide into place in my holder now with a snap. The main differences seem to be that the front to back placement of the nozzle is about .5mm or so closer to the front than the originals. The spring is strong enough to force the nozzle down and into the hole that easily fits the originals, but it was also changing the natural angle of the nozzle, tilting it back a bit. I could see where that could catch when trying to remove them from the machine. I enlarged the hole in my holder a little so it can accomodate both nozzles without altering their natural angle. The other difference is that the front curve is very different. It doesn't matter when inserting into the machine, but I wanted the sides of my holders to match the contours of each type of print core. Had to include a cut that allows the nozzle to slide competely into my holder that is only as wide as the Solex, while allowing the original slope to still be visible when storing one of those. Can upload a rendering later tonight that better explains.
Have you experienced weird z height when using the Solex in the 2nd core? I was planning on testing it in the left location with a standard AA 0.4 in the right. As long as the original print core's height works in the right slot, I should be able to print in a smaller font. Do you think the Solex was somehow not moving up/down correctly in slot 2? I thought that might be the case, but it moves up and out of the way when the other nozzle is printing. It just moves down too far (or the bed comes up too far) when it's time for it to print. So it didn't seem like it was catching and not moving up/down correctly. The X/Y calibration was a tad off, +2 & -3. I don't know if the z height is set only from the manual leveling or from the active leveling or some combination of both.
-
I wanted to see if I could print smaller text in a 2-color print so inserted my new 3D Solex print core with the .25mm Ruby nozzle.
No matter how many times I tried manual leveling or ran the active leveler (have it set to run Always), When it came time for the 2nd nozzle to print, it would be about .2mm or .3mm too low, digging into the previous layer, blocking any filament from coming out. It purges the filament correctly and prints onto the prime tower (though, the color is clearly lower than the previous color's primed print), but it's too low to print onto the actual model being printed.
This happened with the last & latest U3Ext firmware as well as sliced with Cura 4.0 and then 4.1. (I like the different prime tower behavior in 4.1)
I thought it might be active leveling misbehaving, so I turned it off and did a few manual levelings. I even tried lying on the last z check step of the 2nd nozzle by having it at least .7mm above the build plate when it should have been as close as the paper as the 1st nozzle. Nothing made a difference at all in the print height. As soon as I swapped it out and put the original AA 0.4 in place, I had perfect z height on the 2nd nozzle. The 3D Solex top clear thumb clip broke while taking it out. That's another issue I have to get worked out! The guy who sent me a few extra original print core nozzzles he had, mentioned to me that his clear clip had broken as well. Anyway...
In the image with the multiple prints, the first four are the 3DSolex runs where the lighter color had dug into the darker previous layer. The last two were printed last and are using the AA 0.4. One with text printed on top of a plain layer, one with the text cut out of the top layer and the text inset into that cutout, both done in Solidworks, not by doing anything tricky in Cura or printing on top of an already printed piece.
Does anyone use the 3D Solex as a 2nd nozzle and does the z height work for it?
-
No matter the extrusion pressure/amount, if you are just letting the filament come out into air and measuring that, it "should" always be the same width, which I'd imagine is the width of the nozzle. If the extrusion goes up, it'll just come out faster. It's when the line is actually printed onto a surface that the width could be affected. The speed of the hotend movement PLUS extrusion amount/rate will change the width of the line when printed onto something, whether onyo the glass or a previous layer. Pushing a lot of filament out of the nozzle onto a surface but moving the hotend very slowly will make a wider/thicker line than pushing a lot of filament out of the nozzle and moving the hotend very fast. Also, the layer height is a factor. And pushing too much in relation to height and speed of the head can cause it to pool up around the shape of the nozzle, creating a "U" shaped line instead of a flat "_" line when viewed from the line's end.
-
Was much easier to solder small things when I was younger! Now, I have to wear reading glasses inside a jewler's magnifyer headset looking through a large round mag-lamp!
-
1 hour ago, ctbeke said:
Mm sounds like the list of printers is not coming back from the cluster. This can sometimes happen after a firmware upgrade. Is any of these things true:
* Is any of the printers in your cluster (if you have multiple) on an older firmware version?
* Do you have a CC 0.6 core installed on the printer?
If not, try a Cura Connect reset on the printer's display, that will wipe any old data that might not be compatible.
I believe the U3Ext has the latest firmware. It's currently printing so I can't look it up. Huh! I didn't realize the .6mm ruby print core was "CC". No. I do not have one of those. I currently have both original AA 0.4mm cores. I own two AA 0.8mm's & a BB 0.8mm which have been installed at one time, but not now.
I'll try a Cura Connect reset tomorrow and report back.
PETG on UM3, not in cura?
in Materials & profiles
Posted · Edited by randyinla
For anyone running Cura on a Mac wanting to add PETG inside CURA so your custom profiles display for PETG materials and the PETG custom material doesn't display in orange, I am now able to see and use any custom PETG materials by creating custom config files matched to printcore & PETG material type.
I found a post by @nyxaria Here where he figured out he had to manually add a file for each material type that does exist on the printer but doesn't exist in Cura to a directory INSIDE the downloaded Cura app. Read through his post as he's included a script to auto copy/edit files for you.
Right-click the Cura 4.8 app and choose "Show Package Contents". Then go into /Contents/Resources/resources/quality/ultimaker3
That directory contains config files for combinations of printcore + material type. Any missing printcore & material type config files will cause that missing material to display in orange and hide all of your custom profiles. So, to add Cura support for PETG on an U3 printer, copy a CPE config file (there are 4 per printcore: Draft_Print, Fast_Print, High_Quality, Normal_Quality) and edit it, replacing the, "material = generic_cpe" with, "material = generic_petg" inside the file and change the name of the new file, replacing "CPE" with "PETG".
Example:
Open the file named: um3_aa0.4_CPE_Normal_Quality.inst.cfg in a basic text editor (NOT a rich text editor or something like MS Word) and change the 11th line to read, material = generic_petg, like so:
[general] version = 4 name = Fine definition = ultimaker3 [metadata] setting_version = 16 type = quality quality_type = normal weight = 0l material = generic_petg variant = AA 0.4 [values] machine_nozzle_cool_down_speed = 0.85 machine_nozzle_heat_up_speed = 1.5 material_initial_print_temperature = =material_print_temperature - 5 material_final_print_temperature = =material_print_temperature - 10 material_standby_temperature = 100 speed_print = 55 speed_layer_0 = =math.ceil(speed_print * 20 / 55) speed_topbottom = =math.ceil(speed_print * 30 / 55) speed_wall = =math.ceil(speed_print * 30 / 55)SAVE THE FILE IN THE SAME DIRECTORY AS: um3_aa0.4_PETG_Normal_Quality.inst.cfg
How Cura looked before I added my custom printcore & PETG config file:
*"Fine - HT.1mm, Solid, 3Walls #2" was selected for the last material, which was PLA, and so displays in the drop down when I change to a PETG material... though, in the "Custom profiles" list, it says it is "Not Supported"
How Cura looks after I copied the Normal CPE config file for aa0.4 print core & made the changes noted above:
(The "Normal" config file displays as "Fine" under the Default materials section in the Profile drop down)
And when I open the Profile drop down, I see all of my custom profiles