Jump to content

randyinla

Dormant
  • Posts

    196
  • Joined

  • Last visited

  • Days Won

    2

randyinla last won the day on December 19 2020

randyinla had the most liked content!

Personal Information

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

randyinla's Achievements

14

Reputation

  1. 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 updated my Ultimaker 3 Extended firmware to 5.2.16.20200331 I noticed a popup inside Cura 4.8 when I opened it for the first time saying it was transmitting missing materials to the U3Ext, so that must be how they are on the printer now. I may have signed into my Ultimaker account in Cura AND connected Cura to my U3Ext under the "Network enabled printers" section of the Settings -> Printer menu first PETG is listed on the printer when loading a new material In Cura 4.8, however, any custom material I select that has its Material Type set to "PETG" displays with an orange background and the Profile drop down displays, "Not Supported" 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 Quit/restart Cura Choose some previously supported material type, like any Ultimaker PLA Choose your custom material that has Material Type: PETG The Profile drop down should've auto-selected the, "Fine" Default Profile if you copied from the, "Normal_Quality" file Opening the Profile drop down should now display all of your custom profiles Repeat for any printcore & material type combination you want to add PETG support for (like for aa08 or aa025 printcores) 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
  2. 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.
  3. 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)
  4. 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.
  5. 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.
  6. I, too, usually uncheck the infill before walls checkbox on most prints.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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)
  12. 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
  13. 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! 😃
  14. 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!
  15. I bought a spool of HydroFill from AirWolf3D but have yet to try it out. It was formulated specifically for ABS prints. https://airwolf3d.com/shop/water-soluble-support-3d-print/
×
×
  • Create New...