Hi.

I'm trying to print for the first time. I've compiled libreprap and repsnapper from github, last version, under linux. I can connect to the gen6 board, and issue simple commands under the tab "printer controls" (like moving a few steps in X, Y and Z, turn on and off the heater, etc). Optos are ok. Temps are ok (checked with M105, IIRC). I can even extrude a bit of PLA.

Problem:

I load an STL file, convert it to gcode, hit "print". At first, things look promising: the printer homes, goes to the starting position for the print, etc. However, it nevers actually starts printing.

The first weird thing is that the "Printing:" progress bar progresses very fast (it finishes in a couple of minutes).

Under the tab "comm" I can see:



Every run is the same, with minimal variations (somestimes I get "rs 11", sometimes "rs 6").

IMHO, it seems as if repsnapper (or libreprap) is "spamming" the printer, i.e. it's ignoring flow control. Is it "normal" for repsnapper to send about 3000 lines of gcode, without waiting for the "ok"s of the first lines?

The cable seems ok. I've even recompiled and uploaded succesfully the gen6 firmware several times. I've tried setting the baud rate to 19200, 38400... and even 115200! The outcome is the same. Note I can send the firmware thru the cable without errors.

Apart from the baud rate, I have only reversed a couple of axis directions (I'm building a prusa), I've made no other changes to the firmware.

Edit: actually, I did another change, I changed the "resend" response to "rs", to conform to gcode specs, as mentioned in this thread: viewtopic.php?f=35&t=310&view=previous However, I get the same results with or withour this change.

I've searched the whole internet for hours, to no avail.

Any ideas?

Hmmm.

I can see at http://reprap.org/mediawiki/images/0/0f ... ircuit.pdf that gen6 doesn't seem to implement any kind of hardware flow control. RXD and TXD are the only lines connected between the Atmega 644 and the FT232RL? If so, the Arduino runtime could not signal anything (i.e., "don't swamp me") to the computer.

So, this leaves only software flow control, but at http://reprap.org/wiki/Libreprap "software flow control" seems in the to-do list!

This would explain very well this issue, but, of course, I must be wrong because it seems I'm the only one getting it.

Maybe it's a bug in the last version of repsnapper/libreprap, and usually the people get the packaged version, so they are not getting it?

rs means request for "resend".

In the code you posted the hardware seems to be asking for resend line #7.

The commandbuffer is only a few commands deep (somewhere like 4 commands).

Repsnapper should: wait for OK, ánd it should resend when a mismatch occurs.

If I where you I would be searching in the repsnapper source for the resend command.

In Tonokip version for repsnapper I can find that repsnapper is looking for "Resend"
(libreprap / tonokip.c)

ElmarJongerius: I agree with you. It does not make sense: the printer is ack'ing line 6 (or whatever), while repsnapper is sending line number 3000.

I've been diving into repsnapper and libreprap (repsnapper uses libreprap for "low-level" communications) and it seems to me that this line in serial.c in libreprap is wrong:



I think it must be IXON, not IXOFF.

IXOFF means "I (the computer) will send start and stop software flow control characters", which is useless (the 3d printer is not going to swamp the computer).

IXON means "I (the computer) will parse the start and stop characters received, and stop my flow accordingly".

Reference 1:
http://www.chemie.fu-berlin.de/chemnet/ ... bc_12.html


Reference 2:
http://book.chinaunix.net/special/ebook ... 1sec3.html


It's worth mentioning that this line was introduced in 2011-1-17 and has not been changed since (https://github.com/Ralith/libreprap/com ... 7#serial.c), so everybody should have the same bug! Of course, I must be wrong somewhere because I seem to be the only one getting this issue.

have you made sure your electronic noise environment is as low as possible?... make sure your USB cable is not running along any stepper motor or heater cables...

Al...

To be sure, I'll change back the "rs" to "Resend". I think I checked but I may be wrong, and this change is causing my problem.

This cable is "stolen" from a big USB drive. I've transmitted hundreds of GB withour errors. And I can upload new firmware images to the board without problems. Anyway, it's worth checking, so I'll this afternoon.

You understand that the bot is not switching heaters or running electronicly noisy motors when uploading firmware of course...

I personally twist the coil wires on my motors together... ensure my signal wires never run along (it's ok to cross) noisy drive cables... keep the USB cable well clear of everything.. as one wrong bit in the wrong place can cause disaster...

Al...

I'm more and more convinced that the repsnapper/libreprap current version is bugged.

After googling for a while, it seems to me that what gen6 does (no hardware flow control) is in line with other Arduino-family designs. Also, Arduino runtime does not implement software flow control (no XON-XOFF). So, there's no "traditional" flow control at all.

Arduino has a 128 receive buffer (maybe sanguino's is larger), and you are supposed to do whatever you need to avoid swamping the receiver. And guess what... the last version of libreprap/repsnapper is not taking care of this. Repsnapper totally ignores the "4 lines buffer" (the config parameter is not referenced anywhere in the code), and they also don't count the number of "ok"s received from the board.

I'll check more on this this afternoon.