The pestering is forgiven. You are learning and just want to be sure.
Yes, I will provide with sketch the Cherry leads, the Propeller, and a complete diagram for the connections. But it would be faster and easier to not use an ASCII format. I'll get back to you.
>>>> Which option refers to the pull up resistor connected to 3.3VDC?
Option A is for 3.3VDC, Options B and C are for 5.0VDC.
(You might take another look at posting #114, I did revise the text to make the whole ASCII schematic more clear.)
~~~~~~~~~~~~~
The situation is quite simple. You chose the Propeller which is a 3.3v device in a world with lots of 5.0v items. You need to learn to protect the Propeller inputs at all times.
If you had chosen a BasicStamp2, it is a 5.0v device and this topic never would have been necessary.
Nonetheless, in spite of the Propeller requiring you to learn a bit more, I think you purchased a better value and it will offer a lot more choices in the future.
Here is a wiring diagram for one Cherry attached to Pin 11.
Vn should have been Vin.
I tried to make all the connections with the Propeller QuickStart boards very clear, but all the Grounds should be tied together.
As usually with stepper voltage converters (the Pololu +24VDC to +5VDC), I did not connect the negative side of the +24VDC to a common ground. The board may do that internally if necessary.
This is EXACTLY what I needed. Thanks so much for taking the time to make the sketch! Your point about the use of 5v in the microcontroller world, ie BASICstamp vs propeller is something that had not occurred to me until now. Although mixing 5v components with 3.3v components is a bit trickier, I do feel that I have learned more in the process in addition to knowing how to use a more powerful microchip. I will now be adding the switches into the circuit and start experimenting with Propforth and looping controls.
Well, it is all like a huge video game... once you master one level, we go up to the next.
First we will be verifying all the hardware is working together on the Propeller and using one Cog. But eventually you may want bigger projects with multiple cogs.
There is a reason that the Propeller is not 5.0 volts... by going to 3.3 volt logic, it was able to run faster at 80-100Mhz. That was important to allow it to do color video.
Your mechanical control project doesn't need all that speed and power. But it is difficult to feel good about telling you to buy a BasicStamp2 for more money than a Propeller QuickStart.
After being able to verify the Cherry Proximity Switches are working, you may feel you can move ahead faster in C or SPIN. We will explore PropForth, but if you want to elect to switch at any time.. it is okay with me.
The main use for Forth is to demonstrate that the wiring and motor configuration are working well. In some cases, it is just easy to continue with it for the finished product. In other cases, changing to Spin or C is easier.
The short story is this. You have a device that does integer math in 32 bits and by using 32 bit math you optimize its use.
Floating point in this application is just a distraction.
A. Floating point is done through a rather demanding scheme of conversion.
B. The Propeller will do floating point.. if you need it.
C. Forth is not a very good language for floating point... never has been.
D. C has an excellent floating point library.
E. Spin will also support floating point, but the support in C is better.
Humans use floating point as a 'general scientific /engineering /financial reference' to all the items in the world on various scales: from astronomy to sub-atomic particles.
But microcontrollers never have an inherent capacity for floating point, unless they are specifically constructed as a 'floating point co-processor'.
You goal is the create a mechanical cycle that is optimized to work well with the hardware you have.
The only reason you might need to create floating point is for a human interface that needs the convenience of data provided in accurate floating point in real-time.
The best thing to do is to accommodate the math that the hardware prefers; not the math that a human prefers.
In other words, if your data is converted to fit the 32 bit binary, the Propeller won't have to do quite a bit of extra work to get the same results.
I do suppose you can use another Cog or a few more cogs to handle all these calculations in floating point. But if each step is a defined length to time in the final program, nothing is to be gained by recalculating it on the fly every time you need it.
You just need a loop that marches through the 67 steps in sequence, and knows how to get started, how to stop, and what to do with a malfunction.
If you have 67 steps, you just assign a delay value to each one. Convert the time on your Excel sheet into milliseconds, and subtract 1 millisecond for the delay already included.
Well, I figured out how to do a Look-up Table in PropForth. Have you figured out how many steps you require?
If you can provide me with the time delay for each step in milliseconds, I can convert each item to a word. Then it is merely a matter of including a sequence number in the word's name.
: Step1 105 ;
: Step2 92 ;
and so on
or maybe it would be easier with the following
: 1Step 105 ;
: 2Step 92 ;
et cetera...
You just have to increment the number within the name to call the next step.
For what is is worth, I have set up a copy of PropForth v5.5 for 64K EEPROM to help out with any code problems.
I have no idea what they changed the Baud Rate to 230,400 Baud as 57,600 Baud was plenty fast.
The Propeller QuickStart also has a 64K EEPROM and this may be needed to get an automatic start. The need for that automatic start feature is why I loaded the 64K EEPROM.
I appreciate your prep work! I have been working with Propforth and thinking through how to code an easily adaptable acceleration scheme that will be used during the trial and error process for the the mechanical part . At this point, I am exploring how to use a clock counter to keep track of the time lapse since the beginning of the acceleration loop (triggered by a high at pin 11). I have been experimenting on using the 'waitcnt' word to implement the clock counter.
More specifically, my initial assumptions are
-time span of the 120 degree rotation is 2500 ms.
-stepper configured for 1/2 step, ie 400 steps/rotation
My acceleration equation essentially calculates the number of accumulated steps at a given number of milliseconds (calcd_steps) that have lapsed since the start of the 120 degree rotation (time 0). Using a counter for the number of steps that have occurred since time 0 (step_counter), the value of step_counter is compared to calcd_steps (calc'd using the clock counter value). With each pass of the continuous loop, if calcd_steps>step_count then the motor is stepped. The continuous loop is terminated when the stop switch is triggered (pin 12 high).
Since I am working in nothing smaller than 1 ms increments, I hope that my computation speed needs aren't too demanding for Propforth, I would like to stick with Propforth for my development, but if I determine that Propforth isn't fast enough, I will then have to explore moving to Spin with a look up table as a last resort.
Any input for setting up a clock counter in Propforth would helpful
I am not exactly sure what you mean by 'clock counter', but if you are making progress - by all means continue.
I guess that 'clock counter' is a 32 bit register that just gets numbers added to and is read for reference. IN other words, it would be a variable that starts with a value of zero, creeps up and is reset.
Do I have that right?
The Propeller actually has to counters in each cog that do rather sophisticated things, but I don't think that they really can be exploited in PropForth. I am presuming you don't want to try to use those.
~~~~~
At this point, you have a 1/2 step increment of 0.9 degrees or 400 steps for a 360 degree rotation.
Are you wanting a cycle for 120 degrees, or 400/3 or 133 or 134 steps (to alternate as we discussed before) ?
Or do you want to have all 400 steps defined individually? I am not sure there is any advantage to doing 400 steps versus the 134 steps maximum.
~~~~~~~~
Have you actually mounted the stepper motor in the sculpture to observe motion in the installed situation?
IN other words, it would be a variable that starts with a value of zero, creeps up and is reset.
You are correct. I understand that the cnt value is holds the value of the number of clock cycles (0-80,000,000). If that's correct, the cnt value restarts from 0 every 53.6 seconds according to the Propforth FAQ
I am trying to make use of waitcnt as a clock counter, but I'll have to deal with the reset every 80,000,000 cycles. Thoughts?
Yes, about 133 steps would be 120 degree rotation. I say ABOUT 133, because I don't need EXACTLY 133 steps. Because of the reduced precision in the mechanics, it will not be important to have the motor rotate a precise amount of steps. Since I am using a hall-effect switch to stop the rotation cycle, the low precision of the magnet with the switch will likely translate to a rotation of 128-138 steps (133 steps +/- 5 steps). That's ok as long as the error is not compounded, ie one of the three brass pins on a pulley is near the 12 o'clock position every 3 rotation cycle.
I won't be experimenting with the mechanics until I get the stepper and switches working properly with the propeller program.
A. In the case of counted loops, the variable for the loop is put an the second stack, the R stack. You could just set up a counted loop with 400 steps and check which step it is on.
B. Other variables as required are generally part of your regular, or data stack.
So we don't normally name variables and add them to the dictionary in Forth.
But the most important question is how big a number can the Forth stack have? Is PropForth a 16bit stack or a 32bit stack.
2 to the 16th power is limited to 65,525; while 2 to the 32nd power is limited to 4,294,267,295.
I suspect even a 16 bit stack goes high enough for your project and the counter you want. After all, you did say a total of 2500 milliseconds, and that is way below 65,525. Integer maths should do fine.
Ah, yes, the Propeller does have a feature in SPIN and PASM that counts the exact ticks of the oscillator. And at 80Mhz, one tick is equal to one count. By the way, the timing of Xtals is +/- 3%, so don't get carried away with it being the same as your clock.
But the PropForth has insulated us from that and just provides a slower tick of 1 millisecond. Using the CNT feature could be done in Spin, but the only reason to is if we require a tick faster than 1 millisecond.
The big advantage of the slower 1 millisecond tick is that we just don't have to count as high.
I thought we already resolved that the motor and everything doesn't need the extra-fast response that this might provide?
We are pretty much set of 400 steps per 360 degrees, and 1 millisecond minimum wait.
~~~~
I do realize that you might be buried in a sea of manuals and technical jargon, but I am trying to keep you from getting too distracted by all of it.
A. We can do the program in integer maths.
B. We can make a main loop that is 400 steps, or a loop that provides 140 steps, but is always cut short by the sensors triggering position.
(I just wonder if you need yet a 3 Cherry Prox Sensor to recognize when you pass the exact 360 degree mark. I had been thinking that if we always delivered 400 steps and restarted from their, the cycle would remain correct.)
~~~~~~~~~
I hope I am making some sense.
If you could provide me with your Excell spread sheet with either the 134 steps calculated to milliseconds for each step; or 400 steps calculated to milliseconds for each step --- I might be able to provide a working thesis in the form of a code example.
!!!!!!!!!!!!!
The stepper motor and the Propeller will be faithful -- 400 steps will provide an exact 360 degree rotation. So the drift, if there is any, comes in from the triggers and the mechanics involved.
Maybe a correction after each 400 steps is wise, but having not seen the mechanics and how the sensors might behave -- I am not certain that you have the right solution.
Once the trigger occurs, 120 degrees of movement takes place. If the next trigger comes early, the steps will take place on time. If the next trigger comes late, we may have problems that could be resolved by setting up the trigger to always be on time or early--- but never ever late.
Early triggers would just start after the completion of the previous cycle's step sequence.
Still I am not sure late matters at all. If the motion looks good and the lateness isn't visual obvious, you are still going to get exact 360 degrees of rotation out of 3 cycles.
So you fears may be unfounded.
Do you really have to have an exact 2500ms movement as well in each segment? I suspect not.
1. I think it is extremely important to have your motor step through exactly 400 steps per 3 cycles.
But, you acceleration might be sustained over something less, like the 128 you mention. The other steps could be inserted with a nominal value at the beginning and/or the end of the cycle.
2. Waitcnt is not really PropForth, it is PASM in PropForth. It can be reached and used in an Assembly routine with PropForth. But this is all rather advanced programing... and I strongly suspect unnecessary.
3. We may be up against what you imagine you need for precision versus getting the device to move faithfully through a cycle of three 120 degree movements.
I am shooting for the simplest solution to get the cycle of three 120 degree movements to be faithful to what you want.
4. You have not really explained what you expect the two Cherry Proximity switch to do. I know one will confirm the end of one 120 degree movement, but what does the other one do?
And are you at any time going to have the device seek a new starting point if misaligned? If so, will it only rotate forward, or will it have to reverse direction to resolve the problem?
As you can see, there are some features that I am unclear on.
I will send you a sketch of the mechanism that will help explain what I need. Hope to have time to do that later today. Been exploring the clock counter loop that you mention using the R stack. Have found discussion of a return stack but not an R stack.
I have however, written a simple loop to step through 2500 steps using a variable. Here is a snippet:
2500 constant .PTIME / .PTIME is total time of step pulses in ms
wvariable timelapse
0 timelapse W! /set value
: ClkCntr .PTIME 0 do
timelapse W@ 1 +
timelapse W!
1 delms
loop
;
I am finding that the loop takes about 3-4 seconds to run, so use of a stack instead of a variable may be better.
The 2500 ms pulse period is just a starting value that will be refined. The sketch that I will send shows using extension springs which will effect the duration of 120 degree rotation, so interval of steps will require tinkering.
The R stack is another name for the Return Stack. Forth usually is a Two Stack machine: a Data Stack and an Return Stack. When you create loops the second stack comes in handy. "Starting Forth" presents an explaination of all this if you get far enough into the text. You really need to have completely studies "Starting Forth" to have the basics presented.
Why are we now using 2500 steps, when we were at 400 steps in 7500 milliseconds. I suspect your are geting steps of rotation confused with your 2500 ms for a 120 degree rotation. Take some time to reconsider this sudden need for 2500 steps.
Or, this is just an example unrelated to the project. When you say 'steps', I think you mean stepper motor steps.
For you project, your actual loop never needs to be bigger than 400 steps if you have 400 steps per 360 degrees. Did you change the step resolution again?
I have asked you to provide an Excel list of how long a delay each of 133 steps would be. With that we can just use 'delms'. You could provide your formula for your acceleration curve as well.
~~~~~~~~~~~~~~~~~~~~`
There is nothing wrong with learning how to use the clock counter on the Propeller. It is the way that delays must be calculated in Spin or PASM. You just don't need it for this project. If you want to jump around and learn a bit of whatever seems interesting or useful, that is okay. But the project is going to take longer to complete. And you risk getting off into topics that I may not be able to help you with.
Using CNT and WAITCNT is much finer resolution than the 1ms or more delay than you need. PropForth provides delms to avoild using WAITCNT. It is ideal for what you want to do.
80,000,000,000 cycles per second are being monitored, but 1000 cycles per second is adequate, so you are just adding 80,000,000 to your 1ms count.
I do admit that this would be useful if you wanted the Step sequence to have a delay smaller than 1 ms, closer to the 10usec limit. But any delays of less than 10 to 20us for the step are likely to cause misses. The I ms cycle is more reliable. The stepper motor controller cannot handle a Step pulse under 10 us, and maybe even 10us is a little too fast. It did just fine with 1 ms.
~~~~~~~
I am having difficulty with your change of having steps vary from somewhere around 126 to 138 steps. This makes coding and tracking a 360 degree rotation more complex. I wonder if it is necessary.
I had thought your biggest concern was to get enough acceleration, but not too much in a 120 degree arc of motor shaft rotation. Are you saying that you need less than 120 degrees? Or are you saying that sometimes you want less than 120 degrees and at other times you want more than 120 degrees?
You are creating more variation. Thus there is more potential for drift.
~~~~~~~~
What I had thought you wanted was a 120 degree rotation that at its end would provide some momentum for something to swing and trigger the sensor. So there would be the following:
1. active driven rotation.
2. wait for trigger
3. active driven rotation.
4. wait for trigger
5. active driven rotation.
6. wait for trigger.
7. back to #1
The only way to get 360 degrees is to keep an accurate tally of 400 steps. I don't see where the motion might be enhanced by you varying the number of steps more than you have to.
I have code that will handle the following
1. 133 steps
2. 133 steps
3. 133 steps
4. 1 step (for adjustment to a full 360 degrees)
5. Back to #1.
You get the exact same acceleration every time. The 1 step adjustment can occur after your swing has started and while you are waiting for your trigger event to start another cycle.
Stepper motors are precise. If you want 360 degrees in 400 steps, you will always get 360 degrees in 400 steps. So there is no need to have a feedback loop of some sort that confirms your position. And cutting short at 126 steps one time while adding 138 steps another and then having to figure out how many you need to get to 400 the next time seems to be adding a lot of unnecessary computation.
Where did this variation come in from?
I patiently await clarification of the need for all these things. If you think you really are getting the hang of PropForth and can write the whole application on your own from here, excellent. I'll just back off.
I will attempt to have Propforth do the acceleration calc on each ms pass. If I find that it is too slow, I think a lookup table might work.
Although my spreadsheet shows 2500 table entries, the 2500 entries represent varying delms values between a rotational velocity of 0 and 53 steps per seconds (cell C21). So a look up table could contain the 53 rows with 1 column. The column would contain the accumulated time in ms since the start switch was tripped. But the values in the column would only be when a pulse is required. For example, the motor is stepped once when the start switch is tripped, but the spreadsheet does not call for another step until 100 ms, and a 3rd at 168 ms, etc. The difference between the the current value and the subsequent value would be the duration of the delms value.
Every time a change is made to the excel table, the look up table would need to be changed. If that process is fairly easy, that might be a workable solution. It would be very helpful if you could provide a sample of Propforth code that retrieves a value from a single column look up table?
HI,
The truth is I am learning quite a bit along with you. This just occured to me.
At 80mhz, you not only have 80,000,000,000 cycles per second. That implies that the Propeller has the ability to easily do 10,000 or 20,000 low-level calculation commands in a millisecond. So calculation on the fly may not be a bit deal, even though a look-up table might be even faster.
In other words, we are dealing with eight stallions pulling a milk cart. We really need only one slow donkey.
The truth is that one has to use PASM to know exactly how much time a calculation will take. Once a software language such as C, Forth, Spin, or Basic is introduced; the overhead of the language begins to slow processes down.
In other words, if all else fails to be quick enough, there is always the option to write the whole program in PASM.
Forth just makes it easy for you to verify the physical wiring is working. That is important, especially to someone new in electronics. But I am always willing to change to a better tool, if a better tool is required.
There seems to be plenty of empty time to get a calculation done.
I did get confused a bit by your mention of 2500 steps, as the stepper motor rotates in what I term as steps. Actually I see from the data you sent me that you were referring to 2500 time slices of 1ms.
So your calculations are in the 'time domain' and not the rotation of the stepper.
I am going through the data and making sure I fully comprehend it, including the underlying maths and formulas used.
If I have to, everything will be derived directly from the curve you provided,
and the formula of y = aX+bX*X+cX*X*X according to your input for a, b, and c.
~~~~~~~~~
Other topics..
>>> Bevel gears
I see you included a 90 degree turn in your drive train via bevel gears. Bevel gears always push against their shafts due to inherent thrust. Things might get loose over time and the gear train might become noisy. I don't see why you don't just keep all the the rotations parallel and avoid this kind of hazard.
Besides, using bevel gears is expensive and requires more construction effort. But it really is up to you what you decide to go with.
>>>The need for a Stop and a Start sensor.
There are two points of view.
In a traditional mechanical device the need to have information on when to start and when to stop is quite obvious. You need a complete feedback loop.
With a stepper motor, by the ability of motor to execute a precise number of steps at specific intervals, it finds the same stop every time unless drive belts slip significantly. You need only to tell it when to start. The start sensor will correct any previous slippage. If the location of start position needs to be adjusted, a fudge factor can be put in to delay the start. There just is no real reason to include all the hardware and the additional sensor to stop the device.
In either case, a mechanical failure is going to miss the stop mark. So I can't seem to justify a stop sensor as a fail-safe.
Including the stop sensor does open you up to other possible drive solutions aside from stepper motors. But the stepper motor will first prove the operation of the device is right, and will offer a lot of data that will help to build another alternative drive that might be less bulky, quieter, and less expensive.
In you context, you might even have a push rod driven by a solenoid deliver a precise acceleration via Pulse Width Modulation from a Propeller.... no motor at all, just a precise shove of a 120 degree arc.
It is an interesting project. I've mentioned some additional possibilities, but the goal is to get the first version finished and not to change the design mid-stream.
You have my email now, so you need not post publicly. I will be watching that mail box for your email.
~~~~
Steps versus time slices. There are always some hazards of using jargon. In addition Forth uses words as commands that can all too often look like everyday terms. This is one reason people often dislike Forth, everyone extends their dictionary in their own way and then has difficulty getting others to look at their special dictionary.
With Basic, C or Spin, code always looks like code -- so it is easier to notice what someone is sharing with you.
Comments
Yes, I will provide with sketch the Cherry leads, the Propeller, and a complete diagram for the connections. But it would be faster and easier to not use an ASCII format. I'll get back to you.
>>>> Which option refers to the pull up resistor connected to 3.3VDC?
Option A is for 3.3VDC, Options B and C are for 5.0VDC.
(You might take another look at posting #114, I did revise the text to make the whole ASCII schematic more clear.)
~~~~~~~~~~~~~
The situation is quite simple. You chose the Propeller which is a 3.3v device in a world with lots of 5.0v items. You need to learn to protect the Propeller inputs at all times.
If you had chosen a BasicStamp2, it is a 5.0v device and this topic never would have been necessary.
Nonetheless, in spite of the Propeller requiring you to learn a bit more, I think you purchased a better value and it will offer a lot more choices in the future.
Vn should have been Vin.
I tried to make all the connections with the Propeller QuickStart boards very clear, but all the Grounds should be tied together.
As usually with stepper voltage converters (the Pololu +24VDC to +5VDC), I did not connect the negative side of the +24VDC to a common ground. The board may do that internally if necessary.
First we will be verifying all the hardware is working together on the Propeller and using one Cog. But eventually you may want bigger projects with multiple cogs.
There is a reason that the Propeller is not 5.0 volts... by going to 3.3 volt logic, it was able to run faster at 80-100Mhz. That was important to allow it to do color video.
Your mechanical control project doesn't need all that speed and power. But it is difficult to feel good about telling you to buy a BasicStamp2 for more money than a Propeller QuickStart.
After being able to verify the Cherry Proximity Switches are working, you may feel you can move ahead faster in C or SPIN. We will explore PropForth, but if you want to elect to switch at any time.. it is okay with me.
The main use for Forth is to demonstrate that the wiring and motor configuration are working well. In some cases, it is just easy to continue with it for the finished product. In other cases, changing to Spin or C is easier.
The short story is this. You have a device that does integer math in 32 bits and by using 32 bit math you optimize its use.
Floating point in this application is just a distraction.
A. Floating point is done through a rather demanding scheme of conversion.
B. The Propeller will do floating point.. if you need it.
C. Forth is not a very good language for floating point... never has been.
D. C has an excellent floating point library.
E. Spin will also support floating point, but the support in C is better.
Humans use floating point as a 'general scientific /engineering /financial reference' to all the items in the world on various scales: from astronomy to sub-atomic particles.
But microcontrollers never have an inherent capacity for floating point, unless they are specifically constructed as a 'floating point co-processor'.
You goal is the create a mechanical cycle that is optimized to work well with the hardware you have.
The only reason you might need to create floating point is for a human interface that needs the convenience of data provided in accurate floating point in real-time.
The best thing to do is to accommodate the math that the hardware prefers; not the math that a human prefers.
In other words, if your data is converted to fit the 32 bit binary, the Propeller won't have to do quite a bit of extra work to get the same results.
I do suppose you can use another Cog or a few more cogs to handle all these calculations in floating point. But if each step is a defined length to time in the final program, nothing is to be gained by recalculating it on the fly every time you need it.
You just need a loop that marches through the 67 steps in sequence, and knows how to get started, how to stop, and what to do with a malfunction.
If you have 67 steps, you just assign a delay value to each one. Convert the time on your Excel sheet into milliseconds, and subtract 1 millisecond for the delay already included.
If you can provide me with the time delay for each step in milliseconds, I can convert each item to a word. Then it is merely a matter of including a sequence number in the word's name.
: Step1 105 ;
: Step2 92 ;
and so on
or maybe it would be easier with the following
: 1Step 105 ;
: 2Step 92 ;
et cetera...
You just have to increment the number within the name to call the next step.
I have no idea what they changed the Baud Rate to 230,400 Baud as 57,600 Baud was plenty fast.
The Propeller QuickStart also has a 64K EEPROM and this may be needed to get an automatic start. The need for that automatic start feature is why I loaded the 64K EEPROM.
More specifically, my initial assumptions are
-time span of the 120 degree rotation is 2500 ms.
-stepper configured for 1/2 step, ie 400 steps/rotation
My acceleration equation essentially calculates the number of accumulated steps at a given number of milliseconds (calcd_steps) that have lapsed since the start of the 120 degree rotation (time 0). Using a counter for the number of steps that have occurred since time 0 (step_counter), the value of step_counter is compared to calcd_steps (calc'd using the clock counter value). With each pass of the continuous loop, if calcd_steps>step_count then the motor is stepped. The continuous loop is terminated when the stop switch is triggered (pin 12 high).
Since I am working in nothing smaller than 1 ms increments, I hope that my computation speed needs aren't too demanding for Propforth, I would like to stick with Propforth for my development, but if I determine that Propforth isn't fast enough, I will then have to explore moving to Spin with a look up table as a last resort.
Any input for setting up a clock counter in Propforth would helpful
I guess that 'clock counter' is a 32 bit register that just gets numbers added to and is read for reference. IN other words, it would be a variable that starts with a value of zero, creeps up and is reset.
Do I have that right?
The Propeller actually has to counters in each cog that do rather sophisticated things, but I don't think that they really can be exploited in PropForth. I am presuming you don't want to try to use those.
~~~~~
At this point, you have a 1/2 step increment of 0.9 degrees or 400 steps for a 360 degree rotation.
Are you wanting a cycle for 120 degrees, or 400/3 or 133 or 134 steps (to alternate as we discussed before) ?
Or do you want to have all 400 steps defined individually? I am not sure there is any advantage to doing 400 steps versus the 134 steps maximum.
~~~~~~~~
Have you actually mounted the stepper motor in the sculpture to observe motion in the installed situation?
You are correct. I understand that the cnt value is holds the value of the number of clock cycles (0-80,000,000). If that's correct, the cnt value restarts from 0 every 53.6 seconds according to the Propforth FAQ
http://code.google.com/p/propforth/wiki/PropForthFAQ#How_does_the_WAITCNT_word_work?
I am trying to make use of waitcnt as a clock counter, but I'll have to deal with the reset every 80,000,000 cycles. Thoughts?
Yes, about 133 steps would be 120 degree rotation. I say ABOUT 133, because I don't need EXACTLY 133 steps. Because of the reduced precision in the mechanics, it will not be important to have the motor rotate a precise amount of steps. Since I am using a hall-effect switch to stop the rotation cycle, the low precision of the magnet with the switch will likely translate to a rotation of 128-138 steps (133 steps +/- 5 steps). That's ok as long as the error is not compounded, ie one of the three brass pins on a pulley is near the 12 o'clock position every 3 rotation cycle.
I won't be experimenting with the mechanics until I get the stepper and switches working properly with the propeller program.
A. In the case of counted loops, the variable for the loop is put an the second stack, the R stack. You could just set up a counted loop with 400 steps and check which step it is on.
B. Other variables as required are generally part of your regular, or data stack.
So we don't normally name variables and add them to the dictionary in Forth.
But the most important question is how big a number can the Forth stack have? Is PropForth a 16bit stack or a 32bit stack.
2 to the 16th power is limited to 65,525; while 2 to the 32nd power is limited to 4,294,267,295.
I suspect even a 16 bit stack goes high enough for your project and the counter you want. After all, you did say a total of 2500 milliseconds, and that is way below 65,525. Integer maths should do fine.
But the PropForth has insulated us from that and just provides a slower tick of 1 millisecond. Using the CNT feature could be done in Spin, but the only reason to is if we require a tick faster than 1 millisecond.
The big advantage of the slower 1 millisecond tick is that we just don't have to count as high.
I thought we already resolved that the motor and everything doesn't need the extra-fast response that this might provide?
We are pretty much set of 400 steps per 360 degrees, and 1 millisecond minimum wait.
~~~~
I do realize that you might be buried in a sea of manuals and technical jargon, but I am trying to keep you from getting too distracted by all of it.
A. We can do the program in integer maths.
B. We can make a main loop that is 400 steps, or a loop that provides 140 steps, but is always cut short by the sensors triggering position.
(I just wonder if you need yet a 3 Cherry Prox Sensor to recognize when you pass the exact 360 degree mark. I had been thinking that if we always delivered 400 steps and restarted from their, the cycle would remain correct.)
~~~~~~~~~
I hope I am making some sense.
If you could provide me with your Excell spread sheet with either the 134 steps calculated to milliseconds for each step; or 400 steps calculated to milliseconds for each step --- I might be able to provide a working thesis in the form of a code example.
!!!!!!!!!!!!!
The stepper motor and the Propeller will be faithful -- 400 steps will provide an exact 360 degree rotation. So the drift, if there is any, comes in from the triggers and the mechanics involved.
Maybe a correction after each 400 steps is wise, but having not seen the mechanics and how the sensors might behave -- I am not certain that you have the right solution.
Once the trigger occurs, 120 degrees of movement takes place. If the next trigger comes early, the steps will take place on time. If the next trigger comes late, we may have problems that could be resolved by setting up the trigger to always be on time or early--- but never ever late.
Early triggers would just start after the completion of the previous cycle's step sequence.
Still I am not sure late matters at all. If the motion looks good and the lateness isn't visual obvious, you are still going to get exact 360 degrees of rotation out of 3 cycles.
So you fears may be unfounded.
Do you really have to have an exact 2500ms movement as well in each segment? I suspect not.
1. I think it is extremely important to have your motor step through exactly 400 steps per 3 cycles.
But, you acceleration might be sustained over something less, like the 128 you mention. The other steps could be inserted with a nominal value at the beginning and/or the end of the cycle.
2. Waitcnt is not really PropForth, it is PASM in PropForth. It can be reached and used in an Assembly routine with PropForth. But this is all rather advanced programing... and I strongly suspect unnecessary.
3. We may be up against what you imagine you need for precision versus getting the device to move faithfully through a cycle of three 120 degree movements.
I am shooting for the simplest solution to get the cycle of three 120 degree movements to be faithful to what you want.
4. You have not really explained what you expect the two Cherry Proximity switch to do. I know one will confirm the end of one 120 degree movement, but what does the other one do?
And are you at any time going to have the device seek a new starting point if misaligned? If so, will it only rotate forward, or will it have to reverse direction to resolve the problem?
As you can see, there are some features that I am unclear on.
I have however, written a simple loop to step through 2500 steps using a variable. Here is a snippet:
2500 constant .PTIME / .PTIME is total time of step pulses in ms
wvariable timelapse
0 timelapse W! /set value
: ClkCntr .PTIME 0 do
timelapse W@ 1 +
timelapse W!
1 delms
loop
;
I am finding that the loop takes about 3-4 seconds to run, so use of a stack instead of a variable may be better.
The 2500 ms pulse period is just a starting value that will be refined. The sketch that I will send shows using extension springs which will effect the duration of 120 degree rotation, so interval of steps will require tinkering.
Why are we now using 2500 steps, when we were at 400 steps in 7500 milliseconds. I suspect your are geting steps of rotation confused with your 2500 ms for a 120 degree rotation. Take some time to reconsider this sudden need for 2500 steps.
Or, this is just an example unrelated to the project. When you say 'steps', I think you mean stepper motor steps.
For you project, your actual loop never needs to be bigger than 400 steps if you have 400 steps per 360 degrees. Did you change the step resolution again?
I have asked you to provide an Excel list of how long a delay each of 133 steps would be. With that we can just use 'delms'. You could provide your formula for your acceleration curve as well.
~~~~~~~~~~~~~~~~~~~~`
There is nothing wrong with learning how to use the clock counter on the Propeller. It is the way that delays must be calculated in Spin or PASM. You just don't need it for this project. If you want to jump around and learn a bit of whatever seems interesting or useful, that is okay. But the project is going to take longer to complete. And you risk getting off into topics that I may not be able to help you with.
Using CNT and WAITCNT is much finer resolution than the 1ms or more delay than you need. PropForth provides delms to avoild using WAITCNT. It is ideal for what you want to do.
80,000,000,000 cycles per second are being monitored, but 1000 cycles per second is adequate, so you are just adding 80,000,000 to your 1ms count.
I do admit that this would be useful if you wanted the Step sequence to have a delay smaller than 1 ms, closer to the 10usec limit. But any delays of less than 10 to 20us for the step are likely to cause misses. The I ms cycle is more reliable. The stepper motor controller cannot handle a Step pulse under 10 us, and maybe even 10us is a little too fast. It did just fine with 1 ms.
~~~~~~~
I am having difficulty with your change of having steps vary from somewhere around 126 to 138 steps. This makes coding and tracking a 360 degree rotation more complex. I wonder if it is necessary.
I had thought your biggest concern was to get enough acceleration, but not too much in a 120 degree arc of motor shaft rotation. Are you saying that you need less than 120 degrees? Or are you saying that sometimes you want less than 120 degrees and at other times you want more than 120 degrees?
You are creating more variation. Thus there is more potential for drift.
~~~~~~~~
What I had thought you wanted was a 120 degree rotation that at its end would provide some momentum for something to swing and trigger the sensor. So there would be the following:
1. active driven rotation.
2. wait for trigger
3. active driven rotation.
4. wait for trigger
5. active driven rotation.
6. wait for trigger.
7. back to #1
The only way to get 360 degrees is to keep an accurate tally of 400 steps. I don't see where the motion might be enhanced by you varying the number of steps more than you have to.
I have code that will handle the following
1. 133 steps
2. 133 steps
3. 133 steps
4. 1 step (for adjustment to a full 360 degrees)
5. Back to #1.
You get the exact same acceleration every time. The 1 step adjustment can occur after your swing has started and while you are waiting for your trigger event to start another cycle.
Stepper motors are precise. If you want 360 degrees in 400 steps, you will always get 360 degrees in 400 steps. So there is no need to have a feedback loop of some sort that confirms your position. And cutting short at 126 steps one time while adding 138 steps another and then having to figure out how many you need to get to 400 the next time seems to be adding a lot of unnecessary computation.
Where did this variation come in from?
I patiently await clarification of the need for all these things. If you think you really are getting the hang of PropForth and can write the whole application on your own from here, excellent. I'll just back off.
Although my spreadsheet shows 2500 table entries, the 2500 entries represent varying delms values between a rotational velocity of 0 and 53 steps per seconds (cell C21). So a look up table could contain the 53 rows with 1 column. The column would contain the accumulated time in ms since the start switch was tripped. But the values in the column would only be when a pulse is required. For example, the motor is stepped once when the start switch is tripped, but the spreadsheet does not call for another step until 100 ms, and a 3rd at 168 ms, etc. The difference between the the current value and the subsequent value would be the duration of the delms value.
Every time a change is made to the excel table, the look up table would need to be changed. If that process is fairly easy, that might be a workable solution. It would be very helpful if you could provide a sample of Propforth code that retrieves a value from a single column look up table?
The truth is I am learning quite a bit along with you. This just occured to me.
At 80mhz, you not only have 80,000,000,000 cycles per second. That implies that the Propeller has the ability to easily do 10,000 or 20,000 low-level calculation commands in a millisecond. So calculation on the fly may not be a bit deal, even though a look-up table might be even faster.
In other words, we are dealing with eight stallions pulling a milk cart. We really need only one slow donkey.
The truth is that one has to use PASM to know exactly how much time a calculation will take. Once a software language such as C, Forth, Spin, or Basic is introduced; the overhead of the language begins to slow processes down.
In other words, if all else fails to be quick enough, there is always the option to write the whole program in PASM.
Forth just makes it easy for you to verify the physical wiring is working. That is important, especially to someone new in electronics. But I am always willing to change to a better tool, if a better tool is required.
There seems to be plenty of empty time to get a calculation done.
I did get confused a bit by your mention of 2500 steps, as the stepper motor rotates in what I term as steps. Actually I see from the data you sent me that you were referring to 2500 time slices of 1ms.
So your calculations are in the 'time domain' and not the rotation of the stepper.
I am going through the data and making sure I fully comprehend it, including the underlying maths and formulas used.
If I have to, everything will be derived directly from the curve you provided,
and the formula of y = aX+bX*X+cX*X*X according to your input for a, b, and c.
~~~~~~~~~
Other topics..
>>> Bevel gears
I see you included a 90 degree turn in your drive train via bevel gears. Bevel gears always push against their shafts due to inherent thrust. Things might get loose over time and the gear train might become noisy. I don't see why you don't just keep all the the rotations parallel and avoid this kind of hazard.
Besides, using bevel gears is expensive and requires more construction effort. But it really is up to you what you decide to go with.
>>>The need for a Stop and a Start sensor.
There are two points of view.
In a traditional mechanical device the need to have information on when to start and when to stop is quite obvious. You need a complete feedback loop.
With a stepper motor, by the ability of motor to execute a precise number of steps at specific intervals, it finds the same stop every time unless drive belts slip significantly. You need only to tell it when to start. The start sensor will correct any previous slippage. If the location of start position needs to be adjusted, a fudge factor can be put in to delay the start. There just is no real reason to include all the hardware and the additional sensor to stop the device.
In either case, a mechanical failure is going to miss the stop mark. So I can't seem to justify a stop sensor as a fail-safe.
Including the stop sensor does open you up to other possible drive solutions aside from stepper motors. But the stepper motor will first prove the operation of the device is right, and will offer a lot of data that will help to build another alternative drive that might be less bulky, quieter, and less expensive.
In you context, you might even have a push rod driven by a solenoid deliver a precise acceleration via Pulse Width Modulation from a Propeller.... no motor at all, just a precise shove of a 120 degree arc.
It is an interesting project. I've mentioned some additional possibilities, but the goal is to get the first version finished and not to change the design mid-stream.
You have my email now, so you need not post publicly. I will be watching that mail box for your email.
~~~~
Steps versus time slices. There are always some hazards of using jargon. In addition Forth uses words as commands that can all too often look like everyday terms. This is one reason people often dislike Forth, everyone extends their dictionary in their own way and then has difficulty getting others to look at their special dictionary.
With Basic, C or Spin, code always looks like code -- so it is easier to notice what someone is sharing with you.