solidoodlesupport wrote:

Rincewind wrote:

Thanks! I was thinking about waiting for a few other beta-testers, but I'd be delighted to see the mod on the official github... Just to be sure, it is the Marlin_v1 branch in https://github.com/mlaws/solidoodle2-marlin right? (that's what I forked).

Nope. This is our official one: https://github.com/solidoodle/Marlin/tree/master
Excuse our dust, we need to clean up / clarify the git situation. I encourage you
to fork Lawsy as well. Our firmware is essentially the same as his at the moment.

I agree, perhaps we should wait for further testing for a merge, but I'd be glad to take
a look at your fork and consider it for shop use.

Of course you can check it out any time... https://github.com/fsantini/solidoodle2-marlin
I'm new to github, so I still have to figure out how pull requests work, but at the moment if I try a pull with your master repo it shows a billion commits to merge... Maybe before doing so I should fork the official one and add the mod by hand, seems easier.

I've had to do as much in the past. I'm not a git wiz myself, but there are supposed to be tools to help prevent such issue (the grep tool?)

One thing I do to make things perfectly clear is to comment everything I change with a marker like:
#changed for solidoodle

so if we ever have to merge with a reprap fork, we can quickly figure out where to update the Solidoodle bits.
Wish there was a way to merge selectively....

Rincewind wrote:

solidoodlesupport wrote:

Impressive. If you do a pull on our official github, I'd be amenable to doing a merge.

Thanks! I was thinking about waiting for a few other beta-testers, but I'd be delighted to see the mod on the official github... Just to be sure, it is the Marlin_v1 branch in https://github.com/mlaws/solidoodle2-marlin right? (that's what I forked).

Nope. This is our official one: https://github.com/solidoodle/Marlin/tree/master
Excuse our dust, we need to clean up / clarify the git situation. I encourage you
to fork Lawsy as well. Our firmware is essentially the same as his at the moment.

I agree, perhaps we should wait for further testing for a merge, but I'd be glad to take
a look at your fork and consider it for shop use.

Of course you can check it out any time... https://github.com/fsantini/solidoodle2-marlin
I'm new to github, so I still have to figure out how pull requests work, but at the moment if I try a pull with your master repo it shows a billion commits to merge... Maybe before doing so I should fork the official one and add the mod by hand, seems easier.

solidoodlesupport wrote:

Rincewind wrote:

My X motor decided to give up on me just these days, fortunately I had ordered a spare one a few weeks ago (I had the feeling that something was going wrong) and I managed to replace it... So I only have few prints. But here's an old print, before any correction, followed by my most recent print:

Impressive. If you do a pull on our official github, I'd be amenable to doing a merge.

Thanks! I was thinking about waiting for a few other beta-testers, but I'd be delighted to see the mod on the official github... Just to be sure, it is the Marlin_v1 branch in https://github.com/mlaws/solidoodle2-marlin right? (that's what I forked).

Nope. This is our official one: https://github.com/solidoodle/Marlin/tree/master
Excuse our dust, we need to clean up / clarify the git situation. I encourage you
to fork Lawsy as well. Our firmware is essentially the same as his at the moment.

I agree, perhaps we should wait for further testing for a merge, but I'd be glad to take
a look at your fork and consider it for shop use.

Rincewind wrote:

nickythegreek wrote:

Rince, do you have any other post-fix prints to show off?

My X motor decided to give up on me just these days, fortunately I had ordered a spare one a few weeks ago (I had the feeling that something was going wrong) and I managed to replace it... So I only have few prints. But here's an old print, before any correction, followed by my most recent print:

Impressive. If you do a pull on our official github, I'd be amenable to doing a merge.

Thanks! I was thinking about waiting for a few other beta-testers, but I'd be delighted to see the mod on the official github... Just to be sure, it is the Marlin_v1 branch in https://github.com/mlaws/solidoodle2-marlin right? (that's what I forked).

nickythegreek wrote:

Rince, do you have any other post-fix prints to show off?

My X motor decided to give up on me just these days, fortunately I had ordered a spare one a few weeks ago (I had the feeling that something was going wrong) and I managed to replace it... So I only have few prints. But here's an old print, before any correction, followed by my most recent print:

Impressive. If you do a pull on our official github, I'd be amenable to doing a merge.

Rince, do you have any other post-fix prints to show off?

My X motor decided to give up on me just these days, fortunately I had ordered a spare one a few weeks ago (I had the feeling that something was going wrong) and I managed to replace it... So I only have few prints. But here's an old print, before any correction, followed by my most recent print:

My initial problem could be rated as "pretty bad", meaning that it was not terrible but I often had delamination in large prints and the parts were not smooth at touch. I managed to break down the problem into three parts and found respective solutions.

1) Hardware: this is the most important source of banding. The fix for it is now well known and documented: see the wiki http://wiki.solidoodle.com/z-axis-anti-backlash. This solution fixes the Z backlash and considerably reduces the overall wobbling of the Z axis. This wobbling makes the bed shift nonuniformly in Z, making some layers thinner and some layers thicker. Prints change noticeably with this fix.

2) Slicer software: some other users reported problems with Slic3r (version > 0.9.7). I can confirm these problems. Specifically, I found that the feature "randomize starting points" generates shifts between one layer and the next. Such shifts resemble banding because apparently the randomization function has some periodicity. The shifts are probably due to backlash and can be compensated with Neil Martin's hysteresis fix, but unfortunately I did not have success in using it, noticing a constant shift in the direction of the compensation. My suggestion at the moment is to turn off the "randomize starting points" feature.

At this point, your prints will hopefully look quite smooth, with possibly a tiny banding with a period of 1.41mm, due to a residual wobbling of the Z axis. In my case, I could see the banding only by looking at the part with the right angle... However, I could still feel it by touching the part. To remove this last wobbling, I implemented the following:

3) Firmware: Z wobble correction (as described in this other post). I am very satisfied with the final result (top: all corrections applied minus the firmware, bottom: all corrections including firmware. Layer thickness: .3mm):

The final firmware correction only compensates for the bed level: other users reported/hypothesized an XY coupling to the Z wobble. This could probably be the case if the rod wobbling is very bad. My firmware mod is not designed to take care of this, but it could be easily inserted. Manually finding the right parameters would be really painful though.

Hope this helps, and if someone has different experience, please share it!