Welcome! Log In Create A New Profile

Advanced

Last few lines of g-code fail to print

Posted by drax 
Last few lines of g-code fail to print
April 16, 2013 05:00PM
Hi all!
I have assembled my Mendelmax and we are getting acquainted. It prints quite well appart from stopping the print just before the end.
Just a few lines of the last layers' infill are missing. Well it doesn't exactly stop. It prints and then as if late for a bus or something just homes X and Y (I think) and parks. Heaters also shut down like they should. Everything is fine except from the last layer on the object is not complete.
I'm attaching an image of how the print ends up.
The g-code seems OK (at least the 3D representation - I'm not exactly literate in G-code).
I don't know where to post this as I don't know the cause of this behaviour. I'm thinking maybe it's something with communication between Repetier host and the machine.

Here are my connection settings from Repetier:

Port: COM3
Baud: 250000
Stop Bits: 1
Parity: None
Transfer Protocol: Autodetect
Receive Cache Size: 63
Use Ping-Pong Communication: off

My setup:
- RAMPS 1.3 with Arduino (think it's fake but works ok otherwise),
- RELEASE CANDIDATE 2 FOR MARLIN 1.0.0
- I upload with Arduino 0022
- Repetier Host v0.85b
Edit: Actually I just remembered that the box was my first print and done with Pronterface. But in Repetier Host the problem persist.

Can somebody please help me with that?

I can also provide a log file etc.

Thank you,
Andrej

Edited 1 time(s). Last edit at 04/16/2013 05:03PM by drax.
Attachments:
open | download - IMAG2053_proc.jpg (51.1 KB)
Re: Last few lines of g-code fail to print
April 16, 2013 11:34PM
I run repetier too and never saw that one before.
It looks like the ending home instruction is overriding the buffer full of commands.
Which slicer are you using?
Maybe try printing with the home instruction at the end turned off first? and see where it stops.
Re: Last few lines of g-code fail to print
April 17, 2013 06:59PM
I took your advice and it looks like you nailed it. I removed the home-x G28 line and here is the before-after result (see image). It went straight to 'park' after completing the moves I think but left a blotch at the end. Maybe it should retract. I guess I could manualy edit the code on every print but I suppose that would not be the most elegant solution. And I wonder why it puts a home command in there in the first place. Interestingly Repetier played the sound notification I set up for the end of printing right at the point where the print on the left had stopped - on the right side print also.
Any suggestions on how to troubleshoot this further?
Oh, and I use Slic3r v0.9.9-dev - the one that came bundled wth Repetier 0.85b.
Thanks for your help.
Attachments:
open | download - IMG_bad_good.jpg (147.7 KB)
Re: Last few lines of g-code fail to print
April 17, 2013 10:11PM
So you still had a x-home command in there but it worked fine?
It would be interesting to see the last layer of G-code commands before and after to compare where the homing command was at in the failed prints. (The last layer would start from the last z-move)
It could be due to how the slicer program is processing the code when you request to home at the end.
After that, I do not know how slic3r is coded internally.
Re: Last few lines of g-code fail to print
April 18, 2013 10:30AM
No, with the x-home command it skipped the last lines. And when I deleted the whole line "G28 X0 ; home X axis" it printed the whole box (the box on the right in previous post image).
I don't have the log for the two boxes from my previous post but here's the log of another print that failed in the same way - tower callibration object >>attachment.
The M105 and M106 are about the fan I think but they shouldn't be relevant because this problem was also present before I had connected the fan.

I can also recreate the situation with the box before-after example and log it if you wish.
Attachments:
open | download - TowerCalibrJobLastLayerLog.txt (3.5 KB)
open | download - TowerCalibration_LastLinesFail.jpg (56.6 KB)
Fil
Re: Last few lines of g-code fail to print
May 10, 2013 02:12AM
I have exatly the same problem.
and this problem appear when I change sprinter to marlin (I need Marlin for my lcd)
do you solve your problem?
Re: Last few lines of g-code fail to print
May 10, 2013 11:26PM
I am not a g-code expert either but the way I read it:
M107 is for fan off setting but it was "depreciated" i.e. changed to M106 in later versions purportedly.
M104 S0 is zeroing the temperature of extruder.
M105 was getting extruder temp.
translated using reprap-G_code

Apparently something is triggering the last operational line to execute before the prior moves were finished. Maybe you could add a pause before the home to give it time to complete the moves. This would be a manual patch for each print, so not a fix, just temporarily expedient.

You probably need someone who knows Marlin to help.
Re: Last few lines of g-code fail to print
May 11, 2013 10:42AM
Hi,
@Fil: No, I haven't really solved the problem. My workaround (temporary I hope) is... I just delete the home x-axis (G28) command from the end g-code before I print (or better - delete it from slic3r end code in Slic3r profiles so it doesn't get generated). I figured that much out - thank you rrr7 for the tips.
Can you post your specs (software, hardware components) so we can compare and see where the problem could be?
If you find a better solution please post back.
Sorry... it took me a while to answer as I couldn't remember my login.
Fil
Re: Last few lines of g-code fail to print
May 12, 2013 01:35AM
my harware arduino+ramps1.4
and my software pronterface+skeinforge and marlin in the arduino

I try some other parts (like the frog) and when the last layer is verry small, I don't notice mistake.

for the moment I can't do other tests because my hotend is clogged
Re: Last few lines of g-code fail to print
May 12, 2013 04:46AM
I've had this issue in both Pronterface and Repetier, so the problem obviously lies somewhere else. RAMPS couldn't be the reason also as it is not interpreting any codes and such. Also mine is 1.3 and yours 1.4.

Like rrr7 has pointed out I also suspect it is Marlin. I'm using Marlin 1.0 RC2. What's your version?
My Marlin runs on a fake Arduino. I think maybe this is causing the problem. It would be useful to know if this happens on an original also. Is your Arduino an original one? What about your OS. I use Win XP SP3.

I'm not saying that I'll be able to diagnose the problem from that but if we figure out the possible causes at least we'll know where to ask next.
Re: Last few lines of g-code fail to print
May 12, 2013 04:32PM
Hi
I'm having the exact same problem with marlin and slic3r.
My guess is that the G28 command is implemented incorrectly in the marlin firmware - it should be buffered with the other commands and executed in order, but for some reason it gets executed immediately.
My fix to it is quite simple, I replaced the G28 command in slic3rs profile with these 2 commands:
G92 Z0 ; set Z to zero
G1 X0 Y200 Z10; elevate 10mm, move to left and back
This will move your nozzle up 10mm and to the left side and move the print bed all the way forward so the piece can easily be removed. The G92 and G1 commands get queued correctly, so the last layer will be printed completely.
Fil
Re: Last few lines of g-code fail to print
May 12, 2013 05:10PM
before I had not this problem and I was using sprinter, I move to marlin 4 days ago because I need it for my lcd screen.
That's why I think that the problem come from marlin but it can be to a parameter in skeinforge (Ichange somes too smiling smiley
I think it's strange we are only three to have this problem.

sorry for my english, it's not my native language
Re: Last few lines of g-code fail to print
May 12, 2013 09:38PM
Mine setup in case you were wondering is:
Libuntu (Linux) on a laptop
RAMPS 1.4
Repetier Host v.72
Repetier-firmware v.71
Skeinforge v 50
Re: Last few lines of g-code fail to print
May 13, 2013 03:27AM
Hi,
Based on our assumption that it is a Marlin issue I searched the Github for similar issue. We are right. This is what I found out:
[github.com]
and at the end of the thread ErikZalm posted a link to a thread that explains
[github.com]
I will go through the whole two threads when I have time but I wanted to let you guys know about it and read it for yourself if you like.
@Fil: If you own a Reprap machine or a pack of smokes you are not alone winking smiley

Edited 4 time(s). Last edit at 05/13/2013 03:43AM by drax.
Fil
Re: Last few lines of g-code fail to print
May 14, 2013 01:50AM
it mean that we know where is the problem, and we have a temporary solution (add manually M400 at the end of the Gcode before G28(Ijust tested it, It works fine!))

buffering or no buffering that is the question
Re: Last few lines of g-code fail to print
May 14, 2013 02:58AM
Great!
You could also add M400 to slic3rs "end code field" and save to profiles so it is generated automatically on every slicing job but I'm sure you already know about that. I only use Slic3r so I don't know about other slicers but probably they have the same functionality.
smiling smiley
Fil
Re: Last few lines of g-code fail to print
May 14, 2013 01:41PM
no I don't know smiling smiley
I don't use slic3r I use skeinforge, I will look if it allow yis kind of manip
Fil
Re: Last few lines of g-code fail to print
May 14, 2013 01:46PM
i'm not sure skeinforge allow this add. i'vn't found it
if somebody know if it is possible or not, it can tell me please smiling smiley
Re: Last few lines of g-code fail to print
May 14, 2013 10:35PM
Add it to your end.gcode, which should be in your alterations directory alongside start.gcode and replace.csv. If it doesn't exist, create it, its just a plaintext document with gcode to be included.
Sorry, only registered users may post in this forum.

Click here to login