anon4321

I have a problem with Cura "flaring" the layer view when the tool path is loaded. It renders the layer view somewhat unusable. Before the tool path gets loaded,it looks fine: When the tool path is rendered, it is flared out and overlaps itself smear out the actual path: Here is the behavior a little lower: I originally thought that the entire layer view was broken and was suspecting that I had a video driver problem. However, I just noticed that the display is fine before the tool path is loaded. I think this makes it less likely to be a driver problem but it could be driver problem as my video card is somewhat old and the driver hasn't been updated in a while. Anyone else see this? Any suggestions on how to determine if it is Cura or the video driver?

Sorry, yes I see now that at the top they are .25 x .25. Lower in the page it says - Product Details Product Dimensions: 0.5 x 0.5 x 0.2 inches ; 1.6 ounces .25x.25 is about the same size as the ones that I ordered and are uses on the A4988 type drivers or slightly smaller. The A4988 sinks are 6.3x8mm. I think they ones you got should work for you.

You can remove them with a twisting motion and then scrap off the cement. I've done these for drivers I burn out to use the sinks on the replacements.

There is a little problem in that if you pick the wrong sensor type, the firmware enters an error state when it first starts. Eliminate some variables and get some confidence in the builder by using the most basic template to build the firmware for the simplest configuration and see if you can get that to work. Either Basic UM or Basic UM plus Ulticontroller and do NOT change for the heated bed.

Didn't get to work on this, long day and needed to do housework... Will continue tomorrow and/or over the weekend aviphysics, as long as the heatsinks fit and don't short something, they will be OK. They might be too large. Amazon link has them as 0.5 inch square which is what about 12mm. The ones I linked to are half that size. The problem might be that they mount on the side opposite the chip so the chip won't elevate them such that they don't touch traces. At least you don't need to worry about them hitting components because on the back, I don't think there are any...

Wetterott sells the tiny sinks that are used on the originals so it made sense to add them to the order. http://www.watterott.com/en/Heatsinks-6-3x8mm I'll attach them with some Arctic Alumina™ thermal adhesive which I like better than the tape.

For white, I've been using 255/65 and 50% fan for prints with lots of retraction.

Just need to cement the heat sinks on. Getting too late to continue tonight. Maybe heat sinks tomorrow and recording the sound of existing drivers. Then Friday I'll drop these in and see how they do...

Easiest way is to look into how to use: http://marlinbuilder.robotfuzz.com/ This will save you the trouble of figuring out what is need to recompile the firmware as the builder will do that part for you. You just need to supply the correct values. I'm sure there are many writeups on how to use ginge's builder but I'm sorry I don't have one to provide... Start with the correct template and you will be 98%-100% there...

Did you rebuild the firmware for your bed temp sensor type? You can NOT use the firmware that comes with Cura.

I have four of these drivers on the way so we will see how it goes...

One other thing, the way the shield enables/disables the drivers may not allow the current reduction on idle feature to be used. To enable the current reduction mode, enable must be left open whereas grounding it will enable the driver but without the current reduction feature. The drivers will still work as letting the enable pin go high disables the driver. Grounding it enables the driver. However, optimally, letting the pin float would be the best way to enable the driver as it would also enable the current reduction on idle. However, that would at least be a firmware change if not a hardware change...

These are sort of pin compatible to the current drivers. "Sort of" because they are configured differently and in a way that can't be supported by the jumpers on the shield which either leave the conf pin open or pulled to 5V. Also they don't support the range of microstepping that the polulo type drivers do. So my plan is to: - Purchase 4 or 5 drivers - Since - The UMO uses 16 microstepping mode for X and Y - That is one of the microstepping modes supported - No firmware changes are required if X and Y stay in 16 microstepping mode - Those axes are the biggest source of noise I'll try the drivers in those to axes first. - In order to get into the recommended mode, I will NOT solder header pins to the 3 config pins which basically disables the use of the jumpers on the shield. - Then to get into the recommended mode which is 16 microstepping with 256 microstepping interpolation with spreadCycle enabled, cnfg1 needs to be open which it already is due to the lack of header pins on the cnfg pins and cnfg2 needs to be grounded. Since the jumpers on the shield can't ground the pin, you need to solder a jumper wire from cnfg2 to one of the ground pins on the carrier. See the notes here: https://github.com/watterott/SilentStepStick/blob/master/pcb/SilentStepStick_v10.pdf?raw=true If the extruder is in 16 microstepping mode (can't remember at the moment), I'll do that one next. Then I'll make a call about the Z axis. It isn't very noisey at all and I believe it uses 8 microstepping mode which is NOT supported on this driver. This means the FW would need to be changed for 16 microstepping mode and it might not be worth the hassle...

Daid, Does your comment refer to the stealthChop feature or the spreadCycle feature? As noted, stealthChop while extremely quiet doesn't provide enough torque for a 3D printer. SpreadCycle is the advanced current/frequency control which I believe gets you the 256 microstepping interpolation. 256 microstepping should help quiet things down but not to the extent of stealthChop.

I'm looking for a decent set of jeweler's files. I just have one massive file.

TMC2100 is more like the polulo driver in that they are still driven with dir/step pins. The MS1-MS3 functionality isn't the same neither is the fact the TMC2100 has diag out pins that aren't compatible with the typical polulo socket pinout. However, you can apparently make them work in a polulo type socket but NOT soldering certain header pins on.

The function that fails for 3d printers is the "stealhchop" mode which would be virtually silent operating apparently in a constant voltage mode much like a brushless motor controller. However, some noise reduction can be had using the 16->256 interpolation and the "spreadCycle" modes.

Note: ms=microstep not millisecond. GR5, these are 16 microstep drivers but somehow they interpolate to ***256*** microsteps.... Maybe this means when going from one ms to the other, instead of immedately switching the current pattern to move to the next ms, it makes 16 incremental changes instead. So from the arduino standpoint, the step rate is still the same as 16 ms but the ms to ms transition is smoother. https://github.com/watterott/SilentStepStick/blob/master/pcb/SilentStepStick_v10.pdf?raw=true

Yes, it's about drivers not the motors. The title would be better as "Silencing stepper motors". Again, the primary marketecture that almost completely silences the steppers isn't useful to 3D printing due to the lost of torque. However, the better current management of the spreadCycle feature seems to help quiet the motors while allowing them to run cooler too.

Some other videos in github for the OS hardware: https://github.com/watterott/SilentStepStick

If you watch the videos, there are two unique things, one of which is useless for 3D printers (stealthchop) . But the other (spreadCycle) and the 16->256 microstepping interpolation quiets the movement (but not as well as the other mode) while providing good torque with less motor heating. See this video: The super quiet feature is noted as useless for 3d printers due to the lack of holding power.

http://hackaday.com/2015/01/24/new-part-day-silent-stepper-motors/

Thanks, I suspected that was the case. I looked at the arduino schematic and there is no flow control between the ATmega16U2 handling the USB connection and ATmega2560. So I guess buffer overruns are simply something that occurs and the firmware handles by requesting a resend. However, your fix helped. With one print, the whole system of Cura and the printer just seem to stop.

Daid it looks like that patch fixes the issue. However, I'm still seeing a lot of checksum errors: < Error:No Line Number with checksum, Last Line: 54 < Error:No Line Number with checksum, Last Line: 83 < Error:No Line Number with checksum, Last Line: 114 < Error:No Line Number with checksum, Last Line: 157 However, at least now the print isn't halting like it did before....