Alright, thanks, I will change this
5 is the value I found by testing, it give me approximately 7 frames/sec (the driver is set to 1/4 steps, I have a smoother move and less vibrations in this mode). I need a range from 2 to 7 fps, I still have to set the higher value, 300 is too slow.
You wrote that there is a rotary switch on the projector. It would be important to know which contact is active in which position. Then you can evaluate it reasonably.
For an acceleration, the moment of switching from STOP → START and vice versa must be recognized.
That' really fast. Even if it's not the real stepping rate, because of loop cycle time.
Anyway, I'm not surprised that the stepper can't do it without a ramp.
I have recognized 3 contacts that are active on the rotary switch on 3 positions : Forward, Stop and Backward (I didn't use Backward in the code, as I could simply use "Else" for the Direction HIGH or LOW). I have a contact active on the ON/OFF switch too.
Could it be problematic somehow? Would you suggest to switch for 1/2 step Mode?
I would create a binary table, which contact is open/closed in which rotary position.
In the sketch you read all contacts and you can see in which position the rotary switch is. And you can see when it was moved to start or stop the motor.
This is much clearer and more concise than that many if / else
At least it is a demand for a ramp.
The sketch determins the final speed. Acceleration is done by the lib - the sketch doesn't have to bother with.
I found this example in the Mobatools : MobaTools/Stepper_03.ino at master · MicroBahner/MobaTools · GitHub
It's seems pretty close from what i want to do, I will spend time trying to understand it
If you don't understand something, simply ask 
I got my new Arduino and tried this sketch, I just had to modify the pins, it works well with acceleration.
I don't know exactly why but I couldn't reach the speed I had with my first sketch. I changed the value of the pot to :
vspeed = map((analogRead(potPin)), 0, 1023, 200, 4200); Which should give me between 200 and 420 rpm but the max speed is much lower.
I tried to switch from 1/4 steps to 1/2 steps on the driver, changed STEPS_REVOLUTION to 400 and could have a better speed.
Another question : I don't really understand what does the enable pin does in this sketch. I only saw it on this line :
myStepper.attachEnable( enaPin, 10, LOW ); // Enable Pin aktivieren ( LOW=aktiv )Is that disabling the driver when the motor is not running?
Yes, that's true. MobaTools is designed to drive multiple steppers and it limits the speed to not overload the AVR processor. Because you only need one stepper, you can loosen this 'brake' by changing an define in MobaTools.h.
Change this line
#define CYCLETIME 200 // Min. irq-periode in us ( default is 200 ),
to
#define CYCLETIME 80 // Min. irq-periode in us ( default is 200 ),
and you should get the speed of your first sketch.
( There are several similar lines for the different supported processors. You must change the line with default is 200 )
Yes it is. The enable pin is managed by the lib in this case. 'attacheEnable' tells the lib to do so, and it tells the lib which pin and if it's LOW or HIGH active.
Thanks for those informations !
it took me some time to find out how to modify the library but I could change this value to 80.
The speed increased indeed but the motor doesn't stop any more once started and the pot is not controlling the speed. I modified back to 200 and went back to the previous situation with limited speed. Is there something I could have done wrong?
I thought I tried it with 80, but maybe I'm wrong. Try with 100 that should do. I'm shure, that I tried it with 100 already. If it still doesn't work I have to see what's wrong.
100 seems to work fine !
Did you modify the example, or does it fit for you as it is ?
I didn't have to much modify . Just the speed and the buttons.
I just didn't manage to work on the buttons with MoToButtons and removed this part to go back to what I wrote first for the button. It's probably not the most elegant way to do but it works. All the controls are working like with the original motor.
I am just a bit worried because I start to loose the 12V Power connection on the Driver, the breadboard is getting hot on those points and I had to change the position of the Driver to have a new line on the board. I guess the board can not handle 12V / 1.2A, it's a cheap one I bought on Ebay, without datasheet or mention of the max power.
I think the contacts of your rotatry switch behave different from buttons as the are assumed in the example.
A Breadboard is generally not a good idea fo such currents. Did you place a capacitor of at least 100µF directly at the Vin and Gnd Pins of the driver? This is important too.
Yes, I guess it will better once soldered on a real board. For now I remade the circuit just with wires, the connection is stable.
I have a capacitor yes but only 47µF, I can change it for 100µF .
I also realized that the new sketch using the Mobatool library is giving me some smalls bumps/changes in speed. I initially thought it was because of the bad connection with 12V but I tried again to run my first code and the speeds are totally stable (but no acceleration of course).
Any idea of what could be the problem? I tried to go back to #define CYCLETIME 200 in MobaTools.h just in case but it didn't improve the speed stability.
How big are these changes in speed? Can you post your sketch - as it is now?
The changes are audible, difficult to say exactly how big they are. (I will try to add a tachometer to the sketch).
Here is the code how it is now :
#define MAX8BUTTONS // spart Speicher, da nur 4 Taster benötigt werden (saves RAM)
#include <MobaTools.h>
// Pindefinitions - change to your needs
const byte dirPin = 11;
const byte stepPin = 12;
const byte enaPin = 10;
const int FORWbuttonPin = 6;
int FORWbuttonState = 0;
const int REVbuttonPin = 9;
int REVbuttonState = 0;
const int ONbuttonPin = 7;
int ONbuttonState = 0;
const int STOPbuttonPin = 8;
int STOPbuttonState = 0;
const byte potPin = A0; // must be an analog input
const int STEPS_REVOLUTION = 800;
//Stepper einrichten ( 800 Schritte / Umdrehung - 1/4 Microstep )
MoToStepper myStepper( STEPS_REVOLUTION, STEPDIR ); // 800 Steps/ Umdrehung
MoToTimebase speedIntervall; // Zeitinterval zum Auslesen des Speedpotentiometers
// the speed pot ist read only every 'speedintervall' ms
int vspeed = 0; //Steppergeschwindigkeit in U/min*10
void setup()
{
myStepper.attach( stepPin, dirPin );
myStepper.attachEnable( enaPin, 10, LOW ); // Enable Pin aktivieren ( LOW=aktiv )
myStepper.setSpeed( 200 );
myStepper.setRampLen( 100 ); // Rampenlänge 100 Steps bei 20U/min
speedIntervall.setBasetime( 100 ); // 100ms Tickerzeit pinMode(hall_pin, INPUT);
}
void loop() {
// Speed alle 100ms neu einlesen und setzen
if ( speedIntervall.tick() ) {
// wird alle 100ms aufgerufen ( Tickerzeit = 100ms im setup() )
vspeed = map((analogRead(potPin)), 0, 1023, 200, 4200); //Poti mappen auf 2 ... 180 Umdr/Min
//min speed =2 and max speed =180 rpm
myStepper.setSpeed( vspeed );
}
FORWbuttonState = digitalRead(FORWbuttonPin);
if (FORWbuttonState == HIGH && ONbuttonState == HIGH) {
myStepper.rotate( 1 ); // Stepper dreht vorwärts
}
REVbuttonState = digitalRead(REVbuttonPin);
if (REVbuttonState == HIGH && ONbuttonState == HIGH) {
myStepper.rotate( -1 ); // Stepper dreht vorwärts
}
STOPbuttonState = digitalRead(STOPbuttonPin);
if (STOPbuttonState == HIGH) {
myStepper.rotate(0); // Stepper stoppt
}
ONbuttonState = digitalRead(ONbuttonPin);
if (ONbuttonState == LOW) {
myStepper.rotate(0); // Stepper stoppt
}
}Audible is normal, since there is - especially at high speeds - an audible jitter on the stepping pulses. This is due to the fact that the pulses are only generated in a grid of 200 - or in your case 100 µs. If you change the speed, the jitter changes too, and that is audible.
Due to the inertia of the motor, this should not lead to an actual jitter in the speed.
But there are some drawbacks in your code. You should not call rotate(1) in every loop. rotate(1) is a command to start the motor. Then it will rotate without any further call of this command.
Remember wether you started it already - forward/backward - or stopped it. And only if you change the state than call the acoording command.
It will probably work anyway, but it's not the way it should be.