anon4321

Well, you need to rebuild the firmware. See the bottom of https://github.com/ErikZalm/Marlin and you need the hardware which will depend on the way you mount it. For example: http://www.thingiverse.com/thing:225584 http://www.thingiverse.com/thing:89146

There is no need. The firmware has a mathematical leveling function. You just need a Z probe. Once the points are measured, marlin will mathematically adjust the coordinates so the part is printed level to the bed even when the head isn't level to the bed. I have a magnetically mounted probe I use at the start at the start of a print.

See this for more troubleshooting ideas: http://umforum.ultimaker.com/index.php?/topic/6908-ultimaker-original-wont-print/

I've only slightly worse repeatability using a microswitch. http://umforum.ultimaker.com/index.php?/topic/6805-limit-switch-repeatability/?p=63303

Daid, I would have thought the opposite and have the grub screws pulling the pulley to the round part of the shaft ensuring it is concentric. Plus it would be impossible to have the pulleys slip. Could you explain a little more why not using the flat is better for print quality?

The correct connection is the thermistor across the outer pins which are gnd and signal. The middle pin is 5V and isn't used with a thermistor. You should measure 4.7k between the middle %V pin and the signal pin which is towards the power connector without the sensor attached and no power. See if someone else with a better understanding of thermistors chimes in but 140K sounds high. I thought the typical thermistor used for 3D printers are the 100K types which means they are around 100K at room temperature. So m the unconnected sensor at room temperature and it should be near 100K.

A cheap one would do. They are good to have for this hobby and for checking batteries.

Ok, this is cutting into my nap time but.... There seems to be three things left: Bad Driver Bad Board Noise causing extra steps. So let's try to eliminate what we can. NOTE: see NOTE after this.... To check for a bad driver. with the power off, swap it with another one. IMPORTANT NOTE: The drivers on the one side are installed 180 degrees different than the opposite side. So if you are swapping the E driver with say the X driver, you would flip them 180 degrees. Alternately, note the location of the current adjust pot and make sure you match the orientation. NOTE: If you get the orientation wrong, you will KILL the driver immediately upon powering up. Once you have the drivers swap, put the cover on and test. If the problem moved to the other axis, you know it's the driver. If the problem stays on the same axis, you will need a voltmeter to check if it is the board. NOTE: you must be careful with the probes to ensure you don't short something What you need to do is to measure the MS1, MS2 and MS3 pins on the driver. These pins control the microstepping mode. A stepper motor has a set number of physical steps per rev. For the UM1, the motors have 200 steps/rev. However, the drivers can partially step the motor. We don't need to go into the mechanics and electronics on how this is done. Just know that when MS1 - MS3 are high (5V), the driver divides each step by 16 so the motor that has 200 steps will appear to have 3200 steps. If MS1 - MS3 aren't held high, the firmware will issue a step assuming that the motor moves 1/3200th of a rev whereas the motor really moves 1/200th of a rev. If the firmware wants 1 rev, it will issue 3200 step pulses. However, if the steps are full steps, the feeder will turn 16 revs So see the pic below. With the meter set to measure voltage on a range that will measure 5V. place the black probe (-) on either black circle BEING CAREFUL not to short between pins with the probe tip. Then with the red (+) probe measure EACH of the red points. Each one should measure 5V. IF they don't ALL measure 5V then we found part of the problem. Check the jumpers next to the driver. Pull them off and reseat them. You should be able to touch the metal inside the jumper with the red probe while the other probe is on one of the black points. The metal in each should measure 5V. If MS1-MS3 are at 5V, then it might be noise from the arduino causing false steps but from your videos, the stepping seems pretty consistent. So I suspect that you will find MS1-MS3 aren't all at 5V or the driver is bad.... BE CAREFUL and good luck...

Jonny, regarding the slack joint (at the head end I assume), ***cough see second pic *** cough *** shameless plug *** https://www.youmagine.com/designs/um-original-bowden-tube-clips-and-retainer *** cough ***

So on the hardware side, it looks like if you solder a 100K in the R23 (or R21 for dual extrusion) would fix the floating ADC issue. Correct?

If you are going to address this, You should also address this: http://umforum.ultimaker.com/index.php?/topic/7070-feature-suggestion-nozzle-heater-runaway-protection/?p=65778 *******NOTE: if my analysis of the above code is correct. Pulling the temp sensor HIGH is BAD unless the code is fixed. UNLESS, the condition is detected elsewhere. Is there code that produces the MAX TEMP error and would it detect this? I think so... However, I think for the most consistent and safest checking, I think the changes I suggested should be made. The architect in me says the temp checking should be handled in one place and should be defined as the temp being within the expected range within the expected time. This check would handle fail to 0 and fail to MAXTEMP. The only thing it doesn't handle is fail to continuous reporting of the current value which I believe should be handled by the pull up resistor fix.

So based on the code - The first requirement is that the current temp be less than the target temp being set by twice the watch increase value. The UM1 firmware comes with a increase vale of 10. So that means if the hotend is at say 180 and you set the new temp to be anything less than or equal to 200, the watch code won't be trigger. The second requirement is that when the watch temp period elapses (the period by default in the UM1 firmware is 40 seconds), the temp must be ANY AMOUNT greater/equal to than the set temp plus the watch temp increase (10 for the UM1 firmware). The third key point is that when the second requirement is met, the watch is DISABLE. So for the UM1, this check won't help if - The sensor reporting fails in a mode where the reported temp is a high value (10 more than the temp value set) or max value... - If the sensor reporting fails in any mode after 40 seconds, the error won't be caught. Obviously, this could and should be improved - - There shouldn't be a check when the temp is changed that the hotend is less than the set point less twice the watch temp. If the set temp is changed, the watch temp should just be updated along with the watch temp check time to be the current time plus the watch temp time period. - When the watch temp time period elapses, the temp should be checked to see if it is in the range of set temp plus/minus the watch temp increase. Hmmmm... well, see notes below. - When the check is done, the check shouldn't be disabled. Instead, it should be set to the current time plus the watch temp period. Note: After thinking about this a little - obviously, cooling down is a lot slower than heating. So the values might not work well and there might be need for a second set of cold down values used when the set temp is set below the current temp. However, an additional check should be implemented that when the cool down mode values are in effect, the temp should be checked at the heating check period to ensure that it hasn't INCREASED above the temp at the time of the temp change was requested plus the temp increase check value. Not impossible to code. However, it's quite possible I haven't considered everything and could introduce all sorts if false "heating failed" problems... Don't have time now but might attempt to implement if someone else (cough GR5 cough Daid cough illuminarti cough) doesn't.... Here is the existing code for the UM1 - Marlin does this when you change the temp. void setWatch() { #ifdef WATCH_TEMP_PERIOD for (int e = 0; e < EXTRUDERS; e++) { if(degHotend(e) < degTargetHotend(e) - (WATCH_TEMP_INCREASE * 2)) { watch_start_temp[e] = degHotend(e); watchmillis[e] = millis(); } } #endif } Then during heating it does this check during the manage heater routine. #ifdef WATCH_TEMP_PERIOD if(watchmillis[e] && millis() - watchmillis[e] > WATCH_TEMP_PERIOD) { if(degHotend(e) < watch_start_temp[e] + WATCH_TEMP_INCREASE) { setTargetHotend(0, e); LCD_MESSAGEPGM("Heating failed"); SERIAL_ECHO_START; SERIAL_ECHOLN("Heating failed"); }else{ watchmillis[e] = 0; } } #endif For the UM1 version, the values involved //// Heating sanity check: // This waits for the watch period in milliseconds whenever an M104 or M109 increases the target temperature // If the temperature has not increased at the end of that period, the target temperature is set to zero. // It can be reset with another M104/M109. This check is also only triggered if the target temperature and the current temperature // differ by at least 2x WATCH_TEMP_INCREASE #define WATCH_TEMP_PERIOD 40000 //40 seconds #define WATCH_TEMP_INCREASE 10 //Heat up at least 10 degree in 20 seconds

I remember that it was mentioned that there would be a version of the UM1 with the kit AND the UM2 electronics...

I've recently learned that DC causes arcing issues and it very hard to switch mechanically with any reasonable reliability at a cheap cost. Your best bet is to use a solid state switching solution such as a MOSFET. See http://umforum.ultimaker.com/index.php?/gallery/album/1093-heated-bed-mosfet-relay-hack/ and http://umforum.ultimaker.com/index.php?/topic/6478-ultimaker-original-upgrades/ or SSR if you aren't into soldering and electronics. I'm using this: http://www.phidgets.com/products.php?category=9&product_id=3950_0 Works well but at 30USD not something I would call cheap. Jonny's circuit could be built for a few bucks/euros...

Well, using the M42 would NOT provide PWM. It would only provide on/off control. And on -> off and off-> on would only happen as quick as the gcode is executed. I don't think the execution is quick enough or predictable enough to be considered PWM. Plus you would need to have lots of M42 commands turning on and off. If you really need PWM for something that you need to run at 10% or 60% or 43%, it would take more effort. There is an array of three values used by the ISR to produce the PWM for the heaters and bed at a speed and regularity required to be fairly accurate PWM.

Oh 3dcase you are such a tease!!!!!! In your profile - Printer(s):UM orginal, Dual Ext, HBKit !!!!! Are you under non-disclosure? Could you at least tell use that major components ? Wood drill? Sounds like the Z rods need to be changed, relocated or swapped. So it sounds like you are really paying for a new Z stage that has a heated bed so it might improve print quality or reduce leveling issues and almost as a side effect you get a heated bed.... In that case, I might pay the price!

I assume you don't want any of the heating functions. So no nozzle 1 or nozzle 2 or hotbed heaters correct? If this is the case, you can disable the code that manipulates the pins used for the software PWM to those three MOSFETs. Then you can remove the PINs from the excluded list of PINs you can't use with the M42 command. Get the source for Marlin https://github.com/Ultimaker/Marlin and look at Temperature.cpp and search for ISR(TIMER0_COMPB_vect) This is the interrupt service routine where the pins are toggled. After reviewing and understanding what's going on there, you will know what to comment out. You should also search all the source for other references to HEATER_0_PIN, HEATER_1_PIN and HEATER_BED_PIN to ensure they aren't being manipulated somewhere else. You might need to change things in the manage_heater function of Temperature.cpp as there are a bunch of checks around the heaters to ensure the temp is rising when expected etc. However, if you don't call for the temperature to be anything other than 0, you might not run into the checks. Then you could remove HEATER_0_PIN, HEATER_1_PIN and HEATER_BED_PIN from the sensitive list that prevents their use in the M42 command. Look for a section like this and remove HEATER_0_PIN, HEATER_1_PIN: //List of pins which to ignore when asked to change by gcode, 0 and 1 are RX and TX, do not mess with those! #define _E0_PINS E0_STEP_PIN, E0_DIR_PIN, E0_ENABLE_PIN, HEATER_0_PIN, #if EXTRUDERS > 1 #define _E1_PINS E1_STEP_PIN, E1_DIR_PIN, E1_ENABLE_PIN, HEATER_1_PIN, #else #define _E1_PINS #endif #if EXTRUDERS > 2 #define _E2_PINS E2_STEP_PIN, E2_DIR_PIN, E2_ENABLE_PIN, HEATER_2_PIN, #else #define _E2_PINS #endif Then look at the end of the file for this and remove the HEATER_BED_PIN - #define SENSITIVE_PINS {0, 1, X_STEP_PIN, X_DIR_PIN, X_ENABLE_PIN, X_MIN_PIN, X_MAX_PIN, Y_STEP_PIN, Y_DIR_PIN, Y_ENABLE_PIN, Y_MIN_PIN, Y_MAX_PIN, Z_STEP_PIN, Z_DIR_PIN, Z_ENABLE_PIN, Z_MIN_PIN, Z_PROBE_MIN_PIN, Z_MAX_PIN, PS_ON_PIN, \ HEATER_BED_PIN, FAN_PIN, \ _E0_PINS _E1_PINS _E2_PINS \ analogInputToDigitalPin(TEMP_0_PIN), analogInputToDigitalPin(TEMP_1_PIN), analogInputToDigitalPin(TEMP_2_PIN), analogInputToDigitalPin(TEMP_BED_PIN) }

No!!!!!!!! that sucks. You might try colorfabb XT. Less brittle/more flexible but that sometimes requires thicker and heavier shells.

I might be wrong on the UM2 electronics but I'm pretty sure about the complete Z platform, stepper motor and PS. So without the UM2 electronics, I'm guessing 300 euros. We will see ...

You can also set the steps/mm via gcode so no ulticontroller or custom firmware required. Other (US) sources of belts and pulleys would be: http://www.sdp-si.com/ Long https://sdp-si.com/eStore/Catalog/PartNumber/A%206R51M303060 (oddly the pitch length doesn't match the number of teeth (612 vs 303) hopefully it is an oversight). Short https://sdp-si.com/eStore/Catalog/PartNumber/A%206R51M100060 Adafruit Pulleys http://www.adafruit.com/products/1251 http://www.adafruit.com/products/1252 These are 3-4x the cost of robotdigg. Hopefully that translate to quality.

I can answer this. Yes. Cura only comes with firmware for the UM kit heated bed. Even if you select custom/self installed, Cura will flash the UM kit heated bed firmware. This has caused locked up printed for some of us.

That is sweet. The body looks like it was commercially made! 133MPH? Real not scale speed? WOW! Now we need VIDEO!

Exactly, you need different blocks. I tried the 303 tooth GT2 with the twister blocks and had a HORRIBLE time. The blocks are designed for the stock belts and the shorter center-to-center distance if the 303 GT2 belts means that the built in tensioner is too much. Did you use the twister blocks as designed or with a different clamp part?

I think the official one is going to be pretty expensive. Based on leaks here an there, if I had to guess, it is basically the UM2 platform retrofitted to the UM1. It seems that in addition to the complete replacement platform and heatered bed combo, you will also get a new stepper motor and I'm guessing the UM2 electronics plus the UM2 power supply. Given all that, my guess is the price will be around 500 euros...

RE 1) Strange, it always reloads the same for me no matter which format I use. Hopefully someone else knows 2) You can't set the order but cura knows how not to run into the other parts. However, it only knows that by what you tell it as far as the head size goes so yes if you are using a different fan shroud you need to update the values. Note that if any part is higher than the gantry height setting, cura will force "Print all at once" where all parts get the first layer then all parts get the next layer and so on. Otherwise the smaller shafts would potentially hit a completed part.