Excuse me but there is no "maybe not" about this proposal! This stuff does work...have you actually had any experience with closed-loop servo motion control systems? I'm guessing no!
Mickster
P.S. However, I wish the OP luck in following the prescribed solution as the DIY, home-grown approach certainly is much more fun and educational and will provide much more satisfaction than my proposed off-the-shelf alternatives.
I have been reading through the docs and tutorials for Gforth and think I have a concept for words and their usefulness. But the words that you asked that I create, like enable, clockwise, pulseon seem to involve some I/O control, which I don't find much help for in the Gforth manual. Can you give me some example forth code for a couple of the words in your list?
I have begun setting up my hardware configuration, but I am trying to do so without soldering to the QuickStart. I am using wires from the 40 pin socket to a breadboard, so I think I will be ok. I may have to solder a few wires if we need to use J4-J7. I won't be energizing anything until I confirm my wiring config with you.
Hi,
Most of the wiring centers around two items -- the stepper motor controller, and the Cherry Proximity sensor. I don't think you need to add a breadboard as an intermediate at this point.
Everything should be adequate with solid copper telephone wire, except the power supply to stepper motor controller. I suggested a bit heavier to accomodate the full 5 amps.
You do need to use J4-J7 for extra ground connections, but I don't think you need the 3.3V side. The 40 pin 2x20 has one 3.3V for your pull-up.
About the only thing I haven't mentioned is the +24VDC to +5VDC converter. It does come off the +24VDC output and can use telephone wire. Pololu strongly recommends an added capacitor on the input. It should be rated OVER +24VDC, at least +35V.. but +50VDC or +100VDC is equally okay. As best as I recall, they wanted 30uF. It you wire it backwards, it will blow up. So, the + to + and the - to - and stand back before you turn it on.
The other side is pretty simply - a +5VDC and ground output. Version B of the QuickStart board has some discussion of modifications to properly isolate power. I am not sure that applies. But you would put the +5 to one of the 40 pin 2x20 +5VDC, and the other side to Gnd.
I will get back to you regarding any possible need to modify the QuickStart, but find out if you have a Version A or Version B.
~~~~~~~~~~~~~
PropForth has the words you need, not GForth. You are 100% correct about this.
There is a reference list that is good enough, but not 100% up-to-date. I think it came out with V3.5
You will need the following words to control pin output and input
pinout
pinhigh
pinlow
pinin
px? (This will sense Hi and Low for an input)
There are also the Definite Loop to get a specific number of steps,
and the Indefinite Loop that you will run to sense the input hi or low, and when low it will jump to a state machine to take action as you decide.
See delms for inserted delays in loops.
There is NO one second delay (was delsec in an earlier version), just the 1 millisecond delay. You can't get down to 10 microseconds, but 1 millisecond for your Pulse should do fine... it just should not be less than 10 microseconds or you may not get the motor to step.
As you will see, the PF_QUICK_REFERENCE has a heck of a lot of words you don't need to know about at this time.
One of the greatest hazards to a new learner in Forth is to try to learn each and every word right away. If you are experienced with other computer languages in great depth, it might be fun. But if you are on your first microcontroller, it is way over the top to expect to understand all right away.
@Mickster
Are you just jumping in without reading the whole thread? You come into the thread very late and suggest we completely restart what has been done.
The Animatics Smart Motor does seem good, but the PIC controlled items seemed at first impression to similar to we went with. Besides, all the stuff has been purchased.
BTW, I do admit that there are new products that combine the stepper motor and the stepper motor controller all in one package. Or other ones, that package a servo motor and contoller in to one package. But I went with something that was reasonable on Ebay, not the more costly leading edge.
Your salesmanship is very compelling, but maybe not considering a new user's situation or wishes. And you are right, I've no experience with closed loop servo control systems. Why? Good ones are usually very proprietary and expensive.
Set aside the selling and tell me how many Man-hours you are willing to provide to help a rank beginner get what he wants in a cost-effective manner?
Excuse me but there is no "maybe not" about this proposal! This stuff does work...have you actually had any experience with closed-loop servo motion control systems? I'm guessing no!
Mickster
P.S. However, I wish the OP luck in following the prescribed solution as the DIY, home-grown approach certainly is much more fun and educational and will provide much more satisfaction than my proposed off-the-shelf alternatives.
When I connect the +5v out of the 24 VDC-5VDC convertor to the 40 pin 2x20 +5VDC, would that be pin 40 marked Vin?
I have the Version B QuickStart
Will I be writing the code in the Gforth environment, but using some of the PropForth words? Can you elaborate on how that will work?
Since I will be using a second Cherry switch to terminate the stepper movement, is the use of a Definite Loop relevant?
GForth really won't know what to do with special PropForth code as it doesn't have Cogs or the individual i/o.
You need to load the QuickStart with PropForth (I guess for a 32K rom) and play with it independently of GFORTH. There are some differences is style. For one, PropForth requires the right case. And so words for looking at the stack are different.
GForth is just good for working with Brodie's book, "Starting Forth". Brodie never anticipated Forth on parallel microcontrollers. So he is easier to study in GForth on a regular computer.
~~~~~~~~~~~~~
Now you want 2 Cherry Proximity switches? That is not really a problem. But you will need a combination of at least one infinite loop and one or more definite loops.
~~~~~~~~~~~~~~~
I need to get a better idea of what cycles you expect the program to do. Maybe one infinite loops until a start, and another infinite loop until a stop.
The thing that worries me as that you were talking about accelerating or decelerating the step rate. Is that still something you want?
~~~~~~~~~~~~~~
Yes, Vin is for a +5VDC input. But if you only have the USB providing power, it can provide a little +5VDC output. I think you previously mentioned it was at +4.77, a little low, but not too low for the Cherry Proximity sensor.
In other words, the Vin is supposed to be Vin, but one can borrow a wee bit of +5 from it.
This bring up another fact. You will have to provide a +5VDC to the QuickStart, and a +5 to each Cherry Proximity sensor. It is best practise to do all directly from the +24 to +5 converter, and to provide GND for both directly from the converter as well.
Too many grounds create something called a 'ground loop' and that can cause problems occasionally. So ground connects should avoid loops and be distributed in a tree-like distribution pattern.
~~~~
On other fronts, it is income tax time in Taiwan and I may have to spend a few days of intense number crunching for that. I am not sure I will respond to your emails as quickly as I have up to now.
If Propforth contains the commands that we need, do I need to learn Gforth and use of its environment? I will spend my time getting familiar with Propforth and its use with the Quickstart unless you recommend otherwise.
I won't need to decelerate, but I I will need to be able to accelerate. This is because, although I will be using a spring to absorb some of the inertia the sculpture initially exerts on the stepper drive mechanism, I want to minimize the amount of dampening work done by the spring. In order to do this, the stepper can't just start abruptly at a constant speed.
Hope your tax prep goes well. Propforth will keep me plenty busy during the fun you're having :-)
Overall, if you feel confident, you can skip GForth entirely and work with PropForth on the Propeller. I feel I am making things more complex than they have to be.
PropForth is different enough that I don't want to get too attached to "Starting Forth" and GForth. PropForth has its own tutorial.
But if you ever want to explore more of Forth, GForth is there as a represtative of ANSI Forth. And I believe that now Forth, Inc. also offers a free verison of Polyforth .by Chuck Moore, himself. That used to be a very expensive version to buy.
Regarding accelleration. You start out with a Pulse and then a Delay, then you deduct a bit of time from the Delay and do another Pulse, and so on. This is a linear acceleration. If that works well we can stop there. If not, it will be a bit more complex to do an exponential accelleration. You will just have to figure out how many steps you want to build acceleration with. Nobody knows the right answer, but Forth will allow a trial and error process to get to it rather quickly.
If you are sure that you want to build accelleration over 120 degrees, we know that is 66 steps, so it would just be the delay factor. If the motion is to continue on without accelleration, the delay would not be reduced after 66 steps.. but the steps would continue.
If you have a different amount of revolution, just start with how many degrees and divide that by 1.8 degrees to get the number of steps.
Alterntively, you might have an actually number for angular acceleration and can do some fancier maths to get the decreases in delay and the number of steps.
~~~~~~~~~~~~~~~
But at this point, you are getting a bit ahead. I just want you to get all the wiring good to go. And then be able to use PropForth to verify that all your inputs are right and all your outputs are right.
Once you have a confirmed bench top build. We can start putting all the pieces of software together into one routine. Also, that is the point at which you will mount the stepper motor and the Cherry Proximity sensors in the sculpture to see what is really happening.
The biggest advantage with using Forth, in this case PropForth, is that you can immediately observe your motion and adjust it until you are satisfied. But the other excellent thing is that you can test all your wiring in separate bits so if there is a fault, you don't have to guess where it is.
1. Have you arrived at a point where you are confident about all your wiring?
2. Have you decided which i/o pins are going to be used of the 3 outputs and the 2 inputs?
If you have gotten that far and feel the wiring is safe, you need to actually load PropForth and use it with the i/o.
If you are unsure and what to operate just PropForth for learning, you can load it in the QuickStart and NOT have the board connected to the Cherry Proximity sensors or the Stepper Motor controller.
While a lot of software provided from Parallax comes with elaborate software editors to write and do the housekeeping chores.
PropForth is much simpler. You have two ways to write programs.
A. Direct input from the keyboard that creates new words.
B. Writing to a ASCII document and then using 'cut and paste' to enter a program rather than having to retyping the whole application. For these purposes, a very simple editor is use - as we need clean ASCII 8 bit code.
Generally, the way to start over is to reload the PropForth image clean, without any of your program additions to EEPROM.
Also, the 'B' option is enhanced by have a few special words that will help you to load large programs by ignoring and notation you might put in them to remind you what has been done. This is certainly NOT the same as what Brodie presents in a traditional Forth... he presents the older Block system that is NOT used in PropForth as there is no hard disk storage.
~~~~~~~~~~
If you can understand what I have said here, and can provide me with a map of the i/o you are using for your six pins --- I can write small test programs for you to use and post them in the Forum. Then you can just 'cut and paste' them to load the whole into the PropForth.
In that way, you can move along more quickly.
But we have to first be sure you are confident that the wiring is right.
First choice for the i/o allocation is the 12 uncommitted i/o pins as they are the simplest to manage.
Second choice is the 8 touch switch input, and these pins can be used as either inputs or outputs. But touching the touchswitch will interfer with their behavior.
Third choice is the LED outputs, and with a bit of care these too can be used as inputs or outputs -- but you will at times have LEDs blinking.
Fourth choice are the 4 remaining i/o pins that have 2 dedicated to the EEPROM and 2 for Rx and Tx of the Programing ports. There are very specific ways to exploit them and you really have to be careful to not conflict with their original purposes. In other words, they are best avoided for now.
I have not done any wiring to the QuickStart yet because I wanted to get PropForth loaded so I can experiment with toggling some LEDs. I spent alot of time yesterday trying to get PropForth running with a terminal program. I first loaded Tera Term and couldn't seem to get the program to do a simple stack command. I was exploring if I had a communication problem between the PC and the QuickStart when I discovered that Prop Tool software includes the Parallax Serial Terminal. I successfully configured the terminal with the appropriate COM port but I still could not do a simple stack command. Not sure what my problem is, ie in the use of the terminal or something else.
I thought maybe that the DevKernal.spin program for PropForth was not properly loaded on the QuickStart.I initially loadied DevKernal into RAM, but then loaded on EERPOM. The Prop tool seemed to do both fine, but later in my repeated attempts to try to get the terminal program to handle a simple stack command, I decided to reset the QuickStart and reload the DevKernal. When tried to load the DevKernal into RAM or EEPROM, the Prop tool started giving me an error "Propeller chip lost on COM17". The error comes up after clicking on Load RAM, which then displays a dialog box that reads "Loading RAM" with a progress bar, then "Verifying RAM" with a progress bar, followed by the error. I have screwed something up, and I am experimenting with few things. Any suggestions?
Do you recommend using Parallax's terminal program, Tera Term, or another?
Am I supposed to load the DevKernal.spin for PropForth into EEPROM?
Does the EEPROM contents get totally written over every time something is written to it?
As for the wiring, I think I will use pin 8-10 as outputs and 11 & 12 as inputs. Those pins are all uncommitted.
There are multiple versions of PropForth and you need to be careful which one you use at this point. I recommended V5.0 because V5.5 was headed towards adding a lot of features I don't use. I am not sure of its status. But it looks like V5.5 is the only version available for download, so we will have to work with that.
And then, there are a 32K EEPROM version and a larger 64K EEPROM version. For the QuickStart you actually have the 64K EEPROM, so both will work.
Also, there are .spin files you should not load at this time. They are for advanced users and the creator of PropForth provided them to allow others to extend PropForth.
I think you want a PropForth.spin and not DevKernal.spin or others. See, the link below.
I think that once you have downloaded the PropForth V5.5 zip file and unzipped it, read the ReadME.txt file. And then use one of the .spin files in the /Current Releases as your first PropForth. Only one is suggested for new users.
Well about Terminal software....
Parallax's terminal program within the Spin IDE for loading the EEPROM will work fine with PropForth. You don't really need to go further. I find it quite handy.
There are a lot of free terminal programs, like Tera Term. Tera Term will work, you just have to get the settings right.
I never use it as I generally am in Linux, so my choice of a terminal program is a bit different. I use PuTTY a lot and it is available both in Windows and Linux, also Apple.
~~~~~~~~~~~~~~~
But the real core issue here is whether you understand serial terminal configuration at all. This is a serial communication terminal using an RS232 standard that is very handy and useful with microcontrollers. It should be mastered even if you don't use Forth. Just about every language supports it.
You are use the simplest form, just two wires -- a Transmit and a Receive. The standard allows other additional Flow control, but it is not used here and not needed. (Do you recall the RTS (Ready to Send) and CTS (Clear to Send) they are Flow control hardwire lines)
There are the basic configuration of 8N1 -- which is abbreviated jargon for 8 bits (not the 7 bits or less), N for no parity, and 1 for a stop bit that is 1 bit long (can be 1 and 1/2 or 2).
These days, just about everything uses the 8N1. In the old days, there were others.
There is no additional Flow control on the terminal program, and no delays in the default settings.
Getting the PropForth up and running first is much simpler. Mistakes you make on the bare QuickStart board are more forgiving.
And then the rate, called a BAUD rate or just plain old BAUD in units of bits per second. PropForth wants a 57600 baud rate, you may have something different, like 19200 bits per second.
Okay, the pins 8-10 for outputs, and 11-12 for inputs are just fine. But I can't write code unless you assign specifics. Which is Step, which is Enable, which is Direction, which is Start sensor, which is Stop sensor?
~~~~~~~~~~
You say you can't get the stack commands to work right. In PropForth they are different.
To first test the Serial Port Connections, try something else.
Try typing 'words' and see if the report looks right. If it does, you are just having beginner's problems with the oddities of PropForth. There serial port is working fine.
You can do some math
1 2 + and return should give you 3. If not try a period ( . ) to pop it from the stack.
Try reading the PF_QUICK_REFERENCE to identify the different commands or word through the first portion the PropForth HTML tutorial.
I will wire the pins as follows:
p8 Step (output)
p9 Enable (output)
p10 Direction (output)
p11 Start sensor (input)
p12 Stop sensor (input)
The parallax terminal program only asks for COM port and baud rate. Unlike Tera Term, it does not ask for the basic configuration of 8N1, so I assume it defaults to that. I am dead in the water until I determine why I am getting the communication error. I have posted my issue on Parallax general forum, but no response yet. Googling the error I find others have had the same problem, but I have not found help for a solution. Could I have permanently damaged the QuickStart with merely improper use of the Prop tool ???
I spoke with Parallax tech support, and they too are stumped. I will go over to swap out boards within the hour. Its nice having Parallax headquarters only 10 miles from my home
I doubt that you damaged the QuickStart, but you may have loaded a junk program into the EEPROM.
You are using the Prop Tool. I may be wrong, I might have been using the terminal in Brad's Spin Tool, known as BST. It is another way to write Spin and load the EEPROM.
If you have found the right image of Propforth 5.5 in the /current release subdirectory.. try reloading and try to use either Tera Term or PuTTY.
When PropForth is properly loaded, a reset should have it come up with a message right away. From there, you are good to go.
If you are really worried about damage, try loading one of the touchswitch and blinking LED programs you first used. That should work and confirm the board is okay.
What you are experience is a normal situation for new users.. don't panic. It gets easier.
Communication error? Is your USB cable plugged in properly and the only source of power?
Disregard my PM question on the pulse duration. I realized you had answer it previously.
[FONT="] I still need to learn how the stepper is pulsed with Propforth. Is the pulse related to the duration of the voltage at a given pin? [/FONT]
You don't have to repeat setio or startup. The Enable is on by a low pin 9, and you can observe whick direction is a low pin 10.
If you have trouble observing motion on the shaft, just stick a piece of tape on it and do 5 or 10 steps.
: 5step step step step step step ;
5step 5step <enter>
All that should work to confirm the OUTPUTs if the wiring is right.
We will have to do something else to test the INPUTs
~~~
I think it would be better to post here than in a PM. In the PM, I don't get to have a record to review of what I have written to you. Once the message is gone, it is gone and only you have a copy.
I have to confess that I've not used PropForth for several months and have forgotten a bit of it.
I am still trying to recall how to use the word 'words' to look for a short list... say all the items that start with 'p' or other wildcard searches. I have gotten rusty. The problem with using the 'words' comand is that the whole list just quick rolls by.
Let me know if you are getting a good rotation and are satisfied with how quite the device is.
: fullspin 51200 0
do i .
step
loop
;
The motor made a full spin, which took about 2 minutes to do so. The motor runs very quiet. Without the slight vibration of the motor resting on the desktop, I could not hear the motor. I think I am ready to add the hall switched into the circuit.
Great, I was worried that 3.3v output of the Propeller might not be enough for the stepper motor controller. You wanted no hum, no noise, and no fan. It seems that we achieved that.
Input is a bit different because you have to create an infinite loop that looks for a change in input pin status.
When you get the expected change, you jump out of the infinite loop and execute your task... then you return to infinite loop.
OR, you jump out of the Start infinite loop and go into another infinite loop that tests for a Stop condition before going once around the loop again.
The first option was what we originally had planned, but you seem to have shifted to the second option.
~~~~~~~~~~
PropForth has a feature called 'fastload'.
Fastload allows you to create software applications as whole txt files with commentary and then load the entire document as a block cut and paste to the TeraTerm screen at one go.
To make this work, one has to begin a text file with an 'fl' on the first line and nothing else, and an 'fl' on the last line.
Commentary in PropForth is not quite the same as standard ANSI Forth.
For comments of unlimited lines, use the { and the } to surround the comments and these have to be on an empty line.
For comments on just one line, maybe after a bit of active code, you a / and a space, then your comment
So a fast load text file would look something like this. Be aware of what needs to be on its own line.
A Fastload Code Style Example
~~~~~~~~~~
fl
{
This is an example of a fast load PropForth .txt file. blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah,
}
: newword 1 pinhi ; / a comment to explain that the Pin 1 will go high
/ a single line of comment that is not following a bit of code.
fl
~~~~~~~~~~~
Fastload has the code within it to ignore all the commentary, so it makes your text files easier to manage. Without fastload, you would have to keep your .txt files without commentary.
I think that is a good style example, but I am working from memory. Everything goes into RAM, if you want it all to go into EEPROM so the PropForth will still retain it, you will have to use 'saveforth'.
I will try to write up you input testing as a fastload .txt file.
We are getting very close to being able to write the complete application.
The completed application in PropForth will have the advantage that you can easily insert or adjust timing delays to get the right acceleration and motions that you want while observing the sculpture in real time.
As I said before, with Spin or C, you have to write-compile-load-test, and then start over again.
Even if you want the final program in Spin or C, PropForth will give you all your timing information much faster during the developmental stage.
I have to dig a bit to find out how PropForth will 'autostart' you program in the final form when power is turned on. I know the feature is available, I just never used it.
******************************
BTW, all the provided Extensions to PropForth in XXXXX.f files are really just text files with the Fastload feature. The .f is just there to remind you it is code for a PropForth device.
After experimenting with the stepper configuration. I have found that the using a microstep of 1/256 and pausing between pulses by 1 ms, a single rotation of the motor takes about 2 minutes. If 1 ms is the shortest delay in Propforth, I assume that I need to decrease the microstep setting to achieve a faster rotation. Is that correct?
I changed the microstep setting from 1/256 to 1/2 and was able to speed up a single rotation to about 1 second.
I have determined that initially I want the stepper motor to run for 2.5 seconds with a final velocity of 360 degrees per second. As you know, the stepper will actually rotate 120 degrees during the 2.5 seconds that lapse between tripping the start and stop sensors.
BTW, the reason I changed my design from a defined angle of rotation to the use of a 2nd sensor was because I needed to protect against a possible interruption of the stepper circuit. For example, if for any reason the stepper does not complete a full 120 degree rotation, mechanical components will be misaligned with the stepper's irregular rotational position. Upon reboot of the QuickStart, the stepper will be able to complete its full rotation and realign itself with other mechanical components with the help of a stop switch.
I have begun writing pseudo code for my Propforth program. I am thinking about using a clock counter that would start when the start switch is tripped. The continuous loop would end with the tripping of the stop sensor. During the time that the loop is running, the velocity would gradually increase using an acceleration equation that I developed in excel. I concluded that I need an exponential equation that uses 3 constants. Although linear would have been easier, it is not too complicated.
I am still thinking about how to translate a desired velocity into a given delms value for a given step. Within the loop, I would use the clock counter to keep track of the number of ms since the start switch was tripped. The length of time in the loop will define whether or not the motor gets a pulse on a given pass. I start to taper the acceleration off when the the rotation is at about 90 degrees, ie the 120 degree stepper rotation is about 75% complete. The stop sensor will be mounted at the 120 degree position.
Using the clock counter and the acceleration equation as a reference, I hope to track how many steps have occurred at a given clock counter value. For example, one second after the start sensor is tripped, I hope to expect to confirm the following:
- The clock counter will be at 1000 ms
- Based on my acceleration equation, the 120 degree rotation will be 40% complete, ie stepper rotated 48 degrees.
- The loop will have pulsed the stepper about 53 times (based on 400 steps/rotation 1.11 degree/step, so 48 degrees x 1.11 = 53 steps)
I am sure that my assumptions above will change once I better understand the how the propeller chip works. For example, I have assumed that the total time lapse for 1 pulse is about 1 ms. But that assumes virtually all of the pulse time is the 1 delms between a pinhi/pinlo command. I realize that the pinhi/pinlo time lapse will be some amount of time, but since we are dealing in ms with the delms limitation, is the time lapse for the pinhi/pinlo sequence something to consider.?
Also, can I use a clock counter to do what I have explained.
I look forward to hearing your thoughts and suggestions.
Well, we are at the point where you can experiment with parameters.
If you really need less of a step delay, there are ways to do so. A new Forth word would need to be created in assembler language to do microsecond delays.
But the first question is whether you really need the microstep to be so small for the sake of smoothness or quite running. If not, it is simpler to just use less steps.
You have to observe and decide.
The advantage to not using any microstepping at all is that the stepper motor and stepper motor controller run more efficiently and the way that the stepper motor was originally intended to operate. Microstepping is a bit of creative electronics.
Additionally, with bigger step angles you have more time between steps for the Propeller to do a calculation and seek the right delay value if you are using some sort of complicated acceleration calculation.
Try to keep things as simple as possible, but don't worry if the code evolves into something fancy.
~~~~
All along I figured that you were likely to change things as the design evolved. I have tried to make sure you got a hardware setup that was both cost effective and powerful enough to adjust to whatever changes you came up with.
Still, it was a bit of a gamble that you might suddenly discover you need even more powerful items. One really has to bench test to see what you really have.
~~~~
Are you up to doing the Cherry sensor code on you own, or do you need me to start you off? You really are very near to writing a complete version 1 of your application. But you still have to get things started by typing in the Forth word to start the automation loop.
If you want my help, please tell me the actually step size you decided on as it is of key importance to doing any timing calculation.
Once you get a version 1 or version 0.1 working, you can tweek the code and observe until you get exactly what you want for movement and response to sensors. That is where inserting delays are useful. Acceleration indicates that you want the delay to change each and every step in a decreasing... and this can be done with a math formula, or it can be done with a look up table that just keeps jumping to the next entry on the table.
By using the lookup table approach, you can create a curve than is near impossible to describe with a a math formula.
The choice of formula or look-up table is really up to you. If you can get an exact value for delay of each step in an Excel sheet, you can used that as a look-up table and avoid having the Propeller repeat the maths. A look-up table is a much faster algorithm that a recalculation after each step.
I'd like to see your pseudo code. You seem to have added another layer of code to reset the machines position in the case of poor alignment. It sounds like a good idea, but there is the question of how it fits in.
At this point, I am trying to figure out how PropForth will autostart, once you settle on your right code. That is the final piece of the puzzle. Prof Brain assures me it is possible but seems to have forgotten exactly how it is done.
So I am doing some bench testing of code for that objective.
~~~~~
It certainly seems to be coming together well. But I am sure there will be more discoveries and more changes before you get to a finished project.
I have concluded that microstepping is not necessary.
I am ready to add the Cherry switch. I understand that I am to use a 1k resistor in series with the Cherry Output lead. However, I want to confirm with you that the Output lead is connected to one of the two defined input pins and the VCC lead is connected to the QuickStart's VDD terminals. Is that correct?
If a lookup table is faster than repeating the acceleration calculation, I'l go with the lookup table. I developed my acceleration curve by simply defining 4 points of a curve shape that I wanted and then had excel create the curve fit and equation. The lookup table is in 1 ms steps. So, because the total rotation time span is about 2.5 seconds, the lookup table has 2500 rows. Is that too much?
To get me started, I would appreciate any help in providing Propforth code for a continuous loop that begins when pin 11 goes hi (input pin for start sensor). Also, a clock counter would start when the pin goes high, and during each pass of the loop, the current value of the clock counter would be used as an index, rounded to the nearest whole ms, to retrieve a value from a look up table. The continuous loop would end when the clock counter reaches a value of, say 2500 ms.
Once I have this code, I will try adding code that will control the pulse rate with the frequency of the delays and do some experimenting with the hardware.
After finding a successful pulse rate, I will then add code to use the stop switch to end the motor pulsing loop instead of using the 2500 ms limit from the clock counter.
I am happy to hear the microstepping is not needed, but in some future project it might.
Okay, The Cherry switch calls the 3rd wire 'output', but when activated by the Hall effect sensor, it really pulls whatever is attached to it to near ground.. that is the open collector configuration. The Hi/Low condition is provided by a combination of the pull up resistor and the open collector device, with the input to the Propeller attached inbetween
So we have a rough ASCII schematic as follows. (ignore the dots)
NOTICE - only the Output and the Ground of the Cherry sensor are shown below, the +4.5 to +24 power is NOT shown.
...
+3.3V
.. |
.. \
.. / 1 K ohm resistor (you provide a 1/4 resistor)
.. \
...|________ Cherry output connected to Propeller Input pin
...|
... \ collector (inside the Cherry sensor)
.... \|
......|
base--- to Hall Effect senor (inside the Cherry sensor)
...../|
..../ emitter connected to ground (inside the Cherry sensor)
... |
. _|_
... ground
What you and Cherry call 'output' is the transistor's collector, the emitter is connected to ground inside the Cherry sensor. And the base of the transistor is controlled by the hall-effect sensor.
I am purposely avoiding using Vcc and Vdd terminology and using +5, +3.3, and ground for greater clarity.
The Cherry sensor requires more than 4.5 Volts to operate and also has a built in voltage regulator that allows you to use anywhere from 4.5 to 24 volts for power.
You DO need to providee +5VDC to the Propeller QuickStart to provide power to both the Propeller chip and the USB interface. But the Cherry sensor could operate with +24 directly connected to the plus side just as easily as using +5VDC.. but the internal voltage regulator would run hotter. So use +5VDC for now.
The Safety issue is that the Propeller is limited to 3.3VDC on its inputs. And the open collector configuration requires you to pull the Propeller input high. So the 1K resistor provide the HI signal to the Propeller, the 1K resistor makes it easier for the open collector to pull it to near ground when turned on, so the input see a LOW.
You may have seen the 1K resistor recommended for 5 Volts in the Cherry document and the same document has nothing recommended for 3.3 Volts. Do not worry about this, pullup resistors are NOT an exact science. But using less that 1K just means it consumes more power.
And so, you have the Cherry outputs connected directly to the Propeller inputs, but if you don't include a 1K on each that pulls the input to 3.3V, it will either float or go low. The pull up resistors make the inputs behave properly.
DO NOT attach the pull ups to +5 or any other voltage higher than +3.3V as you risk damage to the Propeller input pin.
~~~~~~~~~
I am a bit embarrassed about mentioning Look-up Tables. Why so?
These are extremely easy to do in SPIN or C, but Forth doesn't easily accommodate a Look-up Table.
So after we finish testing your Cherry senors and run some trials in Forth, you might want to take what you learned and provide a finished program in Spin or C.
There is no reason to stay with Forth if it is going to be more complicated to get a nice clean program. The Propeller doesn't care which language you use and all of them are free.
Timing can be less predictable in Forth because it has to search the Dictionary for the words every time you call them. Different words might be fast or slow to perform in different ways.
For robotic control, you want 'deterministic timing'. That means you want to be sure the timing will be always performed exactly the same.
~~~~~
I think the PropForth continuous (infinite) loop is as follows.
: Mainloop begin 20 delms 11 px? 1 - until stepper ;
1. Mainloop would start a loop that would test Pin 11 for a true or false condition
2. The word stepper would be your stepping sequence.
3. The loop would test the pin every 20 milliseconds
4. When Pin put a 'true' on the stack, the loop will be jumped out of and stepper would start.
5. Get back into watching Pin 11, you would have to call Mainloop at the end of your word called stepper.
6. Or you could jump into a similar look for Pin 12 as follows
: 2ndloop begin 20 delms 12 px? 1 - until other ;
7. The 2ndloop would wait for the 2nd Cherry sensor and then jump to a word called other.
~~~~~~~~~
Be careful of what is a true condition. You want a HI input to be read as False and a LOW input to be read as True. But px? reads a HI as True, and a Low as False.
A true is indicated by BEING equal to 0 and False is indicated by being NOT Equal to 0.
So a High providing a 1 is okay as a False, and a Low providing a 0 is okay at a True.
But any number positive or negative will indicate a False.
You will notice that I subtract 1 from what px? puts on the stack so that 'until' will see the 'true' and 'false' properly.
Let me confirm my understanding of your Cherry switch wiring explanation.
- With the Cherry switch is in its normally Open configuration, the current flows from the 3.3v through the 1 k resistor to input Pin 10; thus the propeller sees the input as high.
- When the Cherry switch closes, the current flows to ground through the 1 k resistor and the switch; thus the propeller sees the input as low at input pin 10.
- The code needs to handle a high signal at pin 10 as false since that is when the Cherry switch is open.
Did I get that correct?
[FONT="]"And so, you has to Cherry outputs connected directly to the Propeller inputs, but if you don't include a 1K on each that pulls the input to 3.3V, it will either float or go low. The pull up resistors make the inputs behave properly[/FONT]"
Not clear with what you mean. My understanding is that I only need one pull resistor in the switch config. and that is between the 3.3v terminal and the collector lead/pin 10 junction as shown in your schematic.
I would rather use 5v to operate the Cherry switch rather than 24 v from the controller ps. So, can you explain again how I am to power the switch with 5v? Does the +5v connect to the base lead (VCC) of the switch?
NOTE - I did a lot of revision and correcting to this after first posting.. so re-read to see if it now makes sense.
Your first part is 100% right.. you understand what the pull up and open collector are doing.
IN the second item, forgetting to insert the pull up creates a condition where the input may 'float'. That means that it might randomly indicate high or low due to static electricity in the surroundings. But if the hall effect sensor does trigger the open collector, it would go to a real low. You just can't be certain the condition is real or false, so you must have the pull up.
If you forgot the pull up resistor, nothing would be damaged, it just would not work right.
Third, the Cherry has three connections - a Vcc or +, and output or O, and Gnd or ground.
The Vcc can go to +5VDC from the converter. The Gnd can go to Ground from the converter.
NOTE - Vcc and Vdd can be different voltage levels of + OR simply indicate a different semiconductor is being used. This perpetually confuses people and causes problems. Vee and Vss are negative, below Gnd.
To make things even more confusing, some devices just use plus and minus, where minus often is the same as Gnd.
The main thing is to not create loops in the Ground connections as they create some exotic problems (such as picking up interferance from household A/C in flourescent lights). Use a tree-like distribution pattern for your Grounds. Since everything is connected to Ground, we sometimes don't notice we are creating a loop by redundant connections. Just be aware of the potential hazard.
You use the term "base lead' for one of the wires in the Cherry sensor -- you just have a Plus, a Minus (or Gnd), and an output.
The final stage inside the Cherry sensor is an NPN transistor and that transistor has a base lead that goes to the amplified hall-effect sensor. You have no way to wire anything to that 'base lead'. I just tried to provide a diagram of how that final stage NPN exists so you have some idea of what an Open Collector is.
Open Collectors are very very handy as they will handle a lot more power by pulling the output to ground. The other alternative that is not an Open Collector is to drive a High output for ON and that never provides as much power as an Open Collector. Also Open Collectors can combine with other Open Collectors to do some fancy things with logic that you can't do with other kinds of outputs.
Maybe you've answered this question when you said
"NOTE - Vcc and Vdd can be different voltage levels of + OR simply indicate a different semiconductor is being used. This perpetually confuses people and causes problems. Vee and Vss are negative, below Gnd.". But I just want to be sure I have this right. Do I connect the 1k resistor to the +5v terminal of the 24 to 5v Pololu converter? If I that is correct, will the propeller input pin handle 5v instead of 3.3.? If that is not correct, and only 3.3v can be input to the propeller, then what do I use for the 3.3 v source that is connected to the pull up resistor. I apologize if I'm being overly dense about this concept.
After studying the purpose of pull up and pull down resistors, I think I get it. My understanding of how the hall-effect switch works is that the operating voltage for the switch is the same voltage that gets passed to the Output pin when the switch is closed. If that is correct, and the switch can't operate at less than 4.5v and the propeller can't handle more than 3.3v, then what needs to be done?
If 5v is needed for the Cherry, then I need to add the pololu step down voltage regulator into the circuit. Your instruction on this was:
About the only thing I haven't mentioned is the +24VDC to +5VDC converter. It does come off the +24VDC output and can use telephone wire. Pololu strongly recommends an added capacitor on the input. It should be rated OVER +24VDC, at least +35V.. but +50VDC or +100VDC is equally okay. As best as I recall, they wanted 30uF. It you wire it backwards, it will blow up. So, the + to + and the - to - and stand back before you turn it on.
What is the capacitor for? The regulator is about 1/2 the size of a postage stamp and has 4 terminals labeled Vin, Vout, Ground, and SHDN?. I assume the 30 uF capacitor + lead connects to the Vin terminal and the - lead connects to ground. I also assume the the Vout will connect at the QuickStart's Vin terminal which is pin 39. Is all that correct?
I do not care what you call it Vcc or what ever, you connect on end of the pulllup resistors to the 3.3V on the Propeller QuickStart board. DO NOT connect it to a +5VDC, even if examples show that is correct. Those examples are for devices that will tolterate +5V inputs. The Propeller is designed for no higher than 3.3V.
Cherry did not publish an example for use with a 3.3v input device. If fact, its documents don't even consider that 3.3v input devices exist.
I specify the voltage and the polarity to avoid errors that might cause damage.
The jargon of electronics started out as an attempt to be very precise and clear, but authors on the internet have muddled everything. So I try to focus on the items that are important. And I try to point of the pit falls along the way.
You can adapt a Propeller input to accept a +5 signal by adding a 3300 ohm resistor in series to protect the input, but it is both simplier and better to have the pull-up on an open collector just connected to the safer 3.3V.
You would still need the 1K pullup as well as the 3.3K protector if you used +5. And performance would be degraded.
To repeat, we just don't have an explaination by Cherry of how to use their device to input to a 3.3V input. But I did check other details in the Cherry specs and the Propeller specs and this will work.
~~~~~~~~~~
The operation voltage of the hall-effect switch DOES NOT get passed through the output. It never passes through to the NPN collector. The output of the hall-event switch passes through the final transistor's emitter to GND.
With an open-collector, you can have a pull-up connected to any voltage you like within a range that the final transistor will tolerate. In some cases, people need +12 volts or +24 volts to drive a light or a relay.
That last transistor, an NPN that has its emitter connected to Gnd will nearly always handle 30VDC or less at its rated current (here it is 20ma max). Some other transistors are able to handle as much as 60VDC, and much more current. It is ALL ABOUT what the final transistor is able to do.
~~~~~~
Why do you need a +5 volt supply?
A. Most importantly, to power the QuickStart board via Vin when you want to use it without the USB connected to anything.
B. The Cherry Proximity Sensors will run cooler at +5 (but need more than +4.5) than at higher voltages such as the +24.
What is the capacitor on the +24VDC for?
The capactor located nearest to the inputs of the Pololu board is to protect the +24 to +5 device from potential damage due to spikes on the +24VDC power line. You might be fine without it, but Pololu does recommend it.
HERE is what Pololu says.. use a 33uf or largercapacitor, maybe 50V or higher rated.
LC Voltage Spikes
When connecting voltage to electronic circuits, the initial rush of current can cause voltage spikes that are much higher than the input voltage. If these spikes exceed the regulator’s maximum voltage (42 V), the regulator can be destroyed. In our tests with typical power leads (~30″ test clips), input voltages above 20 V caused spikes over 42 V. If you are connecting more than 20 V or your power leads or supply has high inductance, we recommend soldering a 33μF or larger electrolytic capacitor close to the regulator between VIN and GND. The capacitor should be rated for at least 50 V.
More information about LC spikes can be found in our application note, Understanding Destructive LC Voltage Spikes.
Ok, it is clear to me that a pin's input voltage can NOT exceed 3.3v.
You can adapt a Propeller input to accept a +5 signal by adding a 3300 ohm resistor in series to protect the input, but it is both simplier and better to have the pull-up on an open collector just connected to the safer 3.3V
I'm confused. I understand that the 3300 ohm resistor would limit current but it wouldn't reduce the voltage from 5v to the safe 3.3v, would it?Given the required 5v for operation of the Cherry switch, can I achieve the 'simplier and better' solution of using 3.3 v as input to the collector?
If this can be done, I think I understand the wiring of the open collector (Cherry's Output) in that the 3.3v terminal on the QuickStart (labeled Vdd) is connected to a 1k pull up resistor and the other end of the resistor connects to input pin 11 and the Cherry Output lead. What does the Cherry lead, labeled Vcc connect to? 5v? Again, I apologize for being super slow here.
Well, at some point I just run out of simple answers and have to teach electronics.
A. The simple answer is use a 1K pullup connected to +3.3v
B. The messy answer is to use a 3.3K resistor to protect the Propeller input AND then a 1K pullup to +5.0 volts (That is 2 resistors)
C.Or the slick answer for +5v is to use a 3.3K pullup to +5.0 volts (only 1 resistor needed).
How did I arrive at C? Thevin's equivalent circuit analysis. Killing 2 birds with one stone.
~~~~~~~~~~~~~~~~~
But whichever you do, the Cherry documents won't provide an answer as they don't consider input to 3.3v devices. And, you really need to learn some electronics to understand that the different ways inputs are used (with pullups, with pulldowns, or with a driven Hi/Low)
Pulldowns are to Ground, so there is nothing much to consider.
Pullups are wisest with the voltage being only to the maximum recommended.
Directly driven hi/lows for the Propeller have been discussed quite a bit and a 3.3K resistor will make the +5 volt HI safe for the Propellers +3.3v limit.
~~~~~~~~~~
I am willing to admit that there are a lot of different ways to do this. But since you have 3.3 volts available, it seemed cleanest to just have the pullup resistor connect to that. If you really want to have a +5 volt source connected to the pullup, it is up to you.
~~~~~~~~~
What does the 3300 ohm resistor do? Well, in combination with the tiny protective diodes that the Propeller has on the inside of each i/o, engineers and Propeller users here have figured out that the Propeller i/o will work just fine. It seems to be the equivalent of a voltage divider that removes any chance of stress to the Propeller's i/o.
In the below link, Beau Schwab says a 1K resistor is adequate, but there are more threads with a huge debate that ended with everyone pretty much accepting a 3.3K resistor was much better. I really don't want to bore you with reading very long threads that go back and forth in debate or the value of one resistor. Some of us use 3.3K and others hang onto the 2006 posting by Beau and use just 1K.
After reading about voltage dividers, I understand the concept of 2 resistors splitting voltage between a ground and a input pin.
I appreciate your listing of the various options, and I agree that we should keep this simple...even though my ignorance has probably frustrated the heck out you.
"since you have 3.3 volts available, it seemed cleanest to just have the pullup resistor connect to that." Are you referring to your option B? Rather than continuing my pestering questions, can you simply sketch a schematic similar to what you provided yesterday that shows exactly how the Cherry leads and resistor(s) are configured with the the 3.3v source that you believe is the cleanest solution?
I think If I have a schematic to study rather than a narrative wiring description, I will understand it sooner and better. Once again , I appreciate you r patience!
Comments
Excuse me but there is no "maybe not" about this proposal! This stuff does work...have you actually had any experience with closed-loop servo motion control systems? I'm guessing no!
Mickster
P.S. However, I wish the OP luck in following the prescribed solution as the DIY, home-grown approach certainly is much more fun and educational and will provide much more satisfaction than my proposed off-the-shelf alternatives.
I have begun setting up my hardware configuration, but I am trying to do so without soldering to the QuickStart. I am using wires from the 40 pin socket to a breadboard, so I think I will be ok. I may have to solder a few wires if we need to use J4-J7. I won't be energizing anything until I confirm my wiring config with you.
Most of the wiring centers around two items -- the stepper motor controller, and the Cherry Proximity sensor. I don't think you need to add a breadboard as an intermediate at this point.
Everything should be adequate with solid copper telephone wire, except the power supply to stepper motor controller. I suggested a bit heavier to accomodate the full 5 amps.
You do need to use J4-J7 for extra ground connections, but I don't think you need the 3.3V side. The 40 pin 2x20 has one 3.3V for your pull-up.
About the only thing I haven't mentioned is the +24VDC to +5VDC converter. It does come off the +24VDC output and can use telephone wire. Pololu strongly recommends an added capacitor on the input. It should be rated OVER +24VDC, at least +35V.. but +50VDC or +100VDC is equally okay. As best as I recall, they wanted 30uF. It you wire it backwards, it will blow up. So, the + to + and the - to - and stand back before you turn it on.
The other side is pretty simply - a +5VDC and ground output. Version B of the QuickStart board has some discussion of modifications to properly isolate power. I am not sure that applies. But you would put the +5 to one of the 40 pin 2x20 +5VDC, and the other side to Gnd.
I will get back to you regarding any possible need to modify the QuickStart, but find out if you have a Version A or Version B.
~~~~~~~~~~~~~
PropForth has the words you need, not GForth. You are 100% correct about this.
There is a reference list that is good enough, but not 100% up-to-date. I think it came out with V3.5
It is the PF_Quick_Reference.zip https://code.google.com/p/propforth/downloads/detail?name=PF_QUICK_REFERENCE.zip&can=2&q=#makechanges
You will need the following words to control pin output and input
pinout
pinhigh
pinlow
pinin
px? (This will sense Hi and Low for an input)
There are also the Definite Loop to get a specific number of steps,
and the Indefinite Loop that you will run to sense the input hi or low, and when low it will jump to a state machine to take action as you decide.
See delms for inserted delays in loops.
There is NO one second delay (was delsec in an earlier version), just the 1 millisecond delay. You can't get down to 10 microseconds, but 1 millisecond for your Pulse should do fine... it just should not be less than 10 microseconds or you may not get the motor to step.
As you will see, the PF_QUICK_REFERENCE has a heck of a lot of words you don't need to know about at this time.
One of the greatest hazards to a new learner in Forth is to try to learn each and every word right away. If you are experienced with other computer languages in great depth, it might be fun. But if you are on your first microcontroller, it is way over the top to expect to understand all right away.
Are you just jumping in without reading the whole thread? You come into the thread very late and suggest we completely restart what has been done.
The Animatics Smart Motor does seem good, but the PIC controlled items seemed at first impression to similar to we went with. Besides, all the stuff has been purchased.
BTW, I do admit that there are new products that combine the stepper motor and the stepper motor controller all in one package. Or other ones, that package a servo motor and contoller in to one package. But I went with something that was reasonable on Ebay, not the more costly leading edge.
Your salesmanship is very compelling, but maybe not considering a new user's situation or wishes. And you are right, I've no experience with closed loop servo control systems. Why? Good ones are usually very proprietary and expensive.
Set aside the selling and tell me how many Man-hours you are willing to provide to help a rank beginner get what he wants in a cost-effective manner?
http://tw.animatics.com/
http://www.jrkerr.com/
I have the Version B QuickStart
Will I be writing the code in the Gforth environment, but using some of the PropForth words? Can you elaborate on how that will work?
Since I will be using a second Cherry switch to terminate the stepper movement, is the use of a Definite Loop relevant?
You need to load the QuickStart with PropForth (I guess for a 32K rom) and play with it independently of GFORTH. There are some differences is style. For one, PropForth requires the right case. And so words for looking at the stack are different.
GForth is just good for working with Brodie's book, "Starting Forth". Brodie never anticipated Forth on parallel microcontrollers. So he is easier to study in GForth on a regular computer.
~~~~~~~~~~~~~
Now you want 2 Cherry Proximity switches? That is not really a problem. But you will need a combination of at least one infinite loop and one or more definite loops.
~~~~~~~~~~~~~~~
I need to get a better idea of what cycles you expect the program to do. Maybe one infinite loops until a start, and another infinite loop until a stop.
The thing that worries me as that you were talking about accelerating or decelerating the step rate. Is that still something you want?
~~~~~~~~~~~~~~
Yes, Vin is for a +5VDC input. But if you only have the USB providing power, it can provide a little +5VDC output. I think you previously mentioned it was at +4.77, a little low, but not too low for the Cherry Proximity sensor.
In other words, the Vin is supposed to be Vin, but one can borrow a wee bit of +5 from it.
This bring up another fact. You will have to provide a +5VDC to the QuickStart, and a +5 to each Cherry Proximity sensor. It is best practise to do all directly from the +24 to +5 converter, and to provide GND for both directly from the converter as well.
Too many grounds create something called a 'ground loop' and that can cause problems occasionally. So ground connects should avoid loops and be distributed in a tree-like distribution pattern.
~~~~
On other fronts, it is income tax time in Taiwan and I may have to spend a few days of intense number crunching for that. I am not sure I will respond to your emails as quickly as I have up to now.
I won't need to decelerate, but I I will need to be able to accelerate. This is because, although I will be using a spring to absorb some of the inertia the sculpture initially exerts on the stepper drive mechanism, I want to minimize the amount of dampening work done by the spring. In order to do this, the stepper can't just start abruptly at a constant speed.
Hope your tax prep goes well. Propforth will keep me plenty busy during the fun you're having :-)
PropForth is different enough that I don't want to get too attached to "Starting Forth" and GForth. PropForth has its own tutorial.
But if you ever want to explore more of Forth, GForth is there as a represtative of ANSI Forth. And I believe that now Forth, Inc. also offers a free verison of Polyforth .by Chuck Moore, himself. That used to be a very expensive version to buy.
Regarding accelleration. You start out with a Pulse and then a Delay, then you deduct a bit of time from the Delay and do another Pulse, and so on. This is a linear acceleration. If that works well we can stop there. If not, it will be a bit more complex to do an exponential accelleration. You will just have to figure out how many steps you want to build acceleration with. Nobody knows the right answer, but Forth will allow a trial and error process to get to it rather quickly.
If you are sure that you want to build accelleration over 120 degrees, we know that is 66 steps, so it would just be the delay factor. If the motion is to continue on without accelleration, the delay would not be reduced after 66 steps.. but the steps would continue.
If you have a different amount of revolution, just start with how many degrees and divide that by 1.8 degrees to get the number of steps.
Alterntively, you might have an actually number for angular acceleration and can do some fancier maths to get the decreases in delay and the number of steps.
~~~~~~~~~~~~~~~
But at this point, you are getting a bit ahead. I just want you to get all the wiring good to go. And then be able to use PropForth to verify that all your inputs are right and all your outputs are right.
Once you have a confirmed bench top build. We can start putting all the pieces of software together into one routine. Also, that is the point at which you will mount the stepper motor and the Cherry Proximity sensors in the sculpture to see what is really happening.
The biggest advantage with using Forth, in this case PropForth, is that you can immediately observe your motion and adjust it until you are satisfied. But the other excellent thing is that you can test all your wiring in separate bits so if there is a fault, you don't have to guess where it is.
1. Have you arrived at a point where you are confident about all your wiring?
2. Have you decided which i/o pins are going to be used of the 3 outputs and the 2 inputs?
If you have gotten that far and feel the wiring is safe, you need to actually load PropForth and use it with the i/o.
If you are unsure and what to operate just PropForth for learning, you can load it in the QuickStart and NOT have the board connected to the Cherry Proximity sensors or the Stepper Motor controller.
While a lot of software provided from Parallax comes with elaborate software editors to write and do the housekeeping chores.
PropForth is much simpler. You have two ways to write programs.
A. Direct input from the keyboard that creates new words.
B. Writing to a ASCII document and then using 'cut and paste' to enter a program rather than having to retyping the whole application. For these purposes, a very simple editor is use - as we need clean ASCII 8 bit code.
I use Gedit in Linux, but you can use Notepad in Windows. There are a very long list of alternatives. See the below link, and any will work.
http://en.wikipedia.org/wiki/List_of_text_editors
~~~~
Generally, the way to start over is to reload the PropForth image clean, without any of your program additions to EEPROM.
Also, the 'B' option is enhanced by have a few special words that will help you to load large programs by ignoring and notation you might put in them to remind you what has been done. This is certainly NOT the same as what Brodie presents in a traditional Forth... he presents the older Block system that is NOT used in PropForth as there is no hard disk storage.
~~~~~~~~~~
If you can understand what I have said here, and can provide me with a map of the i/o you are using for your six pins --- I can write small test programs for you to use and post them in the Forum. Then you can just 'cut and paste' them to load the whole into the PropForth.
In that way, you can move along more quickly.
But we have to first be sure you are confident that the wiring is right.
First choice for the i/o allocation is the 12 uncommitted i/o pins as they are the simplest to manage.
Second choice is the 8 touch switch input, and these pins can be used as either inputs or outputs. But touching the touchswitch will interfer with their behavior.
Third choice is the LED outputs, and with a bit of care these too can be used as inputs or outputs -- but you will at times have LEDs blinking.
Fourth choice are the 4 remaining i/o pins that have 2 dedicated to the EEPROM and 2 for Rx and Tx of the Programing ports. There are very specific ways to exploit them and you really have to be careful to not conflict with their original purposes. In other words, they are best avoided for now.
I thought maybe that the DevKernal.spin program for PropForth was not properly loaded on the QuickStart.I initially loadied DevKernal into RAM, but then loaded on EERPOM. The Prop tool seemed to do both fine, but later in my repeated attempts to try to get the terminal program to handle a simple stack command, I decided to reset the QuickStart and reload the DevKernal. When tried to load the DevKernal into RAM or EEPROM, the Prop tool started giving me an error "Propeller chip lost on COM17". The error comes up after clicking on Load RAM, which then displays a dialog box that reads "Loading RAM" with a progress bar, then "Verifying RAM" with a progress bar, followed by the error. I have screwed something up, and I am experimenting with few things. Any suggestions?
Do you recommend using Parallax's terminal program, Tera Term, or another?
Am I supposed to load the DevKernal.spin for PropForth into EEPROM?
Does the EEPROM contents get totally written over every time something is written to it?
As for the wiring, I think I will use pin 8-10 as outputs and 11 & 12 as inputs. Those pins are all uncommitted.
https://code.google.com/p/propforth/downloads/list
And then, there are a 32K EEPROM version and a larger 64K EEPROM version. For the QuickStart you actually have the 64K EEPROM, so both will work.
Also, there are .spin files you should not load at this time. They are for advanced users and the creator of PropForth provided them to allow others to extend PropForth.
I think you want a PropForth.spin and not DevKernal.spin or others. See, the link below.
https://code.google.com/p/propforth/wiki/GettingStarted
I think that once you have downloaded the PropForth V5.5 zip file and unzipped it, read the ReadME.txt file. And then use one of the .spin files in the /Current Releases as your first PropForth. Only one is suggested for new users.
Well about Terminal software....
Parallax's terminal program within the Spin IDE for loading the EEPROM will work fine with PropForth. You don't really need to go further. I find it quite handy.
There are a lot of free terminal programs, like Tera Term. Tera Term will work, you just have to get the settings right.
I never use it as I generally am in Linux, so my choice of a terminal program is a bit different. I use PuTTY a lot and it is available both in Windows and Linux, also Apple.
http://en.wikipedia.org/wiki/List_of_terminal_emulators
~~~~~~~~~~~~~~~
But the real core issue here is whether you understand serial terminal configuration at all. This is a serial communication terminal using an RS232 standard that is very handy and useful with microcontrollers. It should be mastered even if you don't use Forth. Just about every language supports it.
You are use the simplest form, just two wires -- a Transmit and a Receive. The standard allows other additional Flow control, but it is not used here and not needed. (Do you recall the RTS (Ready to Send) and CTS (Clear to Send) they are Flow control hardwire lines)
There are the basic configuration of 8N1 -- which is abbreviated jargon for 8 bits (not the 7 bits or less), N for no parity, and 1 for a stop bit that is 1 bit long (can be 1 and 1/2 or 2).
These days, just about everything uses the 8N1. In the old days, there were others.
There is no additional Flow control on the terminal program, and no delays in the default settings.
Getting the PropForth up and running first is much simpler. Mistakes you make on the bare QuickStart board are more forgiving.
And then the rate, called a BAUD rate or just plain old BAUD in units of bits per second. PropForth wants a 57600 baud rate, you may have something different, like 19200 bits per second.
Okay, the pins 8-10 for outputs, and 11-12 for inputs are just fine. But I can't write code unless you assign specifics. Which is Step, which is Enable, which is Direction, which is Start sensor, which is Stop sensor?
~~~~~~~~~~
You say you can't get the stack commands to work right. In PropForth they are different.
To first test the Serial Port Connections, try something else.
Try typing 'words' and see if the report looks right. If it does, you are just having beginner's problems with the oddities of PropForth. There serial port is working fine.
You can do some math
1 2 + and return should give you 3. If not try a period ( . ) to pop it from the stack.
Try reading the PF_QUICK_REFERENCE to identify the different commands or word through the first portion the PropForth HTML tutorial.
https://code.google.com/p/propforth/wiki/PFquickRef
st? will let you see the contents of the stack
sc will entirely clear the stack
To be completely honest, I have to plug in and set up a copy of PropForth at this point to be 100% with advice. I have not used it for many months.
p8 Step (output)
p9 Enable (output)
p10 Direction (output)
p11 Start sensor (input)
p12 Stop sensor (input)
The parallax terminal program only asks for COM port and baud rate. Unlike Tera Term, it does not ask for the basic configuration of 8N1, so I assume it defaults to that. I am dead in the water until I determine why I am getting the communication error. I have posted my issue on Parallax general forum, but no response yet. Googling the error I find others have had the same problem, but I have not found help for a solution. Could I have permanently damaged the QuickStart with merely improper use of the Prop tool ???
I spoke with Parallax tech support, and they too are stumped. I will go over to swap out boards within the hour. Its nice having Parallax headquarters only 10 miles from my home
You are using the Prop Tool. I may be wrong, I might have been using the terminal in Brad's Spin Tool, known as BST. It is another way to write Spin and load the EEPROM.
If you have found the right image of Propforth 5.5 in the /current release subdirectory.. try reloading and try to use either Tera Term or PuTTY.
When PropForth is properly loaded, a reset should have it come up with a message right away. From there, you are good to go.
If you are really worried about damage, try loading one of the touchswitch and blinking LED programs you first used. That should work and confirm the board is okay.
What you are experience is a normal situation for new users.. don't panic. It gets easier.
Communication error? Is your USB cable plugged in properly and the only source of power?
[FONT="]
I still need to learn how the stepper is pulsed with Propforth. Is the pulse related to the duration of the voltage at a given pin? [/FONT]
Create a few words in PropForth
For you i/o wiring...
p8 Step (output)
p9 Enable (output)
p10 Direction (output)
p11 Start sensor (input)
p12 Stop sensor (input)
: setio 8 pinout 9 pinout 10 pinout 11 pinin 12 pinin ;
: startup 8 pinlow 9 pinlow 10 pinlow ;
Okay, now you want to create a word for stepping
: step 8 pinhi 1 delms 8 pinlow ;
Then type the following line for 5 steps..
setio startup step step step step step <enter>
You don't have to repeat setio or startup. The Enable is on by a low pin 9, and you can observe whick direction is a low pin 10.
If you have trouble observing motion on the shaft, just stick a piece of tape on it and do 5 or 10 steps.
: 5step step step step step step ;
5step 5step <enter>
All that should work to confirm the OUTPUTs if the wiring is right.
We will have to do something else to test the INPUTs
~~~
I think it would be better to post here than in a PM. In the PM, I don't get to have a record to review of what I have written to you. Once the message is gone, it is gone and only you have a copy.
I am still trying to recall how to use the word 'words' to look for a short list... say all the items that start with 'p' or other wildcard searches. I have gotten rusty. The problem with using the 'words' comand is that the whole list just quick rolls by.
Let me know if you are getting a good rotation and are satisfied with how quite the device is.
I tested the motor using the following code:
: setio 8 pinout 9 pinout 10 pinout 11 pinin 12 pinin ;
: startup 8 pinlo 9 pinlo 10 pinlo ;
: step 8 pinhi 1 delms 8 pinlo ;
setio
startup
: fullspin 51200 0
do i .
step
loop
;
The motor made a full spin, which took about 2 minutes to do so. The motor runs very quiet. Without the slight vibration of the motor resting on the desktop, I could not hear the motor. I think I am ready to add the hall switched into the circuit.
Input is a bit different because you have to create an infinite loop that looks for a change in input pin status.
When you get the expected change, you jump out of the infinite loop and execute your task... then you return to infinite loop.
OR, you jump out of the Start infinite loop and go into another infinite loop that tests for a Stop condition before going once around the loop again.
The first option was what we originally had planned, but you seem to have shifted to the second option.
~~~~~~~~~~
PropForth has a feature called 'fastload'.
Fastload allows you to create software applications as whole txt files with commentary and then load the entire document as a block cut and paste to the TeraTerm screen at one go.
To make this work, one has to begin a text file with an 'fl' on the first line and nothing else, and an 'fl' on the last line.
Commentary in PropForth is not quite the same as standard ANSI Forth.
For comments of unlimited lines, use the { and the } to surround the comments and these have to be on an empty line.
For comments on just one line, maybe after a bit of active code, you a / and a space, then your comment
So a fast load text file would look something like this. Be aware of what needs to be on its own line.
A Fastload Code Style Example
~~~~~~~~~~
fl
{
This is an example of a fast load PropForth .txt file. blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah,
}
: newword 1 pinhi ; / a comment to explain that the Pin 1 will go high
/ a single line of comment that is not following a bit of code.
fl
~~~~~~~~~~~
Fastload has the code within it to ignore all the commentary, so it makes your text files easier to manage. Without fastload, you would have to keep your .txt files without commentary.
I think that is a good style example, but I am working from memory. Everything goes into RAM, if you want it all to go into EEPROM so the PropForth will still retain it, you will have to use 'saveforth'.
I will try to write up you input testing as a fastload .txt file.
We are getting very close to being able to write the complete application.
The completed application in PropForth will have the advantage that you can easily insert or adjust timing delays to get the right acceleration and motions that you want while observing the sculpture in real time.
As I said before, with Spin or C, you have to write-compile-load-test, and then start over again.
Even if you want the final program in Spin or C, PropForth will give you all your timing information much faster during the developmental stage.
I have to dig a bit to find out how PropForth will 'autostart' you program in the final form when power is turned on. I know the feature is available, I just never used it.
******************************
BTW, all the provided Extensions to PropForth in XXXXX.f files are really just text files with the Fastload feature. The .f is just there to remind you it is code for a PropForth device.
I changed the microstep setting from 1/256 to 1/2 and was able to speed up a single rotation to about 1 second.
I have determined that initially I want the stepper motor to run for 2.5 seconds with a final velocity of 360 degrees per second. As you know, the stepper will actually rotate 120 degrees during the 2.5 seconds that lapse between tripping the start and stop sensors.
BTW, the reason I changed my design from a defined angle of rotation to the use of a 2nd sensor was because I needed to protect against a possible interruption of the stepper circuit. For example, if for any reason the stepper does not complete a full 120 degree rotation, mechanical components will be misaligned with the stepper's irregular rotational position. Upon reboot of the QuickStart, the stepper will be able to complete its full rotation and realign itself with other mechanical components with the help of a stop switch.
I have begun writing pseudo code for my Propforth program. I am thinking about using a clock counter that would start when the start switch is tripped. The continuous loop would end with the tripping of the stop sensor. During the time that the loop is running, the velocity would gradually increase using an acceleration equation that I developed in excel. I concluded that I need an exponential equation that uses 3 constants. Although linear would have been easier, it is not too complicated.
I am still thinking about how to translate a desired velocity into a given delms value for a given step. Within the loop, I would use the clock counter to keep track of the number of ms since the start switch was tripped. The length of time in the loop will define whether or not the motor gets a pulse on a given pass. I start to taper the acceleration off when the the rotation is at about 90 degrees, ie the 120 degree stepper rotation is about 75% complete. The stop sensor will be mounted at the 120 degree position.
Using the clock counter and the acceleration equation as a reference, I hope to track how many steps have occurred at a given clock counter value. For example, one second after the start sensor is tripped, I hope to expect to confirm the following:
- The clock counter will be at 1000 ms
- Based on my acceleration equation, the 120 degree rotation will be 40% complete, ie stepper rotated 48 degrees.
- The loop will have pulsed the stepper about 53 times (based on 400 steps/rotation 1.11 degree/step, so 48 degrees x 1.11 = 53 steps)
I am sure that my assumptions above will change once I better understand the how the propeller chip works. For example, I have assumed that the total time lapse for 1 pulse is about 1 ms. But that assumes virtually all of the pulse time is the 1 delms between a pinhi/pinlo command. I realize that the pinhi/pinlo time lapse will be some amount of time, but since we are dealing in ms with the delms limitation, is the time lapse for the pinhi/pinlo sequence something to consider.?
Also, can I use a clock counter to do what I have explained.
I look forward to hearing your thoughts and suggestions.
If you really need less of a step delay, there are ways to do so. A new Forth word would need to be created in assembler language to do microsecond delays.
But the first question is whether you really need the microstep to be so small for the sake of smoothness or quite running. If not, it is simpler to just use less steps.
You have to observe and decide.
The advantage to not using any microstepping at all is that the stepper motor and stepper motor controller run more efficiently and the way that the stepper motor was originally intended to operate. Microstepping is a bit of creative electronics.
Additionally, with bigger step angles you have more time between steps for the Propeller to do a calculation and seek the right delay value if you are using some sort of complicated acceleration calculation.
Try to keep things as simple as possible, but don't worry if the code evolves into something fancy.
~~~~
All along I figured that you were likely to change things as the design evolved. I have tried to make sure you got a hardware setup that was both cost effective and powerful enough to adjust to whatever changes you came up with.
Still, it was a bit of a gamble that you might suddenly discover you need even more powerful items. One really has to bench test to see what you really have.
~~~~
Are you up to doing the Cherry sensor code on you own, or do you need me to start you off? You really are very near to writing a complete version 1 of your application. But you still have to get things started by typing in the Forth word to start the automation loop.
If you want my help, please tell me the actually step size you decided on as it is of key importance to doing any timing calculation.
Once you get a version 1 or version 0.1 working, you can tweek the code and observe until you get exactly what you want for movement and response to sensors. That is where inserting delays are useful. Acceleration indicates that you want the delay to change each and every step in a decreasing... and this can be done with a math formula, or it can be done with a look up table that just keeps jumping to the next entry on the table.
By using the lookup table approach, you can create a curve than is near impossible to describe with a a math formula.
The choice of formula or look-up table is really up to you. If you can get an exact value for delay of each step in an Excel sheet, you can used that as a look-up table and avoid having the Propeller repeat the maths. A look-up table is a much faster algorithm that a recalculation after each step.
I'd like to see your pseudo code. You seem to have added another layer of code to reset the machines position in the case of poor alignment. It sounds like a good idea, but there is the question of how it fits in.
At this point, I am trying to figure out how PropForth will autostart, once you settle on your right code. That is the final piece of the puzzle. Prof Brain assures me it is possible but seems to have forgotten exactly how it is done.
So I am doing some bench testing of code for that objective.
~~~~~
It certainly seems to be coming together well. But I am sure there will be more discoveries and more changes before you get to a finished project.
I am ready to add the Cherry switch. I understand that I am to use a 1k resistor in series with the Cherry Output lead. However, I want to confirm with you that the Output lead is connected to one of the two defined input pins and the VCC lead is connected to the QuickStart's VDD terminals. Is that correct?
If a lookup table is faster than repeating the acceleration calculation, I'l go with the lookup table. I developed my acceleration curve by simply defining 4 points of a curve shape that I wanted and then had excel create the curve fit and equation. The lookup table is in 1 ms steps. So, because the total rotation time span is about 2.5 seconds, the lookup table has 2500 rows. Is that too much?
To get me started, I would appreciate any help in providing Propforth code for a continuous loop that begins when pin 11 goes hi (input pin for start sensor). Also, a clock counter would start when the pin goes high, and during each pass of the loop, the current value of the clock counter would be used as an index, rounded to the nearest whole ms, to retrieve a value from a look up table. The continuous loop would end when the clock counter reaches a value of, say 2500 ms.
Once I have this code, I will try adding code that will control the pulse rate with the frequency of the delays and do some experimenting with the hardware.
After finding a successful pulse rate, I will then add code to use the stop switch to end the motor pulsing loop instead of using the 2500 ms limit from the clock counter.
Okay, The Cherry switch calls the 3rd wire 'output', but when activated by the Hall effect sensor, it really pulls whatever is attached to it to near ground.. that is the open collector configuration. The Hi/Low condition is provided by a combination of the pull up resistor and the open collector device, with the input to the Propeller attached inbetween
So we have a rough ASCII schematic as follows. (ignore the dots)
NOTICE - only the Output and the Ground of the Cherry sensor are shown below, the +4.5 to +24 power is NOT shown.
...
+3.3V
.. |
.. \
.. / 1 K ohm resistor (you provide a 1/4 resistor)
.. \
...|________ Cherry output connected to Propeller Input pin
...|
... \ collector (inside the Cherry sensor)
.... \|
......|
base--- to Hall Effect senor (inside the Cherry sensor)
...../|
..../ emitter connected to ground (inside the Cherry sensor)
... |
. _|_
... ground
What you and Cherry call 'output' is the transistor's collector, the emitter is connected to ground inside the Cherry sensor. And the base of the transistor is controlled by the hall-effect sensor.
I am purposely avoiding using Vcc and Vdd terminology and using +5, +3.3, and ground for greater clarity.
The Cherry sensor requires more than 4.5 Volts to operate and also has a built in voltage regulator that allows you to use anywhere from 4.5 to 24 volts for power.
You DO need to providee +5VDC to the Propeller QuickStart to provide power to both the Propeller chip and the USB interface. But the Cherry sensor could operate with +24 directly connected to the plus side just as easily as using +5VDC.. but the internal voltage regulator would run hotter. So use +5VDC for now.
The Safety issue is that the Propeller is limited to 3.3VDC on its inputs. And the open collector configuration requires you to pull the Propeller input high. So the 1K resistor provide the HI signal to the Propeller, the 1K resistor makes it easier for the open collector to pull it to near ground when turned on, so the input see a LOW.
You may have seen the 1K resistor recommended for 5 Volts in the Cherry document and the same document has nothing recommended for 3.3 Volts. Do not worry about this, pullup resistors are NOT an exact science. But using less that 1K just means it consumes more power.
And so, you have the Cherry outputs connected directly to the Propeller inputs, but if you don't include a 1K on each that pulls the input to 3.3V, it will either float or go low. The pull up resistors make the inputs behave properly.
DO NOT attach the pull ups to +5 or any other voltage higher than +3.3V as you risk damage to the Propeller input pin.
~~~~~~~~~
I am a bit embarrassed about mentioning Look-up Tables. Why so?
These are extremely easy to do in SPIN or C, but Forth doesn't easily accommodate a Look-up Table.
So after we finish testing your Cherry senors and run some trials in Forth, you might want to take what you learned and provide a finished program in Spin or C.
There is no reason to stay with Forth if it is going to be more complicated to get a nice clean program. The Propeller doesn't care which language you use and all of them are free.
Timing can be less predictable in Forth because it has to search the Dictionary for the words every time you call them. Different words might be fast or slow to perform in different ways.
For robotic control, you want 'deterministic timing'. That means you want to be sure the timing will be always performed exactly the same.
~~~~~
I think the PropForth continuous (infinite) loop is as follows.
: Mainloop begin 20 delms 11 px? 1 - until stepper ;
1. Mainloop would start a loop that would test Pin 11 for a true or false condition
2. The word stepper would be your stepping sequence.
3. The loop would test the pin every 20 milliseconds
4. When Pin put a 'true' on the stack, the loop will be jumped out of and stepper would start.
5. Get back into watching Pin 11, you would have to call Mainloop at the end of your word called stepper.
6. Or you could jump into a similar look for Pin 12 as follows
: 2ndloop begin 20 delms 12 px? 1 - until other ;
7. The 2ndloop would wait for the 2nd Cherry sensor and then jump to a word called other.
~~~~~~~~~
Be careful of what is a true condition. You want a HI input to be read as False and a LOW input to be read as True. But px? reads a HI as True, and a Low as False.
A true is indicated by BEING equal to 0 and False is indicated by being NOT Equal to 0.
So a High providing a 1 is okay as a False, and a Low providing a 0 is okay at a True.
But any number positive or negative will indicate a False.
You will notice that I subtract 1 from what px? puts on the stack so that 'until' will see the 'true' and 'false' properly.
Is that clear?
- With the Cherry switch is in its normally Open configuration, the current flows from the 3.3v through the 1 k resistor to input Pin 10; thus the propeller sees the input as high.
- When the Cherry switch closes, the current flows to ground through the 1 k resistor and the switch; thus the propeller sees the input as low at input pin 10.
- The code needs to handle a high signal at pin 10 as false since that is when the Cherry switch is open.
Did I get that correct?
[FONT="]"And so, you has to Cherry outputs connected directly to the Propeller inputs, but if you don't include a 1K on each that pulls the input to 3.3V, it will either float or go low. The pull up resistors make the inputs behave properly[/FONT]"
Not clear with what you mean. My understanding is that I only need one pull resistor in the switch config. and that is between the 3.3v terminal and the collector lead/pin 10 junction as shown in your schematic.
I would rather use 5v to operate the Cherry switch rather than 24 v from the controller ps. So, can you explain again how I am to power the switch with 5v? Does the +5v connect to the base lead (VCC) of the switch?
NOTE - I did a lot of revision and correcting to this after first posting.. so re-read to see if it now makes sense.
Your first part is 100% right.. you understand what the pull up and open collector are doing.
IN the second item, forgetting to insert the pull up creates a condition where the input may 'float'. That means that it might randomly indicate high or low due to static electricity in the surroundings. But if the hall effect sensor does trigger the open collector, it would go to a real low. You just can't be certain the condition is real or false, so you must have the pull up.
If you forgot the pull up resistor, nothing would be damaged, it just would not work right.
Third, the Cherry has three connections - a Vcc or +, and output or O, and Gnd or ground.
The Vcc can go to +5VDC from the converter. The Gnd can go to Ground from the converter.
NOTE - Vcc and Vdd can be different voltage levels of + OR simply indicate a different semiconductor is being used. This perpetually confuses people and causes problems. Vee and Vss are negative, below Gnd.
To make things even more confusing, some devices just use plus and minus, where minus often is the same as Gnd.
http://en.wikipedia.org/wiki/IC_power_supply_pin
The main thing is to not create loops in the Ground connections as they create some exotic problems (such as picking up interferance from household A/C in flourescent lights). Use a tree-like distribution pattern for your Grounds. Since everything is connected to Ground, we sometimes don't notice we are creating a loop by redundant connections. Just be aware of the potential hazard.
You use the term "base lead' for one of the wires in the Cherry sensor -- you just have a Plus, a Minus (or Gnd), and an output.
The final stage inside the Cherry sensor is an NPN transistor and that transistor has a base lead that goes to the amplified hall-effect sensor. You have no way to wire anything to that 'base lead'. I just tried to provide a diagram of how that final stage NPN exists so you have some idea of what an Open Collector is.
Open Collectors are very very handy as they will handle a lot more power by pulling the output to ground. The other alternative that is not an Open Collector is to drive a High output for ON and that never provides as much power as an Open Collector. Also Open Collectors can combine with other Open Collectors to do some fancy things with logic that you can't do with other kinds of outputs.
http://en.wikipedia.org/wiki/Open_collector
Some days, my writing is not so clear.
"NOTE - Vcc and Vdd can be different voltage levels of + OR simply indicate a different semiconductor is being used. This perpetually confuses people and causes problems. Vee and Vss are negative, below Gnd.". But I just want to be sure I have this right. Do I connect the 1k resistor to the +5v terminal of the 24 to 5v Pololu converter? If I that is correct, will the propeller input pin handle 5v instead of 3.3.? If that is not correct, and only 3.3v can be input to the propeller, then what do I use for the 3.3 v source that is connected to the pull up resistor. I apologize if I'm being overly dense about this concept.
After studying the purpose of pull up and pull down resistors, I think I get it. My understanding of how the hall-effect switch works is that the operating voltage for the switch is the same voltage that gets passed to the Output pin when the switch is closed. If that is correct, and the switch can't operate at less than 4.5v and the propeller can't handle more than 3.3v, then what needs to be done?
If 5v is needed for the Cherry, then I need to add the pololu step down voltage regulator into the circuit. Your instruction on this was:
About the only thing I haven't mentioned is the +24VDC to +5VDC converter. It does come off the +24VDC output and can use telephone wire. Pololu strongly recommends an added capacitor on the input. It should be rated OVER +24VDC, at least +35V.. but +50VDC or +100VDC is equally okay. As best as I recall, they wanted 30uF. It you wire it backwards, it will blow up. So, the + to + and the - to - and stand back before you turn it on.
What is the capacitor for? The regulator is about 1/2 the size of a postage stamp and has 4 terminals labeled Vin, Vout, Ground, and SHDN?. I assume the 30 uF capacitor + lead connects to the Vin terminal and the - lead connects to ground. I also assume the the Vout will connect at the QuickStart's Vin terminal which is pin 39. Is all that correct?
I do not care what you call it Vcc or what ever, you connect on end of the pulllup resistors to the 3.3V on the Propeller QuickStart board. DO NOT connect it to a +5VDC, even if examples show that is correct. Those examples are for devices that will tolterate +5V inputs. The Propeller is designed for no higher than 3.3V.
Cherry did not publish an example for use with a 3.3v input device. If fact, its documents don't even consider that 3.3v input devices exist.
I specify the voltage and the polarity to avoid errors that might cause damage.
The jargon of electronics started out as an attempt to be very precise and clear, but authors on the internet have muddled everything. So I try to focus on the items that are important. And I try to point of the pit falls along the way.
You can adapt a Propeller input to accept a +5 signal by adding a 3300 ohm resistor in series to protect the input, but it is both simplier and better to have the pull-up on an open collector just connected to the safer 3.3V.
You would still need the 1K pullup as well as the 3.3K protector if you used +5. And performance would be degraded.
To repeat, we just don't have an explaination by Cherry of how to use their device to input to a 3.3V input. But I did check other details in the Cherry specs and the Propeller specs and this will work.
~~~~~~~~~~
The operation voltage of the hall-effect switch DOES NOT get passed through the output. It never passes through to the NPN collector. The output of the hall-event switch passes through the final transistor's emitter to GND.
With an open-collector, you can have a pull-up connected to any voltage you like within a range that the final transistor will tolerate. In some cases, people need +12 volts or +24 volts to drive a light or a relay.
That last transistor, an NPN that has its emitter connected to Gnd will nearly always handle 30VDC or less at its rated current (here it is 20ma max). Some other transistors are able to handle as much as 60VDC, and much more current. It is ALL ABOUT what the final transistor is able to do.
~~~~~~
Why do you need a +5 volt supply?
A. Most importantly, to power the QuickStart board via Vin when you want to use it without the USB connected to anything.
B. The Cherry Proximity Sensors will run cooler at +5 (but need more than +4.5) than at higher voltages such as the +24.
What is the capacitor on the +24VDC for?
The capactor located nearest to the inputs of the Pololu board is to protect the +24 to +5 device from potential damage due to spikes on the +24VDC power line. You might be fine without it, but Pololu does recommend it.
HERE is what Pololu says.. use a 33uf or largercapacitor, maybe 50V or higher rated.
LC Voltage Spikes
When connecting voltage to electronic circuits, the initial rush of current can cause voltage spikes that are much higher than the input voltage. If these spikes exceed the regulator’s maximum voltage (42 V), the regulator can be destroyed. In our tests with typical power leads (~30″ test clips), input voltages above 20 V caused spikes over 42 V. If you are connecting more than 20 V or your power leads or supply has high inductance, we recommend soldering a 33μF or larger electrolytic capacitor close to the regulator between VIN and GND. The capacitor should be rated for at least 50 V.
More information about LC spikes can be found in our application note, Understanding Destructive LC Voltage Spikes.
You can adapt a Propeller input to accept a +5 signal by adding a 3300 ohm resistor in series to protect the input, but it is both simplier and better to have the pull-up on an open collector just connected to the safer 3.3V
I'm confused. I understand that the 3300 ohm resistor would limit current but it wouldn't reduce the voltage from 5v to the safe 3.3v, would it?Given the required 5v for operation of the Cherry switch, can I achieve the 'simplier and better' solution of using 3.3 v as input to the collector?
If this can be done, I think I understand the wiring of the open collector (Cherry's Output) in that the 3.3v terminal on the QuickStart (labeled Vdd) is connected to a 1k pull up resistor and the other end of the resistor connects to input pin 11 and the Cherry Output lead. What does the Cherry lead, labeled Vcc connect to? 5v? Again, I apologize for being super slow here.
A. The simple answer is use a 1K pullup connected to +3.3v
B. The messy answer is to use a 3.3K resistor to protect the Propeller input AND then a 1K pullup to +5.0 volts (That is 2 resistors)
C.Or the slick answer for +5v is to use a 3.3K pullup to +5.0 volts (only 1 resistor needed).
How did I arrive at C? Thevin's equivalent circuit analysis. Killing 2 birds with one stone.
~~~~~~~~~~~~~~~~~
But whichever you do, the Cherry documents won't provide an answer as they don't consider input to 3.3v devices. And, you really need to learn some electronics to understand that the different ways inputs are used (with pullups, with pulldowns, or with a driven Hi/Low)
Pulldowns are to Ground, so there is nothing much to consider.
Pullups are wisest with the voltage being only to the maximum recommended.
Directly driven hi/lows for the Propeller have been discussed quite a bit and a 3.3K resistor will make the +5 volt HI safe for the Propellers +3.3v limit.
~~~~~~~~~~
I am willing to admit that there are a lot of different ways to do this. But since you have 3.3 volts available, it seemed cleanest to just have the pullup resistor connect to that. If you really want to have a +5 volt source connected to the pullup, it is up to you.
~~~~~~~~~
What does the 3300 ohm resistor do? Well, in combination with the tiny protective diodes that the Propeller has on the inside of each i/o, engineers and Propeller users here have figured out that the Propeller i/o will work just fine. It seems to be the equivalent of a voltage divider that removes any chance of stress to the Propeller's i/o.
In the below link, Beau Schwab says a 1K resistor is adequate, but there are more threads with a huge debate that ended with everyone pretty much accepting a 3.3K resistor was much better. I really don't want to bore you with reading very long threads that go back and forth in debate or the value of one resistor. Some of us use 3.3K and others hang onto the 2006 posting by Beau and use just 1K.
I really don't know whose Propellers last longer.
http://forums.parallax.com/showthread.php/85841-Propeller-Chip-5V-tolerant
I appreciate your listing of the various options, and I agree that we should keep this simple...even though my ignorance has probably frustrated the heck out you.
"since you have 3.3 volts available, it seemed cleanest to just have the pullup resistor connect to that." Are you referring to your option B? Rather than continuing my pestering questions, can you simply sketch a schematic similar to what you provided yesterday that shows exactly how the Cherry leads and resistor(s) are configured with the the 3.3v source that you believe is the cleanest solution?
I think If I have a schematic to study rather than a narrative wiring description, I will understand it sooner and better. Once again , I appreciate you r patience!