Jump to content
Ultimaker Community of 3D Printing Experts
  • Sign Up

randyinla

Member
  • Content Count

    195
  • Joined

  • Last visited

  • Days Won

    1

randyinla last won the day on May 5 2017

randyinla had the most liked content!

Community Reputation

12 Good

Personal Information

Recent Profile Visitors

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

  1. 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.
  2. 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)
  3. 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.
  4. 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.
  5. I, too, usually uncheck the infill before walls checkbox on most prints.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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)
  11. 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
  12. 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! 😃
  13. 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!
  14. 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/
  15. 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.
×
×
  • Create New...