X shift or 1.1.2 problem?

[steve]

Hello Everyone,
I'm new to 3D printing and I'm not sure how to solve my problem. I've upgraded to S3D 1.1.2. My models are printing perfectly, then all of a sudden they start leaning/slanting along the x-axis for about 25mm (see attached pics).The Y=axis and Z-axis are printing fine.

Usually they start leaning for the last 25mm of the model. In the attached pics I was printing two models. It started leaning along the x-axis for the last 25mm of the smaller model, and shifted for the corresponding 25mm of the larger model. When the smaller model finished printing the printer corrected its self and printed that last 25mm of the bigger model correctly. I've attached photos because I know my explanation is difficult to follow!

I'm printing using natural PLA
Extruder is set to 190
Bed temp is 75 for first layer, and 65 for all other layers.
I'm using tomlombardi's profile.

Any help is appreciated!

[Simplify3D]

Steve,

I had a look at the G-Code and STL files you posted on the MG thread, and the output from Creator looks fine. You can always verify this yourself by opening Creator and clicking the Preview button. Select the 17.G file and then use the sliders at the bottom of the window to scroll through the build. The way that the preview rendering is interpreted is very similar to how your actual printer will interpret the commands, so it's a very useful tool! In this case, the towers are all coded correctly and should be vertical based on the G-Code that was produced.

I have a few suggestions that might help with the results you're getting on your M2. My first guess is that your X-axis motor might be skipping steps which causes the shift you are seeing. This can be caused by poor motor or power supply connections or by too high of speeds or accelerations. The first thing I would do is double check all of your power supply and motor connections to make sure they are snug. In particular, make sure the X-axis wiring harness is firmly connected into the X-axis stepper motor and into the RAMBo connection. I have also seen similar results from someone who's power supply was not fully connected (which leads to fluctuating currents and voltages). Make sure the power supply is firmly pushed into the RAMBo housing and also that the actual power cord is completely plugged in to the power supply "brick". After you've checked all of those things, then I might try slightly lowering the printing and rapid speeds in your G-Code to see if that makes a difference.

Let me know if that helps!

[steve]

Thanks for the reply.

I've checked the wiring and it all seems to be fitting snugly. I'm going to play around with speed settings this weekend and see if this makes any difference.
Yesterday I reprinted the files again and the x shift happened at the exact same location. Because the problem is so predictable, and because it happens only for a 25mm increments, the corrects its self, I'm inclined to think that it is not a mechanical error.

Also, the first time I saw this happen it was with an L shaped block (50mm high and 50mm wide). Twice I tried to print it and twice the problem occurred at the same point. The third time I printed the model I rotated the it about the y axis and it printed perfectly! I'm going to try rotating the models, and see if the shift happens about the Y axis, or if it happens at all. I'll let you know if this makes any difference.

Interestingly when It is going to apply an X-shift on a model it will print a diagonal of blobs about 10mm off the glass plate for approximately 10mm in height (im away from home at the moment but I will attach photos on Friday). These dots/blobs dont appear in the g-code previewer either.

I want to have a completely clean install of S3D. However, when I uninstall it, run c-cleaner, then re install it, S3D is is still picking up my old fff profiles, so obviously something of the programme remains even after its uninstalled. Is there anyway to remove all S3D data?

Thanks for all the help and for the prompt reply. I know this is a strange issue!

[steve]

I printed out the objects again, but rotated 90 degress across the x axis. The x axis shift still occurs but it is not as pronounced (picture 1).

Picture 1

01.jpg (117.38 KiB) Viewed 9809 times

I then tried printing the objects individually and they printed perfectly. I thought printing two objects at once was the problem so I began printing the rest of my models individually. Unfortunately, the x shift keeps occurring (picture 2).

Picture 2

02.jpg (131.16 KiB) Viewed 9809 times

The x shift occurs at different heights depending on the models being printed. However, if I repeat print a model it occurs in the same location (picture 3). I've checked all the wiring and the machine is only two weeks old and came pre-assembled.

Picture 3

03.jpg (116.27 KiB) Viewed 9809 times

The models I'm printing have very defined features. They are essentially stacked blocks. When printing individual models, the x shift occurs for the final feature (top block feature) of the model (this was starting to be printed in picture 2, but I aborted the print). If two models are being printed together, at the height of the top block feature of the smallest model, this causes x shift at this height for both models, but will return to normal for the remainder of the taller model (as seen in the tower feature in picture 3).

[steve]

Photos explaining my top feature problem

Picture1 (640x497).jpg (166.47 KiB) Viewed 9806 times

Picture1 (640x497).jpg (166.47 KiB) Viewed 9806 times

[steve]

Ive been looking at g code files of models sliced using S3d and slic3r. Ive noticed the the S3D code looks different to the slic3r code for the top feature. S3D applied a blueish colour to the top feature while the top feature in slic3r keeps the original green colour.

s3d (640x360).jpg (123.75 KiB) Viewed 9795 times

slic3r (640x360).jpg (112.4 KiB) Viewed 9795 times

Im also attaching the g-code files because the blueish colour is not very visible in the screen shot. Anyone know what this colour means?

[Simplify3D]

The color represents the printing speed of those segments. It's starting to look blueish because the software is automatically starting to slowdown the printing speed to help maintain adequate cooling for these regions. This is intentional and can significantly help to improve print quality. If you want to try printing with it disabled you can uncheck the "Adjust printing speed for layers below XXX seconds" option on the Cooling tab of your FFF settings.

[steve]

Thanks Clayton,

I'm going to give this a try, and hopefully it will work. I've slowed my prints down to 3600 mm/min and I'm still getting x shift!

I tried printing using slic3r and printrun and I had no x shift but it was printing at 30mm/sec, which is a bit slow, and the quality top surface layers was very poor.

Any suggestions on how I should progress with the problem?

[slipshine]

This is just something else to look for.

It looks like you start having problems when the print is starting to rapid to seperate areas. You might want to check the x-Axis Drive pully to make sure it it tightened on the flat on the stepper motor and then re tention the belt. It is possible to have the pully tight but not on the center of the flat and it can cause periodic shifting. You can use the Y-Axis as a reference to see how tight to get the belt. When you have the belt off look for any signs or ware or contamination that might be in the teeth.

Hope it helps.

[Karl_Williams]

If the problem is caused because of rapid movements to separate areas causing the stepper to over shoot then you could try increasing the current setting in the firmware in the configuration.h file. I was having a similar problem, but to a much lesser degree, so I bumped the digipot settings for X, Y and Z up to 1 Amp. The strange thing about your prints is that the print seems get back to where it should be later on in time. If you were missing steps or overshooting then the model wouldn't get back on track later because these machines don't have absolute position encoders. Is it possible that your glass build platform is moving?

// Motor Current setting (Only functional when motor current pins are connected to digipot)
// Values 0-255
// RAMBO 135 = ~0.75A, 185 = ~1A
#define DIGIPOT_MOTOR_CURRENT
#define X_CURRENT 185
#define Y_CURRENT 185
#define Z_CURRENT 185
#define E0_CURRENT 165 //For MakerGear M2, 165 is a good starting point
#define E1_CURRENT 125