Notifications
Clear all
2023-06-30 12:31 am
Hi @will,
-----------------------
My initial conclusion is there are no step pulses...
-------------------------
The first suspect of a code issue is a combination :
stepper.moveTo(-10000)
and
while (stepper.distanceToGo() >0 ) { stepper.run () }
--------
My interpretation is whilst you and I know -10000 steps is 10000 steps from where you want to be, the >0 is taken literally, and it goes nowhere.
My understanding is that moveTo is telling it to move backwards (usually widdershins) that many steps. So the command is interpreted as 10000 steps in the direction -1.
The distanceToGo returns the number of steps remaining to be completed to satisfy the command. That is, it specifically addresses only the count of steps, nothing at all about direction. So moveTo, in this case, will set the direction to be 'reverse' and then move 10000 steps.
I believe my sketch is the source of the error, perhaps I've missed a valid speed, reversed the driver's enable or missed some setup value. The growling in my experience has most often been from speed problems (too fast or too slow) or a bad current setting on the driver.
It's always difficult to tune or diagnose driver problems so that's why I switched over to deliver a library-free version that handles the steppers directly. That'll fail too (the first versions always do 🙂 but it'll be easier to modify to see what's failing (I hope).
Anything seems possible when you don't know what you're talking about.
2023-06-30 12:47 am
Hi @bradscopegems, cc &will,
Your wiring diagram looks ok for the simple job of winding back to the home position to activate the microswitch, then count a fixed number of steps in the forward direction to the 'IN' position.
I haven't checked the 12V power supply is suitable, and I am assuming you have set the current limit potentiometer on the A4988 board correctly.
In case of problems, do a meter check of all of the connections ... it is not unusual with prototype boards, etc, for one or more connections to look correct, but not actually functional.
-----------
You should NOT link the ground wires ... leave that connection to one through the board between the Gnd pins.
If you have any doubts, then with all the power off, use a meter (on Ohms) to check for a direct connection between the two grounds.
If it does not show zero Ohms, (or as near to zero as your meter goes when you short the probes together), find out why, don't add a connection.
(Adding a connection creates a ground loop and encourages noise from the motor to enter the computer control inputs, both of which may introduce problems .. the PCB should have been designed to do the job of keeping both grounds at the same potential. )
---------
Personally, I can think of a couple of reasons for changing the microswitch wiring to my previous suggestion, and also the other switches to add functionality, but that is all for the future.
I am concerned you said the motor growled with Will's AccelStepper program, but perhaps this will be resolved... I'll wait and see what happens.
Best wishes and good luck, Dave
2023-06-30 12:54 am
Hi @will,
I have finally got my old mega2560 clone, Arduino 2.1-ish, and Accelstepper library together + a scope to if there any pulses that could drive an A4988 (if I had one). I have never seen this library before, so I have been grovelling around at the bottom of a learning curve and may easily be mistaken.
If you still have this set up, could you please check something else. I believe the A4988 ENA (enable) pin should be pulled low to enable the stepper. I'm not sure how AccelStepper treats it.
Could you please change the code from
stepper.enableOutputs(); // Enable the stepper
to
digitalWrite(LENA,LOW); // Enable the stepper
and see if that makes any immediate difference ?
Anything seems possible when you don't know what you're talking about.
2023-06-30 1:13 am
Hi @will,
I don't know if there are any other issues, but the first one is really simple ... unless you are a human .. because humans make a 'reasonable' interpretation of the instructions, not the literal one!
The program initially sets the distanceToGo to -10000
Then the program says, continue to move (run) another step, providing the distanceToGo is greater than 0
but the distanceToGo is -10000, so it immediately abandons the idea of stepping on the first time through the loop... and
it also exits the loop via the return statement
------
And as supporting evidence, I changed the distance to go to (+) 10000 ... and my scope has pulses on the step pin...
Best wishes,
Dave
2023-06-30 1:16 am
Excellent work. The criteria should probably be stepper.distanceToGo()!=0 then.
moveTo still has to be negative to indicate that it's moving backwards.
Anything seems possible when you don't know what you're talking about.
2023-06-30 1:32 am
Hi @will, cc @bradscopegems
Sorry it is really stupidly late here, so I'll look at the enable code change till later today (its gone 2am friday!)
.. I have just checked and the program does drive Arduino pin 12 high when it gets going, which as you say will disable the A4988. (Obviously it did not affect my scope searching for step pulses.)
In the meantime, (@bradscopegems) if you temporarily remove the Arduino pin 12 to A4988 notEnable connection, it will not matter if the AccelStepper code is pushing it high
... According to Pololu diagram, the pin is pulled low, so it should be enabled with no connection.
(I have seen that with the boxed drivers as well ... I think it might be normal to use the enable as an independent way of stopping a motor when things go wrong -- the 'main' interface only requires step and dir signals.)
----
Hope that is ok, best wishes Dave
2023-06-30 1:35 am
Hi @will, cc @bradscopegems
Sorry it is really stupidly late here, so I'll look at the enable code change till later today (its gone 2am friday!)
No problem, thanks for solving the immovable carriage conundrum 🙂
Anything seems possible when you don't know what you're talking about.
2023-06-30 11:18 am
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.
DaveE reacted
2023-06-30 11:33 am
Excellent work. The criteria should probably be stepper.distanceToGo()!=0 then.
moveTo still has to be negative to indicate that it's moving backwards.
I really dislike code that checks for 0 and earlier noticed a pin called DIR so a hunting I did go.
The pic is what I found, so can Direction be controlled via the DIR pin then the positioning logic can be what I consider a safer test of < 1 or > 1 depending on the scenario.
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.
2023-06-30 3:13 pm
Now that @davee has figured out the problem with the versos that uses AccelStepper and in the spirit of Bertie Bott's Every Flavour Beans, here's an updated version of the AccelStepper sketch that incorporates the three switches and movement from the engaged to disengaged position.
The notes from the non-library version still apply regarding wiring and selecting positions as step counts.
Anything seems possible when you don't know what you're talking about.
2023-06-30 4:37 pm
Hi @will,
Sorry I am still catching up with a few hours ago. I have checked out the enable and used the setPinsInverted function to fix it.
Also added a few print statements.
Enable is now low whilst steps are being sent
-------------
Looking at the scope, initial step rate is difficult to capture but may be a few millisecs between steps
It slowly accelerates over quite a few seconds ... very crude eyeball guesses ...
- after 10 seconds looks like 2ms
- 20 sec down to 1ms
- 40 sec 0.6ms
- after about 1 min 20 it started to slow down again .. not sure why
step pulse width is about 20 microsecs
-----------------
With negative step count .. dir output is low
with positive step count (and test change to >0) dir output is high
-----------------
I have included a copy of your 'last night code' with my test changes just for your reference.
I realise you have moved on with new code, but not yet looked at it. That is my next treat!
(REFERENCE CODE ONLY)
------------
ps I know you can probably get away with Input_pullup, but a 1 to 10k resistor is required for reliable operation,
together with capacitor to kill off any bounce.
--------------
Hope new code all works.
Best wishes Dave
2023-06-30 5:37 pm
ooking at the scope, initial step rate is difficult to capture but may be a few millisecs between steps
It slowly accelerates over quite a few seconds ... very crude eyeball guesses ...
- after 10 seconds looks like 2ms
- 20 sec down to 1ms
- 40 sec 0.6ms
- after about 1 min 20 it started to slow down again .. not sure why
step pulse width is about 20 microsecs
The slow build-up and dissipation of speed is due to the acceleration. It allows the speed to be gradually changed in order to reduce the inertial load on the stepper.
With negative step count .. dir output is low
with positive step count (and test change to >0) dir output is high
That's the way most divers seem to work but it can be reversed by the wiring to the motor. IIRC, reversing the pair of wires for either the A or B pair will reverse the direction as well.
As you have found, the class provides a mechanism for inverting the logic inside the class so you don't have to rewire if operates in what you feel is the "wrong direction" 🙂
ps I know you can probably get away with Input_pullup, but a 1 to 10k resistor is required for reliable operation,
together with capacitor to kill off any bounce.
The SimpleButton class assumes the easiest configuration (because I'm cheap and lazy) with wiring directly from the Arduino pin to the switch/button and back to the Arduino GND and an internal pull-up via the pinMode's INPUT_PULLUP parameter.
The class handles a time-based debounce (i.e. the button must remain pressed over a specific time to be interpreted as a valid button push, so no extra components are required.
As an aside, the extended version of the AccelStepper does NOT check the limit switch after each step. It's still unclear whether a far-end limit switch will be involved and since the device is assumed to be moving only between two step counts it didn't seem worth putting it into this version.
Anything seems possible when you don't know what you're talking about.
2023-06-30 8:07 pm
Hi @will,
I understand acceleration is used to minimise effects of inertia .. such tricks are used in 3D printers .. but I had expected the acceleration phase from stationary to full speed, to last about a second or so, ... and similarly for deceleration. My crude scope suggested the acceleration phase was more like 30 seconds to a minute.
Obviously only a parameter or two that needs tweaking, but worth bearing in mind.
Best wishes, Dave
2023-06-30 8:13 pm
Tuning it up will be the responsibility of @bradscopegems as he's the only one with the correct equipment and understanding of the full set of requirements. So it'll be up to him to set the initial speed, maximum speed and acceleration that he finds most suitable for moving the carriage.
We're still waiting for significant information about the configuration details.
Anything seems possible when you don't know what you're talking about.
2023-06-30 9:51 pm
Hi @will,
Yes, I agree the only person who can 'tune it up' will be @bradscopegems, as it needs the full system. Just hoped the info might be helpful. As you say, the full configuration details is too sparse to complete the task. Well done for putting today's code together!
Take care and best wishes, Dave