Dibloff's Build Log

[dibloff]

Changed the temperatures to 180C, nothing. then 200C, nothing. the extruder does not move. I changed a bunch of other settings, but I can't make the extruder to move.

[brnrd]

Can you extrude manually using the Extrude or equivalent button?

[dibloff]

Sure. The manual extrusion work fine. If I slice the same part with the clic3r that prints out just fine.
Only if I slice it with the Kisslicer it'll not work.

[SystemsGuy]

Did you select 5D Rel-E for gcode flavor?

EDITED : Looks like you have BFB g-code selected - this won't work with Marlin/Repetier style firmware...

Sure. The manual extrusion work fine. If I slice the same part with the clic3r that prints out just fine.
Only if I slice it with the Kisslicer it'll not work.

[dibloff]

Systemsguy. thanks for the suggestion.
I ended up setting the
- Firmware type to 5D - absolute E and the
- 5D temp g-code to M104. It is printing now.

When the print started it shut the hot end down. It happened twice, until I realized it's sending me the "echo: cold extrusion prevented" message. I manually set the hot end temperature for this print.

[SystemsGuy]

Glad it pointed you in the right direction! I've been switching between one too many platforms - I'm confusing my firmware flavors!

[dibloff]

Printed some springs. they really do work as a spring. they won't even break @ full compression.
The green has a 2 mm wire diameter, and is 48 mm high. the red has a 3.2 mm wire dia and 38 mm high

[dibloff]

This will be long, so grab a cup of coffee, or whatever is your favorite drink is and read on.
In the last couple weeks I’ve been working on the housing print. This is the largest part of my project. The housing fills up the Hadron’s tray. It measures 193.8 mm wide, 194.43 long and 110.75 high. I attempted one full print earlier. I used slic3r to generate the gcode, and the pronterface predicted ~9 hours for the print. After 18 hours! of printing I stopped the print (4am in the morning). There were 3 things that went wrong.
1. The layers were shifted at the top. Here is a picture.

There were two shifts as you can see. With the current slic3r (0.9.7) version this happened before. It usually happens when the printer is done with the vertical walls and support and it starts to create the first ceiling layer. Right now I think it’s the non print moves travel speed that causes this. I had it set up to 130 mm/s. I suspect the code sends the tray (Y axis) to too high accelerations. Because there is a considerable amount of mass resting on the tray the stepper will not be able to generate such a high torque and it’ll skip. You can see that there are 2 shifts on the print. The bottom one is +2 mm the top one is -1.5 mm. they’re both along the Y axis.
2. I realized there were horizontal cracks in the print. First I thought the extruder was skipping, but since I implemented the MK7 gear and the new filament retention arm it never skipped again. I further investigated the cracks and realized they were @ different heights. Then I realized they’re @ the thinnest sections of the part. Because I used 30% infill only – to save on material – the part became too weak, and the thermal contraction ripped the print apart. I’ll use 60% infill for the next print.
3. The filament holder broke off, and the filament got tangled.

I decided to give a try for the kiSSlicer to see if it’ll solve the problems. I tinkered with it for 2 weeks. I managed to create nice prints, but it created new problems, although the kiSSlicer seems a lot more advance than the slic3r. After I finally managed to print the housing with it the printer started to behave funny. It stopped for a moment. The print head just stopped, and then it restarted after 1-2 seconds. This kept happening until ~10 minutes into the print the printer stopped for good. The stl file is 13.3 Mb. The gcode generated by the kiSSLicer is ~ 162 Mb. The gcode generation on the kiSSLicer took 1 minute 49 seconds. I looked up the preferences and noticed it has a checkmark for comments. These are the things in the gcode that says: wipe and solid and perimeter etc. I turned it off and re-sliced to make the file size smaller. It came out as 160 Mb.
I thought the printer controller ran out of memory so I installed an 8 gig micro sd card. Off course it did not help. I’m not sure about the memory sharing between the printer and the workstation. The WS is a dell precision t7500 with 8 cores and 12 gigs of ram.
So I decided to go back and use the slic3r. Here is a screenshot for the slic3r while it’ slicing:

It is set to use 6 threads (6 processor cores). As you can see it really uses 6 cores while chewing on 14.8 gigs of RAM. It’ll take the code ~27 minutes to slice.
I found out that slic3r has a new version out. 0.9.8. How magnificent! I quickly downloaded sliced and it took ~25 minutes, but it only used 6.4 Gb of ram and I set it to two processors.

I restarted the print, but two hours into the print it shifted the layers once more.

At least this time I did not loose half a spool of filament.
Anobody. Any ideas why this is happening?

[BenJackson]

Someone recently diagnosed a similar problem as losing *Z* steps causing the hot end to drag the print and causing lost steps in one of the X/Y axes.

skeinforge has settings to limit Z moves, but slic3r relies on the jerk/max speed/accel settings of the FW. Some Z moves are going to be faster than others, and if your FW allows them it might choke.

[orcinus]

Are you using Repetier FW by any chance?
If yes, check your MAX_TRAVEL_ACCELERATION_UNITS_PER_SQ_SECOND and MAX_FEEDRATE_X / MAX_FEEDRATE_Y.

I had the exact same symptom (shift before the final solid layer/s) and this was the culprit - it was trying to move my Y axis faster than possible, because i've neglected to reduce the above settings. For some odd reason, KISSlicer and Cura weren't doing that, but Slic3r always did it. An absurdly fast travel move along Y just before the final layers. Choking down the above settings limited it to something more sensible and made the problem go away.