lars86

Kevin, thanks for the replies! This forum is like a ghost town. I'm not sure I'm familiar with a formula like that. There are very basic formulas that govern a circuit like this ( Joule's law, Ohm's law). I have done these calculations. But, how hot somethings gets, is much more complicated and involves heat transfer. I change the firmware quite a bit, so I'm not against it. What do you think needs to be changed? I'm sure that tuning the heater PID parameters will improve the thermal response, but on my first tests, the heater output was pegged at 100% duty cycle (which should be a constant 19V), yet still struggling, so no PID tuning will help that. Using both heater circuits would give you more output capacity, but as the max output of my new configuration is only 10w above the original, I'm not sure that I would need to.

@baasb @tz-advantage @ulbie @foehnsturm Did you guys continue developing your ideas? I have been scheming about a similar cooling setup.

Anyone? I reduced the wall thickness on the heat brake and the seemed to help. I was able to get it running a print (still took a while to reach temperature). But only a few minutes in, the display started doing that "fade out" thing and gave me a "heating failed" error.

Hi guys, I could use a bit of help from the electronic gurus, I'm more of a mechanical guy. I redesigned the whole print head / hot end (again), and decided to use twin heaters for more uniform heat flow. I went with 6mm cartridges rated at 40w / 24V; which I calculated to have about 25w each @ 19v. I figured that running them in parallel for 50w would be plenty. The cartridges are wrapped in aluminum foil to acheive a very tight fit to the block. When I fired it up to test, the hot end had a very hard time reaching temperature. After insulating the heater block a bit, I was able to get up to printing temps (didn't see how high it would go), but it definitely struggled compared to the stock setup. Any ideas as to what could be going on? Did I miscalculate?

I don't have an UM2, so I had to look up pictures, but I fail to see any 6mm shaft cantilevered out like you've drawn. Doing so might change the vibration characteristic a bit, but wouldn't serve to reduce vibration.

@dim3nsioneer Thanks man. Since Z moves are fairly sparse, noise isn't a big concern for me. I'm thinking more about higher velocity/accel, or better precision for thin layer change moves / microstepped spiral vases.

Would there be any benefit from switching the Z microstepping from 8 to 16 after the bed upgrade? It's quite a bit faster pitch.

The newest Marlin build has that section of code rewritten. I'm hoping they nailed it this time: https://github.com/MarlinFirmware/MarlinDev/issues/77

This. After running autotune with 8 cycles, twice over and pushing those calculated values across, this was my bed response: After throwing out those values and starting over manually:

You could say the same for extruder PID settings, but they are listed in the controller menu, and respond to being saved to EEPROM. Seems like there must be a correctable difference in the firmware between extruder and bed settings. That is what I am asking about, not how to do something I have obviously already done.

Right, I was interested in fine tuning without recompiling.

Hi guys, I just enabled PID bed control on my UMO + heated bed kit last night. With the right Kp, Ki, Kd parameters, the result is lightyears ahead of bang bang control. I'm not sure why it isn't the default. The autotune generated terrible values for the constants in my experience, so I have been spending a large amount of time manually tuning the control constants, and am getting it looking very nice. (I'll start another thread for that) My issue, is that the constants don't show up as settings in the Ulti-controller. I can tune them via gcodes, but even if I issue an M500, they don't stick. There must be some other portion of code to uncomment in the firmware. Can anyone point me in the right direction? Thanks!

Did you uncomment just "#define PIDTEMPBED" or "#define BED_LIMIT_SWITCHING" as well?

@dim3nsioneer Was this an issue with your UM2 as delivered? Did you have to modify the firmware settings to fix this?

I finally tore my build platform back apart for modifications. I used two 12" sticks of .75"x.75" aluminum angle stock from McMaster Carr to stiffen the assembly. I found them to be pretty flat out of the box, but I went ahead and gave them a sanding on my granite block to ensure I wasn't forcing the bed to conform to a curved surface. Installation was a piece of cake. I used three M3 bolts on each brace, through-bolted into M3 nuts, to avoid relying on tapped aluminum threads. There were already two thru-holes in the bed platform that I made use of for the frontmost and rearmost bolts. Once those two bolts were secured, I drilled a 3rd hole through the bed and brace, in the middle of the span. While I was at it, I drilled two more holes in the platform, at the Z nut mounting position, to allow use of an anti-backlash nut I got from Robotdigg (for Tr8*8 Leadscrew). It ends up with a slight amount more friction (which I think will come down after break in ), but in return you ensure the Z position is more repeatable. This is especially helpful during Z reversal moves (like Z hop on retract), when this style linear bearing has a tendency to bind slightly.

I tried that the other day. What K value did you use? Watching the motion of the extruder, it looks to be trying to prime / deprime the extruder pressure. I had good results in some areas of my print, but other areas didn't get filled at all. Not sure if it was an anomaly or the pressure advance function, or those fast extruder moves causing skipped steps.

Ah, gotcha! I have played with that too. I used to keep a heavy metal plate in the bottom of my Ultimaker, and have also clamped it to a workbench before. It can definitely help keep things a little more still and quiet, but you have to be careful. Since the UM sits on 4 feet, you can easily overconstrain the bottom plane when clamping. Basically, it only takes 3 points to define a plane, so when you have 4, the fourth needs to very closely match the plane defined by the other 3, or it will not touch the ground ( like a wobbly table at a restaurant). If you clamp everything down, there is a good chance that you force the whole frame to flex in order to put the 4th point down. This would be much worse than a little vibration. My thought is that any print head accelerations fast enough to shake the frame, are also powerful enough to flex the 6mm/8mm shafts. Clamping the frame down won't fix this. You are better off to tune the motion parameters to avoid acceleration this high, and maybe add a bit of weight to the UM floor if you want a little more help.

If I understand you correctly, you are talking about adding mass to the build platform. This really won't help "ringing", since the primary factor in ringing is the 6mm and 8mm printhead shafts flexing. It would help slow vibrations in the bed, and I have done it before I upgraded to the heated bed. It won't eliminate the vibrations though. You are better off trying to make the bed more rigid.

I like it.

So, besides the print end move (XYZE), I am seeing the skipped steps when doing a retracted rapid, with "wipe" enabled. Instead of performing the retract move first, then making the rapid move, it allows the retract to happen during the rapid positional move. So simultaneously it is retracting, doing a Z lift/hop, and moving XY in rapid. This avoids the print head dwell during retracts. It's not the only way to do things, but it should still work in my eyes.

Okay, so I finally edited my planner.cpp to implement those changes. I ran prints that caused this issue back to back with the new firmware changes, using Slic3r's "wipe during retract" option to help show the issue. This causes more frequent movements that involve all axes simultaneously. It seemed to improve it slightly, but the steppers skipping steps still exists. Is there a possibility of fixing this with stepper drive tuning?

It seems like working within existing acceleration values for the head and extruder, you could still implement this. The two main issues are: - There is a relationship between extrusion rate and extruder pressure. (this will vary between hot end design, temperature, filament characteristics, etc). No need to force mathematical modeling in real time of this (in my eyes). Just model it offline to determine correct application and starting coefficient values, then empirically tune the value(s) for your machine/print. - There is a spring effect when using filament to drive extrusion (especially with bowdens). This K will also vary between bowden setup, filament type, etc. The idea seems to be keeping the extruder at the pressure required for the current extrusion rate ( 0 - max mm^3/s), and you can do this by knowing the spring constant K of the drive system, therefor how much linear filament movement is required to get from the current extruder pressure to desired pressure, and doing so slightly ahead of time relative to the print head, to account for the time needed for that prime/deprime extruder move.

Hi guys, Is anyone currently using this successfully? I enabled it in my firmware, and posted code via Slic3r using G10/G11. Despite having the FW retraction menu on my machine and a much slower "recovery" feed rate set, both motions appear to be the same speed (fast). Any ideas what is going on here? Thanks!

Thanks Joerg! The print head is full custom. One of a kind currently. I'm actually modeling up a complete new print head / hot end now. It is a much more minimalistic design, and should save a ton of weight. I think that I have some very solid ideas on improving the hot end to allow high temp use, eliminate jamming and excess friction. I have some 4/5 axis mill turn machines at my work that I can use to make prototypes, and am trying to refine the design for best manufacturability. Hoping it could be feasible to do some production runs. I'm also considering making the print head out of billet aluminum as well (versus printed), to ensure perpendicularity between linear bearings, rigidity, and to help dissipate heat.

I agree. I see evidence of the need for this all the time in my prints. If you could effectively bleed off extruder pressure when approaching the end of a print move, you could get away with much shorter retract moves as well. Then you spend less time dwelling, waiting for the retract to finish. It sounds as if sailfish has implemented this motion control logic without the need for faster hardware. I have to believe that you can simplify the mathematical model to predict the most dominant effects, in a way that isn't computationally expensive.