Prusa i3 Aluminium unexpected motion problem
Posted: Sun Jan 03, 2016 10:35 pm
Hello, I am experiencing a very strange problem I found very difficult to identify and debug.
I bought a Geetech Prusa i3 Aluminium, directly from Geetech in China through a Chinese partner I am working with (using the sanguinololu board controller), assembled and used it to prototype projects for about one month. After the first tests I have found the good settings to manage the printer producing very good prototypes I use for work.
A couple of days ago, a strange things happened coming me crazy. Starting a print (a design already printed several times before) I saw the axis moving extremely fast, so the print head does not move at all due the loosing of the steps. First of all I checked all the settings again and all was unchanged, including the firmware setup from the Repieter configuration option. The printer homes the axes correctly, responding with no issues to the manual commands and the heating curves for both bed and print head are correct. Tried again and got the same problem.
I have tried to slide with both Cura slicer and Slic3r with the same result. Then I started debugging the generated g-code. The axis motion feedrate is determined by the G1 code including (when the feedrate should be changed) the feed F parameter.
Values are correct based on the configuration settings; I keep the acceleration almost low (between 200 and 500 in the different conditions) to grant a low average speed change also during long paths.
As far as I know, I set in the configuration parameters the speed in mm/s (millimeters per seconds) while the F parameter in G1 gcode command use the feed rate in mm/min (millimeters per minute). So it sounds normal, and all worked fine until two days ago.
The first lines of a previously working g-code file shows
where the feed rate is set in values around 6000 that means 100 mm/s for fast moving.
Instead the printer comes crazy.
I have tried to send manually some gcode z-moves from the Repieter manual control interface and this focused the problem: without any change in the settings, by two days the firmware seems interpreting the gcode F parameter as mm/s instead of mm/min generating an unacceptable speed over the axis movements.
I have no idea if this is a software problem and in this case what are the parameters that went wrong or if it is some strange of hardware issue producing this result.
As I am a hardware engineer and developer I have no problem to change parameters on the board source firmware (I have just to install the Arduino platform on the computer I have dedicated to the 3D printing) but remain the very strange fact that this phenomenon has occurred without changing nothing.
Thank you in advance for any suggestion or advice.
Enrico
I bought a Geetech Prusa i3 Aluminium, directly from Geetech in China through a Chinese partner I am working with (using the sanguinololu board controller), assembled and used it to prototype projects for about one month. After the first tests I have found the good settings to manage the printer producing very good prototypes I use for work.
A couple of days ago, a strange things happened coming me crazy. Starting a print (a design already printed several times before) I saw the axis moving extremely fast, so the print head does not move at all due the loosing of the steps. First of all I checked all the settings again and all was unchanged, including the firmware setup from the Repieter configuration option. The printer homes the axes correctly, responding with no issues to the manual commands and the heating curves for both bed and print head are correct. Tried again and got the same problem.
I have tried to slide with both Cura slicer and Slic3r with the same result. Then I started debugging the generated g-code. The axis motion feedrate is determined by the G1 code including (when the feedrate should be changed) the feed F parameter.
Values are correct based on the configuration settings; I keep the acceleration almost low (between 200 and 500 in the different conditions) to grant a low average speed change also during long paths.
As far as I know, I set in the configuration parameters the speed in mm/s (millimeters per seconds) while the F parameter in G1 gcode command use the feed rate in mm/min (millimeters per minute). So it sounds normal, and all worked fine until two days ago.
The first lines of a previously working g-code file shows
Code: Select all
M190 S100.000000
M109 S220.000000
;Sliced at: Sun 03-01-2016 11:32:05
;Basic settings: Layer height: 0.2 Walls: 0.8 Fill: 20
;Print time: 1 hour 1 minutes
;Filament used: 5.147m 15.0g
;Filament cost: 0.31
;M190 S100 ;Uncomment to add your own bed temperature line
;M109 S220 ;Uncomment to add your own temperature line
G21 ;metric values
G90 ;absolute positioning
M82 ;set extruder to absolute mode
M107 ;start with the fan off
G28 X0 Y0 ;move X/Y to min endstops
G28 Z0 ;move Z to min endstops
G1 Z15.0 F6000 ;move the platform down 15mm
G92 E0 ;zero the extruded length
G1 F200 E3 ;extrude 3mm of feed stock
G92 E0 ;zero the extruded length again
G1 F6000
;Put printing message on LCD screen
M117 Printing...Instead the printer comes crazy.
I have tried to send manually some gcode z-moves from the Repieter manual control interface and this focused the problem: without any change in the settings, by two days the firmware seems interpreting the gcode F parameter as mm/s instead of mm/min generating an unacceptable speed over the axis movements.
I have no idea if this is a software problem and in this case what are the parameters that went wrong or if it is some strange of hardware issue producing this result.
As I am a hardware engineer and developer I have no problem to change parameters on the board source firmware (I have just to install the Arduino platform on the computer I have dedicated to the 3D printing) but remain the very strange fact that this phenomenon has occurred without changing nothing.
Thank you in advance for any suggestion or advice.
Enrico
