hp-65

Phew, I am relieved... So, I indeed understood what you meant rightaway, but it doesn't work very well on my machine. To align the pulley, I loosened it and looked at where it moved. This is where the came from. After tighening the pulley at "the best place" (no matter where): Additionally, it even got more complicated: As it seems, the appearance of the noise is not linear nor time invariant and - in addition - temperature dependent :wink: I'll have to do some experiments... Thank you for all the hints!

You are right! My fault, didn't check and they seemed to be much too fast... But I guess G. meant the clicking was caused by the belts, moving up and down on the edge of a misaligned pulley and not the rods? I am terribly sorry, but I still don't get this...

Yes, I know all of this (and more 8) But I don't want to hijack your thread, so back to the topic: I increased the filament driver current a bit and it's definitely working better now, but I still, really miss the tactile feedback. I guess I will replace the filament driver with a one that can be used manually. Also, I tried to exchange a 250°C filament with a 180°C type and vice versa. Not (safely) possible without a PC attached to the serial port...

Yep... These won't last long... === I am sorry, but I don't understand what you mean... The pulley can either be moved outwards, pushing the spacer against the bearing, which is the current "clickclick...click" setting or I can move it towards the inside of the machine. Probably less clicking, but the rod isn't hold in place any more... Maybe I soak it up with grease 8) *blobblob..blob*

https://github.com/Ultimaker/Ultimaker2 1) No, I guess Dhaid (*1*) left it out intentionally. 2) Yes. The code is already about to hit the last stages of entropy. You won't break it (no offense, here !-) === (*1*) Neither I am, nor I know the guy who posted this, but I can't get this out of my head (-; I very much apologize for this...

I programmed an endless back and forth travel for the y-axis and clearly heard the clicks coming from the left, but I did not notice the belt moving up and down. But I can imagine that. At least, I can't think of any other source for these clicks :wink: After loosening the pulley, three things happened: 1) the pulley moves right if the y-axis is moving backwards 2) the pulley moves left if the y-axis is moving forward 3) the rod leaves the case I guess I have to put in some clamping collars there... 8/ I bet these are 12V fans, attached to the 24V supply... *clickclick..click*

Like I assumed above: Reference voltage is created by an RC low-pass filtered PWM. Image shows X-stepper, but all others are the same.

Just to make sure: You copied the files with the extension .gcode right?

DIGIPOTSS_PIN is not defined for this board, so you can't change the motor currents via M907/908: case 907: // M907 Set digital trimpot motor current using axis codes. { #if defined(DIGIPOTSS_PIN) && DIGIPOTSS_PIN > -1 for(int i=0;i<NUM_AXIS;i++) if(code_seen(axis_codes)) digipot_current(i,code_value()); if(code_seen('B')) digipot_current(4,code_value()); if(code_seen('S')) for(int i=0;i<=4;i++) digipot_current(i,code_value()); #endif } They obviously did it the cheap way, via a filtered PWM on pins 44, 45 and 46: #define MOTOR_CURRENT_PWM_XY_PIN 44 #define MOTOR_CURRENT_PWM_Z_PIN 45 #define MOTOR_CURRENT_PWM_E_PIN 46 ... //Set timer5 to 31khz so the PWM of the motor power is as constant as possible. TCCR5B = (TCCR5B & ~(_BV(CS50) | _BV(CS51) | _BV(CS52))) | _BV(CS50); ... void digipot_current(uint8_t driver, int current) { #if defined(DIGIPOTSS_PIN) && DIGIPOTSS_PIN > -1 const uint8_t digipot_ch[] = DIGIPOT_CHANNELS; digitalPotWrite(digipot_ch[driver], current); #endif #if MOTOR_CURRENT_PWM_XY_PIN > -1 if (driver == 0) analogWrite(MOTOR_CURRENT_PWM_XY_PIN, (long)current * 255L / (long)MOTOR_CURRENT_PWM_RANGE); if (driver == 1) analogWrite(MOTOR_CURRENT_PWM_Z_PIN, (long)current * 255L / (long)MOTOR_CURRENT_PWM_RANGE); if (driver == 2) analogWrite(MOTOR_CURRENT_PWM_E_PIN, (long)current * 255L / (long)MOTOR_CURRENT_PWM_RANGE); #endif } Hopefully that timer never stops :wink:

Nice one, good job! Just to put in some tolerances here: I need 235°C for 65mm/s, same configuration as yours... At least for me, the new, "no manual operation" material feeder is one of the biggest disadvantages of the UM2, it lacks the tactile feedback... Time for a tear down ;-)

M106 :wink: I fixed it: The noise is caused by the metal sheets. They are not rigid (or damped) enough. === The other part, the quite loud clicking noise is not caused by the material feeder, this one sounds very different. I already had and solved the feeder/stepper issue (yup, I had 3 noises before this post :wink: This one is caused by the X/Y movement, but I can't figure it out. I already spent hours and hours on diagnostics on my UM1 (sounds the same, but occurs less) and the only thing that helped was increasing the belt tension (too much). click, clickclick, click, click *aaaaaaarrrgh*

I can't hear you, because my UM2 makes strange, loud noises 8D https://www.dropbox.com/s/xwy6bro8fw8h2ft/UM2.mp3 The hissing/rattling noise is caused by the two, outer fans and stops if the PWM is reduced below ~90%. The clicking sound, well, I don't know where it's coming from, but my UM1 has exactly the same issue. It once got better after increasing the belt tension a bit (UM1), but reappeared after a while. Anyone with the same issues? Any ideas on how to get rid of this? It's really driving me mad...

? You already had this "better handling" built in, but removed it...

Ich benutze auch sehr oft und gerne PLA90, deswegen kann ich das mit den +10K sowie der besonderen Wärmebeständigkeit nicht nachvollziehen... Ich drucke das Zeug, im Vergleich zu anderen, harten PLA-Sorten 10K "kälter". Kann es sein, daß Du bislang immer nur mit "Wabbelkram" gedruckt hast? ;-)) Oder vertickt Orbi-Tech hier einfach nur wechselnde Herstellerprodukte unter selben Namen? OT: Ebenso bin ich überrascht, daß auf deren Webseite nun auf einmal wieder farbiges Material auftaucht. Nach ein paar Tests bin ich ziemlich sicher, daß das exakt dasselbe Material wie bei germanreprap.com ist.

Same here... More than 2300€ for a "balance due" and no response to any of my tickets or emails... What takes less time? Waiting for a reply or canceling the Visa transaction?

1) Improve your customer support.

Cool... I ordered and paid 22th September via credit card and all get is a lousy "Balance due"??

I never experienced this and I hope that (almost) everything remains as it is, right now :wink: I have a profile setting for every filament spool: "File" -> "Open Profile" -> "Ulti1_Nr2_SchwarzHart_v05.ini" That easy! 8D Additionally, I have multiple copies of Cura in different directories, one for every machine, because Cura only supports one. A change would make sense for that indeed...

Tested with Cura 13.06.4 and 13.07.T2. Infill settings below 25% produce a very coarse structure. 25%: 24%: The infill created with 24% looks more like a 10% setting. Is there any quick workaround available? Any command line arg for the slicer that can be enabled/changed to revoke an older algorithm?

I was disappointed too, I came to order an UM2, but didn't... Add a detachable hatch with hinges and a magnet lock on each side and develop a filament driver that still can be operated manually - and I'm in!

Da ist was unfest ;-) Entweder sind die Riemen viel zu schlaff oder Schrauben an den zugehörigen Riemenrädern locker. Schrittmotor-Riemen und Räder nicht vergessen!

Works great (-; After I printed this, I suddenly thought if it wouldn't be a good idea if one could enter a negative "Cut off object bottom"-number, just to lift the object a little and avoid this: Because the first two (maybe three) layers always have a slightly different height, the printing quality of a lifted object would benefit from this...

Nice upgrade! The bottom indeed looks much better now, a rigid base for complex builds. Unfortunately, 13.07_T2 now prints in mid-air :wink:

I didn't use the project planner for a while, an unforgivable mistake: Whamm, there went another fan... Short description: Although the "scene" sort- and placing algorithm takes care about object hits, it completely ignores their order. At least, not in relation to the size of the printing head. I didn't test this on my Ultimaker and concentrated on the y-axis, because the crashed machine has the fan towards y-min. Maybe that's the reason because it's working for most of us while we're using the Ultimaker? With the fan on the left side? My (debug) settings: xmin 100 ; only to block x-placement xmax 100 ; only to block x-placement ymin 50 ymax 1 Try swapping ymin and ymax and look at the gcode output (or put in some debug prints after sorting completes or the slicer starts to work): The objects are always sorted in the same (wrong) direction... Here are my findings, so far. def setHeadSize(self, xMin, xMax, yMin, yMax, gantryHeight): self._leftToRight = xMin < xMax self._frontToBack = yMin < yMax self._headOffsets[0] = min(xMin, xMax) self._headOffsets[1] = min(yMin, yMax) self._gantryHeight = gantryHeight Ok, a clever solution (except for the overall readability of the algorithm, which got lost without a single comment :wink: Indeed, if we know the right direction, towards the longer head part, we only need to store the shorter dimension. Unfortunately, the "scene sorter" while len(self._todo) > 0: n += 1 current = self._todo.pop() for addIdx in current.todo: if not self._checkHitFor(addIdx, current.order) and not self._checkBlocks(addIdx, current.todo): todoList = current.todo[:] todoList.remove(addIdx) order = current.order[:] + [addIdx] if len(todoList) == 0: self._todo = None self.order = order return self._todo.append(_objectOrder(order, todoList)) self.order = None only cares about the initially created hit map, created via: def _checkHit(self, addIdx, idx): addPos = self._scene._objectList[addIdx].getPosition() addSize = self._scene._objectList[addIdx].getSize() pos = self._scene._objectList[idx].getPosition() size = self._scene._objectList[idx].getSize() if self._leftToRight: if addPos[0] - addSize[0] / 2 - self._offset[0] <= pos[0] + size[0] / 2: return False else: if addPos[0] + addSize[0] / 2 + self._offset[0] <= pos[0] - size[0] / 2: return False if self._frontToBack: if addPos[1] - addSize[1] / 2 - self._offset[1] >= pos[1] + size[1] / 2: return False else: if addPos[1] + addSize[1] / 2 + self._offset[1] >= pos[1] - size[1] / 2: return False return True but never about the preferred direction towards the small head dimension. Until know, I indeed did not manage to find any code that cares about the direction or am I missing something? I was afraid of touching this hell of a sorter code, so I disabled it and wrote a quick workaround that allows me to select the order of the objects by simply clicking at them, but that's probably not what you want :wink:) It really would be nice having this piece of code back and working!

Your SW, your decision, but importing old setups results in a two times larger overlap. Maybe a note or a warning would be helpful...