Jump to content

lars86

Member
  • Posts

    351
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by lars86

  1. Bummer!

    I can't help but wonder if there is a simpler approximation of this model, that could run well on the arduino, or even just a slicing feature.

    I understand that skeinforge and slic3r (experimental) have features to shift extruder moves relative to print head moves, to help account for this spring induced lag/energy storage effect.

    I was thinking about making a test print that laid down some single filament lines as a "start/finish line" , then approach them at 90* in a print move and right when the print head crosses the start line, begin the extruder move for printing, and at the finish line stop extruding.

    You could look at the distance between nominal and actual start/stop, do this at different speeds and see if there is a correlation of lag time or distance.

  2. No - it's more than that.  That was the first step which then allowed the second step: to add extra velocity when accelerating and remove some when slowing down.  This preloads the pressure and removes the pressure sooner when slowing down than normal extruder movement.  This is especially helpful in printers with Bowdens which store some of the energy/pressure.

    The feature in Marlin that does something similar called "advance" has faulty logic - it may work somewhat but for the wrong reasons.  Bernhard did the math better and realized to do it right you need infinite acceleration/jerk on the extruder and so I think he just kind of gave up instead of trying to come up with an approximation/improvement to Marlin.

    Bernhard has a paper and several blog posts.  Some posted years ago, some posted 3 days ago.  This single image is sufficient though to understand it if you stare at it long enough:

    http://bernhardkubicek.soup.io/post/425547834/My-anti-oozing-algorithm-was-implemented-using

    The UM2 can probably handle the infinite acceleration (it's not a huge velocity increase) as it should be able to handle much larger sudden velocity changes for typical extruding speeds.

    Someone at UM should send Bernhard a free UM2 so he can test this stuff out with that fast feeder.  This could improve "blobbing" on sharp corners and such.  It should help with Bridging also.  It should make it so you can print faster and still get excellent quality.

     

    This deserves a bump!

    Has anyone been experimenting with the "advance" function in Marlin?

  3. Try the new cura!  The slicing engine was rewritten - I'm sure it has all new bugs!  But god rid of many others.

     

    Great to see the new version has gone official!

    I just tested this spiral vase in 15.06.01 and found that instead of a small stutter backwards at "layer changes", it now rapids forwards leaving a gap. It is actually two rapid moves, one larger and one smaller move. If instead of these two rapids, we made a printing move which ended at the final XY coordinates, it would probably work perfectly. I hope they can fix this!

    vase1.thumb.jpg.cf8628708adbe726757b9e6e03aa2d69.jpg

    vase3.thumb.jpg.b4f88af3a7a8a935cf9ddd3994e6ac52.jpg

    vase1.thumb.jpg.cf8628708adbe726757b9e6e03aa2d69.jpg

    vase3.thumb.jpg.b4f88af3a7a8a935cf9ddd3994e6ac52.jpg

  4. Hy,

    I'm a French Maker and we are basically in the same situation, i'm trying to mount the E3DV6 on my Ultimaker. I don't have changed the firmware but directly bought a new Motherboard from Create it Real which is way smarter (and is compatible with SLA for my next printer ;)).

    Do you still have the .stl file of the mount ? Because i have made a diy montage with the original Head support, but it's pretty heavy and ugly to be honest. I'm trying to make my Ultimaker as fast as possible.  

    I have also deported the fan out of the Head and there is now 4 big 12v fans on the frame of the machine, It work pretty well, i have still a really good quality.

     

    Hi Nicolas,

    I'm curious about what benefits you see with that electronics package over the Arduino based UM setup? Does it run proprietary firmware?

  5. I usually print small detailed angular things, this has been a huge thing I've been toying with over the years. Frame rigidity & the surface it sits on plays a big part in it too besides just the acceleration. The more micro 'wobbles' the worse it gets for small 90 degree angles.

    like you I've found around 1500 works best for UMOs I find.

    I run 2300 on my UM2's

    and leave the default 4000 on the UM2GO.

    The small frame of the UM2GO lets that thing go at full speed without introducing much ringing artifacts. it's awesome.

    While lowering acceleration helps the ringing artifacts, it seems to affect the top surface quality. It slows down as it reaches the perimeter sometimes creating thicker fills near the edge, and thinner (sometimes apparent line separations) in the center top of your print. So consider this when making big flat top objects.

    For your ringing test, consider adding some small grooves on the side. That stuff rings like mad.

     

    Nice photo! That really helps illustrate the ringing effect.

    It's cool to see you land very near to me on max acceleration, independently. I agree on the top layer infill aspect as well. I think the narrow rectangular infill section on my part should provide an exaggerated version of that, since the head is constantly in a state of acceleration, likely never hitting commanded feed. If you can find a setting that provides fairly uniform extrusion on this test part, there shouldn't be a worry on a live part.

    On the grooves, do you mean a vertical, square profile groove? I could definitely add those in, but was thinking that the two 90* OD corners would show the same thing. One corner shows the Y axis coming to a rapid stop, with a pure X move following to show any ringing. the other corner shows X stopping. Thoughts?

  6. Hi guys,

    I started writing a reply to an old thread about excessive "ringing" on the UM2 vs UMO. Then is just kept writing and writing, and eventually I decided to just start a thread about this! hahaha

    This should be helpful on any machine really, and can serve as a generalized guide for machine motion tuning. Feel free to ask questions, or correct any errors.

    I think that many are proud of how high they "can" run max accel values, but I am very much of the opinion that there is a sweet spot well short of that.  I run my UMO++ acceleration at 1600mm/s^2, and jerk at 12 for X & Y. I feel like this gives very crisp motion, without beating everything up.

    If the concern is saving time, increasing acceleration is not a reasonable way to achieve this. You would be far better off tuning acceleration for better motion, and running faster print speeds.

    Force exerted on the drivetrain components is directly proportional to acceleration, so the higher max acceleration is set, the more likely you are to exploit lash in the system, or make a more permanent alignment shift (belt slipping in an XY block or against the pulley, pulley shifting on the shaft, stepper shifting in relation to the frame, etc). Also, as I'm sure you guys have seen, there is a natural resonance to the carriage system. Everything supporting and driving the printhead acts elastically (the 8mm and 6mm shafts, the belts, the printhead itself).  

    Printing in one of the back corners helps reduce vibration from the cantilevered bed, and deflection of both sets of shafts. The shafts flex most in the middle, and least where they are supported (frame mounted bearings, and XY block attachments). Printing in the middle of the bed encourages the print head to whip around, riding the wave of the shaft flex, so moving to a back corner reduces ringing two times over.

    The driving belts still have the same force exerted on them and elongation from it, in any print position. Reducing max acceleration is the best way to combat this.

    I encourage everybody to test and tune on their own machine and find the best settings for you. Customizations will have a big impact on machine behavior, especially total mass of printhead (different hot ends, XY blocks, printed heads, fans, etc), since force is also directly proportional to mass.

    The print itself has a big impact on how much the acceleration settings affect things. A good test part would have some big and small vertical holes, sharp OD / ID corners, narrow rectangular sections. I whipped up a model but haven't tested it yet. Feel free to make suggestions on additional features!

    Calibration.thumb.jpg.c63da41fe15c8b0e54f64c3f37c8e4cc.jpg

    Start with a print speed / layer height that you use frequently, and print one of these with your current settings, as your baseline. Don't run slow outside/inside perimeters, as we don't want to hide acceleration effects. Keep speeds of everything equal.

    I suggest 100% infill, 2 perimeter walls, and a filament / temp combo you are comfortable with. Pick a filament that prints very well for you and shows good detail. Then print one with 1600 accel on X&Y and jerk at 12. See what you think of the results.

    Once you have some data points, play around with the settings mid print. Listen to the machine, feel the vibrations through the frame. The motion should be quick and clean, without jarring or vibrating everything. If your accel/jerk is too low, you will see over extrusion in the narrow infill sections. If it is too high, you will see evidence of ringing (like an echo in the print surface) during sharp direction changes.

    For reference:

    • Max acceleration: maximum change in velocity per unit time.
    • Jerk: maximum change in velocity allowed without being bound by max acceleration. Think of it as a "bypass" on acceleration, so be careful here. I would start with this value low (12 or less), get your acceleration well tuned, then increase this and watch/listen to the printer.

    • Like 3
  7. Nice well thought out design Lars!  Do the GT2 belts have good tension without needing adjustment?  Do you have a way to adjust them?

     

    Thanks!

    With 606mm GT2 belts and 20 tooth pulleys, I found no need for additional tensioning. If anything they start out a bit snug, but seem to have relaxed a bit after some use.

    These should work just fine with the stock MXL belts as well. At first my belt clamps had a negative of the GT2 belt profile (which looked cool and fit perfectly), but they forced you into increments of belt pitch. My newer smooth clamp design lets you clamp anywhere, and removes the need to loosen pulleys for alignment.

  8. Hi guys,

    After switching to a GT2 belt configuration, and needing a solid belt clamping mechanism without the complications of integrated tensioning, I decided to design my own XY blocks.

    The factory bronze bushings are very prone to clamping deformation and bind, so I wanted something with separate bushing and belt clamping. I designed these around some replacement bushings I got from Robotdigg that have a 12mm OD instead of the stock 11mm. If there is some interest, I can kick out an 11mm version as well.

    I made allowances to insert M3 nuts into the blocks for all connections, so no plastic threads are relied on. The one exception being that I left holes in the block back face to thread in an M3 bolt in various positions to trip the limit switches. This means all 4 blocks are identical prints, and you decide which need a bolt, where, for limit switch triggering.

    One of the biggest benefits of this design is the ability to square the print head by loosening a single bolt on each block to release the belt. This means no more fumbling with pulley set screws! The other benefit of this is that once the belt is released, there is almost no drag compared to loosening pulleys where you are still moving belts and spinning pulleys on the 8mm shafts. This gives you a MUCH more clear picture of how freely your print head moves. I actually discovered that my printed print head was holding the 6mm shafts slightly out of square, so forcing them square to the 8mm shafts actually induced bind! You can simply loosen the belt clamps on two opposing XY blocks, move the print head back and forth by hand and reclamp.

    https://www.youmagine.com/designs/lars-ultralight-ultimaker-xy-blocks

    XY1.thumb.jpg.913f36cc211936596326bd633d75aa2c.jpg

    XY2.thumb.jpg.ba45eb72118f3a7ef94e84145a7ff337.jpg

    XY3.thumb.jpg.a1add603b7b446244205b0344d1fe91d.jpg

    XY4.thumb.jpg.190d44fa2e232d024bbd368299653e48.jpg

    XY5.thumb.jpg.85d981d0ea28534bf3979018475bb170.jpg

    • Like 5
  9. Well, I've got bad news. I really had hoped for more from this product, especially for the money.

    What I received was a Chinese Android tablet, lacking the feel of decent build quality. I had hoped to also be able to use it as a general tablet. But, it has no battery, so it must stay plugged in all the time, and obviously can't be used as a tablet because of that.

    The rear camera is really bad, and has no autofocus. I had no dreams of a camera on level with my M9, but still hoped for more, even for print monitoring.

    My unit must has been defective, because after connecting to my wifi, and verifying the browser connected, I couldn't get Matter Control to connect for an update (Maps wouldn't connect either). The MC software also crashed a number of times just navigating around, not working on models. It's possible that the newer version available would be more stable, but this did not impress.

    They show it always in a printed cradle, which I assumed was included. Nope, up to you to find somewhere to put it, and keep it hooked up to the short power cable.

    The support response has been very good, and they would replace the unit no problem, but I don't think a fully working unit will be up to my expectation for $300. I don't see where the value has been added over what feels like a $50 tablet.

    • Like 1
  10. Thanks makes sense, thanks for posting!

    I definitely don't think this issue is a result of lacking mesh density. Here is my model:

    mesh.thumb.jpg.f6dfa2eda982fa85d0fbb6107551ea17.jpg

    It seems to me that you could accomplish it one of two ways:

    Find the closest line segment on the next slice to the ending vertex, then linearly interpolate to the nearest point on that segment, and have the first move of the next layer be a print move from the ending vertex to the interpolated close point. This is certainly more intensive in coding and in processing.

    An alternative could be just to find the closest vertex on the next layer, which is generally in the same direction as the last print move. You could find the closest two vertices, one should be "ahead" of the nozzle, and the other behind. Then, you look at the average delta X and delta Y over the last 'n' number of print moves, and see which of the two vertices has deltas in the same direction(s). Again, the first move of the next "layer" is a linear segment from the ending vertex to the closest forward vertex.

    mesh.thumb.jpg.f6dfa2eda982fa85d0fbb6107551ea17.jpg

  11. Hi lars86,

    Thank you for your message. Sorry to hear your idea is not being acted upon.

    It would be an improvement for sure, but currently we are also working on The New Cura which keeps our dev. team very busy. So even though it would be an improvement, it may not receive our priority right now like BagelOrb says. Since Cura is open source, perhaps you could be part of the solution?

     

    It turns out that the link I followed to report the bug is for the new Cura development. I tried the same print in the latest Cura beta, and found a similar bug exists in the new engine as well. I documented it, and uploaded all pertinent files.

    I'm happy to help, but not sure what else I can do. I'm a mechanical engineer, not a programmer. I have plenty of improvement ideas for the build platform, hot end, print head, etc :)

  12. I found that those changes were not adopted in the latest firmware I am using. I backed up those files and hand edited in the changes. There is one line shown in the the change log (but not changed), that doesn't match up:

    Changelog:

    block->acceleration_rate = (long)((float)block->acceleration_st * 8.388608);

    My file:

    block->acceleration_rate = (long)((float)block->acceleration_st * (16777216.0 / (F_CPU / 8.0)));

×
×
  • Create New...