Hi,
i have project with stepper and it is working good. Now I need add some display. I tried Nokia5110, Nextion, OLED and all have same problem. I need send motor position during move to the display, but display slowing the stepper. I tried send the position only 10 times per second, it is better, but the move is not smooth and motor loose steps - it is still unusable. I tried search something about it, but no result 
Have someone any idea?
Thank you
How can we help when you have not posted your program?
My wild guess is that you have written your code in such a way that it spends too long updating the display.
...R
yes, may be is the problem in the display library, but i tried about 5 displays with different libraries and situation is same. It is also same if i try send data only to serial monitor.
Code is here, is very simple. Thank you
#include <SoftwareSerial.h>
#include <Nextion.h>
SoftwareSerial nextion(2, 3);
Nextion myNextion(nextion, 9600);
#include <Encoder.h>
#include <AccelStepper.h>
#define EN 8
AccelStepper stepper(1, 4, 7);
float pozice = 0;
Encoder posEnc(18, 19);
long kroky = 0;
long millisOld = 0;
float koeficient = 1.99795;
void setup(){
Serial.begin(115200);
myNextion.init();
stepper.setMaxSpeed(1000);
stepper.setAcceleration(500);
pinMode(EN, OUTPUT);
stepper.moveTo(-3000);
}
void loop(){
pozice = posEnc.read()/koeficient;
kroky = stepper.currentPosition();
if (stepper.distanceToGo() == 0)
stepper.moveTo(-stepper.currentPosition());
stepper.run();
myNextion.setComponentText("t0", String(pozice));
}
I had been imagining a program with several calls to the display in every iteration of loop() but you have only one call. I have no idea what that library does so I can't make any suggestions for improving it. It looks like it is just printing a few characters on a single line. But maybe behind the scenes it is unnecessarily re-writing the whole display.
There is certainly no need to update the display in every iteration of loop().
Is it practical to hold off the display update until the stepper has reached its destination?
Another option may be to update the display immediately AFTER each step so you have the whole interval to the next step for the update.
...R
yes, the idea with unknown library is good, but same situation is when i try to send info to Serial.print - it is only one number, nothing complicated. Send information after reaching position is ok, but in this application is very usable to see actual position - progress time and ETA. In reprap with the same CNC shield it is working. But how? 
Update display after each step and use the hole is ok, but still is it too short and it is not smooth
I can use another arduino to control only the display and send only ping to one pin, but it is not so clear solution
btw when i use simple 7 segment LED display, situation is dramaticaly better. It look like arduino wait for any feedback form serial, but why?
Nextion myNextion(nextion, 9600);
Can you change the baud for the Nextion? My experience with software serial is that it will work, reliably, at 38400 baud (maybe more for short wires).
9600 baud is useful for sending over very long wires, but for local signalling use as high a baud rate as you can to avoid slowing everything down.
pfifferling:
but in this application is very usable to see actual position
You will know that a step has been made when the value of stepper.distanceToGo() or stepper.currentPosition() changes.
...R
Robin2, yes, but i have implemented independent rotary encoders. I will try change the baud rate but for serial it is without effect.
groundfungus:
Can you change the baud for the Nextion? My experience with software serial is that it will work, reliably, at 38400 baud (maybe more for short wires).
thank you, it is better, but still not smooth, i tried also higher rates and from about 38000 it is not a better.
can i try I2C display, or does not matter?
Hard to say if I2C would be better, but maybe. I2C transfers data at minimum of 100KHz (SCLspeed) and can go to 400 KHz. Worth a try, I guess. SPI can be even faster (2 MHz?).
So not now i also tried only parallel communication instead serial, and it is also better. But still not good
if i tried use LED instead display, it is without problem. So may be only one way is send tick-tack to one pin and read it with second arduino for control display
Just now I noticed that you have a floating point division - I had not spotted that before. Floating point maths is slow and division is especially slow. You can probably get the effect you want without float data AND without division. Integer division is also slow.
And I have no idea whether that encoder library is fast or slow.
By the way, why do you need an encoder with a stepper motor?
...R
float is ok, same problem is with map, int, or without recalculation
the project is about robotic hand and i want use easy settings for positioning. i saw controlling only by keyboards or joysticks but i thing is more user friendly set it by arm dragging to position and then mathematicaly smooth the curve and change the time of movement. it working very well, but for some special aplication with long time of movement i want show the ETA yes, it is not good for playing with arm but for moving automatization to untechnical users is it right step. i hope
pfifferling:
i want show the ETA
Am I correct to guess that this is why you have the encoder?
If so, why not just figure out the position from the number of steps that the motor has completed?
...R
no, if i move the arm by hand, i need know the position where the arm is. It is possible only with encoder. Or any other idea? I tried read steps from stepper by current induction between coils when it moves without power, but it is not usable
pfifferling:
no, if i move the arm by hand, i need know the position where the arm is. It is possible only with encoder.
I don't think you mentioned that requirement earlier. Is there anything else you have not told us?
...R
but the encoder is not the problem in the loop. situation is same with or without enc, i tried send only one number, or text and it is same. Problem is in serial communication. Every communication slows the loop, for stepper it is a problem.
serial communication - reduced stepper speed to about 30%
parallel communication - 60%
LED - 100%
SPI OLED - 30%
7 segment display - 85%
pfifferling:
but the encoder is not the problem in the loop.
Perhaps, but it makes it much easier to help when you give us the full picture.
The question in my mind is whether the Nextion stuff is just the last little bit too much. If you don't include Nextion then loop() is repeating just fast enough to allow the stepper to move as you want. But when you add in Nextion the time between iterations of loop() is just a little bit too long.
Have you tried the code with Nextion stuff and without any encoder stuff?
Also I don't think it is fair to blame Serial. Your call in line 32 is to myNextion and goodness knows what that library gets up to behind the scenes. Serial is probably only a small part of it. You need to poke about in the innards of the Nextion library.
...R
understand, yes, i tried it also without encoder and also with another displays (no nextion), also only with serial monitor without display and it is total lazy i tried search for similar application - arduino and stepper with display and real time info, and it looks like nobody made it
