anon4321

I think must CAD programs will represent a cylinder as a mathematical cylinder. The issue is I believe that STLs are polygon based so the object in the CAD program has to undergo tessellation resulting in the surfaces you see. DesignSpark Mechanical lets you control the surface generation was you "Save as STL". Look for similar options in other programs. The unavoidable issue is that the more surfaces you use to get a smoother look, the longer Cura takes to slice the object

I wonder if the stage is rigid enough, z wobble goes away and therefore the nut can be fixed to the stage.

If I may ask, why are you using any tape with a heated bed for PLA? I just print directly on to the glass at 220c/70c for the first layer and usually with a brim to control corner shrinkage. Seems to stick very well until the bed temp is allowed to drop for removal.

The upgrade firmware hang happens under Win7 x64 too.

Yes, that size wire is overkill but it is the smallest that vendor has in this product line and it was just a matter of convenience to buy it with the other. The wire is very flexible. However, that doesn't guarantee it is suitable to high flex situations but that is somewhat implied.

Did you update the firmware through Cura or more specifically is the version of the firmware from Ultimaker? Marlin is customizable for various printers and we just need to be sure you used the version built for the UM. If so, the steppers are missing steps. There are two major reasons this happens: - The XY axes are binding - The stepper drivers aren't delivering enough current Since your initial post implies that you have had previously successful prints, I'm going to assume the drivers current limits remain unchanged which leaves binding. With the printer off, can you (slowly) move the head smoothly throughout the XY range? Does it get difficult in certain parts? Does it "chug, chug, chug" (you will know what I mean if it does it)? If you have binding, are the rods straight? Both the thick rods and the thin rods through the head? If you get "chug, chug, chug", look at the pulleys as you move the head. Are they off center?

Your analogy would be valid if you added a forum and a second product where a half assembled on the floor is a valid end state. Here the problem is if you read these forums, you see one product leveled using a piece of paper and then go to the instructions for another product that starts out the leveling instructions with something that could be misread as saying you do the same thing using a piece of paper. A reasonable person could conclude that two products from the same manufacturer with the similar purpose have the same calibration procedures. Another complicating factor is that the calibration instructions are separate from the assembly instructions and don't appeared to be referenced by the assembly instructions. Thus it would be reasonable to end up searching the forums for this information, finding the instructions for the other product, assuming they apply to the product they purchased and have that further reinforced by the instructions are found later that start off seeming to say that the nozzle distance should be about a piece of paper away from the bed. Even more so when you consider it takes WEEKS to get the product so people often access the forums to get up to speed while waiting. Or I guess I'm just stupid and it can't possibly be due to unclear instructions and communications via the forums.

ORLY paper only for the UM2 Then http://wiki.ultimaker.com/Calibrate is WRONG or at least misleading! (yes that is the correct capitalization when trying to get attention! :-P ) From: "Now we level the bed. Before we do anything, turn on your Ultimaker. With your software, or with your UltiController, move the printhead to the home position. What is the distance between your nozzle and the build platform? There should be as much room as the thickness of a regular piece of paper. About 0.1mm. " Now, the remaining instructions do seem to have you level and adjust to 0 gap but the above is misleading at best. It should really be rewritten to say something to the effect of: For this leveling process, there should be much room as the thickness of a regular piece of paper. About 0.1mm. However, upon completion of this process is there will be NO gap between the bed and nozzle in the home position when properly leveled and adjusted".

Looking at the gcode generated when using the leveling wizard, the typical instructions and common point that the "firmware assumes 0.1 mm" appear to be wrong!!!! The gcode homes all axes and then positions the extruder at the ZERO height at each corner during leveling. THEREFORE THERE SHOULD BE NO SPACE BETWEEN THE BED AND THE TIP. Then when printing the calibration test square, Z is set to 0.3 mm and performs the test. Z0 means Z0. It is not the thickness of a piece of paper. Therefore, I believe the following is true: Do NOT use a piece of paper when leveling. The firmware makes NO adjustment or assumptions If you measure the height of the test square, it should be 0.3mm The log of the leveling wizard is below but immediately below is the output of the M501 command and notice the home offset settings in the firmware: I added comments starting with >>>>> Send: M501 Recv: echo:Hardcoded Default Settings Loaded Recv: echo:Steps per unit: Recv: echo: M92 X78.74 Y78.74 Z533.33 E836.00 Recv: echo:Maximum feedrates (mm/s): Recv: echo: M203 X500.00 Y500.00 Z5.00 E25.00 Recv: echo:Maximum Acceleration (mm/s2): Recv: echo: M201 X9000 Y9000 Z100 E10000 Recv: echo:Acceleration: S=acceleration, T=retract acceleration Recv: echo: M204 S4000.00 T3000.00 Recv: echo:Advanced variables: S=Min feedrate (mm/s), T=Min travel feedrate (mm/s), B=minimum segment time (ms), X=maximum XY jerk (mm/s), Z=maximum Z jerk (mm/s), E=maximum E jerk (mm/s) Recv: echo: M205 S0.00 T0.00 B20000 X20.00 Z0.40 E5.00 >>>>> Recv: echo:Home offset (mm): Recv: echo: M206 X0.00 Y0.00 Z0.00 >>>>> Recv: echo:PID settings: Recv: echo: M301 P22.20 I1.08 D114.00 Here is the gcode so others can validate this. >>>>> <snip baud rate detection and idle testing Log: Send: M105 Log: Recv: ok T:36.9 /0.0 B:25.0 /0.0 T0:36.9 /0.0 @:0 B@:0 Log: Baudrate test ok: 9 Log: Send: M105 Log: Recv: ok T:36.9 /0.0 B:25.0 /0.0 T0:36.9 /0.0 @:0 B@:0 Log: Send: M999 Log: Changing monitoring state from 'Detecting baudrate' to 'Operational' Log: Send: M105 >>>>> Home all axes and since there is no home offset in the firmware, we are at 0,0,0 Log: Send: G28 Log: Recv: Resend: 1 Log: Recv: ok Log: Recv: ok Log: Recv: echo:Unknown command: "" Log: Recv: ok Log: Recv: ok Log: Send: M105 T0 Log: Recv: ok T:36.1 /0.0 B:25.0 /0.0 T0:36.1 /0.0 @:0 B@:0 >>>>> Go to Z3 Log: Send: G1 Z3 F3000 >>>>> Go to back left Log: Send: G1 X0 Y205 F9000 >>>>> Go to Z0 at back left Log: Send: G1 Z0 F3000 Log: Send: M400 Log: Recv: ok Log: Recv: ok Log: Recv: ok Log: Send: M105 T0 Log: Recv: ok Log: Recv: ok T:37.6 /0.0 B:25.0 /0.0 T0:37.6 /0.0 @:0 B@:0 >>>>> Go to Z3 Log: Send: G1 Z3 F3000 >>>>> Go to back right Log: Send: G1 X200 Y180 F9000 >>>>> Go to Z0 at back right Log: Send: G1 Z0 F3000 Log: Send: M400 Log: Recv: ok Log: Recv: ok Log: Recv: ok Log: Send: M105 T0 Log: Recv: ok Log: Recv: echo:endstops hit: Z:0.01 Log: Recv: ok T:39.1 /0.0 B:25.0 /0.0 T0:39.1 /0.0 @:0 B@:0 >>>>> Go to Z3 Log: Send: G1 Z3 F3000 >>>>> Go to front right Log: Send: G1 X200 Y20 F9000 >>>>> Go to Z0 at front right Log: Send: G1 Z0 F3000 Log: Send: M400 Log: Recv: ok Log: Recv: ok Log: Recv: ok Log: Send: M105 T0 Log: Recv: ok Log: Recv: echo:endstops hit: Z:0.01 Log: Recv: ok T:37.2 /0.0 B:25.0 /0.0 T0:37.2 /0.0 @:0 B@:0 >>>>> Go to Z15 Log: Send: G1 Z15 F3000 >>>>> Heat up extruder Log: Send: M104 S220 >>>>> Zero XY axes, still at Z15 - Log: Send: G1 X0 Y0 F9000 Log: Recv: ok Log: Recv: ok Log: Recv: ok >>>>> <snip> Log: Send: M105 T0 Log: Recv: ok T:224.0 /220.0 B:24.4 /0.0 T0:224.0 /220.0 @:0 B@:0 Log: Changing monitoring state from 'Operational' to 'Printing' >>>>> Go to Z2 Log: Send: N0G1 Z2 F3000*37 >>>>> Zero extruder length Log: Send: N1G92 E0*102 >>>>> Go to X5,Y5 Log: Send: N2G1 X5 Y5 F9000*100 >>>>> Go to Z0.3 !!!!! NOTE no adjustment !!!!!! Log: Send: N3G1 Z0.3 F3000*57 Log: Recv: Error:Line Number is not Last Line Number+1, Last Line: 0 >>>>> Due to error, resend some commands Log: Recv: Resend: 1 Log: Recv: ok >>>>> Zero extruder length Log: Send: N1G92 E0*102 Log: Recv: ok >>>>> Go to X5,Y5 Log: Send: N2G1 X5 Y5 F9000*100 Log: Recv: ok >>>>> Go to Z0.3 !!!!! NOTE no adjustment !!!!!! Log: Send: N3G1 Z0.3 F3000*57 Log: Recv: ok >>>>> Feed 5mm of filament Log: Send: N4G1 E5.000000 F2400*18 Log: Recv: ok >>>>> Now print the squares !!!!! NOTE that Z is still 0.3mm !!!!! Log: Send: N5G1 X5.000000 Y200.000000 E8.668059 F3000*25 Log: Recv: ok Log: Send: N6G1 X200.000000 Y200.000000 E12.336117 F3000*35 Log: Recv: ok Log: Send: N7G1 X200.000000 Y5.000000 E16.004176 F3000*36 Log: Recv: ok Log: Send: N8G1 X5.000000 Y5.000000 E19.672234 F3000*33 Log: Recv: ok Log: Send: N9G1 X5.400000 Y199.600000 E23.325244 F3000*47 Log: Recv: ok Log: Send: N10G1 X199.600000 Y199.600000 E26.978254 F3000*23 Log: Recv: ok Log: Send: N11G1 X199.600000 Y5.400000 E30.631264 F3000*22 Log: Recv: ok Log: Send: N12G1 X5.400000 Y5.400000 E34.284274 F3000*28 Log: Recv: ok Log: Send: N13G1 X5.800000 Y199.200000 E37.922236 F3000*17 Log: Recv: ok Log: Send: N14G1 X199.200000 Y199.200000 E41.560198 F3000*20 Log: Recv: ok Log: Send: N15G1 X199.200000 Y5.800000 E45.198159 F3000*17 Log: Recv: ok Log: Send: N16G1 X5.800000 Y5.800000 E48.836121 F3000*19 Log: Recv: ok Log: Send: N17M400*49 Log: Communication timeout during printing, forcing a line Log: Send: M105 T0 Log: Communication timeout during printing, forcing a line Log: Send: M105 T0 Log: Communication timeout during printing, forcing a line Log: Send: M105 T0 Log: Communication timeout during printing, forcing a line Log: Send: M105 T0 Log: Communication timeout during printing, forcing a line Log: Send: M105 T0 Log: Communication timeout during printing, forcing a line Log: Send: M105 T0 Log: Communication timeout during printing, forcing a line Log: Send: M105 T0 Log: Communication timeout during printing, forcing a line Log: Send: M105 T0 Log: Recv: ok Log: Changing monitoring state from 'Printing' to 'Operational' Log: Send: G1 Z15 F3000 Log: Send: G92 E0 Log: Send: G1 E-10 F2400 Log: Send: M104 S0 Log: Recv: ok T:217.9 /220.0 B:24.5 /0.0 T0:217.9 /220.0 @:53 B@:0 Log: Recv: ok T:217.9 /220.0 B:24.5 /0.0 T0:217.9 /220.0 @:53 B@:0 Log: Recv: ok T:217.9 /220.0 B:24.5 /0.0 T0:217.9 /220.0 @:53 B@:0 Log: Recv: ok T:217.9 /220.0 B:24.5 /0.0 T0:217.9 /220.0 @:53 B@:0 Log: Recv: ok T:217.9 /220.0 B:24.5 /0.0 T0:217.9 /220.0 @:53 B@:0 Log: Recv: ok T:217.9 /220.0 B:24.5 /0.0 T0:217.9 /220.0 @:53 B@:0 Log: Recv: ok Log: Recv: ok T:217.9 /220.0 B:24.5 /0.0 T0:217.9 /220.0 @:53 B@:0 Log: Recv: ok T:217.9 /220.0 B:24.5 /0.0 T0:217.9 /220.0 @:53 B@:0 Log: Recv: ok Log: Recv: ok Log: Recv: ok Log: Send: M105 T0 Log: Recv: ok T:217.9 /0.0 B:24.4 /0.0 T0:217.9 /0.0 @:0 B@:0 Log: Send: M105 T0 Log: Recv: ok T:218.0 /0.0 B:24.4 /0.0 T0:218.0 /0.0 @:0 B@:0 Log: Send: M105 T0 Log: Recv: ok T:217.7 /0.0 B:24.4 /0.0 T0:217.7 /0.0 @:0 B@:0 Exception in thread Thread-7: Traceback (most recent call last): File "C:\Program Files (x86)\Cura_14.04-RC1\python\lib\threading.py", line 552, in __bootstrap_inner self.run() File "C:\Program Files (x86)\Cura_14.04-RC1\python\lib\threading.py", line 505, in run self.__target(*self.__args, **self.__kwargs) File "Cura\util\machineCom.py", line 464, in _monitor self.sendCommand("M105 T%d" % (self._temperatureRequestExtruder)) File "Cura\util\machineCom.py", line 608, in sendCommand self._sendCommand(cmd) File "Cura\util\machineCom.py", line 558, in _sendCommand self._log('Send: %s' % (cmd)) File "Cura\util\machineCom.py", line 501, in _log self._callback.mcLog(message) File "C:\Program Files (x86)\Cura_14.04-RC1\python\lib\site-packages\wx-2.8-msw-unicode\wx\_core.py", line 14610, in __getattr__ raise PyDeadObjectError(self.attrStr % self._name) PyDeadObjectError: The C++ part of the bedLevelWizardMain object has been deleted, attribute access no longer allowed. Exception wx._core.PyDeadObjectError: PyDeadObjectError('The C++ part of the bedLevelWizardMain object has been deleted, attribute access no longer allowed.',) in <bound method MachineCom.__del__ of <Cura.util.machineCom.MachineCom object at 0x051C4390>> ignored Closing down

If you really want stiffness and are ok with going a slightly different route, duplicate the bearings, shafts and stepper in the front too. If you could figure out a way to capture the tops of the shafts in the corners under the XY axes, you could get them out of the way neatly tucked in the corners. With the second stepper, it would be really stiff.

It's a good assumption that you have blown all three. One option would be to just buy three new drivers from polulu and in fact upgrade them to these: http://www.pololu.com/product/2133 UM will make things right but it might take time. For $42 + shipping, you will have them ASAP and they are better. However, with these drivers note: - You must be able to solder the headers on, easy if you can solder. - No heatsinks supplied. They might not be required as the drivers dissipate less power due to being capable of higher current. I managed to wrench the heat sinks off my blown drivers, clean them (scrapping the adhesive off and finishing with alcohol) and attaching them to the upgraded ones with arctic sliver alu adhesive http://www.arcticsilver.com/arctic_alumina_thermal_adhesive.htm just use an incredibly small amount. I applied it with a pin and if you have a dot bigger than a pinhead, it's too much. - As you know now, orientation is very important. The location of the potentiometer on these is opposite of the black and standard drivers. Review the docs. These actually have the reverse orientation with respect to the location of the pots. -By default, these running in 32 microstepping mode as the standard drivers are 16. So you need to adjust the jumpers next to each (easy) or double the steps per mm in the firmware (hard). See the docs. - Finally, I believe the most important or heavily used and therefore hottest drivers are XY and E. I would upgrade those drivers and use the remaining working E driver as the Z driver. However note that from E to Z, the driver should be flipped 180 degrees. I have blown so many of these, I have like 3 spares now....

I have one idea that should be easy enough to check. The controller board (the PCB 1.5.7) has a 12V regulator on it that powers the Arduino. WITHOUT the ulticontroller connected (actually keep it simple and don't connect anything), REMOVE the jumper (if it exists) labeled ARDPWR. I believe if you hold the controller board with the power, USB and switch on the left and the top of the board with the stepper drivers on the well top, the jumper is in the lower part to the right of the center of the board. This will disconnect the 12V regulator from the Ardruino. Now with the Arduino attached to the controller board, connect the USB cable to the Arduino and see if the PC or MAC "sees" the Arduino. If so, the regulator is bad and unless you can solder, you will need a replacement control board. If the Arduino remains visible, see if it still works with the 19V power main supply connected. If so, you can use the printer with the jumper off BUT not with the ulticontroller connected. It uses too much power and needs the 12V regulator to supply power to the Arduino so it can power the ulticontroller. Good luck.

So I scanned that thread and unfortunately, they have already ran you through the gauntlet of checks. I have an idea and will reply in the other thread.

They have issues for sure. Two suggestions: PM your ticket to Sandervg he is the community rep and might be able to help you with your issue. Post your issue here on the forums (with pics if you can). You might think it is unfixable but there are many bright people here with vast knowledge of the UM products. They might be able to help you cobble a fix together to get you running while you wait for a formal resolution from UM.

Hi Jonny, your pic of the platform is private. Can you make it public? I'd like a closer look. I don't know about the parallel-ness in practice. I guessing that was a problem with the plywood and that is why one side of the platform is rigid and the other side floats in the XY direction. I'd be interested to know how you go about getting parts laser cut. I've wondered if you could take the laser patterns for the plywood and just send them to a place to have the same parts cut from alu or some other material.

Regarding the limit switches, use the initial configuration wizard in Cura. If will force you to check the switches but asking you to manually trigger each one. Then you know they are connected correctly and you won't get any missed steps growling when the head reaches the limit but the wrong switch is trigger. If you have Cura already installed and you used it, I believe you can copy the .ini files out of the "Cura x.x.x/Cura" directory and that will cause Cura to run the first time wizard.

Do you think that they Z stage should be more ridged? Some thing like: An Alu plate top and bottom that holds the ends of the shafts possibility with some way to adjust for parallel-ness and then the captive bearings should be rigidly mounted possibly with some adjustment to ensure they can be made parallel?

The fan connector outputs 19V, your 12v fans might be shutting down due to overvoltage. The transistor used in the UM1 should be able couple amps, more than most fans of any reasonable size will draw.

I think the recommended approach would be to use Cura to rescale the object in the XY direction. See "Scaling your object" here: https://www.ultimaker.com/spree/uploads/38/original/Cura_User-Manual_v1.0.pdf The firmware has a mapping of (stepper) steps per unit distance (mm I guess). However, I've seen in another post that the UM person (Daid or possibly SandervG) recommended not changing them. If you really want to change them, I think the three ways to do so is: Through the ulticontroller if you have it Via the start gcode using (I believe) M92 Modifying the firmware defaults and rebuilding it. I think the default steps per mm is correct but the difference you see is due to shrinkage. I think the reason why they recommend you don't change the steps/mm is because different materials or the same material from different batches or vendors will shrink a different amount. Also, the issue with any of the three ways above is that you cause the XY axes to move every so slightly more than Cura expects when it calculated the volume of material to extrude. So you will have an ever so slight underextrusion. When you scale the model, Cura adjusts the extrusion rate as required. So try scaling the XY axes with a factor of 1.018 or 1.019 and see if the size measures up. And in case you are wondering, I think the reason why the Z axis is accurate is because as the layers shrink, the layer above is constantly compensates for the shrinkage when it is extruded. Until the last layer which in and of itself doesn't shrink a measurable amount. However, in the XY direction, no such compensation occurs.

I found a nice link on the dioder LEDs bars. The controller is powered by 12v and each bar consumes about 100ma. So 4 of them might be too much for the 12v regulator on the UM control board. If you wanted to eliminate the line/mains adaptor, you could replicate the 12v source the UM uses on a small protoboard and then power it from the 19v coming from the LED connector. http://www.rwalter.de/dioder-hack/ You just need the same 12v regulator the UM uses and some capacitors. I don't have access to the schematic but this is the basic idea: http://www.researchcell.com/electronics/7812-pin-and-circuit-diagram/

>>> As well as a new firmware for an upgrade kit. Did you just let something slip? What upgrade kit??!?!?!!?!!!?!!??!!?!!!!!!!!!!!!11111111one

The UM1 can be expanded with a second extruder and hotend. Assuming you aren't going to do that, it means that the power used for the 40w second hotend and extruder stepper is available for you. With power = current * voltage then current = power / voltage so 19V @ 40W means you have more than 2 amps free without the second hotend and even more because you don't have the second extruder. So that gives you a budget of about 500ma per fan which is more than enough. The current that would have been used for the stepper, probably along the lines of 750ma-1a can be used for your LED lighting. Just be careful when selecting the fans. The one on the hotend is 12v but is actually running at 19v. However, you should really use a 24v fan if you are powering from the existing PS. I broke my fan on the hotend and tried to replace it with another 12v fan model and it instantly went up in smoke. Plus a 24V fan running at 19v will run slower and therefore quieter. There is a 12V regulator on the UM board but I think it is limited to 1 amp. Four fans + the arduino will be close to this if not exceeding it and even more so if you have the ulticontroller. To be honest, the steppers don't need to be cooled. I think they are rated at 80C. If they are getting that hot, you probably have too much friction or belt tension. Plus if I had to guess, the z stepper probably doesn't even get warm as it is only intermittently used. So focus on the XY E steppers if you really want to do this just because... For LEDs, there are mounts for these on thingiverse and youmagine: http://www.ikea.com/us/en/catalog/products/20119418/ But they are powered separately.

Daid, The new UI looks nice and very polished. LOL - "Big and Bold - That's what she said!!!!' Is the Cura icon changing to a pink horse/unicorn?

Well to me it seems that is the opposite of what you should do in my uneducated opinion. If you decouple then you can have the platform moving in one direction due to a lag in it responding to a previous frame movement because of its increased mass and the frame moving in the opposition making the error much larger. I would think that the three axes should be as strongly coupled as possible so they move as one unit due to the shifting mass of the hotend or the XY axes should dampened by the frame so that vibration between the XY and Z don't occur. However, I have little mechanical engineering or experience with 3D motion systems so there is probably something I don't understand deeply enough. I think there might be something to increasing the weight of the platform AND the weight of the frame. The Z stage has a lot of "slop" in the vertical axis. It's possible that it is bouncing up and down slightly as the z-screw moves. Weighing it down probably helps it settle more forcefully and accurately when the z-screw attempts to move it down.

Bloody brilliant!!!! Although, I would think that the opposite would be the way to go. The z-stage should always be the same distance from the from the print head in all three axes during printing when the head moves. The movement of the head doesn't move the z-stage directly. Instead, the shifting of the frame is then translated into the z-stage. If the shifting of the z-stage doesn't exactly match that of the rest of the frame, the relative positioning of the stage to the head will have error. I would think that the way to reduce this error is to make sure the z-stage stays in sync with the shifting of the frame. There are two ways to do that. Make the z-stage LIGHTER or prevent the frame from shifting by making IT heavier and more rigid. I guess I should read the other thread.