Serial Output
A.C. fishing
Posts: 262
How could the stamp send the numbers 1-3 to a program up a serial· cable?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·Somebody said...
-Never Underestimate the power of human stupidity.
Comments
You probably want to do something like this:
{'PBASIC 2.5}
'Assign Pin Ports
OutPin PIN 1 'Arbitrarily assign Pin Port 1 to serial output, set as required
'Assign Variables
Numbr VAR Byte
'Assign Constants
BaudM· CON 84 'Set baudmode to appropriate value as required
FOR Numbr = 1 to 3
· SEROUT OutPin, BaudM, [noparse][[/noparse]Numbr]
NEXT
END
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->
I modified your program to
' {$STAMP BS2} ' {$PBASIC 2.5} ' {$PORT COM4} DO 'Assign Pin Ports OutPin PIN 1 'Arbitrarily assign Pin Port 1 to serial output, set as required 'Assign Variables Numbr VAR Byte 'Assign Constants BaudM CON 84 'Set baudmode to appropriate value as required Numbr = 1 IF (IN0 <> 0) THEN SEROUT OutPin, BaudM, [noparse][[/noparse]Numbr] ELSE SEROUT OutPin, BaudM, [noparse][[/noparse]3] ENDIF LOOPI have to have the COM4 there because that is the port I'm using. I seem to be getting a random pattern in my program which receives this:
There is no obvious pattern, so I beleive they are random.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·
In your first posting you asked "How could the stamp send the numbers 1-3 to a program up a serial· cable" which I interpreted to mean the numbers 1 THROUGH 3, or 1, 2, and 3 in sequence. Thus the reason for the FOR ... NEXT loop to generate that number sequence.
It appears now that you have some sort of unknown input or input sensor that you're checking in an infinite loop. If that input never changes, changes less often than you expect, or if there is an intermittant wiring error, you will probably get just the kind of results you are getting. What is that input, and how often do you expect it to change?
Additionally, how that passed data (1 or 3) is treated in the upstream program will depend very much on how it is being checked in that program. We haven't seen that program yet!
Presently if the input pin port 0 is equal to 0 (or is LOW), you will send a 3 out the assigned serial port. If input pin port 0 is equal to 1 (or is HIGH), you will send the value of the variable "Numbr"·out the assigned serial port. I hope that is what you were planning to have happen.
Lastly, the DO ... LOOP should surround just the executable part of your program, a summary of which is shown below:
DO
IF (IN0 <> 0) THEN
· SEROUT OutPin, BaudM, [noparse][[/noparse]Numbr]
ELSE
· SEROUT OutPin, BaudM, [noparse][[/noparse]3]
ENDIF
LOOP
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->
Post Edited (Bruce Bates) : 5/14/2006 4:40:46 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·
If you're using the circuity from the Parallax documentation, the sensor has ONLY two states: active and inactive. If the sensor has been touched, tapped, or has sensed vibration, a 1 or HIGH will be present when you check it, otherwise it will present a 0 or LOW when checked. There is no detectable third or other state that I can see, based on the documentation.
HOWEVER - If it has been touched, tappped, or senses vibration, depending on how it's mounted, you _may_ get a long STRING of HIGHs and LOWS as the sensor oscillates, and finally over time reaches it's inactive or resting state. Or, alternatively, it may give a long period of HIGHs representing that same period. It's not quite clear to me which will be the case. In either case, you may not even be able to see the vibration visually, yet it is still in physical oscillation, and thus producing an output.
Thus, you may need to de-bounce it, just like you might an input push button or keypad press. It's even possible that the BUTTON command may be helpful her, although that's not one of my favorite commands.
The documentation would indicate that it is a rather sensitive device, so it may sense the diminishing oscillations for a good deal longer than you think. The perfect tool for debugging this would be an oscilliscope, wherein you could see the entire period of voltage output, and therein the actual vibrations if you can sweep it long enough.
Short of that it might be interesting to see what PULSIN or COUNT had to say about the duration of the output you're getting, if you can set it up in a manner such that the results were quite repeatable. Touching the sensor every so briefly with a tuning fork _might_ provide such a means. If you don't have a tuning fork, a small kitchen fork with multiple small tines might suffice in a pinch. Put on gloves, "twang" the fork with your finger, touch it briefly to the end or tip of the sensor, and see what PULSIN has to say. If you DON'T use a glove you may get a nastly JOLT from what the documentations says! Use DEBUG to view the output from PULSIN.
Good luck with it.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->
Post Edited (Bruce Bates) : 5/14/2006 6:30:30 PM GMT
What's wrong with using this code:
' {$STAMP BS2}
' {$PBASIC 2.5}
' {$PORT COM4}
TriggerPin PIN 0 ' Input Pin From LDT0
Main:
IF TriggerPin <> 0 THEN Main ' Check For Trigger
DEBUG "Triggered!", CR ' Display Result To DEBUG Window
GOTO Main
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·
The direct answer to your question is - if it does what you want it to do, it's "right", if not it's "wrong". Although, I'm not sure how you wanted that question answered.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·
If that provides the trouibleshooting information you require, then that's the way to go. PULSIN was just an alternative means to a slightly different end, but don't be concerned about it.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->
Does it matter that I'm using a serial to USB cable with my boe? The port is COM4. Does that make a difference?? Is there anyway the DEBUG window can tell me if the bs2 is sending the data? The hard thing is I don't know what's worng, there are so many things, when usually there is just hardware and software. Now it could be the JB program, the bs2, the cables, the PBASIC, the sensors, anything. I can't seem to read the data with my program. I just keep getting blanks. I know the vibra tab is working, i have tested it. If anyone knows how, could I be shown an example in Visual Basic?
Thanks,
AC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·
All along the way here you've given us so little information to work with that it's almost impossible to help you. Add to that that some of the information was wrong, and I'm surprised you're as far along as you are.
All I can do is guess at this point as to what's going wrong. My guess is that there is probably a problem with your VB program, although this is the first that we've even heard that a VB program existed. I know nothing about VB, so someone else will have to help you with that.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·
Now, every time its OnComm event fires, check to see if the CommEvent = 2, this means data has finished being transmitted and leaves the Input property with the new text.
Private Sub MSComm1_OnComm() If MSComm1.CommEvent = 2 Then Text1.Text = MSComm1.Input End If End Subedit; I'm assuming this will work the same with the USB as it is another COM port, and the VB documentation doesn't state otherwise.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beware the pink squirrel!
Post Edited (Pezi_Pink!) : 5/15/2006 11:36:27 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·