Random movements during printing

Hi,



As this is my first post, first a quick intro:



I'm Phil Le Sueur, from Marple, UK and a newcomer to the reprap scene (since March). I've pretty much completed my mendel prusa build and it has just started to produce reasonable quality prints (small things only so far).



In terms of software / electronics / firmware I'm using:



skeinforge version 41

repsnapper - timschmidt/repsnapper.1.1.x

RAMPS electronics (ish)

Sprinter version of Tonokip_Firmware

Ubuntu 10.10



While using repsnapper I've had a number of occasions where the print head didn't go quite where I expected. So, for example it would print out the raft and then print the object half on and half off it and, checking on the forums, I got the impression that others were suffering from this too. Turns out this was happening because repsnapper was overflowing the serial buffer on the Arduino. When this happens the firmware requests the line to be sent again but I think it still executes the buffered lines - so the print gets somewhat out of sync.

The arduino (by default) has a 128 byte receive buffer. Longer lines of gcode - including the line number and checksum can easily get longer than 32 bytes (one of the ones I had which was causing a problem was 50 bytes) so if 4 of these are sent by repsnapper before the sprinter firmware reads any then you run the risk of an overflow.

This is easy enough to fix (or so I thought) - repsnapper has the ability to reduce the number of lines sent to the firmware (receiving buffer size) before it will wait for a reply from the first. I reduced this to 1 and tried again but the problem remained the same. So I took the other easy way out and altered the serial buffer size of the arduino:

On my machine that involved editing

/usr/share/arduino/hardware/arduino/cores/arduino/HardwareSerial.cpp

and changing

#define RX_BUFFER_SIZE 128

to

#define RX_BUFFER_SIZE 1024

You can choose any number you like (within the memory constraints of the arduino) and 1024 is probably way over the top but my mega has plenty of spare space at the moment.

Whatever you do choose it is probably best to use a power of two as I think then the compiler will generate bit shifts instead of long divisions for the modulo arithetic it performs to move around the serial ring buffer - using long division inside an interrupt isn't a good idea.

That cured the problem and my prints stopped having comms errors but I was interested in why reducing the 'receiving buffer size' in repsnapper didn't have the expected effect. What I found was that just before sending the first 'receiving buffer size' count of gcode lines from the file to be printed to the firmware it sent three other gcodes - two M110 commands and one M111 command. By adjusting the firmware to add the line number of the gcode line being acknowldged in each ok acknowledgement I could see that all these four gcodes were being sent to the firmware before it had a chance to process any of them - so the receiving buffer size in repsnapper actually starts at 4 and when set to its default of 4, is actually 7.

An update to the above. As the arduino mega has 4 serial buffers, the above code change uses up 4k of the available 8 for the serial buffers - which probably isn't such a good idea. I ran out of space when I tried to use marlin with the above settings. I've now turned mine down a bit.

Thanks for the information ,
makes the things easy... have a nice day,