Here it is: [color=#0000FF]http://flowersbyvalerie.com/3dp/van%20storage%20box.stl[/color]
thanks, the gcode file is already running, when did is fail?
just snapped in my mind, what did you set the receive buffer value to in repetier printer settings?
Is it set to 127 or 63?
edit :
2.nd layer printed well, 3rd is still running
edit :
I stopped the print now, first 5 layers worked perfectly.
I think you should set the receive buffer size to 63 and try again.
Maybe the buffer on the Printer overflows.
It usually would fail on around the 4th layer, so I think you got farther than I. It is hard to tell exactly because the LCD deletes the current position once the print stops.
The receive buffer would not affect sd printing would it? I did try repetier once, but used the sd on the other attempts.
Did you print from your g code or mine? If it is your g code, can you get it to me so that I can try it? (mp(at)flowersbyvalerie.com)
Which marlin version are you running? Is it one of the downloads from Velleman or did you get a newer version?
I guess I am trying to figure out the potential differences between your setup and mine to isolate the issue.
I printed from repetier with your g-code.
I don’t have a SD module by now.
I didn’t get you tried printing from sd. There the receive buffer should’nt interfere.
But maybe it helps to change the SD card.
Some cards are problematic with some readers. Just worth a try.
Maybe try it from repetier (USB) again with 63 receive buffer set.
I use the Marlin “v1” version that came from velleman.
I changed the velleman hotend for a E3D v6.
Thank you for the help. Your test confirmed my result from more testing.
It turns out the receive buffer was already set to 63. It also seems that it is not software, but hardware.
I tried to print from a file that had previously printed successfully. This time it stopped on the first layer. Based upon the behavior, I am feeling pretty confident that there is a problem with the controller board. I thought something else was wrong because I thought it was isolated to this object. Now that it has happened to another object that previously printed successfully, I have to conclude that it is a problem with the controller board.
My next step will be to get another board and see what happens. If the new board works, then I will know and I can return the old one for replacement.
My concern is that I somehow hastened the board’s demise by changing to ABS, although I do not see how. The nozzle is set to 250, which is really about 240. The bed is set to 100 using a separate power supply and circuit described on this forum, which means that the mosfet on the controller is not bearing any extra work. The thing that has me worried is that the printer worked fine for almost a year until I tried to run ABS. Shortly after switching to ABS, problems. Hopefully coincidence.
If you set your extruder temp to 250 the printer might stop because it hits the MAX_TEMP value set.
The the extruder is shut down by marlin to prevent overheat and possible fire.
Check for such message in repetier when printing from usb.
Have you tried to print it from a Computer?
Yes. Three times now. I have also disconnected the LCD/SD while doing so to eliminate the possibility it causing a malfunction.
MAX_TEMP is set at 275. It is not fluctuating that much. It stays in the 247-253 range.
I turned all the logging options on in Repetier during the last attempt. It appears to me that the controller resets itself mid print because it displays the last firmware update and the other stuff you see at the start.
I am curious about the communication between the drivers and cpu. Does the driver report back to the atmega once a move is completed? Or, is the communication one way where the cpu only sends instructions?
If it is the former, perhaps a bad driver board could be messing things up. I’ve searched for the symptoms of a bad driver. What I have found indicates erratic servo movement rather than causing a total reset. Does anyone have experience with a bad driver causing a reset?
Do you use the stock power supply for heatbed and hotend?
If so, the power supply might switch off due to overload while printing.
That could be a reason for the reset you found.
I have a separate power supply for the heat bed.
What about the stepper drivers? Can they cause this symptom if one is going bad?
New controller board with drivers is ordered and on the way. I’ll switch out the old and see what happens.
Does any of your motors get noticably warm during print?
Or maybe one of your stepper drivers gets hot?
I have not checked the driver temps. The extruder servo is fairly warm, but not hot. Did not check x or y motors. Z is cool.
Check X and y axis motors as well.
If the printer resets with a second wower supply on the bed some of the motors or stepper drivers might
draw to much current sometimes and thus causing the board do brown out an reset.
Can be a intermittent short in the motor wiring as well.
Here’s the Repetier log. I deleted most of the print to reduce length. As you can see, it looks like it resets, but I don’t see the brownout message. It just resets and repetier keeps sending instructions.
00:20:14.449 : N5938 G1 X120.03 Y178.36 E287.7242 F2940 *41
00:20:14.636 : N5939 M105 *49
00:20:16.324 : ok
00:20:16.324 : N5940 G0 X120.73 Y178.36 F5940 *82
00:20:16.355 : ok T:259.3 /260.0 B:99.7 /100.0 @:128 B@:128
00:20:16.355 : ok
00:20:16.355 : N5941 G1 X47.01 Y104.64 E289.1992 F2940 *23
00:20:17.699 : N5942 M105 *61
00:20:18.496 : ok
00:20:18.496 : N5943 G0 X47.72 Y104.64 F5940 *108
00:20:18.511 : ok T:258.4 /260.0 B:99.8 /100.0 @:128 B@:128
00:20:18.511 : ok
00:20:18.511 : N5944 G1 X121.44 Y178.36 E290.6743 F2940 *35
00:20:20.652 : ok
00:20:20.652 : N5945 G0 X122.15 Y178.36 F5940 *85
00:20:20.683 : ok
00:20:20.699 : N5946 G1 X48.42 Y104.64 E292.1493 F2940 *30
00:20:20.761 : N5947 M105 *56
00:20:22.621 : start
00:20:22.621 : echo:Marlin 1.0.0
00:20:22.621 : echo: Last Updated: Nov 19 2014 15:11:34 | Author: (Boris Landoni)
00:20:22.621 : Compiled: Nov 19 2014
00:20:22.621 : echo: Free Memory: 4298 PlannerBufferBytes: 1232
00:20:22.621 : echo:Stored settings retrieved
00:20:22.621 : N1 M29 *57
00:20:22.621 : N2 M104 T0 S0 *3
00:20:22.621 : N3 M140 S0 *70
00:20:24.965 : echo:SD init fail
00:20:24.980 : ok
00:20:24.980 : N4 G1 X100 Y180 F4800 *111
00:20:24.996 : ok
00:20:24.996 : ok
00:20:24.996 : ok
00:20:24.996 : N5 G1 Z50 F150 *32
00:20:24.996 : N6 M84 *57
00:20:24.996 : N1 M110 *2
00:20:24.996 : N1 M110 *2
00:20:25.011 : ok
00:20:25.011 : N2 M115 *4
00:20:47.683 : ok
00:20:47.683 : N3 M111 S6 *68
00:20:47.715 : ok
00:20:47.715 : ok
00:20:47.715 : N4 M111 S6 *67
00:20:47.715 : FIRMWARE_NAME:Marlin V1; Sprinter/grbl mashup for gen6 FIRMWARE_URL:http://www.k8200.com/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:K8200 EXTRUDER_COUNT:1
00:20:47.715 : ok
00:20:47.715 : ok
00:20:47.715 : N5 M80 *62
00:20:47.715 : N6 M105 *1
00:20:47.715 : N7 M220 S100 *70
00:20:47.730 : ok
00:20:47.730 : ok
00:20:47.730 : N8 M221 S100 *72
00:20:47.730 : ok T:249.4 /0.0 B:97.1 /0.0 @:0 B@:0
00:20:47.730 : ok
00:20:47.730 : N9 M111 S6 *78
00:20:47.746 : ok
00:20:47.746 : ok
00:20:48.324 : N10 M105 *54
00:20:48.340 : ok T:249.4 /0.0 B:97.0 /0.0 @:0 B@:0
00:20:51.386 : N11 M105 *55
00:20:51.386 : ok T:247.2 /0.0 B:96.5 /0.0 @:0 B@:0
00:20:54.449 : N12 M105 *52
00:20:54.449 : ok T:245.0 /0.0 B:96.2 /0.0 @:0 B@:0
00:20:57.511 : N13 M105 *53
00:20:57.527 : ok T:243.3 /0.0 B:95.7 /0.0 @:0 B@:0
00:21:00.574 : N14 M105 *50
00:21:00.574 : ok T:241.7 /0.0 B:95.3 /0.0 @:0 B@:0
00:21:03.636 : N15 M105 *51
00:21:03.652 : ok T:240.0 /0.0 B:94.8 /0.0 @:0 B@:0
00:21:06.699 : N16 M105 *48
00:21:06.715 : ok T:237.5 /0.0 B:94.4 /0.0 @:0 B@:0
00:21:09.761 : N17 M105 *49
00:21:09.761 : ok T:235.2 /0.0 B:94.0 /0.0 @:0 B@:0
00:21:12.824 : N18 M105 *62
00:21:12.840 : ok T:233.8 /0.0 B:93.6 /0.0 @:0 B@:0
00:21:15.886 : N19 M105 *63
00:21:15.886 : ok T:231.4 /0.0 B:93.2 /0.0 @:0 B@:0
00:21:18.949 : N20 M105 *53
00:21:18.965 : ok T:230.0 /0.0 B:92.8 /0.0 @:0 B@:0
00:21:22.011 : N21 M105 *52
00:21:22.011 : ok T:228.6 /0.0 B:92.4 /0.0 @:0 B@:0
00:21:25.074 : N22 M105 *55
00:21:25.090 : ok T:227.0 /0.0 B:92.0 /0.0 @:0 B@:0
00:21:28.136 : N23 M105 *54
00:21:28.152 : ok T:226.0 /0.0 B:91.6 /0.0 @:0 B@:0
00:21:31.199 : N24 M105 *49
Seems like something makes your power fade out.
Try to move the printbed around in a 180-200mm square by a g-code script,
just to find out if it’s the movement (faulty wiring) that causes the power to fail.
Okay, this is getting more confusing. I can’t even decide what is to blame. I have gone from g code to mechanical to electrical, but none of these seem the be the issue. I keep coming back to the firmware because nothing else makes sense.
Using an sd card, 24v p/s for bed, drivers tuned correctly, and using ABS (250 nozzle, 100 bed):
I just printed an object that is 119 X 71 X 50. It took about 3:12. No problems.
Another object (172 x 154 x 152) using the same settings fails around 2:00 on a layer nearly identical the the ones below it.
A third print (119 x 150 x 50) using the same settings fails on the second layer.
The only thing I can find in common in failure is that the two failed prints have a big footprint. Keep in mind that I have been using this printer for close to a year without problems until now. All previous prints were smaller in size to the object that printed successfully above.
You can see from the log in the previous post that it looks like the controller resets during the print. No error is reported. I have had errors for “too long extrusion prevented,” but since I disabled this in firmware it has not come up. That error did not make sense to me anyway since the object is smaller than the bed size settings in the firmware. ichbinsnur was able to print with my g code without getting an error, so I believe it has nothing to do with slicing.
What would cause failure on an object with a larger footprint and not fail on a small object?
Overheating cannot be the issue, which the 3:00 print above proves.
Does a lot of long extrusions somehow create a bigger burden on something that a bunch of short extrusions does not? I would think one long extrusion would be easier on the printer than several short ones.
Does anyone know of an M code that will display the bed size and maximum allowable extrusion? I am thinking that maybe I am missing something in the configuration.h file that might change the running settings. Perhaps disabling the prevent_lengthy_extrude setting causes the board to reset because it can’t deal with something that would have been otherwise caught by the error. I tried using M503 in the g code editor of repetier, but nothing displays in the log except the regular bed and nozzle temp readings. Probably doing something wrong or don’t understand how to use m code.
Did you enable both #define EEPROM_SETTINGS and #define EEPROM_CHITCHAT?
[code]// EEPROM
// the microcontroller can store settings in the EEPROM, e.g. max velocity…
// M500 - stores paramters in EEPROM
// M501 - reads parameters from EEPROM (if you need reset them after you changed them temporarily).
// M502 - reverts to the default “factory settings”. You still need to store them in EEPROM afterwards if you want to.
//define this to enable eeprom support
#define EEPROM_SETTINGS
//to disable EEPROM Serial responses and decrease program space by ~1700 byte: comment this out:
// please keep turned on if you can.
If not, do so and try to reflash the board.
When your last prints failed, did you have a “reset” message in the log again?
Thank you for the tip and your continued help.
#define EEPROM_CHITCHAT was commented. I’ll fix this and see what settings I can see. I also changed HEATER_0_MAXTEMP to 300 just to be sure there was enough margin.
Yes. I am going to re-enable prevent_lengthy_extrude and try to print a box 175 x 175 x 2 to see what happens. If it fails, hopefully I’ll be able to see the configuration using your above change.
The config snippet below looks good to me, but I am wondering if, for instance, min_software_endstops or max_software_endstops is set to true and prevent_lengthy_extrude was commented out that the firmware might not know what to do and just reset on an extrude beyond the limits. The only way this would happen on the failed prints is if the travel limits were somehow changed to something smaller than what I see below.
[code]#define min_software_endstops true //If true, axis won’t move to coordinates less than HOME_POS.
#define max_software_endstops true //If true, axis won’t move to coordinates greater than the defined lengths below.
// Travel limits after homing
#define X_MAX_POS 200
#define X_MIN_POS 0
#define Y_MAX_POS 200
#define Y_MIN_POS 0
#define Z_MAX_POS 220
#define Z_MIN_POS 0
#define X_MAX_LENGTH (X_MAX_POS - X_MIN_POS)
#define Y_MAX_LENGTH (Y_MAX_POS - Y_MIN_POS)
#define Z_MAX_LENGTH (Z_MAX_POS - Z_MIN_POS)
// The position of the homing switches
//#define MANUAL_HOME_POSITIONS // If defined, MANUAL_*_HOME_POS below will be used
//#define BED_CENTER_AT_0_0 // If defined, the center of the bed is at (X=0, Y=0)
//Manual homing switch locations:
#define MANUAL_X_HOME_POS 0
#define MANUAL_Y_HOME_POS 0
#define MANUAL_Z_HOME_POS 0
[/code]
Just for eliminating possible error sources, try this G-code script.
G1 X0 Y0 F300
G1 X0 Y200 F300
G1 X200 Y200 F300
G1 X200 Y0 F300Let this g-code repeat for a while, (just copy and paste the block into repetier lets say 50 times and press run job)
to see if moving the bed around large distances makes the reset reappear.