mpatoulachik

Note that a little bit of axial load is actually benefical to the lifetime of the bearing as it makes sur the balls are always in contact somewhere and not wobbling around. Generally this is done on high speed applications (universal motors etc) with a ring-shaped wave spring ("Smalley spring"). Normally you should allow one of the bearings to float axially a tiny bit to compensate for thermal elongation. If your shaft and chassis do not expand at the same rate it will generate axial loads. One thing to think about: the deeper the groove, the less tolerant the bearing is for misalignment (again, pressing the balls sideways and eating lifetime). Normally you should also lock radially the race that rotates seen from the load's point of view (sometimes the load turns with the shaft, sometimes the load is always in the same direction compared to the chassis. This is to avoid that the bearing starts doing "Hula Hoop" in its housing (or the shaft doing it in the inner race depending on the load case). But for DYI all this is overkill... Normally the relevant info you look for are dimensions and maybe load. Outside tolerances are usually pretty standard and not needed if you don't manufacture an engine yourself. (we are talking microns of tolerances...) Usually the inner race bore is tolerance H7 which means it will slide on a standard ground shaft rod and the outer race is so that you will have to slightly tap it into a standard bore. The load will help you determine the statisical lifetime (L10, expected lifetime after which there is a 10% chance of failure) This is counted in milions of turns, so if you don't put huge overload or fill the bearing with sand you will never experience a bearing failure in your lifetime. Inside tolerances will give you an indication of how much play there is in the bearing itself. Tighter means more expensive. If you don't have a good reason to have a precision bearing (high speed and/or accurate positioning like a high rpm mill spindle) then stick to the regular ones. Again, we are talking a couple of microns here, so if your machine is made of plywood or if you didn't manufacture the whole bearing arrangement within microns, you don't need accurate bearings or carefully calculate load case and liftime, it would be like putting a Ferrari motor in a Lada.

Hi, I can hear a clicking noise from the heated bed electronics board even when the printer is off. Actually it clicks only if the printer has been on before. If I unplug and plug in the power, no clicking. If turn the printer on and off again, the board will be clicking (even if the heated bed has not been activated). The clicking is about 3-5Hz and does not stop unless I unplug the power. Is that normal ?

You were right! The SD card in question is causing problems. I couldn't reproduce the issue with my old (512 Mb) SD or printing from USB. Quite odd that the bad SD created problems with some files and not others. Amazing that the corrupted data sent to Marlin was still good enough to be interpreted as coordinates and somehow "printed" (except when the printer got stuck..). I guess there is a special paragraph about this in Murphy's law like "if somethig can go wrong, it will, but in the way that will make troubleshooting the most difficult and counter-intuitive possible" I would have expected bad SD issues to show up as files impossible to open or not detected card, not these half-random printing glitches... Anyhow, thanks for the help, I was miles away from suspecting the SD card itself.

Ok, I will look at that. So far I have printed about 10 ultirobots from both versions of Cura (14.09 and 13.10) and it never flipped out on the file from 13.10 but only succeeded once with the file from 14.09. But looking at the code I can't see anything that can make the printer freak out on just one of the versions; both files have roughly the same size (64-65 000 lines) and roughly the same paths and speeds. I will try from USB and from another SD card (the original one I got with bthe printer is broken)...

Changing the Z-speed to 5-10% lower or higher might help as well as the standard speed might create vibrations at just the right wrong frequency to trigger resonance in the frame. I have been experimenting with MIDI-CNC music and some notes play definitely louder than others on the machine (mill or printer).

Hi, I have issues when printing models sliced with Cura 14.09 (and 14.07 a well). The symptoms: Although the generated Gcode seems ok, the printer goes crazy in some places and goes all the way to some X or Y endstop before continuing or sometimes feeding out 20 cm of filament, feeding it in again and continuing to print. Sometimes it skips a layer or two and continues printing. Sometimes the printer stops in the middle of the print with the heat on. It just stops where it is and still says "printing" See how it goes here: http://www.dailymotion.com/video/x2949c6_issue-with-cura-14-09-and-ultimaker-firmware_tech The video starts after it already went to x- endstop and Y+ then Y- then printed "normally" a few seconds. Since I know the print is doomed to fail I use all my short leftover filament bits, which explain the color changes... The setup: I run an Ultimaker original and Ulticontroller, just upgraded with a heated bed kit (but had the issue before). Slicing from Cura 14.07 and 14.09 gives the issue on some models (not all). The problem existed before I updated to the firmware from 14.09. I believe I had the one that came with 14.04 or something like that. Ironically the ultimaker robot is the model I have most problems with. Tests: -From the same computer I sliced the same model (UltiRobot) with the same settings with both Cura 14.09 and 13.10 (was still installed) -I put both files onn the same SD card (2Gb MicroSD from AData) -When I print the one sliced in 13.10, no problem whatsoever -When i print the on from 14.09 the printer goes to endstops, winds out and in filament and finally stops with the nozzle in the part and leaves the heat on (not good at all..) Thoughts: When I look at the Gcode in Notepad++, Repetier or Pronteface I can't find any command for this weird behavior (no Y0 or E-200 or anything looking like that). The code looks prety normal although it has a lot of tiny segments and many small travels. Could it be something that makes the firmware go nuts??? Other thoughts?

Hi, I noticed Cura has problems exporting printing time, filament length and cost to the gcode file when using Batch run What I get in the header of the file is: ...;Print time: #P_TIME#;Filament used: #F_AMNT#m #F_WGHT#g;Filament cost: #F_COST#... Not a big deal really, but it is the only way to know how much filament I must have available and if the print will take half a day or just 10 min. When it comes to project planner the above works fine but the line regarding the filename says : ;Sliced ?filename? at: Wed 10 Oct 2012 17:25:27 It can't display a filename since there are several source files. Really not a big deal, but hey, if someone ever happens to do stuff in this part of the code, maybe making it write a list of the filenames or just default it to say "several files" would make it nice. And by "nice" I mean "Even more badassly-freaking-awesome than Cura is today) Thanks!