@Railroader , In which reply?
#15
Oh, meaning that the way I have it wired in the simulation is appropriate for the driver I have?
GND is missing between driver and controller.
That sounds perfectly reasonable. And it sounds like you have steppers, drivers, an Uno, you like the AccelStepper library. Do you have buttons? Do you have all these things connected to your Uno already? Do the steppers and buttons and switches each work individually with the relevant example scripts like File/Examples/DigitalInputPullup and File/Examples/Accelstepper/Bounce?
You could then add functions to the BlinkWithoutDelay.ino script (or any other non-blocking script) loop(){...}
like this (completely untested and unconfigured) code:
void loop(void){
...
handleButtons();
handleUpMotion();
handleDownMotion();
handleStopped();
myStepper.run();
}
void handleButtons(void){
if(digitalRead(goUpButtonPin == LOW){
motionState = UPWARD;
}
if(digitalRead(goDownButtonPin == LOW){
motionState = DOWNWARD;
}
if(digitalRead(stopButtonPin == LOW){
myStepper.stop();
motionState = STOPPED;
}
}
void handleUpMotion(void){
if(motionState == UPWARD){
if(digitalRead(upLimitSwitchPin) == HIGH) // wired normally closed w/PULLUP
{
myStepper.move(10); // move target further upwards
myStepper.run(); // take a step if needed
} else { // limit switch opened
mystepper.stop();
motionState == STOPPED;
}
}
...
Yes, you were not posting code, you were posting links instead of data, etc. but now it seems like you're on track, so...
Try:
Thanks Dave. That's a great starting place for me. For some reason, it didn't include my entire response to you. Below is the full description of what I said:
Blockquote
@DaveX , thank you very much. So here is a better explanation of what I'm trying to achieve:
I have a table (or will have) that folds/hinges out from a wall into "normal" position, and then back up out of the way. The table is on linear slides connected to ball screws and "lifted" via a stepper motor (picture in first two posts). I'd like to have a limit switch at the full "up" position, one at the full "down" position (to tell it to stop when going "up" or "down". I would then like to have a button dedicated to telling the motor to spin clockwise (up), another button dedicated to telling the motor to spin counter-clockwise (down). Hitting a limit switch while traveling in either direction would stop the motor. I originally thought I would like a third button just to "stop" the motor in any location while in motion, but this isn't 100% necessary as I will have an e-stop which could technically do the same thing.
I am also curious about the logic if I am in a full "up" position and the switch is already triggered. Do I have to add some special code that if when I push a button and the switch is already triggered to go ahead and move? Or would it be more along the lines that if the upper switch was triggered, pushing the button to move the motor "up" further would not work, but hitting it to go down would work? Thanks for taking the time Dave.
Wow @FernandoGarcia , thank you very much! That's getting a bit closer. I may be able to tweak it from there. On post 28, I detail exactly what I'm trying to accomplish in better detail.
A couple of notes: I'm using a stepper driver, so the stepper isn't connected directly to my board, but I believe I can assign the "dir" and "step" pins from the arduino out to the drive.
In your simulation, I can click the green start button and it will start the motor turning. I can then trigger one of the switches (simulating hitting the first limit switch) and it stops. All is good. I can't get the motor to reverse or move anymore after that though. I'm sorry. I'm so new at this. Thank you again for your help.
Do I need one between them? I know I have external power via a power supply that supplies the necessary voltage to the driver and ground; however, the simulation said that wasn't necessary for it to work, so I didn't mess with those two. Or do I need another ground from the controller?
We are past post #30 and a schematic still hasn't been posted.
I'm sorry @anon57585045 I was still sorting out exactly how that needed to be configured; but I can take a snapshot of the simulation that fernando showed me of how I currently have it configured. Would that work? I'm not intentionally going against the grain. I'm just trying to sort it all out. i apologize if I somehow have broken some rules.
I don't understand. It's not complicated. Basically you are just supposed to post stuff in line. Here, so we can see it.
Please try to avoid posting links to other sites where code or photos or schematics are hosted. Most of us will not follow such links, partly due to the risk that they hold malware or other unwanted content, partly to maintain everything on this site for the benefit of future users looking for an answer to a similar question, and partly because we feel that if you want our help you should provide everything we need on this site not expect us to go hunting elsewhere for it.
https://forum.arduino.cc/t/how-to-get-the-best-out-of-this-forum/679966/1
One problem with this idea is that, for example, if you have hit the lower limit switch and stop, and then call for motion away from the limit switch towards the top, you don't want the lower limit switch to inhibit upwards motion.
In my head I think of your problem as that at any one time the motor should be either goingUp, GoingDown, or notDoingAnything -- three mutually exclusive states. Beyond how you tell if a button or switch is triggered, or how you drive the motor (which should be worked out if you can do the sample sketches with your hardware), the important logical details are in how you tell the device to change in between the different tasks.
With the untested snippet I posted, no, you don't need much special code. The device only needs to remember if it is going up or down or stopped, the limit switches stop it from going wrong, and the buttons force a state transition.
Or perhaps this logic handles the special cases of multiple buttons pressed at the same time -- the last one checked overrules the earlier checks, so stopButtonPin wins. You get a "Jog" feature for free by holding the upButtonPin
and the stopButtonPin
at the same time.
Yes, and those are reflected in the pre-computer, hardware limit switch circuit. Either left switch is active, right switch is active, or neither (when the carriage is in between limits). Which, drives the motor as described.
If done in hardware, pre-computer, when the left switch triggers, do you need to push it off the stop to the right manually, or can you call for controlled motion in the opposite direction?
Expensive CNCs have hardware limit switches that are part of an emergency stop system which shut off the power before things or people break, along with warning limit switches for softer travel limits.
Guess this was for the OP. But to clarify what I said, the limit switches are wired to allow motor travel in one direction only when the carriage is at an end. So a simple motor voltage polarity reversal will start it moving towards the other end.
I see, you could wire the limits into an H-bridge for a DC motor.
In the context of a STEP/DIR stepper driver I suppose you would control the enable line with some leftLimit, rightLimit & DIR logic hardware.
For a stepper, the hardware limit switches can only be either
- panic (emergency) switches that require a manual reset, cuts power to the motor
- digital inputs that alert the control program that an end has been reached
It's possible with a shutdown input to the H bridge, you could arrange a digital reset method that is too indirect to be likely to happen if the CPU goes out of control... like, an "escape sequence"...
My mind boggles at how you would force a stepper to go in only one direction, using only wiring... maybe... I guess DIR pin on the controller if there is one...
Some systems must hit a limit and recover, if they depend on it for a homing operation.
The folks I used to work with liked hardware stops wired into the E-stop system, and didn't trust fancy electronics for safety.
If you just force the opposite DIR in hardware, it bounces, and you lose homing/position info. Maybe wire this up in silicon:
ENABLE=(softENABLE && (left && DIR) || (right && !DIR))
ENABLE=softENABLE && ((left && DIR) || (right && !DIR))
The better systems use sensors for both an E-stop hardware/safety limit, and a separate soft limit sensor for travel and sane computer control.