Jump to content

UM1 resolution


Recommended Posts

Posted · UM1 resolution

I placed my order for a UM1 kit one week ago and it arrived yesterday.

I chose the UM1 over all of the other machines because of the stated resolution that could be obtained.

I'm a retired EE and love to analyze designs, understand them, and possibly make them better -- hence the UM1 so I can modify it at will.

It will take me some time to assemble the machine, tune it, and get comfortable with what MY machine can print from a resolution point of view.

I ask the following question to those existing technical users so I can obtain your insight and ponder on them awhile.

Given the existing mechanical design, wood, belts, etc -- those parts of the system will result in the minimum obtainable print resolution. THAT bottom floor can not be changed without a change to the hardware.

From that level of resolution (what ever it is) -- we have what the electronics can do. How the steppers are driven, the capability of the CPU (Arduino in this case).

Looking at the controller board, I see the X-Y steppers are being driven in 1/16 micro-steps. (I suspect that has to do with the performance capability of the Arduino).

Taking the CPU/Micro out of the equation, if the controller board could step at 1/32 or 1/64 or 1/128 --- would the increase resolution realized from the steppers be realized in the print?

It will be awhile before I can run my own test - so I would appreciate any insight/comments you might have.

Thanks in advance.

Joe Hinkle

 

  • Link to post
    Share on other sites

    • Replies 51
    • Created
    • Last Reply

    Top Posters In This Topic

    Posted · UM1 resolution

    IIRC the steppers on the UM are 200steps/rev -> 1.8degrees/step. With microstepping at 1/16 we're at 0.1125degress/step. I can't remember the diameter of the pullies but let's say they're 15mm in diameter, I think that's a reasonable guess. Each step would then move the outer part of the pully 0.01mm per step.

    Unless I'm completely off with my calcs that sounds like pretty decent resolution to me. How much more are you looking to get?

     

  • Link to post
    Share on other sites

    Posted · UM1 resolution

    Why not .005mm or .0025mm per step.

    If THAT resolution is not swamped by the minimum imposed by the hardware - why not.

    The question is - if you can acquire a resolution of .005mm or .0025mm per step - will you see it in the print?

    You can definitely see print difference between a UM1 and it's competition --- so can the UM1 do any better if the micro-stepping on the motor can be increased?

    Thanks.

    Joe

     

  • Link to post
    Share on other sites

    Posted · UM1 resolution

    Without any actual evidence to lean against I'd say no, there's no way you'd see that difference. You have bigger variances in the plastic coming into the printer to start with. Then you have slight wiggles of the bed, vibrations from the floor and the machine itself, irregularities in the pullies perhaps, slight movement in the wood etc etc etc.

    0.005mm is ridiculously tiny and I doubt you can get that sort of resolution, and more importantly, repeatability outside of a big chunky CNC mill.

     

  • Link to post
    Share on other sites

    Posted · UM1 resolution

    My question keeps going back to print quality.

    I agree that .005 is very small and having that obtainable step resolution my be in the mud of the hardware resolution.

    But .... when you step a stepper motor you actually induce an oscillation and error term into the mechanical displacement.

    Think no micro-stepping --- just cogging the motor at its rated angular rate of 1.8 deg per step. THAT would produce noticeable artifacts in the print. Print a straight line ... you will see the jogs.

    By decreasing the micro-step size - less energy is required because less of a distance has to be covered so the artifacts associated with that error term will decrease.

    So -- stepping at .005mm or .0025mm per step may still have a measurable resolution of .01 --- but the print surface may be noticeably smoother.

    Just looking for comments.

    Thanks

    Joe

     

  • Link to post
    Share on other sites

    Posted · UM1 resolution

    Whoa, that just flew right past me...

    From a normal non-tech savvy user of a UM1 Kit... I find the biggest limiting factors to be the nozzle at .40mm. So the smallest detail you can create on the XZ plane is .40mm's regardless of Y resolution being a lot finer.

    Want to print a small antenna? not possible if it's anywhere close to .40mms in diameter.

    The second limit being heat. If i wanted to print a 1mm diameter pillar, the heat, oozing and size of the nozzle will pretty much guarantee you a blobby mess. Fans and lowering the speed may help, but there's a pretty hard limit before things get all imprecise due to heat applied in a concentrated area without time to cool and solidify.

    I've never felt that the motors were the cause of any innaccuracy. The only mechanical problem I constantly seem to come across however is the ringing the happens on sharp turns.

    gallery_7531_65_139609.jpg

    I've since reduced this with lots of suggestions from folks here, but still not quite as good as I'd like. The UM2 prints seem a lot better about the ringing, most likely due to it being more solid and weighty than wood.

     

  • Link to post
    Share on other sites

    Posted · UM1 resolution

    The firmware is soft limited at 40,000 steps per second on any axis. I heard it suggested that that was a conservative limit for the Arduino Mega 2560 hardware, and 60,000 might be closer to the physical limit.

    In either case, the x and y axes are driven at roughly 80 steps per mm - so the maximum speed is about 40000/80 = 500mm/s on the x and y axes. In practice, that's about twice the speeds that are likely to be used, so you could probably double the microstepping again, and still have the hardware able to keep up.

    As others have noted though, I suspect that any slight difference from moving the head in 1/160mm increments rather than 1/80 is likely to be swamped by the other factors such as the variability in filament diameter, the viscosity of the plastic itself as it is extruded, and the challenge of keeping the extrusion rate in step with the head speed as the head accelerates and decelerates in the corners. Additional CPU bandwidth is probably better spent modeling - and then controlling - the nozzle pressure more accurately, rather than worrying about toggling the stepper controls twice as fast.

     

  • Link to post
    Share on other sites

    Posted · UM1 resolution

    The nozzle diameter is .4mm and that restricts your "resolution" more than anything else. The Z resolution is fantastic - you can get down to .05mm without too much trouble. So sometimes things are printed "on their side" to increase resolution at least in one axis.

    So back to the .4mm - diameter - that's actually a .2mm radius so if for example you print a square in the XY plane the corners will have a radius of .2mm. This is by far the limiting factor. Some people have bought/built .25mm nozzles (you can by them cheap). The problem however is that it prints much slower and gets jammed more easily. But I've seen fantastic results.

    Things like ringing in the photo above are easy to remove - just lower your acceleration. Basically speed and quality are a constant tradeoff. If you are patient and don't mind printing for several days you can get pretty amazing quality.

     

  • Link to post
    Share on other sites

    Posted · UM1 resolution

    Another questions for those technical users ....

    Besides building and tuning my new UM1 kit (just received), I decided to make my own controller board.

    I will simply swap out the Arduino board with my own design.

    Looking at the GCODE - the Extruder is simply told to push a specific amount filament during the duration of the GCODE segment.

    I've done some testing and plotted the print head velocity from start of segment to end of segment and then from one segment to the next. The print head velocity is the actual nozzle velocity derived from movements along both X and Y stepper sub-systems.

    See pics attached: Each vertical line is a GCODE segment with the line length being the start and ending nozzle velocity. The grid lines show nozzle velocity at 100mm/sec, 200mm/sec, and 300mm/sec.

    I'm in the process of developing the driver for my extruder stepper and hence where my question arises.

    How well does your existing system lay a bead as the print head moves?

    If the extrusion is not managed to track nozzle velocity, you can have a think bead when nozzle velocity is slow and a thinner bead when the nozzle is moving at at higher speeds.

    Any comments about your bead quality is appreciated.

    Thanks.

    Joe

    The plot if from the first layer of printing the robot that comes as an example with the UM1.

    UM1_2.png

     

  • Link to post
    Share on other sites

    Posted · UM1 resolution

    Have you looked at the Marlin or Repetier firmwares?

    There's a lot of smarts build into the movement planning to keep the x, y, z and e axes all in step with one another as the head accelerates in and out of the corners. The system allows for different maximum acceleration rates on each axes, and will also limit the motion plan to control the maximum velocity change at a corner.

    I don't understand you graph... I thought it was a velocity over time, but I'm not clear why the acceleration rate isn't constant. So, I'm thinking its something else; can you explain it a bit more please?

    Also the case you describe where the width of the extrusion varies over time as the head speeds up seems to be assuming a constant extrusion rate. That might have been the state of the art in RepRap printers a long time ago, but since the advent of 5D firmwares several years ago, the extrusion motor is controlled in lock step with the other axes. So the extrusion rate is directly proportional to the head speed, even as the head speeds up and slows down along its path.

    Where there *is* a potential issue - as I alluded to above - is that the extrusion rate isn't directly proportional to the amount of plastic fed in, but rather is a function of the pressure in the extruder head. Therefore, when the extrusion rate changes, it takes a little time for the pressure to change, and hence for the extrusion rate to respond. As a result, when the head is slowing, it can take a little time for the extrusion rate to slow down to match, and when the head accelerates again, it takes time for the extrusion rate to catch up. Not because the extruder motor isn't keeping pace with the changes, but because the effect is more subtle - the pressure in the head needs to be modeled, not just the infeed rate. There needs to be a lag factor taken into account, so that pressure is appropriate to the head speed, not just the extruder feed rate.

     

  • Link to post
    Share on other sites

    Posted · UM1 resolution

    Thanks for your response.

    The plot is not time on the Horz axis but gcode segments.

    Time is not shown. I was interested in visualizing nozzle velocity at the start of each segment and at the end of the segment and how they would smoothly move from one segment to the next. Acceleration is there - you just don't see it -- If only showing the start and ending nozzle velocity of each gcode segment.

    I am purposely not looking at the Merlin code. I find for me, going through the creation process allows me to do some out-of-the-box things. I'm hoping my work here will result is something as good or better.

    There are a lot of articles on real-time stepper systems -- most all quote the work of David Austin. They all speak to the trapezoid profile. They are interesting and insightful when working with a single stepper.

    Controlling a 3D print head involves 3 steppers - as you stated - tightly coupled.

    Currently I am controlling the X and Y steppers with the focus on nozzle velocity - not stepper axis speed.

    Nozzle velocity (as you stated for turning corners, etc) is critical. You have to manage acceleration and de-acceleration of both X and Y steppers to smooth nozzle movement.

    I've tested both 1/16 micro-step and 1/32 micro-step steppers. The results so far suggest it's a toss up if 1/32 will actually provide a noticeable result. 1/32 does provide for smoother operations because of the finer granularity --- but --- we'll see.

    Currently I'm using constant acceleration and limiting nozzle speed to a maximum velocity - 300mm/per to 550mm/sec.

    I tested accelerations from 3000mm/sec/sec to 9000mm/sec/sec. I was hoping the manufacturer would specify max acceleration rates but they don't. Hardware testing will provide me that.

    In pondering the extruder, I had a thought as to why the UM continues to stay with a 2.85mm filament instead of 1.75mm that tends to be more available here where I am (in the States). It has to do what you mentioned - pressure.

    For a given drive force on the filament, a 2.85mm filament will produce more pressure in the melting chamber than a 1.75mm because of the increased surface area. Depending on the volume of the heating chamber - this may be both good and bad.

    My current extruder system models the velocity profile of the nozzle - not the X/Y steppers - and attempts to move the amount of plastic specified in the gcode along the nozzle path taking into account nozzle velocity, melting chamber volume, nozzle opening, and head temperature --- hopefully producing a constant bead size.,

    I know this has all been done before --- there is a good controller in the UM1 kit I just purchased. It seems the the Ardunio solution has been around awhile --- but everyone is using the same core. I'm hoping that by taking a fresh, non-Ardunio, approach --- I might just end up with something better.

    I very much appreciate your technical comments.

    Joe

     

  • Link to post
    Share on other sites

    Posted · UM1 resolution

    So what about "jerk"? If you print for example a square pattern in X,Y. At each 90 degree corner you either have to come to a complete stop (very slow printing) or you get infinite acceleration (in theory only of course) at the corner.

    That's fine for a square but it gets worse for a circle with say 50 line segments. (a 50-gon). At each vertex you theoretically have infinite acceleration even though in reality you shouldn't have to slow down to speed zero at each vertex. That was when "sprinter" version of firmware came along and introduced a "jerk like" parameter which instead specified the max speed change at a vertex (the magnitude of change regardless of direction). This max speed change is typically 20mm/sec at each vertex. But it means now you have to plan the next 20 moves in advance if you want to be able to print fast but still slow down for sharp corners 20 line segments from now.

    As you can see it gets complicated. This algorithm hasn't changed much in a few years and Marlin uses the same algorithm as sprinter for planning moves.

    It makes sense to think of X,Y,Z,E moves as 4 dimensional moves by the way - where you want to travel in a straight line in all 4 dimensions so that the extrusion matches up nicely with the movement.

    Typical Max for UM1 and UM2 acceleration for X,Y is 5000mm/sec. That works well and is screaming fast (compared to some printers which are at 200mm/sec).

    There are very very smart people working on the firmware for Marlin right now - ErikZalm was taking care of supervizing it for a while and now it's been mostly Bernhard Kubicec (spelling?) who also designed the ulticontroller. Nether of them work for Ultimaker. There are probably a few dozen contributors in the last year (that's VERY rough guess based on a quick view a month ago) and there are a few commits every week. Mostly very minor, but also very useful features.

     

  • Link to post
    Share on other sites

    Posted · UM1 resolution

    Welcome by the way. I hope you stick with this printer and keep posting because if you do I can already tell you will be a great addition to the UM community.

     

  • Link to post
    Share on other sites

    Posted · UM1 resolution

    So -- stepping at .005mm or .0025mm per step may still have a measurable resolution of .01 --- but the print surface may be noticeably smoother.

     

    I understand your point, but I think some of the discrete stepping will get smoothed out in the rubber belts. I don't know if you are EE, or CS so I don't know the best metaphor but the belts act as a high frequency RC filter smoothing out those steps. Maybe. Or you can think of it as a mass on a spring with friction. But I don't know the mass or the spring constant or the friction values so I don't know where the damping frequency is but I suspect the steps you speak of are damped out.

     

  • Link to post
    Share on other sites

    Posted · UM1 resolution

    The linear speeds you mention are very high, and need to be tempered by reference to the capabilities of the extruder. A typical UM1 extruder can maybe extrude 10mm³/second of plastic. Any higher than that, and you start running in to pressures that are too high for the extruder to be able to grip the filament.

    At 550mm/s and 0.4mm nozzle opening, that implies a layer height no higher than 0.045mm,which is starting to challenge the accuracy of the z-stage system. You also run into layer cooling issues that the plastic may not be able to cool sufficiently if several seconds haven't elapsed since the previous layer was laid down.

    Furthermore, in reality given the mechanics of the UM1, and the nature of PLA, I found that extrusion becomes somewhat unreliable over about 300mm/s; it's too easy to get small inaccuracies in the system which start to mount up so that you don't get reliable extrusion. The extrusion bead snaps very easily when being drawn out at that high of a speed and as soon as the filament stops laying down perfectly, subsequent layers don't have a smooth surface to bind to, and you start to run into cumulative issues that ultimately cause the print to fail.

     

  • Link to post
    Share on other sites

    Posted · UM1 resolution

    I don't know if you are EE, or CS

     

    I an old EE. Actually had several classes on design using vacuum tubes --- that date's me!

    I understand the use of jerk.

    I use a recursive approach when I find a gcode segment that needs its starting or ending nozzle velocity to be zero or near zero (jerk). The "forced" results are recursively fed back into previously processed segments. the idea is the same as Merlin's forward and reverse planner but totally different. I want to do physical testing to see if I can get the wanted speed without much jerk as jerk produces artifacts in the print.

    I'm currently using the robot gcode that came with the UM1. In processing that gcode, I have had instances where I went back as far as 18 segments to smooth out the segment velocity transitions. That is what will be nice with the ARM I'm using - I will have memory for a very large segment buffer to be able to do recursive smoothing as the print is actively being printed.

    I'm also counting on the hardware floating point processor to keep performance up even with all the heavy floating point calculations I'm doing.

    I've got my embedded Ethernet TCP/IP stack as part of this. I want enough headroom to easily maintain network communications for control and debugging.

    When you retire - you have the opportunity to take the skills others use to pay you for and apply them aggressively towards a hobby.

    I'm looking forward to both using and modifying my UM1.

    Joe

     

  • Link to post
    Share on other sites

    Posted · UM1 resolution

    The linear speeds you mention are very high, and need to be tempered by reference to the capabilities of the extruder. A typical UM1 extruder can maybe extrude 10mm³/second of plastic. Any higher than that, and you start running in to pressures that are too high for the extruder to be able to grip the filament.

    At 550mm/s and 0.4mm nozzle opening, that implies a layer height no higher than 0.045mm,which is starting to challenge the accuracy of the z-stage system. You also run into layer cooling issues that the plastic may not be able to cool sufficiently if several seconds haven't elapsed since the previous layer was laid down.

    Furthermore, in reality given the mechanics of the UM1, and the nature of PLA, I found that extrusion becomes somewhat unreliable over about 300mm/s; it's too easy to get small inaccuracies in the system which start to mount up so that you don't get reliable extrusion. The extrusion bead snaps very easily when being drawn out at that high of a speed and as soon as the filament stops laying down perfectly, subsequent layers don't have a smooth surface to bind to, and you start to run into cumulative issues that ultimately cause the print to fail.

     

    Thank you for your comments.

    I totally understand and those are true for the control system implemented today in the Merlin.

    In the testing I've done so far (simulation - not actual hardware yet) - I've set max nozzle velocity at 300mm/sec. The process I have currently implemented (using 3000 mm/sec/sec acceleration) has the majority of nozzle speed around 200mm/sec with 10% peaks to 300. Move acceleration to 6000mm/sec/sec bring everything up to average around 250mm/sec with 20% peaks maxing at 300.

    When my UM is build and my controller can swap out the Ardunio, I'll do tests to see if my implementation has similar limits as Merlin.

    I appreciate you comments and concerns. Any statement or concern may be a fact that I'm not aware of that may dramatically change my direction. You don't know what you don't know.

    Again. Thanks for your comments.

    Joe

     

  • Link to post
    Share on other sites

    Posted · UM1 resolution

    Question regarding Cura ...

    Cura generates gcode segments that defines a bead length.

    I'm assuming that Cura has decided the volume of material that is to be deposited in the creation of the bead and states that volume via the E gcode parameter. E length of 2.85mm filament equates to a specific volume of material to deposit as the bead. The controller's job is to be aware of the mechanical system and attempt to deposit THAT volume of material in the distance defined in the segment.

    THAT is what Cura is defining as the E parameter - correct?

    Thanks.

    Joe

     

  • Link to post
    Share on other sites

    Posted · UM1 resolution

    Sounds like you're doing some great work.

    I'll reiterate what Illuminarti has said - I think a very critical component in perfecting print quality is accurately modeling the (nonlinear) relationship between intended extrusion and actual extrusion. I'm not exactly sure how to best quantify it... it seems like a multidimensional variable of viscosity per temperature per extrusion force per flow rate. Like a thermistor, however, it might just be best to pragmatically measure it and use the resulting intended vs. actual extrusion curve as a factor in move and extrude planning, even if that curve only approximates the full richness of the physical reality.

    I've also been thinking about trying to use bowden compression pressure as a proxy for nozzle pressure and flow rate (easier to measure, as you could put a force sensor in the bowden clamp at the extruder) and have the printer dynamically slowed to maintain expected bowden pressure.

     

  • Link to post
    Share on other sites

    Posted · UM1 resolution

    The speed issues I mentioned weren't so much related to the behavior of Marlin, but rather the mechanics of the frame and the plastic itself. You can whizz the head around on a standard UM1 at 500mm/s if you want to. But if you extrude plastic while you're doing it, you won't get very good results, and it's not because of Marlin - it's because of how plastic behaves.

    Standard gcode represents the e component as a length of filament of whatever diameter you specify, such that the segment length x extrusion width x layer height is equal to the that length of plastic multiplied by the cross sectional area of the filament.

    On a UM2, the e coordinates are expressed not in linear mm of filament but in mm^3 of filament, so that you can set the filament diameter on the fly in the printer, rather than it being implicitly hard coded into the gcode.

  • Link to post
    Share on other sites

    Posted · UM1 resolution

    Merlin

     

    :) It's not "Merlin the Magician", it's "Marlin the swift fish". A Marlin can change it's direction seemingly effortlessly with a tiny flick of it's tail.

    :)

    The E (Extruder) position is the position along the filament of amount used so far. So if the final E value of the final move is 1.000 then your print used 1 meter of 2.85mm filament.

    After Cura calculates the X Y positions for the next line segment it (usually) calculates the amount of filament needed for that line segment by simply assuming a box shape line with height at layer height and width at nozzle width.

    However there are exceptions. For example you can print a .5mm wide line with a .4mm nozzle by "overextruding" by 25%. Cura takes advantage of this ability when fitting in a line where there is not exactly .4mm of space. I believe Cura will go up to 150% of nozzle width and down to 75% of nozzle width as needed - something like that - not sure exactly.

    For example if you print with a 1mm shell and .4mm nozzle width the outside path is .4mm and the second pass is .6mm worth of filament.

     

  • Link to post
    Share on other sites

    Posted · UM1 resolution

    For example if you print with a 1mm shell and .4mm nozzle width the outside path is .4mm and the second pass is .6mm worth of filament.

     

    Actually, not quite. You get two passes of 0.5mm - and indeed everything in the print (skirt, brim, infill) is printed with that new assumed 0.5mm nozzle width.

  • Link to post
    Share on other sites

    Posted · UM1 resolution

    illuminari:

    The F parameter in the gcode is for FeedRate --- correct?

    I peaked in the Merlin source code to try to get an understanding of its use.

    It appears (please clarify) that the parameter is passed in the F argument is mm/minute. I say this because it is divided by 6o when passed to the planner --- making it mm/sec in the planner.

    When I look at F values in the gcode --- I see F1200 and F1620 being used when associated with G1 codes.

    This would be passed to the planner as 20mm/sec and 27mm/sec --- used as feed_rate in the planner.

    This is why I don't like to attempt to use/reverse engineer someones code because if you don't have a solid foundation in what they are doing ... understanding is difficult.

    The planner uses that value to derive segment time -- from there velocity values and rate value related to the segment.

    All of that then gets rolled into the trapezoid calculation ......

    I'm asking because I don't see or understand the importance of this feed rate gcode value.

    So far - I have been ignoring it ... but I want to do a sanity check.

    Currently - what I do ... I don't need a feed_rate. I need a maximum nozzle velocity defined and a value for the constant acceleration.

    From those, I can calculate time and speed anywhere in the nozzle's path - always having the system attempting to accelerate and maintain maximum nozzle velocity.

    Given the view point I just explained --- I having an issue understanding how Fxxxx feedrate in the gcode would affect anything I'm doing.

    I may be missing something -- so please clarify.

    Thanks in advance for your reply.

    Joe

     

  • Link to post
    Share on other sites

    Posted · UM1 resolution

    The feedrate is the speed that the move should be performed at, and then remains in effect for all further moves until a new speed is included in a future move. Yes, it is in mm/min.

    The feedrate is specified so that you determine the speed that you want to print at. As I discussed at some length above, you can drive the axes far faster than you can extrude plastic; and the faster you print, the more likely you are to have print quality problems due to the thermal and mechanical properties of the plastic being extruded.

    So, you need to be able to specify a print speed that you want to print each part of the print at. You might choose to print visible parts more slowly, and internal infill faster, since you don't care about the appearance of that. You might also need to slow the print down to allow time for the plastic to cool before the next layer is laid on top. Whereas, for moves between parts of prints, you want to move faster to minimize the time taken, and the amount of any oozing from the print head, and do not need to worry about extrusion quality constraints at all for those lines.

    It's great that your have so many ideas about how things can be improved, but it might be an idea to take a step back and understand more about how 3D printers work, and get some experience with them so that you can better understand the practical challenges that need to be overcome before deciding what to re-invent or how to do it. There's a lot of accumulated knowledge of the field that you are likely to have to relearn the hard way if you don't pay attention to what has gone before. You clearly have a lot of expertise to bring to the field, but I feel like your efforts can be better applied building on those who have gone before, rather than reinventing the entire field by yourself :-)

     

  • Link to post
    Share on other sites

    Posted · UM1 resolution

    Thank you for your concern.

    The question I had was if the feed rate given by the gcode was 1200 for the "robot" model and that is in mm/minute which is converted to 20mm/sec segment velocity when passed to the planner --- that is a far cry away from the 300mm/sec I hear everyone talking about making prints on the UM1.

    If the "robot" print is to be printed at a max nozzle velocity of 20mm/sec -- that's fine as I'm just attempting to understand what the F gcode parameter is and confirm my understanding.

    Thanks.

    Joe

     

  • Link to post
    Share on other sites

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

    • Our picks

      • Introducing Universal Cura Projects in the UltiMaker Cura 5.7 beta
        Strap in for the first Cura release of 2024! This 5.7 beta release brings new material profiles as well as cloud printing for Method series printers, and introduces a powerful new way of sharing print settings using printer-agnostic project files! Also, if you want to download the cute dinosaur card holder featured below, it was specially designed for this release and can be found on Thingiverse! 
          • Like
        • 10 replies
      • S-Line Firmware 8.3.0 was released Nov. 20th on the "Latest" firmware branch.
        (Sorry, was out of office when this released)

        This update is for...
        All UltiMaker S series  
        New features
         
        Temperature status. During print preparation, the temperatures of the print cores and build plate will be shown on the display. This gives a better indication of the progress and remaining wait time. Save log files in paused state. It is now possible to save the printer's log files to USB if the currently active print job is paused. Previously, the Dump logs to USB option was only enabled if the printer was in idle state. Confirm print removal via Digital Factory. If the printer is connected to the Digital Factory, it is now possible to confirm the removal of a previous print job via the Digital Factory interface. This is useful in situations where the build plate is clear, but the operator forgot to select Confirm removal on the printer’s display. Visit this page for more information about this feature.
          • Like
        • 0 replies
    ×
    ×
    • Create New...