Large Stepper Code does not work

@ralphxyz FYI @davee

Mine seems more responsive because I have the speed control placed inside the loop, so each pass through sets the speed before it takes the next step. Dave's code reads the pot, reports it, calculates the inter-step delay and then takes 1000 steps.

The difference is that Dave is trying to make small advances in the sketch to identify where problems may (or do) occur. So his sketch is dedicated to verbose analysis of each component. The sketch I wrote was intended to do something quite different.

If you simply move the two lines of code that read the pot and calculate the new speed into the for loop before the call to take_a_step, you'll find Dave's sketch equally responsive to pot changes.

@davee

Oops, sorry Dave. I didn't mean to cross your post.

Looks like your typing is faster than mine 🙂

Now the original Big Stepper code is running.

The pot speed control works.

The DIR button works.

I guess it was a wiring error that I could not get the program to run.

Thanks again for the help, we were able to step through everything

and now everything runs.

I still like Will's speed control, it is a lot quieter seems to put less strain on the motor.

Here is the newest video, again turn your volume down as it gets loud.

https://photos.app.goo.gl/6wug9xsvPBE4tF3R9

The motor stalls if I try to change directions when the motor is spinning fast.

I sure hope other people are following this thread and getting benefit from it.

Or someone in the future might find it and benefit.

Ralph 

Hi @ralphxyz and @will,

Ralph: Good to see that your motor is working and hopefully you have a way forward. I suggest you look more closely at the "maths" to work out what rotation speed and degree of microstepping you need for your application, in line with your previous posting relating screw threads, etc. Then you will be in a better position to 'tune' your software to give the best operation at that rotation speed range. Bear in mind, a moving motor rotor has inertia, and the effects of this inertia will increase when it is driving the whole system ... it is likely you will want to ramp the speed smoothly, both in accelerating and decelerating. Changing direction at full speed is probably the last thing you will want to do!

Will: Thanks for your comments and support - I am pretty certain your typing is quicker than mine, but the limitations of the forum system, such as only showing new messages when the page is refreshed, means messages 'crossing in the post' is inevitable, especially as I sometimes take a few hours to finish writing one message due to interruptions, distractions, etc. - I just accept I will accidentally do it to others and they will accidentally do it to me - no harm done either way I hope!

And thanks for reinforcing my own comments about my code .. its aims were to check out the hardware wiring, which I had as prime suspect from the beginning, and to provide some basic functions which could be used in the future to check out other problems and ideas ... it was never intended to be used in the final system, which I suspect will need a good deal more sophistication to give a 'smooth and efficient ride'.

-----------------

A verbal ramble:

It is sometimes possible to take a hardware system of untested design and construction, and a corresponding software system, of similar untested design and construction, and 'integrate' them successfully. But if both the hardware and software are 'untried', the result can easily be total frustration. In a  'larger' company environment, this approach can result in the software engineers blaming the hardware engineers and the hardware engineers blaming the software engineers, with neither group able to fix the problem. The crowning glory in the company situation is when one or more 'managers' start asserting claims that it 'must be a software problem' or 'must be a hardware problem', typically with no evidence and even less technical comprehension, in an attempt to get someone else to be responsible for fixing it.

....

At this point, my approach is to find/create some very simple software, and possibly simple hardware as well, which tests a particular aspect of the hardware. This process may be repeated several times, until I am confident the hardware is able to support the 'real' software to the extent of showing 'signs of life'. Then introducing the 'real' software, any immediate problems should be software based, and debugging it is likely to be required, knowing on the basis of evidence, that the immediate problems are not hardware.

Note that software to test the hardware need not be the same as will be used in the final system ... in fact it is often better if it is different, as otherwise any problems with the 'real' software may be transferred into the test system, and the confusion continues.

Whilst testing the 'real' software, new limitations and problems of the hardware may become apparent, and the procedure may need to 'loop' a number of times, but it will at least be guided by evidence.

Of course, this approach is not a rigid procedural model, and it must be modified as new evidence comes to light, but it has proved useful and effective on a number of occasions over the last few decades... 

When we are working on a project at home, we may be the hardware, software, testing,...etc teams all in one, but I think the basic approach still applies. And putting pressure on the project manager will certainly not help!

---------------

Good luck and take care to you both. Dave

What a interesting thread, like I said I hope others see it.

Now how would I turn my system On/Off using a switch?

I could just kill the motor feed.

I have seen some examples of using the ENA +/-, but none of them used a switch.

If I switched the Step pulse that would stop operation but the motor coils would be locked

up (if the motor was still energized). I need the motor to be able to turn by hand.

For my lathe I would like to still be able to position the Z and X manually.

Thanks DaveE, " I suggest you look more closely at the "maths" to work out what rotation speed and degree of microstepping you need for your application, "  my mind fries just with the thought to say nothing about actually doing it. Luckily my daughter is a Excel whiz so maybe she will help me.

Ralph

@ralphxyz 

While it is certainly possible to use a switch to enable and disable the motor via ENA (+ or -), the SAFEST way is to completely remove the power any time you need to adjust anything by hand. Preferably with a switch that is not within easy reach of the equipment you're using.

So Will, you are saying to switch the power (VCC) to the motor?

Should I worry/think about disabling the Arduino also?

Ralph

@ralphxyz 

I don't think you need to worry about the Arduino, it's the motor that has the potential to damage you if it starts moving. As long as it's unpowered, you're safe to reach into its range, regardless of what the Arduino thinks about it.

Note, however, that if you reposition anything by hand, you'll lose whatever implicit positioning data remains on the Arduino. So far, you've displayed no homing function, so it appears that you're not interested in where the stepper is.

Hi Will thanks. 

re: "So far, you've displayed no homing function" I haven't had time to even think about "homing" or anything beyond getting the motor to run, change direction and speed control.

Now thanks to you and DaveE I have that. I can start to think of other things.

One of the things I might be thinking of is using a rotary encoder for speed display and position sensing.

I will be needing more help on using the rotary encoder.

Ralph

@ralphxyz 

Why would you need a rotary encoder for speed when you're using a stepper motor ? Rotary speed is just a function of steps/second relative to steps per revolution.

So 500 steps/second with 1700 steps/revolution over 60 seconds is 500/1700 = 560*5/17 = 17.647 RPM

I do not know how to capture the steps.

And how do do the timer. 

The programs that I have downloaded from the net don't work.

Remember I am not a programmer.

Ralph

@ralphxyz FYI @davee

You are setting the length of the pulses to the stepper with the pot. It generates a time which is the length of time that the pulse is applied ON to the stepper and then the time that the pulse is OFF. So the time for each step is twice the time for each ON/Off period.

Dave clearly states, in the calculation of halfStepUS from potval

convert pot val to a Half Step time in microseconds

So the number of steps per second is 1/(2*stepTime_in_ms). For instance, if the halfStepUS calculated is 500 us, then one complete step takes 2*.000500 seconds or .001000 seconds (i.e. one millisecond) so the motor speed = 1 second/(.001) = 1000 steps per second.

if the halfStepUS calculated is 25 uS (i.e. .000025 sec) then 1 step takes 2*25 = 50 uS (i.e. .000050 sec) so we can get 1sec/.00050uS = 20000 steps per second.

Posted by: @ralphxyz

The programs that I have downloaded from the net don't work.

Didn't you say above that Bill's sketch was now running ?

I almost understand what you are saying.

My driver is set to 200 which I assume means 200 steps per revolution.

So with 2*25 = 50 uS (i.e. .000050 sec) so we can get 1sec/.00050uS = 20000 steps per second.

Is that 100 revs per second at 200 steps per rev or 6,000 rpm?

Then what happens if I set the driver to microstep 32 which according to the driver is

6400 pulses per rev.

Posted by: @ralphxyz FYI @davee

My driver is set to 200 which I assume means 200 steps per revolution.So with 2*25 = 50 uS (i.e. .000050 sec) so we can get 1sec/.00050uS = 20000 steps per second.

I doubt that you can achieve that speed, especially in view of Dave's earlier remarks on the on/off time ratios required at higher speeds.

Is that 100 revs per second at 200 steps per rev or 6,000 rpm?

It's steps per second, just like it sounds. If you want to turn it into RPM, then you need to multiply by 60 seconds (i.e. one minute) and divide by steps/revolution

60*20000/200 = 1200000/200 (steps/minute)/(steps/rev) = 6000 RPM (at 200 steps/rev)

Then what happens if I set the driver to microstep 32 which according to the driver is

6400 pulses per rev.

Then if you divide steps/minute by steps/revolution you get 

1200000/6400 = 187.5 RPM (RPM at 6400 steps/rev)