Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
.92 pause print results in grinding gears
#1
I dont know if Ive done something by working on this thing recently, but my 1.0 running the latest .92 effectively cant pause and resume. When pausing for whatever reason, the extruder moves to the front right like its supposed to, but it wants to keep going after hitting the end of the rod, causing the gears to grind pretty bad. If you resume print it doesnt return to the correct location and is further towards the back more than it should. Subsequent pauses doesnt grind, but it doesnt return to the correct position either, presumably due to the machine losing track of where its at. Homing all before the print starts doesnt seem to correct this. Ive stripped my start gcode to the bare minimum and it doesnt seem to resolve it. I did recently switch over the simplify3d from cura and slic3r, when I get home Ill print a file out from slic3r to determine if its gcode or something in my firmware settings or hardware.

Anyone have other ideas on what could be wrong?

UPDATE: Nothing to do with firmware, my apologies. I moved my extruder stepper up, and didnt notice it was hitting the front X rod until I uploaded the video.
Reply
#2
when you pause / resume is from printer or from S3D ?
FYI: Position when pause printing from SD is SadxMin),(yMin + yLength), so check what values you have in EEPROM
Reply
#3
Luc, this is pausing from the printer menu. Simplifiy pauses concern me and causes alot of false failure alarms. My workflow is now slice in simplify, upload to wifi SD, unmount/mount SD card in repetier host, print from SD. Ill check eeprom values against defaults when I get home to see if I have something funny in there. From what I can tell, when you are using simplify as the controller, a pause from printer menu will pause for a split second and then resume, like simplify is unaware of the pause issued at the printer, so I dont use simplify as the controller. Wish I could, but I dont like it compared to repetier host so far.'

Not trying to run past its limits for the second pause is what turned my focus away from eeprom values, but ill double check it.
Reply
#4
Pause from printer when printing from host does not work that is sure / it never worked (even 0.91) - Repetier/S3D are not aware about the pause from printer because no command exists to communicate with host so far, only @pause but in GCODE not from printer - and when I raised this to repetier I got no feedback...

I added this to my tracker since a while

EDIT : I am no sure if you changed the carriage, but this may affect the Ylengh if carriage is bigger
Reply
#5
I did recently install a e3d, but it was on stock carriage. Looks like I have everything assembled correctly and the carriages on Y are aligned. Getting great prints, only downside is this pause location. Hopefully I set something incorrectly in EEPROM and didnt realize it. Ill know when I get home this evening.

BTW, I dont think this a firmware issue, but thought this would be a good place to post in case others have run into this.

If eeprom values look correct Ill post a video in hopes it can illustrate whats going on.
Reply
#6
This topic really should belong in the hardware mod section.

Here is my current problem. The grinding happens when I pause print from SD.

h ps://dl.dropboxusercontent.com/u/41357814/20150126_191402.mp4

This video is from another run, this is a pause after an initial pause (with grinding) and resume (now offset)

h ps://dl.dropboxusercontent.com/u/41357814/2015-01-25%2018.09.29.mp4

Here are my eeprom settings.

[img]
Reply
#7
did you try to generate gcode file from repetier to see if issue also happen ? to see if it is something in S3D header that may cause the shift
Reply
#8
I just tried with a slicer profile I know ive paused several times, same thing.
Reply
#9
I tried on GCODE generated by host/cura and another one with S3D and no issue - but I have a 2.0
Reply
#10
I guess on something I know Ill have to pause I can pause as soon as the nozzle touches the glass, let it do its grind, then resume since subsequent pauses dont crash and an offset on layer one wont matter. Maybe the raised stepper is getting in the way and I never noticed it coming that close before. Sorry I associated this with .92 firmware, I believe my stepper is getting in the way.
Reply
#11
well give a try with 0.91 it may help to trigger the problem if it is fw
Reply
#12
I think your problem is pretty clear after watching the videos. Like you say, the raised stepper is hitting the rod on the front and forcing the Y stepper to skip steps, thus the original position will be lost (the head is not anymore physically where the firmware think it should be). The fix is easy though: in the EEPROM settings reduce your Y max length from 217 to whatever value you need to avoid the crash, probably something around 210. At worst you might lose a few mm of build area, but probably not even that.
Reply
#13
Oscahie, next time you think about it, could you pause a print on the stock setup to confirm pause does move the carriage where the front x rods are positioned over the extruder stepper? I thought I had tested pause after I raised the stepper, but I was super anxious to test the e3d and may have forgotten to test it like I thought.
Reply
#14
Uh, I'm not planning on going back to stock anytime soon Smile But anyway, the root problem here has nothing to do with the pause feature. You just have effectively reduced your max Y distance by raising the stepper, and thus you need to account for that in the firmware.
Reply
#15
Yeah, I got that, I just didnt recall pause causing the front x rail to pass over top of the stock stepper. Ill play around with Y limit or Ill just live without pause since this is the first time Ive needed it since upgrading to e3d. I didnt think you had raised your stepper, is why I had asked for the test. By "stock" I meant original extruder stepper location.
Reply
#16
Ah, sorry then, I misunderstood your request. But yes, I did check that this morning when I saw the thread, not pausing but simply manually moving the extruder all the way to the front, and as expected the stepper motor goes just a little bit under the X rod.
Reply
#17
Thanks for confirming man. Jogging Y to its full extents doesnt touch the X rods at all for me, so that was throwing me off as to why pause went beyond where I could position Y travel via printer menu. Mystery solved, nothing to do with firmware or values and is result of my stepper being moved higher. Ill play with shortening Y travel in eeprom, really dont want to fully dismantle this thing again.

Guess its good I ran into this, as it does point out the downside of implementing a e3d with a raised stepper.

Changed my Y max to 211 and all is well in the universe again. Wink
Reply
#18
Quote: My workflow is now slice in simplify, upload to wifi SD, unmount/mount SD card in repetier host, print from SD. .
Sorry I come back on your workflow : why unmount/mount SD Card ?
I use also wifi SD card and I do not need to do this - what WIFI SD Card do you use ?
Reply
#19
Quote:
Quote: My workflow is now slice in simplify, upload to wifi SD, unmount/mount SD card in repetier host, print from SD. .
Sorry I come back on your workflow : why unmount/mount SD Card ?
I use also wifi SD card and I do not need to do this - what WIFI SD Card do you use ?

FlashAir. I didnt see the option in simplify initially but i now just do a print from SD Card directly after I upload file via browser. I may have overlooked a way to refresh sd contents in repetier host as well.
Reply
#20
OK - I use Flashair also - yes no need to force refresh ^_^
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)