Home
JAQForum Ver 20.06
Log In or Join  
Active Topics
Local Time 10:00 29 Mar 2024 Privacy Policy
Jump to

Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.

Forum Index : Microcontroller and PC projects : STEP Command

     Page 2 of 2    
Author Message
KeepIS

Guru

Joined: 13/10/2014
Location: Australia
Posts: 1336
Posted: 07:09am 19 Aug 2018
Copy link to clipboard 
Print this post

My 2c worth again - this request list appears to heading torwards a basic stepper CNC application?

Going back to basics, one thing to be mindful of when using interrupts to interface / control a frequency generator (as opposed to using hardware PWM) while reading positional data, if the procedure generates interrupts while sending pulse signals during the read cycles, it will render reading "SOME" of the typical Digital slide Scales useless, like the ones I'm using on the MM Plus. This was a major headache for me when writing the two 9 kHz sync clock and decode procedures for reading two Digital scales. Fortunately PIC hardware PWM does not cause that problem. I had to implement code to abort decoded data that had its sync clock interrupted in any way by MM background ISRs that were not under under my control, touch was an SOB but controllable. This also forced me to implement detecting changes in position greater then the current scale speed would generate. Maybe I'm misunderstanding the use of interrupts in the low level frequency generator that was proposed.

For this cutting machine using closed loop positional feedback, PWM works fine, I'm only ramping up to 6 Khz, ramp is automatically variable and determined by position from target, start ramp speed and maximum speed are selected in setup, I'm shifting a heavy 2.2kw Spindle motor and a wide heavy gantry, but I'm not doing fast CNC cutting so I'm not hitting processor speed limitations.

As you know, most of the tasks of reading a position sensor, allowing for emergency stop, aborting PWM drive (or anything that replaces it) are simple to do in MM basic code, including monitoring a hardware emergency stop button and halting / aborting all control data to the Stepper controller. Touch plate implementation is also simple, it just appears to me to be diverging away from a reliable simple method of generating an accurate number of background pulses that some stepper application need.

Perhaps I'm totally wrong? Maybe two things are needed? A simple low level accurate background pulse generator, and a CNC type wrapper application.

Not trying to be d#&% here, just saying there are many exciting uses for automated mechanical equipment using an MM and trying to cover them all may be difficult.

Mike.
It's all too hard.
Mike.
 
Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3163
Posted: 11:56am 19 Aug 2018
Copy link to clipboard 
Print this post

I agree with Azure, KeepIS and others when they are say that what we need to implement is just the primitive function for pulsing the output and keeping count of the number of steps. MMBasic is a programming language after all and things like detecting limit switches, toggling the direction signal, etc can easily be done in BASIC and should.

The STEPPER command should be as simple as possible and just do the things that cannot be easily done in a BASIC program.

Geoff
Geoff Graham - http://geoffg.net
 
sawasdee01
Newbie

Joined: 23/12/2016
Location: United Kingdom
Posts: 33
Posted: 02:22pm 19 Aug 2018
Copy link to clipboard 
Print this post

In the 1980s I worked for a robotics company and we always used rotary optical encoders with steppers. Many would probably say that encoders are not required with steppers, but in robotics you encounter a lot of issues with sudden variations in inertia, load mass, etc.

At the time the name of the game was how to make dual or triple axis interpolation work fast enough on sub 8 Mhz 16 bit processors.

I guess that the point that I am trying to make, is that there may be quite a few layers to the stepper motor thing and some of them might require lots of high speed, real time processor power.

This neatly bring me onto a thought that leads on from Geoff's post, above - the thing that made home computers like the BBC micro and similar machines successful with many Researchers / Makers / Lab workers, was that you could drop into assembly 'in line' with the ASM command. This allowed users to very easily bash together subroutines like STEPPER().

Whilst most would probably not wish for the return of the ASM command in MMBASIC - I wonder if there was a super easy to use method for 'wrapping' C rather than the existing C Function approach, we could drop a lot of the temperature sensor, pwm and other commands and keep MMBASIC more pure.

Sure, the existing CFunctions approach seem to be pretty easy for functions like a=add(b,c), but stuff like I2C, Uarts, Spi, Gpio, PIC32 timers, etc, where you want to 'grab hold' of existing MMBASIC resources, deal with interrupts etc seem to be more difficult.

In turn, a super simple C wrapper approach may encourage the development of a common, shared library for all sorts of hardware devices; steppers, sensors, touch screens, etc etc.

I suspect that this would capture the imagination of quite a few in the Maker market. It would also probably make the job of migrating MMBASIC onto different platforms slightly easier.

I used C with the PIC32 for a few years before I discovered MMBASIC and there is no doubt that MMBASIC brings vast improvements to development ease and speed, but I do feel that the raw magic of the much maligned but very wonderful PIC32 is slightly lost.

The ability to easily 'mix and match' would be mind blowing.

Sawasdee









 
geeken
Newbie

Joined: 13/01/2018
Location: United States
Posts: 20
Posted: 12:18am 20 Aug 2018
Copy link to clipboard 
Print this post

  Geoffg said   I agree with Azure, KeepIS and others when they are say that what we need to implement is just the primitive function for pulsing the output and keeping count of the number of steps. MMBasic is a programming language after all and things like detecting limit switches, toggling the direction signal, etc can easily be done in BASIC and should.

The STEPPER command should be as simple as possible and just do the things that cannot be easily done in a BASIC program.

Geoff


Geoff : Absolutely agree - keep it simple.

This obviously applies to these proposed, new Stepper commands because the existing MMBASIC ALREADY runs multiple steppers just fine, where it's not expected to run too fast. Personally I am OK with it being left as it is, as it will cause work in the future to upgrade commands now :)

However, in the interests of progress, certain combinations of functions will make it control Steppers faster, more simply & more professionally, in line with typical Industrial control equipment.

I suggest getting something up as a Beta for group testing before finalizing it, as we could get stuck with something thats less than what it could be. Temporary does tend to become Permanent, unfortunately - - -

* *
 
Volhout
Guru

Joined: 05/03/2018
Location: Netherlands
Posts: 3422
Posted: 11:43am 21 Aug 2018
Copy link to clipboard 
Print this post

Dear Geoff,

Thanks for proposing this stepper support in MMbasic.
I hope I am not duplicating things said before, but here are my 5 cents.

In general the MM will not drive the servo, but it will control the servo driver IC.
Therefore you have to look into driver IC's to see what control lines they use, and support that into the MMBasic command.

AFAIK there are basically 2 types

1/ the ones that are controlled through STEP and DIRECTION pins, and do all the state handling internal. These are typically fixed in either full step, or half step, or microstepping mode. These are typically used in Arduino type of control boards. And what I would target for MMBasic.
2/ The ones that are basically H bridges, and need to be driven with multiple lines. Here the state logic must be handled by the microcontroller. Also the stepping mode is completely under control of the microcontroller. This typically requires more pins to control the driver IC but also has advantages, especially in high performance apllications. (i.e. if you want to drive a stepper motor past it's resonance frequency, you can dynamically change from half step to full step mode around the resonance point).

Since you want the process to run in the background there is one thing you should evaluate. It may be and idea to include the direction pin into the command. This would simplify, and smooth out, motor control if you change direction in cases where you change direction before the end point is reached (not typical for CNC applications, but invaluable for in example IEEE Micromouse contest applications).

About acceleration: in my experience a percentage would be fine, but a linear function is not typical. There is (below the resonance point of the motor) a non linear function, like
step time is 50ms, 30ms, 20ms, 16ms, 13ms, 11ms, 10ms, .........5.2ms, 5msec.
this curve is depending on the mass, and the power of the motor, but generally behaves as a first order function if you use a PWM motor controller. For none PWM motor controllers (like the old ULN5804) a first order function can still be used at expense of acceleration performance.

For acceleration you would typically have a "initial step time / first step percentage" value, and a "number fo steps to reach max velocity" value).
In above example that could be 10, 100 (first step is 10x longer than the max speed, and the max speed is reached in 100 steps).

I have no experience in CNC, but my micromouse steppers used the same acceleration curve as deceleration curve. My reasoning behind that was that the mass of the micromouse is the same (air friction not important, no up-hill or down-hill), and the energy I put in the motor is constant (PWM driver) accelrating of decellerating.
Of coarse this may be different if you control an elevator.....

Last, you must decide what number of motors you want to control. For micromouse or robots it is typically 2. For CNC minimal 2 but typically 3 or 4.

These are my 5 cents.

Volhout

Edited by Volhout 2018-08-22
PicomiteVGA PETSCII ROBOTS
 
Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3163
Posted: 12:02pm 21 Aug 2018
Copy link to clipboard 
Print this post

Thanks Volhout, a great 5 cents worth.

Yes, I am thinking that the Micromite will work with controllers that are controlled through STEP and DIRECTION pins.

Your sort of applications (micromouse or robots) was what I was trying to target. Thanks particularly for your notes on specifying acceleration. More facts to consider.
Geoff Graham - http://geoffg.net
 
lew247

Guru

Joined: 23/12/2015
Location: United Kingdom
Posts: 1676
Posted: 08:51pm 03 Mar 2021
Copy link to clipboard 
Print this post

Did anything every come of this?

I need to control a small stepper motor that supports microstepping via the AX1201728SG/VID6606 stepper motor driver
the AX1201728SG/VID6606 uses microstepping to provide smoother positioning - 12 steps per degree rather than 3 with only 3 pins to control it from the mm

I can't understand if it needs simple on/off switching per pin, or pulse, or pwn or if there is a step command that i can't find in any of the manuals I've read several times

This is the manual for the driver ic
 
Tinine
Guru

Joined: 30/03/2016
Location: United Kingdom
Posts: 1646
Posted: 11:00pm 03 Mar 2021
Copy link to clipboard 
Print this post

Perfect application for the Prop1 (the older model)

1) Use a cog (CPU) to communicate with the MM (UART)

2) Use a cog to dish out the pulses for as many channels as required, no interrupts required

3) Optionally read encoders to verify positioning

3) Optionally implement a PID for each axis to drive far superior servo motors

3) Handle high speed I/O, even sync'd to a specific single pulse or encoder count, no interrupts required

4) PropBasic is friendly to MMBASIC programmers and produces ASM code.

5) lots of spare cogs (CPUs) for flashing lights or whatever  

6) Did I mention no interrupts required or even supported?

I promised to post some stuff, a while ago but still in the muck and bullets with workload.
 
Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3163
Posted: 08:47am 04 Mar 2021
Copy link to clipboard 
Print this post

  lew247 said  Did anything every come of this?

No, sorry not yet.  It is still on the ToDo list if that helps.

Geoff
Geoff Graham - http://geoffg.net
 
circuit
Senior Member

Joined: 10/01/2016
Location: United Kingdom
Posts: 216
Posted: 09:42am 04 Mar 2021
Copy link to clipboard 
Print this post

  Geoffg said  
  lew247 said  Did anything every come of this?

No, sorry not yet.  It is still on the ToDo list if that helps.

Geoff


Gosh, I missed the original thread on this subject. This is a fabulous idea and I would really welcome it as I make great use of stepper motors.  Being able to assign the parameters that you originally suggested and then letting the thing carry these out as a background operation would be excellent!  The sooner that this comes to the top of the "To Do" list the better!
 
vegipete

Guru

Joined: 29/01/2013
Location: Canada
Posts: 1081
Posted: 06:50pm 04 Mar 2021
Copy link to clipboard 
Print this post

  lew247 said  I can't understand if it needs simple on/off switching per pin, or pulse, or pwn or if there is a step command that i can't find in any of the manuals I've read several times

My read of the manual suggests the chip holds 4 independent but otherwise normal stepper drivers. A motor moves 1 step (whatever the size of the step is) for each rising edge of the f(scx) pin. The level on the CW/CCW pin determines which direction. You will have to count the pulses if you want positional control.

2160 pulses (rising edges) on the f(scx) pin with DIR pin low should turn the motor 180 degrees in a direction determined by the wiring from the chip to the motor. The same number of pulses with the DIR pin high should reverse the motor exactly back to the starting point.

A m-mite at 3.3 volts might just be able to reliably run the chip, given that the minimum high level input voltage is 3.15 volts.
Visit Vegipete's *Mite Library for cool programs.
 
TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 5867
Posted: 09:54pm 04 Mar 2021
Copy link to clipboard 
Print this post

  vegipete said  
A m-mite at 3.3 volts might just be able to reliably run the chip, given that the minimum high level input voltage is 3.15 volts.

Open collector on a 5V tolerant pin and an external pullup to 5V will be safer.

Jim
VK7JH
MMedit   MMBasic Help
 
Volhout
Guru

Joined: 05/03/2018
Location: Netherlands
Posts: 3422
Posted: 09:45am 05 Mar 2021
Copy link to clipboard 
Print this post

As it says on the datasheet, this is a QUAD stepper motor driver for dashboard gauges. It can deliver only 5V 35mA max at the output pins. This is not suited for normal stepper motors that typically need 100x more power.
PicomiteVGA PETSCII ROBOTS
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8516
Posted: 10:10am 05 Mar 2021
Copy link to clipboard 
Print this post

It is easy to do a CFunction to do a background step command with direction, number of steps, maximum step rate  and programmable acceleration and deceleration (steps/s/s). The difficult bit is coordinating more than one stepper motor to carry out coordinated moves as in a 3D printer or CNC machine
 
circuit
Senior Member

Joined: 10/01/2016
Location: United Kingdom
Posts: 216
Posted: 01:37pm 05 Mar 2021
Copy link to clipboard 
Print this post

  matherp said  It is easy to do a CFunction to do a background step command with direction, number of steps, maximum step rate  and programmable acceleration and deceleration (steps/s/s). The difficult bit is coordinating more than one stepper motor to carry out coordinated moves as in a 3D printer or CNC machine


Peter, I fully understand your point, nevertheless, I would really find a number of uses for the C function that you describe; especially (but not exclusively) if the step command could be delivered to two or more output pins - uncoordinated.  Even just one would find a use; stepper motors have a lot more application range than just 3D printers/CNC machines.  For example, a linear camera rail could be set up most elegantly with such a command.  

I do not have the skills to write such a C function but I can certainly build a linear camera rail - one of the projects on my "to do" list! With the massive heap of programming that you are involved with constantly, if there was small slot to write such an "easy to do" (for you!) C function I, for one, would be most appreciative.
Edited 2021-03-05 23:38 by circuit
 
Volhout
Guru

Joined: 05/03/2018
Location: Netherlands
Posts: 3422
Posted: 01:57pm 05 Mar 2021
Copy link to clipboard 
Print this post

Peter,

I am not sure how professional the micromite users want the code to be but for my micromouse (2 stepper motors) I could get very smooth behaviour using a 1ms timer step size.
I used a 1ms hardware timer interrupt, and in the interrupt routine I created software timers for each motor by counting the interrupts.
My acceleration curves went from 150 (ms) for the time between the first 2 steps, up to 5 ms (200 steps/second) at full speed (on a 4MHz pic16F84). In my micromice I also did the stepper logic in the same interrupt through a LUT. But that is not needed if you only need to provide a clock and direction.  

Maybe something similar could be sufficient.

Volhout
PicomiteVGA PETSCII ROBOTS
 
lew247

Guru

Joined: 23/12/2015
Location: United Kingdom
Posts: 1676
Posted: 03:48pm 05 Mar 2021
Copy link to clipboard 
Print this post

  vegipete said  
My read of the manual suggests the chip holds 4 independent but otherwise normal stepper drivers.
A motor moves 1 step (whatever the size of the step is) for each rising edge of the f(scx) pin. The level on the CW/CCW pin determines which direction. You will have to count the pulses if you want positional control.

2160 pulses (rising edges) on the f(scx) pin with DIR pin low should turn the motor 180 degrees in a direction determined by the wiring from the chip to the motor. The same number of pulses with the DIR pin high should reverse the motor exactly back to the starting point.
Thanks  
That explained what I wasn't certain about perfectly
 
MustardMan

Senior Member

Joined: 30/08/2019
Location: Australia
Posts: 175
Posted: 10:44pm 13 Mar 2021
Copy link to clipboard 
Print this post

One of the questions Geoff had right back at the start was how to define acc/dec... How about number of steps?

STEP channel, 50, 1000, 200, Done

Acc/dec is specified as 50 wherein it linearly interpolates from zero to 1000 steps/sec, reverse at the other end, for a total of 200 steps.

Sequence becomes: 50 steps ramp up, 100 steps at 1000 SPS, 50 steps ramp down.



The other interesting point raised (by matherp) is how to stack up a list of actions so they smoothly follow each other.

I suggest that one or maybe two be stacked up, otherwise where do you stop... 20 as matherp suggested? 100? 1000?

It could be left up to the interrupt to push the next command onto that stack.

STEP chA, acc1, speed1, steps ' Start moving
STEP chA, acc2, speed2, steps ' This command gets stacked
STEP chA, acc3, speed3, steps, intA ' Another stacked, but now 'int' is defined...

and from there "intA" adds one to the stack every time an interrupt occurs.

However, what happens if I execute too many STEP commands with no 'int'? At some stage they will have to become blocking, and what happens then?


The other thing is how to get two (or more) channels operating simultaneously. Say I want to drive at 22.5 degrees (to make it more interesting than 45 degrees)...
STEP chX, acc, speed, 1000
STEP chY, acc/2, speed/2, 500

How would I make these run in sync without chX starting slightly sooner?

Cheers,
 
     Page 2 of 2    
Print this page


To reply to this topic, you need to log in.

© JAQ Software 2024