lars86

It can. You would just add in 4 extra pulleys, and two shorter belts to convert everything.

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.

This deserves a bump! Has anyone been experimenting with the "advance" function in Marlin?

Good call. Slic3r 1.2.9 generates some very nice code for spiralized prints. I like how there is a Z position call on every line as well. Cura seems to post them more sporadically (though I'm not sure there would be a physical difference in the print). I do still hope Cura can be made right in this sense.

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!

Has anyone tried the metal UBIS hotend? http://printrbot.com/shop/metal-ubis-hot-end-2/ Similar clean design, with active cooling for the cold zone.

Did it! https://ultimaker.com/en/community/view/16373-lars-ultralight-xy-blocks

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?

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?

Hi guys, in writing a reply to this thread, it started snowballing and I started my own thread: https://ultimaker.com/en/tips-and-tricks/view/16398-how-to-tune-your-motion-parameters?page=1#reply-109916

https://www.youmagine.com/designs/max-acceleration-tuning-print

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! 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.

Uploaded an 11mm bushing version as well.

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.

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

Yes, I am thankful for that! I'm thinking about just buying a decent windows 8.1 tablet and running the printer with that.

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.

I also agree that any improvements in this logic could help results in non-spiral prints as well. Another reason this should be treated with some significance.

Thanks makes sense, thanks for posting! I definitely don't think this issue is a result of lacking mesh density. Here is my model: 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.

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

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)));

This one? https://github.com/Ultimaker/Marlin/pull/7

Well, I wouldn't hold your breath for a fix. They don't seem to care in the least: https://github.com/Ultimaker/CuraEngine/issues/214 This is the first time I've heard the Ultimaker crew have such a bad attitude.

Is it possible that tuning the stepper driver current could help with this? I've never done that.