From your code, are you saying that spin loops are faster than code that uses a counter? This is how I have interpreted what you said.
By the way, thanks for your input, I have been reading it.
Bruce
No, using the counter IS faster because less work is being done in the spin loop. My main point is that spin can be fast if much of the work is done outside of the fastest loop. The last example I gave was from a quick PWM generator i hacked up to play with DC-DC converters. It uses a counter and only runs fast because the repeat loop has 3 statements in it. I also get full 0-100% duty cycle control with that loop because the counter runs independently from the repeat loop.
It would also be useful to look into a more feasible command trajectory. While your commanded acceleration is bounded (good!), the commanded acceleration increases with increasing pulse rate. (because you're linearly ramping pulse period not frequency) This is exactly opposite to the torque/speed curve of the motor and will limit the maximum speed for this command sequence. (this may require a table based solution to operate at the maximum feasible acceleration, but it is likely to be MUCH faster)
the code I posted above uses a table as it uses an array.
In some applications I have seen a quadratic curve for the step-pulse-frequency in the ramp.
Before starting pulse-creation the array is initialised with the calculated timevalues.
So for step-pulse-creation you simply access the values through an array-index
VAR
long ramp[100]
PUB
repeat idx from 0 to 99
...
...ramp[idx]...
take a second look onto my code-example above
it uses exact this programming technique
My favorite way of doing this is summarized in the code snip-it below ...
Hey you're right. I forgot that SPIN waitcnt behaves similar to the PASM waitcnt. Of course PASM waitcnt can do the update adjustment automatically which is very valuable when dealing with sub-microsecond resolution delays.
I came armed today with a few more facts. I don't know why I did not try it the other day when I wrote it, but I tried it today and got quite a bit more speed. Here is a similiar piece of code that got more speed from my stepper motors. It is just bare bones without any of the ramping.
CON
_clkmode = xtal1 + pll16x ' System clock → 80 MHz
_xinfreq = 5_000_000
PUB Main | nCounterTime, minPulseWidth
minPulseWidth := CLKFREQ / 1_000_000
nCounterTime := CNT
CTRA[30..26] := %00100 ' Configure Counter A to NCO
CTRA[5..0] := 3
FRQA := 1
DIRA[3]~~
repeat 1_000_000
nCounterTime += 7_000 'At 6_000 it fails
PHSA := -minPulseWidth
WAITCNT(nCounterTime)
This code results in 5.65 (rounded) revolutions per second. 1,000,000 microsteps at at a 10 to 1 resolution equates to 500 revolutions in 88.5 seconds (rounded).
That may sound impressive to some of you, but to me it is not. I still believe that these motors and drivers are capable of so much more. As an aide to help me into convincing you, I have attached all pertinent documentation into this single post.
In addition to the provided documentation, I also spoke with Technical Support at Applied Motion Products earlier today. And the person I spoke with, who is quite knowledgeable, told me that with 50VDC in combination with the G251's, I should have no problem getting 40 revs per second, however to maintain some torque and avoid resonance, especially for the HT23-400 motors, I should not try to go any faster than 20 revs per second.
If you're going to run your motors so fast, why do you need microsteps at the highest speed? Is there a way to switch to full steps when you want the highest speed?
I really did not want microstep drives, but I could not resist the price, they were on sale with a quantity discount. I got 15 drives for $49 each. I have wondered that same question about getting full steps several times, now that you got me thinking of it again, I am going to call the manufacture.
Ok ... the problem is the time when you read the CNT. Too many instructions in between reading the count and calculating the first value to wait for. The time already has been passed before you reach the waitcnt instruction.
Changes:
The period of the pulses is 25us if you want 40000 microsteps per second. So, there is no good reason to use the minimum possible pulsewidth, so I doubled that value (dividing by 500_000 instead of by 1_000_000). The negation is also done in the initialization, as in the loop each SPIN bytecode instruction wastes time. Negating outside of the loop saves one instruction in each loop-cycle.
The nCounterTime is initialized as the last instruction of the initialization-phase to avoid the problem described in the beginning of my post.
The increment has been changed from 7_000 to 2_000, which is the value needed to get the 25us period.
But this is on the edge of what SPIN can do. For each instruction added inside of the loop you'll have to increase the increment again. So, ramping can only be done at lower speeds. Exchanging the fixed loop-count 1_000_000 by a variable will already be to slow for the 2_000 increment.
I genuinely appreciate your effort in trying to resolve my problem, however that did not work either.
I called Gecko Drive today, and the tech that I spoke with told me that improper linear ramping was probably my biggest problem, and that my maximum ramp rate should be between 4-5 revolutions per second. I am also convinced, that the programming bloat in the original function on page 1, was definitely slowing things down, otherwise I would not have been able to reach 7_000 by removing the bloat. I will be creating ramping tables as suggested by Lawson, and as per the drive manufacturers recommendations.
With that all being said, I do have a couple more questions, which are:
What is the fastest pulse train that can be achieved with counters in NCO mode in Spin?
What is the fastest pulse train that can be achieved with counters in NCO mode in PASM?
Where do I find good information pertaining to PASM?
Bruce: kuroneko is the expert with the counters so hopefully he will answer 1 & 2.
As for pasm. Having programmed in assembler for 40 years, I taught myself pasm. I understand there is quite a lot of info available from the Parallax Home page links. There is also some on the propeller wiki pages. Have a look at the manual - pasm section (in the help section of proptool) - take a look at the pasm instructions.
There are a few things to remember (which are different to most other micros)...
1. Each instruction has two operands - a source and a destination (there are no registers as such). So the instruction takes a source value and operates on it, often with the destination value as well, and stores the results back in the destination. e.g. ADD adds the source value to the destination value and stores the result back in the destination.
2. Each instruction has optional bits "cccc" which are conditional execution bits depending on the "z"ero and "c"arry flags. If the condition is not met, the instruction becomes a "nop" (no operation i.e. nothing happens).
3. Each instruction has optional bits "zcri". "z" determines if the "z"ero flag is changed as a result of this instruction. Likewise for "c"arry. "r" defines if the result will be written back to the destination - so you can add two values and set the z & c flags without actually writing the result. 'i" defines if the source is a literal value (limit of 0-511 because it is only 9 bits) rather than pointing to a cog memory location.
4. There are a small number of instructions, and each instruction is 32bits.
All this is detailed in the manual.
Then I suggest taking a look at some of the simpler OBEX code examples.
To be perfectly honest, I had no desire to learn a new programming language at this time, but I do want my steppers to run the best they can within given restraints. I truly believe they are capable of so much more, however, with the two machines that I am currently working on, they do not require a lot of movement, so I real don't have the headspace to allow for proper ramping. I am beginning to think I should have designed around servos instead. My other CNC will definitely benefit from any effort that I put forth at this time, because it requires a lot of movement.
I suppose I will gather PASM information where and when I can, and try to learn it when I have time available.
Anyhow thanks again for all of your responses, you seem to be a very nice guy.
With that all being said, I do have a couple more questions, which are:
What is the fastest pulse train that can be achieved with counters in NCO mode in Spin?
What is the fastest pulse train that can be achieved with counters in NCO mode in PASM?
Since Cluso99 introduced me so nicely I can't possibly resist. Anyway, I would've answered earlier but wasn't quite sure what you're after. Unmanaged, an NCO (regardless whether used from SPIN or PASM) can manage clkfreq/2 (PLL mode can go up to clkfreq). If the output needs any form of customisation then it really depends on what they are and only then language becomes an issue. HTH
I truly appreciate your response, especially after Cluso99 vouched for you
A lot of people have been telling me that I will probably have to go to PASM to get the speed I want for my stepper motors. I am still not sure if it is necessary for me to learn PASM to get this speed. Can you please advise me.
idea that long variable names mean self-documenting code.
I agree with that Jon, however if you looked at the method within the OBEX, you would see that I truly tried to document the method the very best I could with the limited knowledge that I had with counters and clock frequencies. I personally use descriptive variables for my own benefit. I find it takes me less time to decipher my own code if there is ever a need
I noticed that you must have edited your last post, because it is now gone. I now know for a fact that the original driver will spin steppers up to 5.6 revs per sec. I am sure that code will be good enough for some people, but I have decided to make a better driver. I talked with the manufacturer of my motors and also the manufacture of my stepper drives today. My motors are fully capable of 40 revs per second, however, the motor manufacture suggested limiting it to 15-20 revs per second due to torque and renosance issues. I can live with that. To achieve 20 revs per second I need a total of 40,000 pulses per second, but there is a catch. The stepper driver manufacturer suggests a ramping speed of 4-5 revs per second and I can settle for a mid-point of 4.5. Which means that during cycles of every second I need to linearly accelerate or decelerate, depending on whether it is a ramp up or ramp down, by 9,000 pulses. The code model of Version 4, should be very close in mathmatical substance to be able to achieve this. However, as you pointed out, there is program bloat and the time probably runs out and causes me problems. It was suggested by Lawson to obtain my ramping and running values from tables. I believe this was a very good suggestion, and I think the code will execute much faster. For each unit produced, each motor has a specified number of steps that it must make, and this will never change during a production run. However it will change, according to the size of the unit being produced during a production run. The are six sizes of my product that I will be producing. A good algorithim would be nice to make life easier, and I believe V4 has a fairly decent one, but ultimately I believe it will only slow things down. Considering what Kuroneko said, I should be capable of creating the 40,000 pulses with an NCO counter. That should not be a problem unless I bloat the function. I now believe it is all in the ramping and acquiring the data from tables, but I could be wrong.
I always appreciate your response Jon, and I hope I did not bore you to tears
Ok, what I meant with "this is working for me" means that this piece of code did produce the 40kHz signal that you'd need for your maximum speed. Of course this piece of code won't drive your motor, as the motor needs the ramping up.
More important is the conclusion "use PASM". This working code shows that you are operating on the edge of what SPIN can do. Even a simple "-" (negation) as you used it in your code results in code that won't work any longer. If you still want to use SPIN your max. rounds per second must be slower. For each SPIN bytecode instruction added to the loop you have to increase the increment (2_000) by something around 200.
So, if you want to count pulses, the speed decreases. If you want to do ramping - even if it's with table support - the speed decreases.
If I understand your previous post correctly, you only have fixed numbers of steps?! So the loop would really look like
repeat 1_000_000
...
Is that right? Because a possible solution then could be to do the ramping with another COG.
Instead of
nCounterTime += 2_000
you'd say
nCounterTime += nCounterDelta
and nCounterDelta is modified by the other COG. This means that the ramping up/down piece of code is executed by a separate COG adding it's execution time to your loop. If your ramp up time is constant and the ramp down time is constant and the total number of steps is constant as well (per product) then you'll find a constant wait time that can be used between ramp up and ramp down.
In a company that I worked for some years ago the ramping from zero up to 2 kHz was done within 100 steps.
That is pretty fast. The delay-times between the accelartion (ramping up) and decelaration (=ramping down) was done with a quadratic function.
For each different kind of machine the parameters of this quadratic function was optimised through practical tests.
If you want to go up to 40kHz I estimate you would need 300 to 500 steps. Would this be fast enough?
Do you use a chopper-circuit to supply the coils of the stepper-motors?
This means the supply-voltage is much higher than the nominal voltage on the spec-lable of the stepper-motor
The chopper-circuit regulates the current down to the right value (by doing PWM). But through the high supply-voltage the magnetic fields rise and reverse much faster.
So a higher torque results out of that.
I don't think you can get to 40_000 pulses per second with Spin -- and to check my theory I wrote this little method:
pri stepper(p, spntr, fpntr) | t ' launch with cognew
'' Start stepper pulsing in separate cog
'' -- p is output pin
'' -- spntr is hub address of steps variable (long)
'' -- fpntr is hub address of frequency ticks (long)
'' * max freq is ~25kHz
ctra[30..26] := %00100 ' PWM / NCO
ctra[5..0] := p ' set pin
phsa := 0 ' start off
frqa := 1 ' setup frq for pwm
dira[p] := 1 ' make pin an output
t := cnt
repeat
if (long[spntr]-- > 0) ' while steps left
phsa := -PULSE_TIX ' create step pulse
else
phsa := 0 ' else disable output
waitcnt(t += long[fpntr]) ' at current frequency
This is setup so that you can pass the pin, and pointers to your steps and frequency control variables; this minimizes the time spent inside the loop and allows you to control steps and frequency (expressed in cnt ticks) externally. Note that this is started with cognew() so that the driver is always running. All you have to do is set the frequency and steps count (you should do it in that order).
In testing I found the highest reliable speed is 25kHz -- and, again, this code lets you change the step count and speed on-the-fly (which does slow it down a bit). The PASM version (see below) can easily output to 100kHz and still allow on-the-fly changes to step count and timing.
Sooner or later, I will be able to understand all this clock lingo, which will enable me to better explain myself. Last night I came to the realization that I will never get top end speed out of the motors on these two particular CNC's, because the movements are just to short to ramp the motors up properly. I think that a low cycle of 7_000 is the best that I can hope for in this particular situation. It saddens me greatly, but I believe it is true.
I have another CNC, which is a Printed Circuit Board drilling machine, which will certainly benefit from the discussions in this post, more so than the two machines that I am currently working on, because the travel distances are much greater, and therefore I can achieve a proper ramping profile.
If I understand your previous post correctly, you only have fixed numbers of steps?! So the loop would really look like ->repeat 1_000_000
Yes, you are correct, every step, on every motor, on every machine, ultimately has a fixed number of steps that it must make.
Wire Bending CNC
The amount of steps for every motor is predetermined before run time. There are program variables that store the required number of steps for each motor and for each part of the manufacturing process.
Packaging CNC
The amount of steps for every motor is predetermined before run time. There are program variables that store the required number of steps for each motor and for each part of the packaging process.
PCB Driller CNC
During program execution, X and Y locations are determined from parsing a CADSOFT Eagle DRD file. These locations are then formulated to acquire the required number of steps to get to each location.
nCounterTime += nCounterDelta
I like that plan However give me a little more time to think this all through. I think I now have a very good overview of all the potential problems that are facing me.
Everyone has been very patient with me, and I most certainly appreciate it. So if you are reading this post, I thank you all and thank you MagIO2.
@Jonny:
The loop I posted above runs at 40kHz. And what I suggest is to let it run in one COG and all controll functions (setting PHSA to 0 or the pulsewidth) and setting the cycle-time is simply done in an additional COG. So to say all the changes you did in your code will be done in that additional COG.
The ramping up/down is not that time critical and you can use more instructions to do that than available inside of the loop. Maybe I have some time this evening to try it.
@MagIO: It's easy to write a fixed loop to go fast but, clearly, Bruce is looking to control the speed while the motor is running. Possibly the step count, too; for example, hitting an e-stop sensor might set the count to zero to stop the pulses. The demo program I attached above shows Bruce how to load the Spin cog motor driver. I for one love whole demos to look at versus "here's my theory snippet of code that I think will work" posts.
I'm sure we can agree that one is limited by Spin and moving to PASM will make a big difference. As proof I offer the attached (ready-to-run) demo which works just like my Spin demo above, but runs 4x faster (I checked on a 'scope up to 100kHz).
What I understood is that Bruce has a fixed number of steps that he wants to do at max speed but later found out that he has to ramp up and down. And what I understood is that he currently does not want to learn PASM.
I love giving hints, tips'n'tricks or explainations, but not solving the whole problem for the guys who ask - at least this is my default mode. If someone asks for more - no problem. Why? First of all because by showing the direction and let em walk themselves, they will learn much more. And second ... I have my own problems to solve and the more time I have to spend for writing complete demos the less time I have for my own projects.
And sometimes it's simply a good thing to throw in another idea as soon as possible without having a proof of concept at that time.
If I remember right we already had this kind of discussion. And I think there are people here in the forum that like your way and there are people that like it my way.
The code I posted above is running and it's intention was
1. to show some fixes of Burce's code posted before,
2. to check if SPIN is fast enough to output a 40kHz signal and
3. give Bruce an explaination what the findings mean for his problem.
Yes, PASM is of course much better for this problem, as I already stated a few posts before.
I also believe that PASM would be the best way to go, and I would be willing to learn enough to build a good driver. But just for a test, could one of you gentlemen please alter the LowCycle value in the code below with the lowest possible value that you think this function could run in PASM and port it for me. It ramps up nicely and ramping should be according to manufacturers recommendations. However, I am now stuck at 8,000 for a low cycle. I need to know if it is even possible to get more speed per manufacturers recommendations. If you think that 2,300 will work in PASM, then throw that in there. That should give me approximately 17.5 revs per second, which is well within both manufacturers recommendations. And of course, I would certainly appreciate any effort you put into it. If it doesn't work, then we are all just wasting are time, because the manufacturers are full of bull.
You might want to reconsider using hard-code counts for timing. What happens when you decide to bump from a 5MHz to 6.25MHz crystal? Answer: all your hard-coded cycle counts have to be fixed. Be careful, this is not fun (ask me how I know....).
The PASM demo (v2) I attached above above does what you want, other than allowing a change of the output pulse width on-the-fly. I used 2us which is twice what the Gecko drive needs. If you limit your output frequency to 40kHz you can bump that value (a constant) all the way up to 12. Do you really need to vary the output pulse width? If yes, the updated code attached here (v3) will do that, too.
If you connect a scope to this demo you'll see three pulses, spaced at 40kHz, and each time through the output pulse grows wider.
Yeah I read that the other day about hard code counts. I just threw them in there because it was easy at the time But okay, How do you know?
In answer to your question, no I do not need to alter the high pulse width. A constant 1uS is okay, but so is 2uS. It was explained to me yesterday, that 1uS minimum was established just to give the opto-electronics a chance to receive the pulse, and 1uS works just fine. However, I am certain that being able to vary the outout pulse width will be valuable to someone else.
I was looking at your previous PASM post, and it looks like I can also alter the frequency there on the fly.
I will give it a test and let you know the results.
just fiddled around with the code and now I have this SPIN-only piece of code to offer ;o) :
CON
_clkmode = xtal1 + pll16x ' System clock → 80 MHz
_xinfreq = 5_000_000
VAR
long nCounterTime, minPulseWidth, nCounterDelta
long stack[10]
PUB Main
nCounterDelta := 10_000
minPulseWidth := 0
cognew( stepper, @stack )
' wait for a while until the stepper COG is loaded and initialized
waitcnt( clkfreq*5 + cnt )
repeat
' start the stepper pulse
minPulseWidth := -CLKFREQ / 500_000
' ramp up
repeat nCounterDelta from 30_000 to 2_000
waitcnt( 4000 + cnt )
' let it run at max speed
waitcnt( clkfreq*5 + cnt )
' ramp down
repeat nCounterDelta from 2_000 to 30_000
waitcnt( 4000 + cnt )
' switch off pulse
minPulseWidth := 0
waitcnt( clkfreq*5 + cnt )
PUB stepper
CTRA[30..26] := %00100 ' Configure Counter A to NCO
CTRA[5..0] := 10
FRQA := 1
DIRA[10]~~
nCounterTime := CNT + nCounterDelta
repeat
PHSA := minPulseWidth
WAITCNT(nCounterTime += nCounterDelta)
Please note that the numbers used in the ramp up and down loops are only test values. Measurements need to be done to verify that the speed increase is conform to the specs.
30_000 is the starting speed ... In theory this should be 1.25 revolutions per second. Increas it if it's to fast.
2_000 is the max speed - 20 revolutions per second
4_000 in the waitcnt allows to change the increase rate. Higher value means that it'll ramp up slower. The ramp is linear. It can easily be changed to logarithmic by using a waitcnt which is based on the actual nCounterDelta.
40KHz means a period-length of 25 microseconds.
This means you could use a high-pulselength of 12.5 microseconds and everything is STILL working fine.
Reducing it to the minimum of the specification means to work close to the edge.
Believe me if you ask any professional hardware developer "if you have to create a 100 kHz-signal
what would you choose as the high-pulse length? EVERY single PROFESSIONAL hardware-developer will answer you
"half of the period-time so here 5 microseconds"
I have worked as a softwaredeveloper for industrial machine controls and I was travelling around a lot. I have seen so many bugs and faults
that "outside" people or EE-students would call "this will never happen!" I saw it happen to often. And this is the reason why real professionals
make systems foolproof whereever they can. Using values right in the middle between what is the maximum-requirement and what is still away
from ANY kind of limit (like electrical or timing specifications)
If I understood right you want to manufacture things in serial.
How often do you want to restart the prodution-process?
Best would be only once per product size.
I bet if you push some things near to the limit you will have to restart
every few hours because a fault has happened.
Where does it hurt you if you set the pulse-hightime to 2 or 4 microseconds?
You still can create a 125 kHz signal when you have pulse-hightime of 4 µsecs. This is three times higher than your actual value 40 kHz!!
If you really need high rpms you are right that using a high-perfomance servomotor will be the professional way to solve this problem
Trying to do this with a steppermotor is collecting personal experience in a lot of time where this experience is free to get quickly
from experts that have done it before.
Because I have fixed more programs than I want to remember -- before getting in the habit of writing programs that are, to the degree they can be, clock speed agnostic.
I was looking at your previous PASM post, and it looks like I can also alter the frequency there on the fly.
In fact, you can; the idea is to let you update the frequency for ramping one direction of the other outside the motor speed control. You can also monitor and update the step count on-the-fly too. Monitoring lets you change frequency for ramping as you desire, by changing the step count you could stop the driver in an emergency without having to shut-down and restart the cog.
I was busy interpreting Jon's repeat, when your code arrived, I took time out from Jon's code and tested yours. WHOOPI that motor zinged I will have to really examine what you did there. I figured I would get back here and post the successful news. Thank you so much MagIO2!!! And thank you Jon!!! I am going to test John's code also because he took some of his valuable time to write it for me. It is the very least I can do. Man that was fantastic!!!
I have been waiting TWO YEARS to see those motors run like that.
I will be back here shortly. When I make my $$$$$, I am taking you guys on vacation to someplace nice.
Comments
No, using the counter IS faster because less work is being done in the spin loop. My main point is that spin can be fast if much of the work is done outside of the fastest loop. The last example I gave was from a quick PWM generator i hacked up to play with DC-DC converters. It uses a counter and only runs fast because the repeat loop has 3 statements in it. I also get full 0-100% duty cycle control with that loop because the counter runs independently from the repeat loop.
It would also be useful to look into a more feasible command trajectory. While your commanded acceleration is bounded (good!), the commanded acceleration increases with increasing pulse rate. (because you're linearly ramping pulse period not frequency) This is exactly opposite to the torque/speed curve of the motor and will limit the maximum speed for this command sequence. (this may require a table based solution to operate at the maximum feasible acceleration, but it is likely to be MUCH faster)
Lawson
Bruce
In some applications I have seen a quadratic curve for the step-pulse-frequency in the ramp.
Before starting pulse-creation the array is initialised with the calculated timevalues.
So for step-pulse-creation you simply access the values through an array-index
VAR long ramp[100] PUB repeat idx from 0 to 99 ... ...ramp[idx]...take a second look onto my code-example above
it uses exact this programming technique
best regards
Stefan
It is an easy way to output various debug points to a single pin and resistor to a TV.
I came armed today with a few more facts. I don't know why I did not try it the other day when I wrote it, but I tried it today and got quite a bit more speed. Here is a similiar piece of code that got more speed from my stepper motors. It is just bare bones without any of the ramping.
CON _clkmode = xtal1 + pll16x ' System clock → 80 MHz _xinfreq = 5_000_000 PUB Main | nCounterTime, minPulseWidth minPulseWidth := CLKFREQ / 1_000_000 nCounterTime := CNT CTRA[30..26] := %00100 ' Configure Counter A to NCO CTRA[5..0] := 3 FRQA := 1 DIRA[3]~~ repeat 1_000_000 nCounterTime += 7_000 'At 6_000 it fails PHSA := -minPulseWidth WAITCNT(nCounterTime)This code results in 5.65 (rounded) revolutions per second. 1,000,000 microsteps at at a 10 to 1 resolution equates to 500 revolutions in 88.5 seconds (rounded).
That may sound impressive to some of you, but to me it is not. I still believe that these motors and drivers are capable of so much more. As an aide to help me into convincing you, I have attached all pertinent documentation into this single post.
In addition to the provided documentation, I also spoke with Technical Support at Applied Motion Products earlier today. And the person I spoke with, who is quite knowledgeable, told me that with 50VDC in combination with the G251's, I should have no problem getting 40 revs per second, however to maintain some torque and avoid resonance, especially for the HT23-400 motors, I should not try to go any faster than 20 revs per second.
Okay experts, how do I get this speed?
Bruce
I really did not want microstep drives, but I could not resist the price, they were on sale with a quantity discount. I got 15 drives for $49 each. I have wondered that same question about getting full steps several times, now that you got me thinking of it again, I am going to call the manufacture.
Thanks for reminding me.
Bruce
So, what worked for me is:
PUB Main | nCounterTime, minPulseWidth minPulseWidth := -CLKFREQ / 500_000 CTRA[30..26] := %00100 ' Configure Counter A to NCO CTRA[5..0] := 10 FRQA := 1 DIRA[10]~~ nCounterTime := CNT repeat 1_000_000 nCounterTime += 2_000 PHSA := minPulseWidth WAITCNT(nCounterTime)Changes:
The period of the pulses is 25us if you want 40000 microsteps per second. So, there is no good reason to use the minimum possible pulsewidth, so I doubled that value (dividing by 500_000 instead of by 1_000_000). The negation is also done in the initialization, as in the loop each SPIN bytecode instruction wastes time. Negating outside of the loop saves one instruction in each loop-cycle.
The nCounterTime is initialized as the last instruction of the initialization-phase to avoid the problem described in the beginning of my post.
The increment has been changed from 7_000 to 2_000, which is the value needed to get the 25us period.
But this is on the edge of what SPIN can do. For each instruction added inside of the loop you'll have to increase the increment again. So, ramping can only be done at lower speeds. Exchanging the fixed loop-count 1_000_000 by a variable will already be to slow for the 2_000 increment.
I'd simply switch to PASM.
I genuinely appreciate your effort in trying to resolve my problem, however that did not work either.
I called Gecko Drive today, and the tech that I spoke with told me that improper linear ramping was probably my biggest problem, and that my maximum ramp rate should be between 4-5 revolutions per second. I am also convinced, that the programming bloat in the original function on page 1, was definitely slowing things down, otherwise I would not have been able to reach 7_000 by removing the bloat. I will be creating ramping tables as suggested by Lawson, and as per the drive manufacturers recommendations.
With that all being said, I do have a couple more questions, which are:
- What is the fastest pulse train that can be achieved with counters in NCO mode in Spin?
- What is the fastest pulse train that can be achieved with counters in NCO mode in PASM?
- Where do I find good information pertaining to PASM?
Thanks For Your Effort!Bruce
As for pasm. Having programmed in assembler for 40 years, I taught myself pasm. I understand there is quite a lot of info available from the Parallax Home page links. There is also some on the propeller wiki pages. Have a look at the manual - pasm section (in the help section of proptool) - take a look at the pasm instructions.
There are a few things to remember (which are different to most other micros)...
1. Each instruction has two operands - a source and a destination (there are no registers as such). So the instruction takes a source value and operates on it, often with the destination value as well, and stores the results back in the destination. e.g. ADD adds the source value to the destination value and stores the result back in the destination.
2. Each instruction has optional bits "cccc" which are conditional execution bits depending on the "z"ero and "c"arry flags. If the condition is not met, the instruction becomes a "nop" (no operation i.e. nothing happens).
3. Each instruction has optional bits "zcri". "z" determines if the "z"ero flag is changed as a result of this instruction. Likewise for "c"arry. "r" defines if the result will be written back to the destination - so you can add two values and set the z & c flags without actually writing the result. 'i" defines if the source is a literal value (limit of 0-511 because it is only 9 bits) rather than pointing to a cog memory location.
4. There are a small number of instructions, and each instruction is 32bits.
All this is detailed in the manual.
Then I suggest taking a look at some of the simpler OBEX code examples.
To be perfectly honest, I had no desire to learn a new programming language at this time, but I do want my steppers to run the best they can within given restraints. I truly believe they are capable of so much more, however, with the two machines that I am currently working on, they do not require a lot of movement, so I real don't have the headspace to allow for proper ramping. I am beginning to think I should have designed around servos instead. My other CNC will definitely benefit from any effort that I put forth at this time, because it requires a lot of movement.
I suppose I will gather PASM information where and when I can, and try to learn it when I have time available.
Anyhow thanks again for all of your responses, you seem to be a very nice guy.
Bruce
Since Cluso99 introduced me so nicely I can't possibly resist. Anyway, I would've answered earlier but wasn't quite sure what you're after. Unmanaged, an NCO (regardless whether used from SPIN or PASM) can manage clkfreq/2 (PLL mode can go up to clkfreq). If the output needs any form of customisation then it really depends on what they are and only then language becomes an issue. HTH
I truly appreciate your response, especially after Cluso99 vouched for you
A lot of people have been telling me that I will probably have to go to PASM to get the speed I want for my stepper motors. I am still not sure if it is necessary for me to learn PASM to get this speed. Can you please advise me.
Bruce
I agree with that Jon, however if you looked at the method within the OBEX, you would see that I truly tried to document the method the very best I could with the limited knowledge that I had with counters and clock frequencies. I personally use descriptive variables for my own benefit. I find it takes me less time to decipher my own code if there is ever a need
I noticed that you must have edited your last post, because it is now gone. I now know for a fact that the original driver will spin steppers up to 5.6 revs per sec. I am sure that code will be good enough for some people, but I have decided to make a better driver. I talked with the manufacturer of my motors and also the manufacture of my stepper drives today. My motors are fully capable of 40 revs per second, however, the motor manufacture suggested limiting it to 15-20 revs per second due to torque and renosance issues. I can live with that. To achieve 20 revs per second I need a total of 40,000 pulses per second, but there is a catch. The stepper driver manufacturer suggests a ramping speed of 4-5 revs per second and I can settle for a mid-point of 4.5. Which means that during cycles of every second I need to linearly accelerate or decelerate, depending on whether it is a ramp up or ramp down, by 9,000 pulses. The code model of Version 4, should be very close in mathmatical substance to be able to achieve this. However, as you pointed out, there is program bloat and the time probably runs out and causes me problems. It was suggested by Lawson to obtain my ramping and running values from tables. I believe this was a very good suggestion, and I think the code will execute much faster. For each unit produced, each motor has a specified number of steps that it must make, and this will never change during a production run. However it will change, according to the size of the unit being produced during a production run. The are six sizes of my product that I will be producing. A good algorithim would be nice to make life easier, and I believe V4 has a fairly decent one, but ultimately I believe it will only slow things down. Considering what Kuroneko said, I should be capable of creating the 40,000 pulses with an NCO counter. That should not be a problem unless I bloat the function. I now believe it is all in the ramping and acquiring the data from tables, but I could be wrong.
I always appreciate your response Jon, and I hope I did not bore you to tears
Bruce
Ok, what I meant with "this is working for me" means that this piece of code did produce the 40kHz signal that you'd need for your maximum speed. Of course this piece of code won't drive your motor, as the motor needs the ramping up.
More important is the conclusion "use PASM". This working code shows that you are operating on the edge of what SPIN can do. Even a simple "-" (negation) as you used it in your code results in code that won't work any longer. If you still want to use SPIN your max. rounds per second must be slower. For each SPIN bytecode instruction added to the loop you have to increase the increment (2_000) by something around 200.
So, if you want to count pulses, the speed decreases. If you want to do ramping - even if it's with table support - the speed decreases.
If I understand your previous post correctly, you only have fixed numbers of steps?! So the loop would really look like
repeat 1_000_000
...
Is that right? Because a possible solution then could be to do the ramping with another COG.
Instead of
nCounterTime += 2_000
you'd say
nCounterTime += nCounterDelta
and nCounterDelta is modified by the other COG. This means that the ramping up/down piece of code is executed by a separate COG adding it's execution time to your loop. If your ramp up time is constant and the ramp down time is constant and the total number of steps is constant as well (per product) then you'll find a constant wait time that can be used between ramp up and ramp down.
That is pretty fast. The delay-times between the accelartion (ramping up) and decelaration (=ramping down) was done with a quadratic function.
For each different kind of machine the parameters of this quadratic function was optimised through practical tests.
If you want to go up to 40kHz I estimate you would need 300 to 500 steps. Would this be fast enough?
Do you use a chopper-circuit to supply the coils of the stepper-motors?
This means the supply-voltage is much higher than the nominal voltage on the spec-lable of the stepper-motor
The chopper-circuit regulates the current down to the right value (by doing PWM). But through the high supply-voltage the magnetic fields rise and reverse much faster.
So a higher torque results out of that.
pri stepper(p, spntr, fpntr) | t ' launch with cognew '' Start stepper pulsing in separate cog '' -- p is output pin '' -- spntr is hub address of steps variable (long) '' -- fpntr is hub address of frequency ticks (long) '' * max freq is ~25kHz ctra[30..26] := %00100 ' PWM / NCO ctra[5..0] := p ' set pin phsa := 0 ' start off frqa := 1 ' setup frq for pwm dira[p] := 1 ' make pin an output t := cnt repeat if (long[spntr]-- > 0) ' while steps left phsa := -PULSE_TIX ' create step pulse else phsa := 0 ' else disable output waitcnt(t += long[fpntr]) ' at current frequencyThis is setup so that you can pass the pin, and pointers to your steps and frequency control variables; this minimizes the time spent inside the loop and allows you to control steps and frequency (expressed in cnt ticks) externally. Note that this is started with cognew() so that the driver is always running. All you have to do is set the frequency and steps count (you should do it in that order).
In testing I found the highest reliable speed is 25kHz -- and, again, this code lets you change the step count and speed on-the-fly (which does slow it down a bit). The PASM version (see below) can easily output to 100kHz and still allow on-the-fly changes to step count and timing.
Sooner or later, I will be able to understand all this clock lingo, which will enable me to better explain myself. Last night I came to the realization that I will never get top end speed out of the motors on these two particular CNC's, because the movements are just to short to ramp the motors up properly. I think that a low cycle of 7_000 is the best that I can hope for in this particular situation. It saddens me greatly, but I believe it is true.
I have another CNC, which is a Printed Circuit Board drilling machine, which will certainly benefit from the discussions in this post, more so than the two machines that I am currently working on, because the travel distances are much greater, and therefore I can achieve a proper ramping profile.
Yes, you are correct, every step, on every motor, on every machine, ultimately has a fixed number of steps that it must make.
I like that plan
Everyone has been very patient with me, and I most certainly appreciate it. So if you are reading this post, I thank you all and thank you MagIO2.
Bruce
The loop I posted above runs at 40kHz. And what I suggest is to let it run in one COG and all controll functions (setting PHSA to 0 or the pulsewidth) and setting the cycle-time is simply done in an additional COG. So to say all the changes you did in your code will be done in that additional COG.
The ramping up/down is not that time critical and you can use more instructions to do that than available inside of the loop. Maybe I have some time this evening to try it.
I'm sure we can agree that one is limited by Spin and moving to PASM will make a big difference. As proof I offer the attached (ready-to-run) demo which works just like my Spin demo above, but runs 4x faster (I checked on a 'scope up to 100kHz).
I love giving hints, tips'n'tricks or explainations, but not solving the whole problem for the guys who ask - at least this is my default mode. If someone asks for more - no problem. Why? First of all because by showing the direction and let em walk themselves, they will learn much more. And second ... I have my own problems to solve and the more time I have to spend for writing complete demos the less time I have for my own projects.
And sometimes it's simply a good thing to throw in another idea as soon as possible without having a proof of concept at that time.
If I remember right we already had this kind of discussion. And I think there are people here in the forum that like your way and there are people that like it my way.
The code I posted above is running and it's intention was
1. to show some fixes of Burce's code posted before,
2. to check if SPIN is fast enough to output a 40kHz signal and
3. give Bruce an explaination what the findings mean for his problem.
Yes, PASM is of course much better for this problem, as I already stated a few posts before.
I also believe that PASM would be the best way to go, and I would be willing to learn enough to build a good driver. But just for a test, could one of you gentlemen please alter the LowCycle value in the code below with the lowest possible value that you think this function could run in PASM and port it for me. It ramps up nicely and ramping should be according to manufacturers recommendations. However, I am now stuck at 8,000 for a low cycle. I need to know if it is even possible to get more speed per manufacturers recommendations. If you think that 2,300 will work in PASM, then throw that in there. That should give me approximately 17.5 revs per second, which is well within both manufacturers recommendations. And of course, I would certainly appreciate any effort you put into it. If it doesn't work, then we are all just wasting are time, because the manufacturers are full of bull.
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 PUB Main GiveMeSpeed(3, 1_000_000, 1_000_000) PUB GiveMeSpeed(StepPin, TotalSteps, LowCycle) | Counter, HighCycle, Subtrahend Counter := cnt HighCycle := -clkfreq / 1_000_000 'Per manufacturers recommendation 'Ramp Up 5 Revs Per Second Subtrahend := ((clkfreq / 5) / 2_000) ctra[30..26] := %00100 ctra[5..0] := StepPin frqa := 1 dira[StepPin]~~ repeat TotalSteps Counter += LowCycle phsa := HighCycle waitcnt(Counter) if LowCycle > 8_000 LowCycle -= SubtrahendThanks In Advance
Bruce
You might want to reconsider using hard-code counts for timing. What happens when you decide to bump from a 5MHz to 6.25MHz crystal? Answer: all your hard-coded cycle counts have to be fixed. Be careful, this is not fun (ask me how I know....).
The PASM demo (v2) I attached above above does what you want, other than allowing a change of the output pulse width on-the-fly. I used 2us which is twice what the Gecko drive needs. If you limit your output frequency to 40kHz you can bump that value (a constant) all the way up to 12. Do you really need to vary the output pulse width? If yes, the updated code attached here (v3) will do that, too.
If you connect a scope to this demo you'll see three pulses, spaced at 40kHz, and each time through the output pulse grows wider.
Yeah I read that the other day about hard code counts. I just threw them in there because it was easy at the time
In answer to your question, no I do not need to alter the high pulse width. A constant 1uS is okay, but so is 2uS. It was explained to me yesterday, that 1uS minimum was established just to give the opto-electronics a chance to receive the pulse, and 1uS works just fine. However, I am certain that being able to vary the outout pulse width will be valuable to someone else.
I was looking at your previous PASM post, and it looks like I can also alter the frequency there on the fly.
I will give it a test and let you know the results.
Thanks a lot Jon, I owe you one.
Bruce
just fiddled around with the code and now I have this SPIN-only piece of code to offer ;o) :
CON _clkmode = xtal1 + pll16x ' System clock → 80 MHz _xinfreq = 5_000_000 VAR long nCounterTime, minPulseWidth, nCounterDelta long stack[10] PUB Main nCounterDelta := 10_000 minPulseWidth := 0 cognew( stepper, @stack ) ' wait for a while until the stepper COG is loaded and initialized waitcnt( clkfreq*5 + cnt ) repeat ' start the stepper pulse minPulseWidth := -CLKFREQ / 500_000 ' ramp up repeat nCounterDelta from 30_000 to 2_000 waitcnt( 4000 + cnt ) ' let it run at max speed waitcnt( clkfreq*5 + cnt ) ' ramp down repeat nCounterDelta from 2_000 to 30_000 waitcnt( 4000 + cnt ) ' switch off pulse minPulseWidth := 0 waitcnt( clkfreq*5 + cnt ) PUB stepper CTRA[30..26] := %00100 ' Configure Counter A to NCO CTRA[5..0] := 10 FRQA := 1 DIRA[10]~~ nCounterTime := CNT + nCounterDelta repeat PHSA := minPulseWidth WAITCNT(nCounterTime += nCounterDelta)Please note that the numbers used in the ramp up and down loops are only test values. Measurements need to be done to verify that the speed increase is conform to the specs.
30_000 is the starting speed ... In theory this should be 1.25 revolutions per second. Increas it if it's to fast.
2_000 is the max speed - 20 revolutions per second
4_000 in the waitcnt allows to change the increase rate. Higher value means that it'll ramp up slower. The ramp is linear. It can easily be changed to logarithmic by using a waitcnt which is based on the actual nCounterDelta.
This means you could use a high-pulselength of 12.5 microseconds and everything is STILL working fine.
Reducing it to the minimum of the specification means to work close to the edge.
Believe me if you ask any professional hardware developer "if you have to create a 100 kHz-signal
what would you choose as the high-pulse length? EVERY single PROFESSIONAL hardware-developer will answer you
"half of the period-time so here 5 microseconds"
I have worked as a softwaredeveloper for industrial machine controls and I was travelling around a lot. I have seen so many bugs and faults
that "outside" people or EE-students would call "this will never happen!" I saw it happen to often. And this is the reason why real professionals
make systems foolproof whereever they can. Using values right in the middle between what is the maximum-requirement and what is still away
from ANY kind of limit (like electrical or timing specifications)
If I understood right you want to manufacture things in serial.
How often do you want to restart the prodution-process?
Best would be only once per product size.
I bet if you push some things near to the limit you will have to restart
every few hours because a fault has happened.
Where does it hurt you if you set the pulse-hightime to 2 or 4 microseconds?
You still can create a 125 kHz signal when you have pulse-hightime of 4 µsecs. This is three times higher than your actual value 40 kHz!!
If you really need high rpms you are right that using a high-perfomance servomotor will be the professional way to solve this problem
Trying to do this with a steppermotor is collecting personal experience in a lot of time where this experience is free to get quickly
from experts that have done it before.
best regards
Stefan
Because I have fixed more programs than I want to remember -- before getting in the habit of writing programs that are, to the degree they can be, clock speed agnostic.
In fact, you can; the idea is to let you update the frequency for ramping one direction of the other outside the motor speed control. You can also monitor and update the step count on-the-fly too. Monitoring lets you change frequency for ramping as you desire, by changing the step count you could stop the driver in an emergency without having to shut-down and restart the cog.
I was busy interpreting Jon's repeat, when your code arrived, I took time out from Jon's code and tested yours. WHOOPI that motor zinged
I have been waiting TWO YEARS to see those motors run like that.
I will be back here shortly. When I make my $$$$$, I am taking you guys on vacation to someplace nice.
Bruce