Using rsteppercontroller on an Arduino UNO. Weird performance issue

[lp76]

I am using the Pololu Stepper drivers with the Uno and have
rsteppercontroller loaded on it. First off, Reza, thanks for all your
hard work. I've been toying with rstepper for a month now and am
getting good results overall. There's only *some* flakiness which is
getting in the way which I haven't figured out the cause yet. I built
an XYZ table which I am still testing using a pen and paper. So the
focus of my work right now is 2D with the pen moving up and down until
I am confident with what I am seeing.

I am sending commands to the /dev/ttyACM(etc.) device using a python
script I wrote. Because the device will scramble w/o a delay, I built
one in to the script. At first I used just a fixed delay, but after a
while, I started calculating which were the most intricate parts of
the GCODE and adding more delay in those parts just as an insurance
policy.

What's happening is, randomly a coordinate will zero out, and I'll end
up getting ugly lines drawn where there shouldn't be any. The more
delay I add, the less this happens, but I am quickly hitting a point
where no matter how much delay I build, it still happens. I am
starting to wonder if its a delay issue at all.

I do know that if I run the code in pieces, and rerun the failed
sections, everything looks great. But if I try to run the entire file,
I get those stray lines.

Have you or anybody else encountered this before? I do not think it's
the electronics as the error always involves creating a perfect zero
position where there isn't one. And also that when I rerun the code it
works fine. I am thinking this has to be at the arduino-level.

[iklln6]

have to get the obvious out of the way:
are you sending an instruction, then waiting until you receive "ok"
before sending the next?
e.g.
cpu sends message 1
cpu waits until "ok" received
cpu sends message 2
cpu waits until "ok" received
cpu sends message 3
etc...

and messages are single lines of gerber like "G0 X13 Y24"

...OR are you having to put in delays between individual bytes in the
serial transmissions?

[Reza Naima]

I'm glad your getting use out of the code. 

I'm not sure how you are sending your code, nor what the reason for the delay is.  When you send a command, you should wait till you receive an 'OK' before sending the next command.   Check out this code

http://code.google.com/p/rstep/downloads/detail?name=rStepInject.zip

I've also put it in SVN.  It's what I use to control the mill.  It's not well documented but you should be able to figure it out.  I'll add documentation when I have more time.

Reza

---

lp76 Tuesday, January 11, 2011 1:07 AM

[jlp]

You may uncomment the #define REPORT_DELAY 5000 in _init.h to see the
progress of the coordinates while the GCodes are processed. This
feature may also be used to wait a bit more time for each reported
coordinates vector as this means rStep is alive and still processing
your command.

[lp76]

Thank you everybody. It should have occurred to me to do that and it
was such a head-slapping moment. I think part of it was that I assumed
that rstep was doing something like that internally and the trouble
was from my trying to perform file-like operations (Linux lets you do
this) instead of a proper serial communication setup.

It immediately cleared up the problem and what surprises me now is how
FAST my device is, and how amazingly accurate the drawings are. I'm
very confident about the direction of my project now. :-)

Reza, again. Awesome work.

[Reza Naima]

Glad it's working for you.   :)

reza

---

lp76 Wednesday, January 12, 2011 1:34 PM

---

Reza Naima Tuesday, January 11, 2011 2:20 AM