I am trying to rotate a stepper motor via data from serial monitor. I am trying to work with X-Plane aswell. I already filtered the data from X-Plane, but when I try to rotate the motor, its not fast enough. I tried to execute the program and debugged it via manual input in Serial Monitor. When i connect it to X-Plane i receive a lot more data and the programm can't keep up with input. Now my collegue thought about correcting the data, after every step, but it seems to slow down the program. Does anyone have a another idea?
I know, we used to have the standard baudrate but, the data stacks like this ...
If you get 300, 300, 300 as data for example. It will do the 300 steps, then 300 and so on. But we get in one second a lot more than the program can handle. So after 1 minutes we get for expample a few thounds data, which need to be done before the program can work on the incoming data.
You need to add some kind of flow control: a way for your sketch to tell the sender to pause sending.
Serial.available() will tell you how many characters are in the buffer. You could send that value after reading each input and the sending program can pause sending if the buffer is too full. That will not slow your sketch because the buffer will be kept full enough but not too full.
That code looks like blocking to me. If the stepper is commanded to make 300 steps it takes time to make those steps. How fast is it stepping? How many new commands are coming during that time?
I think the serial buffer might be filled up while the stepper is chewing steps.
As @ johnwasser says, You need some kind of hand shaking, synchronizing.
A few of things to try
i) move to the AccelStepper library that allows multi-tasking.
ii) See the stepper example controlled by user input in my tutorial on Multi-tasking in Arduino
iii) Add extra buffering to the input Serial and change the debug output to be non-blocking. This is covered in detail in my tutorial on Arduino Serial I/O for the Real World
Serial print( )s will block once the TX buffer fills up. At your slow 2400 baud this can easily happen.
iv) add a loopTimer to see how fast the loop is running and where the delays are.
You can add more then one loopTimer to time how often/fast different parts/methods are called.
Definitely concur with this - the sending device needs to wait after sending each command until the stepper system is ready for more input.
AFAICT this is exactly how the universal GCODE sender program works, which is similar to what you are doing.
If the communication is simplex (one direction only), you have to buffer all the data at the receiving end so you never block. This means having enough RAM to store it all, however much that is.