Help needed for my stepper-ballscrew project

@zander     Dear Ron,  Thank you! 

I feel instinctively that you are giving me exactly the advice I need, and that I am almost there...... but I am too unfamiliar with the Arduino language to implement your suggestion. I have set up the motor with my Arduino Uno and the A4988 driver module and I have loaded the sketch described in the last part of the Tutorial on 'Controlling Stepper Motors with Hall Effect Switches...'  This is the sketch for teaching the motor a 'home' position using only one switch, which, in my case is a simple mechanical microswitch rather than a Hall Effect switch.  Although there is , I think, no mention of reversing the motor in the sketch, the motor starts moving in a certain direction and then, as soon as the 'home' switch is closed halts momentarily, reverses and moves back away from the home position . This is not what I want:  I want it to stop at the home position and wait for a signal before reversing away.  You say 'turn off the GO signal', but there is no GO signal in the sketch nor is GO mentioned in the book by Simon Monk on commands for  programming Arduino.  I am sure it is obvious to an experienced person but I would like someone to tell me exactly how to modify the DroneBot Workshop sketch (as shown in the excellent video) to make the motor stop. I can then presumably give it a While... instruction to make it move away from home, e.g. by throwing a toggle switch so that a certain pin goes high  until it has taken the right number of steps to reach a stop point near the other end of the leadscrew.

         Please tell me what exactly to write in the code to stop the GO!  I am unfortunately not able to send you a copy of the sketch because I do not know how to do this: I am keying all sketches in myself after doing laborious printings and cut and pastings of screendumps from the video..... but it is the last sketch explained in the DroneBot video on Controlling Stepper Motors with Hall Effect Switches, so easy to find if  you need to.

@bradscopegems WOW, OK, first let's teach you how to copy Bill's sketches. First is to get to the blog/article if you are not already there. If you are only using the video, then click the more and then the blog link is the first one exposed, click it. This is a text version of the video and there is a link there to download Bill's sketch.

GO is just a mythical function I made up. Obviously what you need to do is look at the code to determine where the motor is turned on and made to move in a direction fwd/back and at what speed. Just modify it to be speed 0 based on (??? I don't know how you plan on doing that). I am enclosing some pics of the steps I outlined. 

IMPORTANT: Read the HELP on the right side above the recent posts for stuff like how to include a sketch.

Posted by: @bradscopegems

↑

         Please tell me what exactly to write in the code to stop the GO!  I am unfortunately not able to send you a copy of the sketch because I do not know how to do this: I am keying all sketches in myself after doing laborious printings and cut and pastings of screendumps from the video..... but it is the last sketch explained in the DroneBot video on Controlling Stepper Motors with Hall Effect Switches, so easy to find if  you need to.

Show us the sketch you're using to back up and stop the motor so we can see what you're doing and can tell you how to stop is.

Generally speaking, you have to tell the motor how to move and in what direction. This is often done by using a library to provide the proper signals to the motor while using simple commands in your sketch.

@will     I have spent two hours trying to download the zip file with the the codes from the video on Controlling Stepper Motors with Hall Effect Switches. I can get to a panel called 'Resources' and the Zip file is listed but there is no link to it. So I have had to copy and paste the code for sending a motor to a home position into a Word document to attach it here. The code is the same as the one shown in the video, except that I have set the digital Read for switch A to be 0, since the original setting of 1 was apparently because the Hall effect switch goes low when active. At first, this sketch seemed to be producing reversal of the motor after a brief stop, but I think the code was then not  properly loaded. Now, the code uploads correctly and motor stops dead when the switch is closed ( which is what I wanted) but remains locked hard so the ballscrew cannot be turned by hand. This state persists even if the motor power is turned off and on again, but the motor can be made to move by hand and be restopped if the reset button is pressed on the Arduino. Maybe if I put some sensible code in the loop and sent a signal to one of the unused digital pins I could tell the motor to move away from home? I feel that I am almost there, but it is frustrating to not know enough to complete the loop and be able to tell the motor to drive the carriage to either one end or the other of the ballscrew at any desired time.

    I would be most grateful if you could suggest some code to finish this project.

@bradscopegems Darn, yes, neither the resource link or the code link is working. Maybe Bill @dronebot-workshop can fix it. You can just download the individual sketches if that helps, just hover over the icons on the right to see what they do. Here is a screen grab.

@bradscopegems 

This sketch controls the motor directly by assigning them to HIGH and LOW directly and using the pd variable to control how often the pulses are sent to the motor.Since you now find that it stops as desired, I'll skip answering that part of your question.

The stepper stays 'locked' in place because you're still powering the coils, you'll need to cut power to them to be able to turn the motor by hand.

I would strongly suggest that you switch over to using a library such as AccelStepper to utilize your motor driver. It will handle the motor specific details and you can even use it to cut the power to the stepper.

You'll need to identify the DIR(section) and STEP pins on the driver as well as the ENA(ble) pins and connect them to your MCU. the following parts are for example only and will need to be modified to fit your requirements ...

#include <AccelStepper.h>

... // in declarations

#define LDIR 10
#define LSTEP 11
#define LENA 12

...

AccelStepper stepper(1,LSTEP,LDIR); // Stepper

... // in setup() you'll want to experiment and choose the best fit here

stepper.setSpeed(1500); // Specify speed or stepper
stepper.setMaxSpeed(1500); // Specify speed or stepper
stepper.setAcceleration(50); // Slow changes
stepper.setEnablePin(LENA); Set enable pin
pinMode(LENA,OUTPUT);
stepper.enableOutputs(); // Enable the stepper

... // Here's the call to home the stepper

@will        It is nearly midnight, so I will be off to bed soon, but I wanted to thank you for your very helpful and detailed reply. The focus of the device is not as critical as ordinary microscope focussing: the image is formed by a lens with a focal length of 500mm which focuses the light vertically downwards, and the stepper carriage will, in the IN position carry a first-surface mirror to reflect the light from the lens horizontally on to a fine plastic Fresnel lens in the image plane which will act as a field lens, gathering a lot of the light into the tiny lens of a webcam. The camera, field lens and mirror are fixed relative to each other and will ride together in a box on the carriage. If I can move the box to within a couple of millimeters of the same position every time all will be well. I have sent a diagram of the ray optics of the microscope, which stands more than 1 meter high off the optical table, with the region in which the stepper motor moves the mirror into the beam labelled. The laser light and the fluorescence it excites will not be contributing to this image: it will just show the transmission image formed by a high-power LED in the usual  position underneath the specimen. But this will be good enough to enable us to align the specimen and find the right region to examine by confocal laser scanning. See https://www.centreforbiophotonics.com/ for the kind of images we get. Once again..... many thanks for your kind advice.

@will   Here is the diagram

@bradscopegems 

Do I understand correctly that the mirror is always returned to the same place to focus no matter what is being viewed ? If that's the case then perhaps you'll only need to move the mirror back (i.e. out of the way) and then forward to a fixed position (i.e. in focus).

If that's the case you'd only need to 'home' the device when it's turned on to establish a known starting position and then have a single button. The first push indicates move to (a known constant) focus position and the second push means move back to (a known constant out-of-the-way) clear position.

It's probably better to use a couple of buttons though, one for 'focus' and one for 'clear'. But in either case, if both positions are known and fixed the sketch will be very easy to write.

Good night,

Hi @bradscopegems,

    Thanks for the update. I have just reread (most of) this thread and note you have a time schedule to meet, so this is my suggestion for 'P1 - Prototype 1' ... assuming this works, then you might like to consider how to make it a more 'polished' and 'stand alone' solution, based on P1.

For P1, I assuming you will be able to use it with a PC attached, so that you can do minor modifications to the code - hopefully mainly just adjusting 'magic' numbers, followed by compile and reload onto the Arduino.

The simplest interface I can think would have a few pushbuttons, plus 2 microswitches. Each pushbutton would relate to a fixed command.

I note you say there are two mirror positions:

• OUT ... mirror removed from image light path - accuracy requirement low
• IN ...... mirror in image light path ... accuracy ~1mm (say)

e.g.

• MS1 - microswitch 1 - allows system to move to a 'defined' state - operates automatically when mirror moved to OUT position ... i.e. motor can be stepped towards OUT position, and stopped when switch closes
• MS2 - microswitch 2 - for 'safety' ... operates automatically when mirror goes too far beyond the IN position, but before anything 'bad' happens ... in normal usage, this switch should never be operated.
  • when operated, permit steps toward OUT end, but not towards IN end
• PS1 - Push switch 1 - Move to OUT - If PS1 is operated, Move towards IN, until PS1 is not operated. Then, whilst PS1 is not operated, step towards OUT position
• PS2 - Push switch 2 - Move to IN - First Move to OUT, then move 'n' steps towards IN position
  • 'n' is hard programmed magic number, based on measurements and user experience
  • 'n' would aim to put mirror in the middle of any 'fine adjustment' range
• PS3 - Push switch 3 - Move 'p' steps towards IN end (MS2 will override if operated to prevent problems)
  • 'p' is 'hard programmed' ... expected to be a small number to give a 'fine tweak' to the focus
• PS4 - Push switch 4 - Move 'p' steps towards OUT end (MS1 will override if operated to prevent problems)

 Each of these 6 switches would be connected to a spare Arduinio GPIO input.

I would recommend each switch is connected as shown in the sketch below .. obviously, this switch is shown connected to GPIO 2 ... a different GPIO will be used for each switch.

From a quick glance at the Arduino Uno data, I am guessing you will have used GPIOs 10 and 11 (as per Bill's sketch), and I think GPIO 13 is used for the onboard LED, so avoid 13, leaving the eleven pins '0' through to '9 and '12'. free to choose from, for these switches.(Obviously this varies with different Arduino boards.)

e.g.

1. MS1 - GPIO 0
2. MS2 - GPIO 1
3. PS1  - GPIO 2
4. PS2  - GPIO 3
5. PS3  - GPIO 4
6. PS4  - GPIO 5

I suggest all of the switches are 'Normally Open' ... that is when not being pushed, or the microswitch is not being pushed by the mirror, then there is no conduction between the pins. This is the most common case for push switches, but some push switches are normally closed.

(Normally closed can be used, but the software will need a small change to look for reversed logic levels.)

Microswitches often have 3 pins, labelled NC (Normally connected), C (Common) and NO (Normally Open), In which case use C and NO for the pin connections.

But in all cases, check each switch with a meter that it works as expected before wiring into circuit!!

The resistor and capacitor values are not critical, so (say 0.1 microFarad and 2k2 or 10k Ohms would do), but omitting them altogether will usually lead to trouble! The resistor ensures the voltage going to Arduino is (very near) 5V when the switch is open. The voltage should go to 0V when the switch is closed. The capacitor helps to prevent 'bounce' .. that is the switch opening and closing several times as it is operated.

You will need to note which GPIO pin is connected to which switch, and have a matching line in the Arduino sketch to tell the program, where to look for that incoming signal.

----------

As I mentioned previously, I am assuming this prototype 'P1' will initially require a PC during 'commisioning' to adjust some numbers, recompile the code and upload to the Arduino.

Hence, I assume the code will be arranged, so it is easy to change the magic numbers for:

• the GPIO pin assignments
• 'n' the number of steps of from 'OUT' to 'IN'
• 'p' the number of steps one push of PS3 or PS4 makes to 'tweak' the focus
• stepping speed

----------

I could start to put a sketch together, but it will take me quite a while as I haven't used stepper motors with an Arduino ... I suspect @will & others, can do it in less time than takes me to re-read this note. However, some coordination is needed if it is to come together.

• @bradscopegems - does this look like a sensible hardware design and can you build it? Will it meet your aims?
• @will, sorry to put the spotlight on you, but I know you are much better placed to do a working sketch in next to no time. IF @bradscopegems 'approves' this circuit, would you be willing to provide a working sketch? (Of course, this is only a polite question/request .. if you are busy, etc. please feel free to pass.)

Obviously if there are queries, better ideas, mistakes on my part, etc., please post appropriately.

Best wishes all,

Dave

Hi @will,

  I hope you don't mind me suggesting you could provide a working code.

  My thoughts were generally along the same baseline as yours, but with tweaks.

• Use the 'OUT' microswitch as both a limit, and a starting point, a bit like 3D printers do when they 'wake up'. This means it doesn't matter if it loses power or whatever.
•  
• Move a fixed amount from the OUT position, to the IN position, as you also suggest.
•  
• Use a second 'IN+++' microswitch as a limit at the other end, that normally shouldn't be activated, to stop things being broken - but allow enough space for fine focus tweaking.
•  
• Add two 'focus' tweak switches to move the mirror in small steps a small way .. either side of the main 'IN' position. Obviously the two limit switches should prevent these buttons used beyond the safe range.

Clearly, we don't how many steps each operation will need, or at what speed, or whether they will become microsteps, which will double, quadruple or... the numbers, so I am hoping these parameters can be in small list of constants that @bradscopegems can adjust as required, without having to understand the whole sketch, at least enough to get it working.

Does it make sense to you? Hopefully it isn't much more complicated.

Best wishes, and thanks for any help you can contribute, Dave

@davee 

I have included sample code for all of the activities that I feel confident will be required from the parts of the thread that I read.

From comments made, it seems that the focussing position is rather broad and doesn't require any fussy adjustments. But only the OP can tell us for sure what's required, so I'm waiting for more details and clarification. 

@will   Dear Will,

                           I have made the new connection (to the 'enable' pin) and typed in the code. I have attached a   copy. Unfortunately I could not get it to compile: maybe I have made some mistake, or you were assuming that I would know how to add extra material? But I was just trying to compile what you sent me, having downloaded the AccelStep library. I have finally managed to download the sketch, with both the Arduino text colours and the error messages and have attached it as a word file, which has been given the name cpp, for some reason. I hope it is possible to  open it ...

. I made some minor errors such as putting lower case instead of uppercase but I corrected them and I do not understand the error messages that remain.

@will        The Word files I make from the Arduino sketches behave in a strange way: they may appear without colour at first. Also, I seemed to see the colours only after clicking on 'enable editing' in Word when I tested the file attached to the previous message. But this is the least of my problems....

@bradscopegems 

I'm having some difficulty with internet access right now. I have downloaded your .docx file and I'm going to expand it and fix it. Hopefully it should appear in a while. Sorry for the delay.