Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login
    1. Home
    2. garethky
    • Profile
    • Following 0
    • Followers 1
    • Topics 8
    • Posts 73
    • Best 22
    • Controversial 0
    • Groups 0

    garethky

    @garethky

    38
    Reputation
    8
    Profile views
    73
    Posts
    1
    Followers
    0
    Following
    Joined Last Online
    Location Settle, WA Age 45

    garethky Unfollow Follow

    Best posts made by garethky

    • RE: Feedback wanted: conditional GCode without indentation

      @wilriker +1

      The target audience for this language is not skilled programmers. Its designers & makers that are trying to solve some problem with their printer. There is going to be a LOT of copy/paste code that mixes indentation types (tabs, spaces, number of spaces). Begin/end constructs survive this kind of abuse better than Python style strict indentation. Having just 1-way-to-do-it makes its safer/easier for newbies copying code.

      The few of us that are writing most of the code can use whatever construct you come up with.

      posted in Future Direction
      garethkyundefined
      garethky
    • Syntax Highlighter for RepRap Gcode

      I've started work on an syntax highlighter grammar for RepRap GCode. These are the results (of some absolute garbage code) in Sublime Text 3:

      Screen Shot 2021-01-08 at 12.37.13 AM.png

      So far it knows about G, M & T commands, expressions, language keywords, comments etc. Open source of course: https://github.com/garethky/RepRapGCodeSyntaxHighlighter/tree/development
      (I'm pointing you to the development branch because its not ready for a mainline release yet)

      I didn't want to do this for just my editor, so I found a tool called Iro. Iro uses a generic grammar and then generates the highlighter files for a slew of popular text editors. Its not perfect, its not open source and I have already found some bugs, but it got me 95% the way there for 1 editor so far (and apparently Sublime is the editor with the weakest support). If you are an editor guru and want to help out I would like your support:

      • You can generate the grammar for your editor using the .rion file on github and test your editor and tell me if it works or not
      • You can contribute the Scope mappings for Pygments & Rogue
      • You want to fix something or make something better, please submit a patch on github
      posted in Gcode meta commands
      garethkyundefined
      garethky
    • rrf-mesh-level: Custom Mesh Bed Probing with Python

      For my E3D Tool Changer I want to have a magnetic bed with swapable build plates. A somewhat surprising roadblock has been using an inductive probe on this bed with G29. With a high enough mesh density its inevitable that the probe samples the magnets and returns a false result:

      Screen Shot 2021-01-24 at 12.23.55 PM.png

      With some GCode meta commands, execonmcode, an attached SBC and Python we can build an accurate heightmap from a set of probe points that miss all of the magnets:

      Screen Shot 2021-01-24 at 12.55.17 PM.png

      Source Code

      I've put everything into a project on github: rrf-mesh-level so you can do this too.

      Results

      Before I talk about how its done lets see how it prints. The best build plate that I have is the Prusa textured sheet so that's what I'm testing on:

      IMG_5953.jpeg

      The lowest square (some over extrusion is present):

      IMG_5956.jpeg

      An average square:

      IMG_5955.jpeg

      The highest square (some under extrusion is present):

      IMG_5954.jpeg

      I could nitpick but I think you see the technique works.

      How?

      The process goes like this:

      • Probe the bed and log the probed points to the SD card
      • Use execonmcode to invoke mesh-level.py with the log file and bed shape
      • mesh-level.py uses Python/SciPy to processes the probe data with some cool math and produce a heightmap.csv file
      • Profit! 💰

      Step 1 - Probing

      You will need to work out what X/Y points you want to probe your bed at. I used a CAD model of my bed to measure X/Y probing locations from machine 0,0. Then I used a Python script to generate the GCode for probing each point. This takes the sensor offset and sensor travel speed into account. My bed.g file contains all the probe points that were generated. This is the truncated version:

      ; delete any previous log file so previously probed points don't get sampled
      M30 "/sys/meshbedprobe.log"
      ; start INFO logging to the SD card
      M929 S2 P"/sys/meshbedprobe.log"
      
      ; probe bed points by moving to each X/Y coordinate and then calling the point probe script
      ; Probing row #1, Direction: ->
      G1 X{32.353 - sensors.probes[0].offsets[0]} Y{-11.0 - sensors.probes[0].offsets[1]} F{sensors.probes[0].travelSpeed * 60}
      M98 P"/sys/probe-point.g"
      
      ; ... many, many more points get probed
      
      ; stop logging
      M929 S0
      

      The probe-point.g macro is where the actual probing of individual points happens. It uses a loop and G30 S-1 to probe the location and M118 to write the results of each probing to the open log file. You don't have to copy this, any macro that writes the same Mesh Point: Xn Yn Zn format will work with the python script. The resulting log file looks like this:

      2021-01-24 12:26:58 Mesh Point: X32.355 Y-11.000 Z-0.254
      2021-01-24 12:26:59 Mesh Point: X32.355 Y-11.000 Z-0.254
      2021-01-24 12:26:59 Mesh Point: X67.030 Y-11.000 Z-0.313
      2021-01-24 12:27:00 Mesh Point: X67.030 Y-11.000 Z-0.314
      

      Step 2: Calling Python with execonmcode

      Using the excellent execonmcode utility we invoke the mesh-level.py script using a custom MCode M7029 from inside bed.g:

      ; call the custom MCode to create the heightmap.csv file, all params must be passed as strings
      M7029 X"0:300" Y"0:200"
      

      The parameters here are the same as X, Y from M557
      The script supports a lot more parameters besides these, the file names, point spacing etc. can be customized if desired.

      Building the heightmap.csv

      mesh-level.py uses something called Radial Basis Functions (RBF) to compute an interpolated surface from your probe point data. The surface is a high quality representation of the bed shape where the surface passes through all of your probe points (no smoothing is performed). The more points your probe, the better that representation is going to be.

      RBF has some characteristics that make it very useful in this application:

      • It can work with scattered X/Y input points, they don't need to be in anything like a regular pattern
      • It can extrapolate beyond the bounds (convex hull) of the probed points. This solves the problem of not being able to probe right at the edge of the bed and allows the final heightmap to cover the entire printable area
      • It can be up-sampled. The final heightmap point density can be higher than the sample density! This leaves the liner interpolation code in RRF with less guessing to do and better encodes curves in the bed surface. The script automatically tries to use up as much of the 441 points that RRF allows.
      posted in Gcode meta commands
      garethkyundefined
      garethky
    • RE: Slow/Unreliable SPI Communication when Logging with M929??

      I switched to a SanDisk Extreme 128GB card and that totally cleared up the issue. This is one that I use for recording 4K video.

      The card I had before was a Kingston 16GB card I got with the Pi.

      I'm happy that I figured out a way around this, but I'm surprised that the async/await programming constructs don't protect us from I/O flakiness!

      • The file is wrapped in a StreamWriter that should have a 4K buffer
      • The whole call chain is async/await. Log writing doesn't have to complete before the next GCode instruction executes (at least from what I can read without debugging it).

      I was going to suggest keeping a queue of logging data and writing it on a separate dedicated thread for I/O. But StreamWriter is basically that. (the only difference being that the log time can be captured without trying to lock the file)

      So yeah, not sure how the code should change. But if you are having problems, get a FAST SD card.

      posted in DSF Development
      garethkyundefined
      garethky
    • RE: Resonance, spreadCycle and stealthChop

      So the StepperOnline 17HS19-2004S1, I'll admit I was skeptical. It doesn't sound any quieter in Stealth Chop mode, if anything its noisier. But in Spread Cycle, its significantly quieter and smoother than the Moons. So quiet that I think I could live with them in Spread Cycle mode in general and leave them on the printer. That's a big deal if you are on the Duet 2 and don't have access to Stealth Chop.

      The other big difference is the low frequency rumble is greatly reduced.

      I don't know why any of this is so?

      The moons are 1.04 Ohm and 2.2mH
      The Stepper Online motor is 1.4Ohm and 3.0mH

      posted in Tuning and tweaking
      garethkyundefined
      garethky
    • Wait for passive thermistor temprature to stabilize

      Do you have a passively heated chamber? Maybe one of those thick Rail Core beds with the secondary thermistor on top? Wouldn't it be cool if you could wait for that temperature to stabilize before starting your print?

      I'm talking about something like this:
      Screen Shot 2021-01-29 at 10.25.26 AM.png
      Top Bed Temp takes ~6 minutes to stabilize after the bed reaches temperature. That's going to cause the bed to change shape as it heats through, possibly messing up the mesh bed leveling. Also the temperature or the print surface is supposed to be 90 degrees, but at the point when the bed heater reports that it has heated its barely 60.

      The trouble is generally we don't know what temperature we are waiting for. There is going to be some thermal loss and the temperature will change with the environment's temperature, airflow etc. Really we don't care about the exact value, we just want to know its not changing before printing. So instead of a fixed temp, we can look at the rate of change of the temperature (delta T) and wait for this to fall below some desired value.

      ; wait for the top bed sensor to stabilize
      G10 L2 P9 Y0 ; keep the loop counter here because it can't be used in sub-expressions
      while true
          ; Store the current temperature reading from the Top Bed thermistor:
          G10 L2 P9 X{sensors.analog[5].lastReading}
          
          ; Dwell for 500ms
          G4 P500
          
          ; if the temperature increase is less than 0.01 C over that time break the loop
          if {sensors.analog[5].lastReading - move.axes[0].workplaceOffsets[8]} < 0.01
              echo "Top of bed temperature stabilized at ", sensors.analog[5].lastReading, "C in ", move.axes[1].workplaceOffsets[8] / 2, " seconds"
              break
          
          ; if 5 minutes has passed abort with an error
          if {{move.axes[1].workplaceOffsets[8] / 2} > {5 * 60}}:
              abort "Bed temp stabilization failed after 5 minutes"
      
          ; increment the loop counter
          G10 L2 P9 Y{move.axes[1].workplaceOffsets[8] + 1}
      

      (source in my printer repo)

      When the temperature stabilizes it prints a message to the console:

      Top of bed temperature stabilized at 74.865C in 18.5 seconds
      

      The script will wait for up to 5 minutes before it gives up. You can extend the waiting time, the sensing interval and the threshold to suit your application. With variables it will become possible to do a better job by saving more temperature history, but this works OK for now.

      Even without variables I still need to store the loop counter and the last temperature reading. I'm using workplace offsets 9 as my temporary variable storage area. Be careful this doesn't conflict with with your printer's configuration.

      posted in Gcode meta commands
      garethkyundefined
      garethky
    • RE: Request for Filament Tweaks

      @chrishamm awesome! I will make both PRs. I don't think its very complicated at all, and from what I read in the C code there wont be any side effects. It doesn't cause a memory leak or anything like that.

      posted in Firmware wishlist
      garethkyundefined
      garethky
    • RE: Resonance, spreadCycle and stealthChop

      +1. I have the same issue with my E3D Toolchanger. I have changed over to 0.9 degree motors and that helped a lot but it did not entirely go away. I have the same vibration problem you are talking about and the community has noticed the same as well. Similar speeds as you demonstrated too.

      Going faster is smoother, switching to 0.9 degree motors is basically doubling the speed. I've also ended up with Stealth Mode being the quietest.

      posted in Tuning and tweaking
      garethkyundefined
      garethky
    • RE: load unload macro with endless loop and cancel condition

      I just did this and I deeply loath writing a macro for every filament. I'll have to go back and try G701 inside load/unload to save some extra lines that are not totally DRY. Here is what I did:

      each filament has a config that defines some variables

      ; set filament name, temperature and speed "variables"
      M563 P5 S"PLA"
      G10 P5 X215 Y300
      
      ; set retraction parameters
      M207 S0.4 F2100
      

      When I make a new filament, this is a bsically all I have to do now.

      Then load.g and unload.g just load up those variables and call a macro (this is where I need to try M703):

      M98 P"/filaments/PLA/config.g" ; the filament config isn't loaded until AFTER this macro runs, but we need the variables set now.
      M98 P"/macros/Filament/loadFilament.g"
      

      Then my load macro looks like this:

      ; loadFilament.g
      
      ; ask the user if they really want to light up the heater and load some filament
      M291 S3 P{"Click OK to heat to " ^ tools[5].offsets[0] ^ "C and load " ^ tools[5].name} R{"Load " ^ tools[5].name ^ "?"}
      
      ; Set current the configured temperature and wait for the extruder to reach temp
      M109 S{tools[5].offsets[0]}
      
      ; Pause and ask the user to position the filament for feeding
      M291 S2 P{"Load filament in the extruder and click OK to start loading " ^ tools[5].name} R{"Ready to Load " ^ tools[5].name} 
      
      M83 ; Extruder to relative mode
      
      ; rapidly feed filament from the gears to the bottom of the heat break
      G1 E58 F900 ; Feed 58mm of filament at 15mm/s
      G1 E30 F300 ; Feed 30mm of filament slowly
      
      ; purge and ask for more loop
      while true
          G1 E30 F300 ; Feed 30mm of filament slowly
          M400; Wait for moves to complete
      
          ; ask the user if they want to do that again?
          M291 S3 P{"Click OK to purge some more"} R{"Continue purging?"}
      

      So it asks put the temps and the filament name in all the messages. Plus it has a loop to purge more plastic and you can keep doing that as long as you want. (See the whole commit on github)

      When variables are implemented this will become so much less ugly.

      My next challenge is finding a way to check, at print start, if the filament/tool pairings in the print match the filaments configured on the tools in in the printer and abort if they don't 😔

      posted in Gcode meta commands
      garethkyundefined
      garethky
    • RE: Request for Filament Tweaks

      No one replied and I'm not keen on wasting my time building and testing a change that the maintainers will not accept because it conflicts with your future plans for the software.

      Going by whats written there: https://duet3d.dozuki.com/Wiki/Filaments#Section_Loading_filaments

      ". You can only load one filament at once. The current filament mechanism is intended to reflect your spools and the underlying mechanism will be likely enhanced to include some usage statistics as well."

      My PR would be to expressly remove this idea. If you want to track filament usage per-spool then you should add that as a separate feature for spool tracking. I don't think the two ideas are incompatible, If you add spool tracking as an extension to filaments you can make the individual spool the thing that can only be loaded into 1 extruder. But we don't have that yet, and even if we did, I don't see why I would copy my filament config for every spool of filament that I buy. Nor would I want the filament selection menu cluttered with dozens of spools of filament. Config for a filament type and tracking data for an individual spool are two different concepts.

      You can keep a file for spools in the filament directory with per-spool statistics. Making a new spool of PETG wouldn't require copying a filament, its just a new line in the stats file. After you select a filament you can then, optionally, select an individual spool if you want to do spool tracking. This de-clutters the main selection menu.

      Can I get a response so I can move forward on this @dc42 or @chrishamm?

      posted in Firmware wishlist
      garethkyundefined
      garethky

    Latest posts made by garethky

    • RE: slicer printing time vs real printing time

      No, I gave up the investigation. Something about the simulation isn't accurate. Something about the real print time isn't right either.

      posted in General Discussion
      garethkyundefined
      garethky
    • RE: Resonance, spreadCycle and stealthChop

      Try the motors, its worth a shot. What you showed in the video its very similar to how the Toolchanger behaved a certain speeds. The frame itself isn't a source of vibration, it can only resonate. For my case its clear the motors are adding the vibration to the system.

      StealthChop is another way to prove its the motors/drivers adding the noise. Maybe it wouldn't achieve your performance goals but it would be a good data point to show that the mechanical system can indeed be quiet.

      posted in Tuning and tweaking
      garethkyundefined
      garethky
    • RE: Resonance, spreadCycle and stealthChop

      So the StepperOnline 17HS19-2004S1, I'll admit I was skeptical. It doesn't sound any quieter in Stealth Chop mode, if anything its noisier. But in Spread Cycle, its significantly quieter and smoother than the Moons. So quiet that I think I could live with them in Spread Cycle mode in general and leave them on the printer. That's a big deal if you are on the Duet 2 and don't have access to Stealth Chop.

      The other big difference is the low frequency rumble is greatly reduced.

      I don't know why any of this is so?

      The moons are 1.04 Ohm and 2.2mH
      The Stepper Online motor is 1.4Ohm and 3.0mH

      posted in Tuning and tweaking
      garethkyundefined
      garethky
    • RE: slicer printing time vs real printing time

      I tried printing the 100mm/s test and the printer prints at the requested speed.

      Screen Shot 2021-02-20 at 2.26.08 PM.png

      Also note that the time for individual layers in perfectly consistent as expected. Its the simulation that is wrong in this case.

      My guess is my real speed issue is related to Z or E as I originally suspected but I'm unable to see that from the simulation.

      posted in General Discussion
      garethkyundefined
      garethky
    • RE: slicer printing time vs real printing time

      Oh and here is a cube for comparison, same vase mode, 100mm/s perimeters etc:

      Screen Shot 2021-02-19 at 11.25.37 AM.png

      Screen Shot 2021-02-19 at 11.24.34 AM.png

      The printer is happy to do 100mm/s and take square corners that fast. Its not a printer settings issue. My computed speed estimate for that is 88.6mm/s.

      posted in General Discussion
      garethkyundefined
      garethky
    • RE: slicer printing time vs real printing time

      @T3P3Tony said in slicer printing time vs real printing time:

      do you have a min layer time set in the "cooling" settings (that may be different)?

      Yes, but even so, the slicer would include that in its estimate, it knows what it did. But I'm going to disable it for this test because its irrelevant.

      @Phaedrux said in slicer printing time vs real printing time:

      Not sure if you've tested this yet, but can you try using firmware retraction instead to see if it changes the outcome?

      I can tell you from prior experience it wont but I will go one better, lets eliminate all retracts from the test print. We can do that with spiral vase mode. No retracts the whole way up, no travel moves other pauses, just plain circles. This is simple enough that we can make an estimate of print time based on the radius (50mm), height (100mm) and print speed of 35mm/s:

      2Ï€ * 50 = 314.2 circumference
      100mm / 0.2 = 500 layers
      500 * 314.2 = 160600 mm traveled
      160600 / 35mm/s = 1h 16m approximately

      The slicers estimate is 1 hour 24 minutes which is pretty close to our estimate. You can also see see the slicer is emitting moves for a 35mm/s speed (this is the configured outer perimeter speed):

      Screen Shot 2021-02-19 at 10.17.09 AM.png

      Then simulate it on the Duet:

      Screen Shot 2021-02-19 at 10.16.24 AM.png

      We can then estimate the Duets actual achieved speed as 160600 / 1h 46m 58s = 25.02mm/s
      That's a loss of 10mm/s from the desired speed.

      And just out of curiosity, what happens if the outer wall speed were a lot faster? Say 100mm/s? Is the effect linear or constant?

      This is where my Jaw hit the floor. Its not a constant effect, going faster makes it worse:

      Screen Shot 2021-02-19 at 11.14.42 AM.png

      Screen Shot 2021-02-19 at 11.15.01 AM.png

      So that's 160600 / 1h 22m 11s = 32.5mm/s

      posted in General Discussion
      garethkyundefined
      garethky
    • RE: slicer printing time vs real printing time

      I tried slicing simpler shapes.

      A 100mm cube with no infill, printed square and at 45 degrees to the printers axes, no top or bottom layers. Both simulations are within 2 minutes of the slicer's predictions.

      100mm diameter cylinder, 100mm tall, no infill, no top or bottom layers. Seems the problem is with curves:

      Screen Shot 2021-02-18 at 4.26.53 PM.png

      Screen Shot 2021-02-18 at 4.46.15 PM.png

      First of all, extruder and z settings are not the root cause here. There are just as many retractions in the square test so that should have impacted both shapes equally. This is about X/Y moves. That's the same conclusion I came to in previous tests.

      Second the variance in layer time here is bizarre. Min layer time is 19s and max layer time (not first layer!) is 34s. All the layers are basically the same. There are no travel moves.

      So what, if anything, can fix this?

      • Doubling speeds to 360mm/s: no impact
      • Doubling accelerations to 4000mm/s: no impact
      • Raising jerk by 10x to 20mm/s: no impact
      • Raising jerk to 100mm/s: no impact
      • 10x speed, accel and jerk on X,Y,Z & E: no impact

      Cool! So its not my config or 👽 👽 👽

      The gcode asks for a specific speed and acceleration that is well within the printers configured limits. The firmware thinks it achieved those requested speeds and accelerations. But the print time is almost an hour longer than the slicer's estimate.

      Can we call this a bug now?

      posted in General Discussion
      garethkyundefined
      garethky
    • RE: slicer printing time vs real printing time

      @T3P3Tony Diffing the files is an excellent suggestion, thank you!

      The two profiles have differing retract lengths distances. But unfortunately this was in the favor of the Duet printer, it is set to 0.4mm and the MK3S is set to 1.4mm. Other than that the two slices make the same moves with the same speeds.

      I set up a profile that the two printers could share so they can slice under exactly the same settings. The only diff I can find is this:

      Screen Shot 2021-02-17 at 5.47.21 PM.png

      For some perimeters, the MK3S gets a slightly higher feed rate. I actually can't find the setting that controls that?

      But I can force 10mm/s higher perimeter speeds on the Duet machine to compensate and run the simulation. Its still about the same amount slower, as reported above, in my simulations.

      posted in General Discussion
      garethkyundefined
      garethky
    • RE: slicer printing time vs real printing time

      This is the most relevant thread to my observations so here goes:

      Prusa Slicer says that Duet is slower than Marlin. Sometimes a lot slower.

      Here are the baseline speed related settings we are working with:

      M203 X{300 * 60} Y{300 * 60} Z{10 * 60} C{300 * 60}  E3600:3600:3600:3600    ; Max speeds (mm/min)
      M201 X2000       Y2000       Z240       C400         E3000:3000:3000:3000    ; Max accelerations (mm/s^2)
      M566 X{10 * 60}  Y{10 * 60}  Z{2 * 60}  C{0.6 * 60}  E600:600:600:600        ; Max instantaneous speed changes/Jerk (mm/min)
      

      These limits have been entered into the slicer. My Duet printer has a lower top speed than the my Prusa MK3S (170mm/s vs 200mm/s). This means it cant hit the 180mm/s travel speeds in the default 0.2mm Quality profile. So that has been reduced in the slicer to be 150mm/s. Both printers have acceleration limits higher than the highest requested acceleration of 1500mm/s^2. I have further tweaked the profiles so I'm asking both printers to print the file at the same speeds. But I have given the Duet the benefit of the higher jerk limits in the slicer.

      I have also tested by printing and I am sure that:

      • The Prusa Slicer estimate is accurate and a Prusa MK3S will print these jobs in the time estimated.
      • The Duet's simulation is accurate. Real print time reported in DWC matches the estimates closely.

      I'm slicing and testing 2 models, one is the Benchy and the other is a bunch of parts for my extruder. since the Duet's simulation is accurate I should just be able to tweak settings and simulate until the two estimates line up, right?

      Benchy slicer time estimate: 1h 33m 22s
      Extruder Parts slicer time estimate: 5h 53m 57s

      Now the Duet simulation times:

      | What settings were tested?                             | Benchy     | Extruder Parts |
      ----------------------------------------------------------------------------------------
      | stock settings                                         | 1h 46m 52s | 7h 13m 37s     | 
      | pressure advance off                                   | 1h 47m 7s  | 7h 16m 48s     | 
      | Jerk Policy 1 `M566 P1`                                | 1h 45m 55s | 7h  9m 53s     | 
      | Raise X/Y/Z/E Acceleration by 10x                      | 1h 40m 24s | 6h 50m 42s     | 
      | Raise X/Y/Z/E Jerk by 10x                              | 1h 38m 46s | 6h 30m 6s      | 
      | Raise X/Y/Z/E Accel & Jerk to 10x, Jerk Policy P1      | 1h 31m 0s  | 6h 3m 49s      | 
      

      So I was able to get very close to the slicer estimates, but I had to set incredibly high jerk and accelerations to do it. This is discouraging, because I cant operate a printer with (checks notes) 100mm/s of jerk in X and Y (on the MK3 its just 8mm/s!).

      But I tried anyway! Starting at 20mm/s of x/y jerk the printer is positively violent. There is no way I would operate a printer like that.

      The X/Y Jerk was the variable with the most impact on print time. This is not what I expected when I started the investigation. I thought my Z or E was killing me.

      I don't understand this at all! 😕😕😕

      I don't think jerk is the right answer. Looking at both printers, they look similar in terms of how snappy they are. So I'm left to wonder:

      • Is the clock in the duet is broken? It reports 7 hours of printing time but maybe the real time is less and we wont find this out without using an external timer?
      • Is there a bug in the Core X/Y kinematics that fails to apply the speeds and/or accelerations requested?
      • Aliens? 👽 👽 👽
      posted in General Discussion
      garethkyundefined
      garethky
    • RE: Request for Filament Tweaks

      @chrishamm awesome! I will make both PRs. I don't think its very complicated at all, and from what I read in the C code there wont be any side effects. It doesn't cause a memory leak or anything like that.

      posted in Firmware wishlist
      garethkyundefined
      garethky