Dim3nsioneer
-
Posts
4,297 -
Joined
-
Last visited
-
Days Won
33
Content Type
Forums
Events
3D Prints
Posts posted by Dim3nsioneer
-
-
It's completely irresponsible of the Swiss to produce such a dangerous device! :huh:
Get well soon!
P.S.: Uhm... usually train station roofs are kind of dark red to brown, aren't they...?
-
Don't panic!
At first sight it really looks as if the new Makerbot models are more or less the same as the Replicator 2. But I think they were clever enough to build the three new models with a maximum number of common parts. This helps to reduce e.g. storage costs. And this is certainly something Ultimaker should be aware of. I don't know if there is any common part between UM1 and UM2.
It is a very strong commitment Ultimaker did when telling, at the moment of the UM2 launch, that they will still care about the UM1 users. However, there might be a time when they will have to break that commitment. It could as well be, when launching the UM3 one day, they will reduce support for the UM2 and still support the UM1 clients.
It might happen that the traditional printer manufacturers will enter the stage. But I think rather not. A main competitor in a few years from now may be Google which has started with a quite huge Motorola team recently. And nobody knows what the guys in Cupertino are currently working at.
And don't forget that the tiger and the dragon are still sleeping. At least China might be an important force in the 3D home printing market, capable of mass producing cheap devices.
So what to do for a small European company like Ultimaker? Find your enthusiastic clients. Don't grow at any prize. Do something no other company does, don't copy. Up to now, I think this is still the case. Cura is a very good example.
I had the chance to work on the key development of a completely new device (in HVAC, not 3D printing) for the last few years. I learned a lot of things during that time. But one of the most important things was, that creating something very innovative and new takes at least four years with a small team (we were about 5-10 people). If you want it to work properly when delivered to your customers.
-
Habe ich mir auch schon überlegt, da ich relativ dickes Filament in der Grössenordnung von 2.95mm verwende und es einige Leute für Soft-PLA auch schon erfolgreich gemacht haben (gibt im Material-Unterforum mind. einen Bericht). Allerdings habe ich einen ziemlichen Respekt davor, dass Öl auf die Extruder-Rändelschraube kommt (sei es nur durch einen Retract) und der Gripp damit dahin ist... das ist bei einem Bowden-Extruder wie dem vom Ultimaker eine verschärfte Situation... :eek:
Du darfst es gerne versuchen; ich würde mir aber vorher überlegen, wie ich im schlechten Fall das Öl wieder von den Komponenten wegbekomme... :wink:
Und Du solltest hocherhitzbares (HOLL) Rapsöl nehmen (die Amis nehmen Mais-Öl), da Dir sonst das Hotend zu rauchen beginnt.
-
[...]
I used flowthermostat in earlier cura versions, don,t know if it works now.
[...]
This one works... :wink:
-
I also thought that the motor should skip and I would hear it. Obviously not. Or I'm deaf... :wacko:
-
First, I have to point out the TweakAtZ is not my invention. First version was written by smorloc. RicardoGA then adapted it for use with Cura 13.06.4+. I've recently contacted the two gentlemen by PM asking how to proceed with the TweakAtZ-plugin but haven't got any answer so far (maybe they read it here?).
It's certainly possible to change the speed over multiple layers. Let's say you want it to decrease from 100% to 50% over 10 layers. Then a plugin could reduce the speed to 95, 90,...50%. However you would need to put in the number of layers.
If the speed should effectively be matched to the current temperature, then it would be a job to be done in Marlin, the Ultimaker firmware. That might actually be a nice feature for an easy-to-use printer as the UM2.
Do you know the flowthermostat plugin? If not: it does it the other way round; it sets the temperature accordingly to the current speed.
-
To be honest, after that adventure I'm rather thinking about a way to get rid of all belts... but you're right about the banana tensioners. However, mines are nearly not used at all right now...
-
Exactly. The old video was ok. The new one is - uhm - suboptimal...
You're right. And the additional friction was a result of the high tension. Anyway, these kind of belts are form-locked. There should actually be no need for a high tension in contrast to a V-belt.
-
Case solved!
(sorry for shouting... :eek: )
First I would really like to thank all of you who helped me finding the way to this extremely satisfying moment for the last two weeks!
This is the solution:
gr5 was actually right, but he was wrong... :wink:
As I wrote earlier, sometimes you first have to make a situation worse to make it better in the end. This is exactly what I did today. After finishing four times two Ultimaker Wiki Calibrate page.
The print I made after this was the one with the absolutely worst displacement I got for the last few weeks! The shift was nearly 1mm! I didn't had to think very thoroughly what was wrong as I had realised the print head needed a tremendous force to be moved.
So the next step was to make the long belts rather sloppy. I just tensioned them enough that they will not slip on the pulleys. The result you see above.
So my problem never was too much play. I actually have some now which results in an increased wobble from layer to layer. However, this wobble is magnitudes smaller than the displacement I had before. I didn't have enough play with the belts tensioned too much. Thus, the video on the Ultimaker page is absolut nonsense in my opinion! If you put that kind of tension onto your long belts, you'll get exactly the troubles I had...
I have to add that the tension on the short belts is still quite high. I will not lower it as I know I'll get troubles doing so.
-
Sounds to me as a USB communication problem. The display doesn't flicker if you have the printer just connected but it is not printing, correct?
Could you please post a screenshot of your Cura print dialog showing the temperature slope while you're printing? Including the sudden switch off...
-
Maybe it's not Facebook but the same guy who listened to Frau Bundeskanzler's mobile phone?
-
Did you download the plugins from the wiki plugin website? These version don't work anymore since Cura 13.06.4 due to the change of the GCODE command for z-movements. There are a few updated versions of various plugins posted in the forum.
Setting the tweak height to 0 will not work with any of the different version of TweakAtZ. The plugin expects you to have at least one layer below the tweak height. It is executed when passing the tweak height from bottom to top. If you want to have a certain setting right from the start, put it into the basic/advanced tabs of Cura. It's also not necessary to fill in a temperature for three hotends (as far as I know, UM2 only has one extruder up to now). Leave the Temp2 and the Temp3 box empty. The plugin will recognize an empty box and will not change temperature for that hotend.
If you build more than one object within one run, I recommend you use https://github.com/Dim3nsioneer/Cura-Plugins/raw/master/TweakAtZ.3.0.1.py. This version resets the values when starting the second object. But it only works with RepRap-GCODE.
-
What version of Marlin firmware are you using, Stefan?
Ginge's Marlin Builder version, dual extruder w/o heatbed
-
First of all, having a look at the last few posts is quite impressive. Within last 24 hours this has changed from being an issue of just one machine to something more general.
Have you looked into the wall thickness ?
I like to print most of my objects with a thick wall 1.5mm or more, this gives it more rigidity when sanding the part,
and I noticed when I forgot to add the thick wall, there was also a step in the outer wall, when the layer went from a more solid infill to a more hollow print.
I made it again with shell thickness 1.6mm. It worked for the model of which gr5 just posted a picture! I then tried it for the original troublemaker: The displacement might be a bit smaller, but is still there. The same with shell thickness 2.0mm.
Wow! I used your gcode exactly and... I got the same problem as you! My previous test was on the UM2 but I'm thinking it might be a slicing issue.
I added arrows. The blue arrow shows the path before the displacement and the green arrow shows it after. I really don't think this is a temperature issue because it's shrinking on the short length, not the long. I think it's play/blackslash due to change in approach side of the wall. I'm wondering if my slicing settings swapped directions here - potentially because I had 1 more or fewer shell layers it may have reversed direction? That doesn't make sense. Or 20% versus 24% fill may have ended up at a different spot. Anyway I never delete anything so I can try:
1) Use my settings and slice up your stl (I don't have your short stl though - please post somewhere)
2) Look at the gcode for the print I printed (using repetier host - wonderful visual viewer for gcode) on the UM2 that came out fine
I might not have time to do any of this until tonight.
Thanks for testing the file. I think it's important to know it is nothing mechanical or an issue of the electronics hardware.
If you want to slice it yourself and test it: here is the stl. I'll be happy to see the result when you slice it yourself with your settings.
I also had the idea it might have something to do with the number of travels on the x axis. I had the impression it's printing it differently on layers with an odd number of travels compared to layers with an even number of travels. But this is much more guessing than knowing.
At the moment it looks to me as if there is something in Marlin causing this. I wouldn't call it a bug; maybe it's a feature which makes absolutely sense for something completely different. If it would be really a slicing error or similar, the probability it comes out exactly the same for Cura 13.12 and Slic3r is relatively small (but not zero of course). But with a nice gcode viewer such as gcode.ws or repetier host or whatever you prefer, one should see a difference between the layers if it is a slicing error.
So we may need a volunteer
who has a look into Marlin to check if something in there could cause such an issue... -
On your video, I see the display of the Ulticontroller first showing a target temperature of 210°C (is this set by Cura over USB?) switching to 0 (this happens e.g. when you open the print dialog in Cura with a USB-connected printer). After that I see just some flickering. If you have your printer connected on USB, try printing from SD card. To my personal experience, connections over USB are quite unsafe and error-prone without a very good error handling of the connection (its ok to upload new firmware but not for printing).
On the mechanical side, first thing to check are the connector screws on the amplifier print on top of the print head. I found they can get loose from vibrations after some time.
-
Can you send me your gcode file? I want to just print it exactly as it is - the gcode file. Make sure this isn't some slicing issue. I might have used a different version of Cura or a different setting. Maybe post the file somewhere and then post the link or I can email you directly if you want and you can reply with the file.
I'll print it on my UM Original.
Although illuminarti already had a look onto one of the gcode files (and didn't find anything suspect), I'll send you a link in a PM. As physicist, I believe in statistics... (well, mainly the statistics I faked myself... :grin: )
@Ian: I've a similar problem. I actually want to use my Ultimaker to produce prints for other people (let's call them customers) in a not to distant future... so I'm running out of time. Timeline says, the case has to be solved a.s.a.p. I know, reality sometimes says something else... :(
But as I see it, you have a slightly different problem. It looks as if the print gets larger all around it and is not shifted in one direction. However, it looks as ugly as my displacements... :wacko:
-
Update:
Reducing XY-Jerk to 5 doesn't change anything.
A smaller version of the test model (20mm x and y size instead of 40mm) shows the very same effect. Thus it's independent of the travel distance.
Visual check of both Arduino and Ultimaker board showed no visible defect. All contacts between the boards are fine (checked with multi-meter).
I could also exclude pickup from radio devices. I switched off everything except the printer (e.g. WiFi etc.) and it was the same.
-
[...] Do you think it's fair to say that it seems to be triggered by longer travel moves?
[...]
More precisely: it's related to longer travel moves. At some layers the travel move ends at the place where it shows the shift, at some layers it begins there (alternately).
I'd love to see a video when it is printing the "bad" portion. I want to see where it is approaching from an instant before.
GCODE analysator says it's approaching from opposite of the direction the displacement goes to for the strongest ones.
To make a video of that in which you actually see the printer producing the displacment one would need something like a super-macro-high-speed-high-res-camera which I do not have. I can't see it by eye, I only see the result after some layers.
-
It's more than fair, it's quite accurate... :wink:
To be honest, I haven't tried the xy-jerk yet. At least not with the new model (where I finally can see if something is changing or not). Is that not one of these quite conservative settings (http://umforum.ultimaker.com/index.php?/topic/3695-acceleration-in-marlin/)? Well, I'll check and change that tomorrow...
-
Things are getting clearer.
First, I tried to print it more slowly. This is the result of the 50mm/s-print (@210°C, 1000mm/s^2 x/y-acceleration, travel-speed 50mm/s as well):
Next try was to print it at even lower speed (25mm/s, both printing and traveling speed):
As you can see, no change. The effect is a bit less visible on the 25mm/s-print as 210°C are quite high for that speed.
After checking everthing again for the slightest play (there is none, really (except the one mentioned above)), I decided to use a special model for further testing. It's a symmetric model (i.e. the same geometry for x and y direction). You can find a description on the first page of this https://dl.dropboxusercontent.com/u/15273556/Ultimaker/Pictures/Displacement%20axes%20analysis.pdf. I will refer in the following to this document. The idea of the model is to simulate a first solid layer zone, a second zone with a reduction, a third zone where the printer has to retract and to travel along more or less just one axis and a fourth zone where the travel distance is about equally distributed on x and y.
First configuration (see page 2) is the standard configuration as any Ultimaker is usually set up. As you can see, the model showed displacements at several spots.
For the second configuration (page 3) I exchanged the plugs of the x and the y motor on the Ultimaker 1.5.7 board (and also the x and y end switches). This is, I guess, the most important result: Within some uncertainties, the effects swaped the physical, i.e. they stayed with the logical axis of the electronics. My conclusion: Whatever it is that causes these displacements, the reason has to be somewhere in between the SD card and the plugs of the motors on the Ultimaker board. It's an issue of the electronics!
In order to narrow it down, I swaped the motor drivers in configuration three in addition to the motors (i.e. each motors is driven again by the driver which drove it in the original configuration). As you can see, it's the same as in configuration two.
After that test, I reversed the changes and printed the model directly via USB instead of using the SD card. It's identical to the original configuration result again.
Unfortunately I cannot exactly determine what the problem is. It may be an issue of the Arduino, of the Ultimaker board or of the connection in between them.
What may also be ruled out is an issue of the firmware. I used two types of firmware. Normally my Ultimaker runs with a firmware compiled by Ginge's Marlin Builder but I cross-checked with the firmware Cura 13.12 installs as the official one.
If you know something to track the error further down, please let me know. Otherwise I think it's time to contact Ultimaker by a trouble ticket...
-
That gap - it looks like play. Usually play comes from the belts but it sounds like your belts are too tight if anything. Play/backlash can come from other things. With power off, place the head near the center of the machine. Then push the nozzle back and forth in X and Y. Does the nozzle move without the belts moving? You might have to hold a belt still to see if there is any play that needs quite a bit of force for it to take affect. If the nozzle moves a distance similar to that gap width in your photo - then that could be the problem. It could come from the bearings in the head. It could come from loose X,Y rods (the two that go through the head). It could come from the blocks that those 2 rods go through. It could be in the print head itself.
I agree, it looks like play. But a very strange kind of play as it cancels out 'on the way back'...
However, I checked a few things:
- I moved the print head to the center (UM off) and checked for play. There is no play. I mean, I can push the nozzle in a way that the flexible parts of the print head begin to deform, but no real play (I've added some spring elements to the design of the dual head in order to make it more sturdy).
- I can move the x and y rod through the print head by 1.5mm with quite some force, but only in longitudinal direction, no way to move it in lateral direction (which is defining the head position). Anyway it might not be a disadvantage to fix that (how? adding some printed spacer at one end?)
- Some time ago (right when this issue started) I also fixed the longitudinal play of the 8mm rods where the pulleys of the long belts are mounted on. I use this nice endcap and adjusted it in such a way that there is only a very tiny play (maybe around 1/100mm) in order not to have friction between the adjustment screw and the rod.
I printed it this evening on my UM1, trying to recreate the settings as best I could, and it came out fine also. Looking at the gcodes I generated, You do get some long diagonal moves on those lower layers; I wonder if that's allowing the head to get up to greater speed, and so making it more likely to overshoot?
You might try reducing your travel speed, and also reducing your head acceleration, if you haven't already tried that, and see if it helps eliminate the size differences.
First, thank you for printing it on your UM1.
I did some tests with different velocities but into the other direction as sometimes it is easier to find the source of an effect by making it worse. I moved travel speed up to 300mm/s. The result was the very same. But I will run a test with travel speed down to 50mm/s.
-
You could have printed the fireworks... :smile:
The same to you!
-
Ok, I'm getting closer...
First, as suggested by gr5, I printed the model with 225°C and at 50mm/s. This is the result:
It looks more or less the same as printed at 210°C. There is no sign of underextrusion during the print. the infill is very solid, no part of it missing (I can post a picture, if someone doesn't believe).
The interesting thing is, that having a closer look at the deplacement indicated by the orange arrows, I found I could stick some very thin foil in behind the lines...
If I look at this print, I have to say, it looks otherwise fantastic. It's an excellent print quality I've not seen so far (the belt tensioners were a quite good investment...) So the overall impression is not the one of a low-quality print, but of a very high quality with one crucial mistake: the displacement. BTW: I began to skip the lower 6mm in Cura as they show no real news...
Having a closer look while printing the next example, I found something very interesting. While on the upper layer (the narrower ones) the printed layer looks ok, on the lower layers (the broader ones) there is a serious gap between the outermost shell lines (of three) and the other two:
So, if my Ultimaker would be a person and not a machine I probably might accuse it to do this intentionally... :wink:
No, seriously: What kind of defect (I start to call it a defect as I think most common-mistakes were exluded already...) could cause this? The belts are tight (the short x belt is so tight that the x motor began to skip when I reduced the current). The gcode seems fine (checked with gcode.ws). I already switched some stepper drivers. This leaves something in the software/firmware (unlikely, as everybody would have the problem), the Arduino, the Ultimaker board, the motor itself and something a haven't thought of...
I guess, my first issue of 2014 will be the last issue of 2013, but with a little bit of luck and help from this great forum, I might be able to solve it.
So, I wish you all a nice 2014! :smile:
And to myself, I wish for a solution of that issue...
-
Would it make sense if gr5 sends you the gcode of his successful print to rule out a software problem?
This would only work if he works with Reprap-GCODE and not Ultigcode.
I had some very thorough looks at the code. I checked the x position of the outer shell line for both shifted and non-shifted layers. There absolutely (means up to two decimals after point) the same. I imported the gcode file into excel and calculated the material density (i.e. amount of material divided by travel distance) FOR EACH G1 command (about 12000 lines). All of them are around the same value; they maybe differ by a percent...
I cross-checked the gcode on gcode.ws, which is a very good tool to find positioning or slicing errors. It even has a line thickness estimation which shows the same result for any layer...
In the meantime I also ruled out the stepper driver. Exchanging the drivers of the x motor and the (currently unused) extruder 2 motor led to the same result...
who has a look into Marlin to check if something in there could cause such an issue...
Experiences with selling your designs?
in Coffee corner
Posted
I guess this is not possible if you put your design under a non-commercial license, right?