ShadowRam Systems

During the time I was attempting to solve the overshoot problem, I was also working on the print platform.

After I tightened up the belts, I printed an object I created in a few mintues. It was a simple bracket that I could screw to the wall and hold some screw drivers.

This was the largest object I had printed to date, and the first attempt ended up in warping.

I cancelled the job, and you can see all four corners of the part are curling up. This means I’m not getting a good adherence to the build platform. So it’s about time I installed the heated bed, as this is what the heated bed was meant for.

After I installed the heated bed, I tested it out and started to heat up the mirror that I’ve been printing on up until this point. The electronics worked, and the sensor was controlling the bed quite well. I heated it up to a measly 30deg Celsius as a test. I then raised the temperature up to 40deg Celsius, and a part of the mirror suddenly come flying off, and a huge crack was generated down the middle of the mirror.

The mirror already had a chip out of it, and the act of heating/expanding had caused it to crack. So there goes my print platform.

No Comments »

So this blog definitely needs an update.

I’ve been struggling to figure out the square not being square issue over the last month, and it’s also been pretty busy, and finding time to work on the printer is scarce, as is updating this blog.

So I’ll give you the overall troubleshooting I’ve been going through over the last month.

I started with making a part myself in 3D CAD which was a larger than the calibration cube. It’s a 50 x 50mm square only 5mm tall. This was done for two reasons. One to test how well I can import my own STL files and address any issues there, and two, to exaggerate the error over a longer distance so I can begin to figure out what’s happening.

As you can see it is still not square, but it’s not a parallelogram shape either. But porting my own 3D models over to the printer, and having the printer software interpret the object worked without issue.

So I clamped a pen to the machine and ran it manually (actually by hand) to first verify that the frame itself was square.

Yes, the X and Y axis are indeed squared. So what was causing it?

I kept the pen clamped to the printer, and I wrote some of my own movement commands in GCODE to find out what’s happening and stretched it out to 100mm square.

So in the first picture you can see that 2 of 4 corners are square, and there’s what appears to be ‘overshoot’ on the other 2 corners. I drew a squared off line on the second image to better show what’s happening.

It looks like the printer is overshooting it’s intended position and eventually settling into where it should be.

So my first hypothesis was belt tension was loose. So I tightened both the X and Y and it caused the overshoot to return to sooner. But the effect was still there.

My second hypothesis was that that this is basically inertia of the heavy carriage was causing the overshoot. So I slowed down the system to a crawl, and reduced the accelerations in the software drastically, it still had no effect.

My third hypothesis was that the carriage was coming out of square because one side was being driven, while the other side was meeting some resistance. So I had two solutions to this. Stiffen up the carriage, or install another belt on the opposite side.

My problem with installing another belt on the other side is that it would be costly. I can’t identify or find the same poly-chain belt that this thing seems to use, so I would require to purchase identical belts for both sides, including matching pulleys (4), and a shaft to connect the two sides, and the mounting hardware/bearings to support the pulley’s and the shaft.

The stiffening up of the carriage isn’t too bad, I purchased some one inch square aluminium tubing and tapped some holes and bolt it on. This stiffened up the carriage quite well.

No Comments »