Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
1.0A and Repetier Host .92 Layer Shifting Support Group
#21
I am just wondering if the firmware is causing some sort of damage to the motherboard (heat, who knows) or the now embedded stepper drivers. I straight up confessed to XYZ today and asked them for a price on a stock firmware refresh. If the turnaround is to slow I will have to keep my new printer but if not and it works then we will have the answer. I would encourage some other brave individual to do the same as i may not have enough time left with my new printers return policy to wait for Da Vinci.
Reply
#22
As I said they change their HW all the time so they may put a weakness if some settings are not used, also would be also interesting to know if any 1.0A does not have the problem and check what is different-
I cannot help more I do not have 1.0A just a 2.0SF which never had this kind of issue.

I would also suggest to share a simple GCODE file which present the issue and saying at which layer the issue happen so everyone could test

Another test would be a fan on drivers on back of printer, the back lid open to see if the problem come from overheat - Just my 2 cents
Reply
#23
Quote:As I said they change their HW all the time so they may put a weakness if some settings are not used, also would be also interesting to know if any 1.0A does not have the problem and check what is different-
I cannot help more I do not have 1.0A just a 2.0SF which never had this kind of issue.

I would also suggest to share a simple GCODE file which present the issue and saying at which layer the issue happen so everyone could test

Another test would be a fan on drivers on back of printer, the back lid open to see if the problem come from overheat - Just my 2 cents

I have the 1.0A and have had Repetier 0.92 installed for 2 1/2 months now and have printed hundreds of models.
I have not seen this problem once on my machine.
I have a micro to SD card adapter and print from the SD card exclusively.
Reply
#24
I've tried leaving the back of the printer open that didn't seem to help (someone said the stepper driver maybe broke/overheating), I will try some active cooling tonight as well.... Maybe tomorrow night I can try to whip up some simple g-code. I don't think it's the firmware itself as I had ~3 weeks of rock solid prints on the RH firmware. I even did before and after tests using the exact same STL files and the difference was huge but i'm thinking it's the firmware's long term affect on the hardware. I'm thinking this because of two things 1st)I have been very aggressively searching for information on this issue and I have yet to find someone on the stock firmware with it. 2nd) If I clear my EEPROM and reflash the firmware, the exact same firmware I used to get the great results, everything should have went back to normal.

Bottom line though I think it's fairly safe to say that "If you flash RH .92 on a 1.0A there is some information out there that this may end up causing an x-axis layer shifting issue that does not currently have a fix". I don't think anyone is expecting you to be able to diagnose this issue without even having the printer but maybe until it is figured out you should add a disclaimer to the firmware install instructions?
Reply
#25
Interesting idea James..... I'm going to test right now. I have tried Octoprint and S3D but both of those run through USB. So tonight's test (and probably the last as my new printer is showing up tomorrow Smile ) is active cooling on the drivers and printing from SD hopefully it works. If it does I will test independently to try to figure it out.

James another question though, when did you flash RH.92?
Reply
#26
I've flashed to .92 on my 1.0A a couple of weekends ago, but haven't really had a chance to print much. Initial prints using the test prints on the sd card were printing 2mm above the print bed. Once I used slic3r on a downloaded .stl it printed well.
I have printed a calibration cube and a different test print and no issues so far.
I'm now printing the parts to a case rap. Current print looks like its at around 5mm and no issues. http://www.thingiverse.com/thing:671209 and will update with results.
Just for info I'm printing over usb via windows laptop running repetier host.[Image: pic1.jpg]
Reply
#27
Switching to SD card and using active cooling on the motherboard did not help Sad
Reply
#28
Yes, i'm 1.0a with .92

Currently have 8 days and 20 hours of print time according to the printer.

Happened first after i flashed. I thought it was slicer issues or model issues but they reoccur. It's a bit random too. It is quite frustrating.
Reply
#29
Interesting, but from a logic point of view the firmware does not care about the position of the extruder. I would think if it is an issue of overheating it would happen in all locations of the print bed. IOW, the steppers and drivers aren't going to run hotter because of where the extruder is.

I don't expect anyone to be able to measure an intermittant wire with a regular meter- it simply wrong respond fast enough in many cases. IMO to be 100% you need a scope capable of recording glitches.

LUC, maybe you could give them some less agressive stepper speeds and accelleration settings to try.

Kieth
Reply
#30
Well 0.92 is only sources so anyone can change in Configuration.h - acceleration are available in EEPROM for modifications no need to recompile
for stepper speed, have several parameters to tune in configuration.h
:
/** Comment this to disable ramp acceleration */
#define RAMP_ACCELERATION 1

/** If your stepper needs a longer high signal then given, you can add a delay here.
The delay is realized as a simple loop wasting time, which is not available for other
computations. So make it as low as possible. For the most common drivers no delay is needed, as the
included delay is already enough.
*/
#define STEPPER_HIGH_DELAY 0

/** If your driver needs some additional delay between setting direction and first step signal,
you can set this here. There are some commands between direction and signal, but some drivers
might be even slower or you are using a fast arduino board with slow driver. Normally 0 works.
If you get skewed print, you might try 1 microsecond here.
*/
#define DIRECTION_DELAY 0

/** The firmware can only handle 16000Hz interrupt frequency cleanly. If you need higher speeds
a faster solution is needed, and this is to double/quadruple the steps in one interrupt call.
This is like reducing your 1/16th microstepping to 1/8 or 1/4. It is much cheaper then 1 or 3
additional stepper interrupts with all it's overhead. As a result you can go as high as
40000Hz.
*/
#define STEP_DOUBLER_FREQUENCY 12000
/** If you need frequencies off more then 30000 you definitely need to enable this. If you have only 1/8 stepping
enabling this may cause to stall your moves when 20000Hz is reached.
*/
#define ALLOW_QUADSTEPPING 1
/** If you reach STEP_DOUBLER_FREQUENCY the firmware will do 2 or 4 steps with nearly no delay. That can be too fast
for some printers causing an early stall.

*/
#define DOUBLE_STEP_DELAY 1 // time in microseconds

/** The firmware supports trajectory smoothing. To achieve this, it divides the stepsize by 2, resulting in
the double computation cost. For slow movements this is not an issue, but for really fast moves this is
too much. The value specified here is the number of clock cycles between a step on the driving axis.
If the interval at full speed is below this value, smoothing is disabled for that line.*/
#define MAX_HALFSTEP_INTERVAL 4000

//// Acceleration settings

/** \brief X, Y, Z max acceleration in mm/s^2 for printing moves or retracts. Make sure your printer can go that high!
Overridden if EEPROM activated.
*/
#define MAX_ACCELERATION_UNITS_PER_SQ_SECOND_X 1000
#define MAX_ACCELERATION_UNITS_PER_SQ_SECOND_Y 1000
#define MAX_ACCELERATION_UNITS_PER_SQ_SECOND_Z 100

/** \brief X, Y, Z max acceleration in mm/s^2 for travel moves. Overridden if EEPROM activated.*/
#define MAX_TRAVEL_ACCELERATION_UNITS_PER_SQ_SECOND_X 1000
#define MAX_TRAVEL_ACCELERATION_UNITS_PER_SQ_SECOND_Y 1000
#define MAX_TRAVEL_ACCELERATION_UNITS_PER_SQ_SECOND_Z 150
Reply
#31
Quote:Interesting idea James..... I'm going to test right now. I have tried Octoprint and S3D but both of those run through USB. So tonight's test (and probably the last as my new printer is showing up tomorrow Smile ) is active cooling on the drivers and printing from SD hopefully it works. If it does I will test independently to try to figure it out.

James another question though, when did you flash RH.92?

I have re-flashed two times in the last couple of months with the latest .92 mostly to get the problem with the pause that had been fixed.
So the last time was about three weeks ago.
I also use S3D for all of my prints.
Reply
#32
Print shifted overnight to the rear of the printer.[Image: img01.jpg]
Reply
#33
Since you don't have a 1.0A Luc, is there anything that I could do to debug the issue to help out?
I'm willing to help, and just need some direction on the hardware side on what is needed if anything.
Reply
#34
First need to get one gcode which allow to reproduce error

you can start by changing this :
// 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.
#define ALWAYS_CHECK_ENDSTOPS 1

by
#define ALWAYS_CHECK_ENDSTOPS 0

If false signal for any reason the extruder may think it is in 0 then shift to be in right position - just a guess
Reply
#35
I have an 1.0A with Repetier 0.92 and running Octoprint.

I had this problem twice (only with Octoprint, never with the Pc connected to the printer).
At first I thought it was because I tried out horizontal or vertical infill an thought through the higher speed of my infill and an because of the abrupt deceleration it might have jumped on the belt. Layer shift was at about 10mm (2h print time)

After switching to honeycomb it still happened. This time at about 5mm (1hour print time).

As I have made a housing for my Raspberry Pi sitting in the side hole of the printer, I thought it my be an interferenece of the X-axis carriage running behind the Raspi.

Solution: Adding a ferrite core to the USB-cable. No more issues! I printed an almost 20h print and had no problem at all.

Maybe it helps
Reply
#36
just be careful Markus. It happened once in a while for me, then more, then more... now it's pretty much anytime i print something towards the front of my printer. Sometimes it's as early as the brim sometimes it's an hour into the print
Reply
#37
looks like i have missed quite a bit. i was able to print successfully in the back half of the bed. my printer looks like a skeleton at this point. Nick i also print shit when I'm running off the sd card with or without an extension cable for it. Did xyz give you a price so i don't get sticker shock when they flash it back?...I need it to print. not be sitting on my kitchen table in pieces. i have orders waiting.
Reply
#38
i just opened a ticket for the board to get flashed back. so if you all want me to test print anything this weekend would be it. i have a mac and windows machine with usb extension cable and a completely stripped down machine meaning all the covers are off and i'm looking at the metal chassis.
Reply
#39
Would anyone have the gcode of a failed print that I could use to try to duplicate the issue?
My print fails after a couple of hours and I would like to find a Gcode that fails earlier to iterate quicker.
Are there any others working on this issue with a 1.0A on hand?

I want to duplicate the issue with repeatability if possible.
And has anyone noticed a correlation to heat of the printer or anything else that may help duplicate the issue?

BTW thanks for the support so far Luc.
Reply
#40
Rick as your issue reproduction step is consistent compare to what I can read :
printing only on specific position of the bed
can you try to change this in FW ? - this is a workaround for sensor issue

#define ALWAYS_CHECK_ENDSTOPS 0
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)