Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
1.0A and Repetier Host .92 Layer Shifting Support Group
Thanks luc!

I am running a quick print to see if there are any issues with a shorter print ( see my post later in the thread ) with minimal changes to my setup.
Hopefully I'll run into the issue and I'll make the changes you pointed out.

Arggg, I was trying to reply to your last post luc....
About Gcode test, I may suggest to use a small circular or square tower, then note the position on bed when starting - do not feed filament, if there is some shift it will be easy to see comparing movement with initial position and it will save a lot of filament - I often do like this to do tests, it save lot of time of cleaning and filament - just my 2 cents
Luc i'll try it when i get back home. will be this afternoon 1-2 EST...on a side note i think i had a side step on the back end of the bed last night. all i heard was it going crazy but it was certainly off....i have my spool on a holder in the back not out of the cartridge so i don't think it was binding but i can't confirm that
No problem - it is 10:30pm for me now so will check your feedback tomorrow - good luck
This probably goes without saying.

I always turn my printer on and off before starting a new print.
If I start a new print right after another without shutting off and on it almost always does weird stepper movements.
Its like the buffer does not get flushed out or something after a print.
well gentleman DaVinci is boxed up. I hope making this thread gets enough people together enough to solve the issue. Honestly I bought the FlashForge creator and while the prints are better I only paid $400 for the DaVinci and this thing cost a litte more than double that, the prints are not twice as nice. Gonna miss the forums going to miss my cheap reliable (before this issue) printer. Cya
ok so here are some pics and the gcode of a print that constantly fails in the front end of the bed but turn it 90 degrees and towards the rear and it prints great. this is just starting the outline as you can see. and the display is showing the right coordinates. I have NOT changed the endpoint yet.[Image: IMG_1829.jpg][Image: IMG_1830.jpg][Image: IMG_1831.jpg]
nick unpack that bad boy and try the endpoint stop thing that LUC is saying. So far its working on the bad print I have printing the second success full set right now. and I even went so far as to not dump the buffers by power cycling in between. FINGERS CROSSED EVERYONE!!!!
Luc that seems to be working but i'll know after I send my 12 hour test print if we've got a fix going. that will be tomorrow so I can monitor the whole thing. Thank you for helping us with this man. much appreciated
Rick, could you please post the stl file or the gcode for the test that you are doing so we can also test it with our version?
Printed a tall xidlers for the case-rap this morning and it shifted after a couple of layers.

I changed
I also added a usb with ferrites on both ends and power cycled the printer before starting this print.
I'm trying a 2nd gcode file of the x idlers right now to see if I get any different results.
Possible dis-regard my last post.
Same part is shifting backwards on a flashforge creator with replicatorg -skeinforge - SD card.

Could someone post a gcode of a file they can consistently get to offset?
I am currently printing a new model on the mac and seems to be going good. Jason i have tried to post the known GCODE that would replicated the issue but it never loads....if someone can give me an email address i'll hand out the GCODE i was using to replicate. Will update when i have more info
you need to zip files you want to attach on this forum or they are ignored
Thanks Luc.
Luc, can you explain what the end stop does and why we turned it off so i understand?
I think I may have found the issue. At least for me.

So this problem reoccurred only when printing towards the front(the door). It has nothing to do with the firmware but as the print moves in the y direction, the cable on the motor moves. Sometimes it snags on the case in my case very briefly. I believe this might be unplugging it from the motor for a brief second causing the missteps.

I put a piece of cardboard to prevent it from snagging on the case and I have no X shifts anymore. Hope that helps.
I have a 1.0A davinci and flashed repetier 0.92 1.15-03-02_1.1A

So far no problems, printed a full spool of xyz black abs at 40mm/s

Did notice a sound/speed increase on steppers after flashing, especially on the g0 commands to move only.
Dialed down move speed a bit (80mm/s) but still loud. Maybe the acceleration is too strong ?

Luc, which value should i enter in the firmware if i would like a lower acceleration on the x/y movement to smooth things out?

i thought the same thing so i stripped out all the wiring and let it hang outside of the chassis and still had side steps. the motor still move in that instance but not like they should. since i changed the endstop option to 0 i have been printing just fine so far. I'm still skeptical though.
when you reach end stop it means you are in homing position, so reference coordinate is the home position
if flag ALWAYS_CHECK_ENDSTOPS is set to 1 it will reset position as soon at end stop send signal
if you are in middle of the bed and end stop got signal, coordinate reference will be from this new "home position" then switch to the left

if ALWAYS_CHECK_ENDSTOPS is set to 0, it will be checked only when doing homing and not anytime

so currently your endstop has a wire touching him when printing or generate false signal randomly because it is defective or bad quality
as comment says:
// You can disable endstop checking for print moves. This is needed, if you get sometimes
// false signals from your endstops. If your endstops don't give false signals, you
// can set it on for safety.

your endstop give false signal for some reason

Forum Jump:

Users browsing this thread: 1 Guest(s)