L298P driver board, Arduino Uno, Nema17-PG5 Stepper

[Acapulco Rolf]

HI

First of all, thank you for sharing this project

I've put a focusser together using the following L298P motor driver module coupled with an Arduino Uno
https://www.amazon.co.uk/gp/product/B07BFQT5Y1/ref=oh_aui_detailpage_o02_s00?ie=UTF8&psc=1

I have bluetooth connectivity and temperature probe working as expected.
I used the (myFP2.L298N, 275) firmware to confirm the operation of bluetooth and temperature probe

I followed the guidance in this post (along with the test sketch here) to test the L298P motor driver with a Nema 17 Stepper.

I have the stepper motor turning clockwise and anti clockwise as expected with fast, medium, slow speeds using the test sketch

Is there a cut of the focuser firmware specifically for the L298P, given the operation of this driver based on the guidance in the thread here

[brownrb]

Hi
Whilst myFocuserPro2 supports a number of different driver boards etc, as yet, the L298P is not supported. I do not have a L298P board to test so would basically be guessing. And there does seem to be variation within the L298P boards meaning one code version might work on one L298P but not on another L298P from a different supplier.

I have very limited funds available and there is zero income from any of this at all. I would like to be able to do more and offer you some assistance but without having access to the hardware am pretty limited in what I can do.

Regards
Robert

[Acapulco Rolf]

No problem Rob
I do understand

By way of an update. I've now looked at the myFP2.L298N, 275 Arduino source and have made changes to the source to allow the code to work with the L298P driver

Changes (these changes work for me for my specific L298P module))

firmware: myFP2.L298N, 275
1
replace
include myHalfStepper.h
with
include myStepper.h

2
// define L298P inputs
define IN1 12
define IN2 10
define IN3 13
define IN4 11

3
// initialize the stepper library
replace
HalfStepper mystepper(stepsPerRevolution, IN1, IN2, IN3, IN4);
with
Stepper mystepper(stepsPerRevolution, IN3, IN1);

4
in clearOutput()
replace
digitalWrite(IN2, false);
digitalWrite(IN4, false);
with
digitalWrite(IN2, HIGH);
digitalWrite(IN4, HIGH);

5
in setup()
replace
digitalWrite(IN2, false);
digitalWrite(IN4, false);
with
digitalWrite(IN2, HIGH);
digitalWrite(IN4, HIGH);

6
in setstepmode()
comment out the following library calls
mystepper.SetSteppingMode()

So far, early stage tests show that the stepper motor responds as expected to commands from the UI

[brownrb]

Hi
Thanks for that. Let me put together a version that you can test for your board.

On the surface your code changes look okay, but i have concerns because the board should support half stepping. In addition, I note at places that you do not reference IN3 and IN1, only using IN2 and IN4. That does not seem to make sense to me.

Anyhow, Ive put your changes into the attached file - please let me know what happens.

Regards
Robert

[Acapulco Rolf]

Thanks Rob

Before I test the cut of the firmware that you've shared here, I've been carrying out further testing with the myFP2.L298N, 275 firmware

My observations so far:

1
To overcome the stepper motor overheating that I observe during further testing, I now set the two PWM pins LOW after completing a mystepper.step() via the clockwise() or anticlockwise() functions

2
There appears to be some stepper motor "judder" introduced in the stepper move calls from the Windows GUI app to the firmware that I'm unable to trap and debug

Without being able to see what the Windows app is doing, I'm not able to see where the judder is introduced

I've seen in the firmware source two areas that might be significant:

1: the intended delay introduced by the MOTORPULSETIME constant
2: the intended delay introduced by the motorSpeedDelay variable

I've tweaked those values downwards to measure the benefit, but I'm not able to remove the judder that I observe

The "judder" manifests as a stuttered motion in the stepper rotation

Things have been otherwise succesful with a test sketch that I've attached where I observe buttery smooth stepper motion using that test sketch :)

I'll continue testing and report back

By the way, thanks again for the cut of the firmware. I'll take that firmware as my baseline for further testing

[brownrb]

A comment on that test code.
Because you are using the stepper library this line is not needed (the stepper library takes care of pulse duration)
delayMicroseconds(MOTORPULSETIME);

It is true that the PWM lines have to go HIGH for the motor to step

I am not convinced that this line is correct
Stepper myStepper(stepsPerRevolution, dirA, dirB);

I would have expected it something like (where each of the 4 pins are specified)
Stepper myStepper(stepsPerRevolution, IN1, IN2, IN3, IN4);

IMHO - Otherwise the stepper routines only know about two lines not 4. To drive the stepper correctly you would need all 4 wires - you are loosing half the states to drive the motor smoothly and only like pulsing it at half the rate and the other stepper pins 3/4 are not being used at all.

here is 2 wires that you are changing
0 0
1 0
1 1

but in reality there are 4 stepper wires to change so it should be
0 0 0 0
1 0 0 0
0 1 0 0
1 1 0 0
0 0 1 0
1 0 1 0
0 1 1 0
1 1 1 0
and so on

Which do you think would be smoother?

[brownrb]

It could be that the sudden judder is caused by activation of coil power before the move is started. The NEMA's are pretty big beasts and suddenly applying coil power on can cause then to jump a bit, especially if you are using half stepping

[brownrb]

MOTORPULSETIME please do not change. This is the required duration of the step pulse to correctly step the NEMA motor and is critical.

motorSpeedDelay is a variable whose value determines the time delay through the loop - meaning it controls the speed of the stepper motor - this value is adjusted depending on motorspeed (s/m/f) and the step mode to try and give reasonable speed rates for these combinations.

In general even when coil power is on the stepper should not overheat - especially with the drv8825 - but other drivers like the L298 you have little control over the current and heat becomes an issue because of this.

If you are running coil power off, and then suddenly energize the coils with like 1A or more especially with the L298 and L9110S boards (which have no current limit) the NEMA is gonna jump alright with that sudden burst of current and may take a few steps to settle down.

This is why the recommended driver board is DRV8825 where the current can be adjusted,

In your case, with stuttered movement throughout the move, I do believe this goes back to what I was saying before about the IN1/2/3/4 leads and combinations and the code not being right. I personally do not like motor shields as they are much more difficult to program and are also time sensitive. Without full access to how the manufacture built it (like schematic) it really is a crap shoot at best.

Regards
Robert