PDA

View Full Version : Serial Output



A.C. fishing
05-13-2006, 11:16 PM
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.


·

Bruce Bates
05-14-2006, 01:18 AM
A. C. Fishing -

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, [Numbr]
NEXT

END

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->

A.C. fishing
05-14-2006, 08:46 PM
Bruce- My BS2 has been giving me some pretty funky data!
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, [Numbr]
ELSE
SEROUT OutPin, BaudM, [3]

ENDIF
LOOP

I 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:


The delay routine shortens (faster).
Oops, the caveman tripped!
The delay routine shortens (faster).
Oops, the caveman tripped!
Oops, the caveman tripped!
The delay routine shortens (faster).
The delay routine shortens (faster).
The delay routine shortens (faster).
The delay routine shortens (faster).
The delay routine shortens (faster).
Oops, the caveman tripped!
Oops, the caveman tripped!
Oops, the caveman tripped!
The caveman stops.
The caveman stops.
Oops, the caveman tripped!
The caveman stops.
Oops, the caveman tripped!
Oops, the caveman tripped!
The caveman stops.
The delay routine shortens (faster).
The delay routine shortens (faster).
The caveman stops.
The caveman stops.
Oops, the caveman tripped!
The delay routine shortens (faster).
Oops, the caveman tripped!
The delay routine shortens (faster).
Oops, the caveman tripped!
Oops, the caveman tripped!
Oops, the caveman tripped!
The caveman stops.
The delay routine shortens (faster).
The caveman stops.
The caveman stops.
Oops, the caveman tripped!
The caveman stops.
The delay routine shortens (faster).
The caveman stops.
The caveman stops.
Oops, the caveman tripped!
The delay routine shortens (faster).
The delay routine shortens (faster).
Oops, the caveman tripped!
The delay routine shortens (faster).
The delay routine shortens (faster).
Oops, the caveman tripped!
Oops, the caveman tripped!
The caveman stops.
The caveman stops.
The delay routine shortens (faster).
Oops, the caveman tripped!
The delay routine shortens (faster).
The caveman stops.
The caveman stops.
The caveman stops.
The caveman stops.
The delay routine shortens (faster).
The caveman stops.
The delay routine shortens (faster).
The caveman stops.
Oops, the caveman tripped!
The delay routine shortens (faster).
The caveman stops.
Oops, the caveman tripped!
Oops, the caveman tripped!
The delay routine shortens (faster).
The caveman stops.
The caveman stops.
Oops, the caveman tripped!
Oops, the caveman tripped!
Oops, the caveman tripped!
The caveman stops.
The delay routine shortens (faster).
The delay routine shortens (faster).
The delay routine shortens (faster).
Oops, the caveman tripped!
Oops, the caveman tripped!
Oops, the caveman tripped!
The delay routine shortens (faster).
The delay routine shortens (faster).
The delay routine shortens (faster).
The delay routine shortens (faster).
The delay routine shortens (faster).
The caveman stops.
The caveman stops.
Oops, the caveman tripped!
The caveman stops.
The caveman stops.
Oops, the caveman tripped!
Oops, the caveman tripped!
The delay routine shortens (faster).
The delay routine shortens (faster).
Oops, the caveman tripped!
The delay routine shortens (faster).
The caveman stops.
The caveman stops.
The caveman stops.
The caveman stops.
Oops, the caveman tripped!

There is no obvious pattern, so I beleive they are random.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔



Somebody said...
-Never Underestimate the power of human stupidity.


·

Bruce Bates
05-14-2006, 11:13 PM
A. C. Fishing -

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, [Numbr]
ELSE
· SEROUT OutPin, BaudM, [3]
ENDIF

LOOP

Regards,

Bruce Bates



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->

Post Edited (Bruce Bates) : 5/14/2006 4:40:46 PM GMT

A.C. fishing
05-15-2006, 12:21 AM
Thanks. The sensor data comes from a Vibra tab. It can either say off, on, or no electricity. It usually says off or on. Yes, that is what I have been planning.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔



Somebody said...
-Never Underestimate the power of human stupidity.


·

Bruce Bates
05-15-2006, 01:26 AM
A. C. Fishing -

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

A.C. fishing
05-15-2006, 03:05 AM
Hmm... Well first, the vibra tab is just two of the states. The third is different, but lets stick to this.
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

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔



Somebody said...
-Never Underestimate the power of human stupidity.


·

A.C. fishing
05-15-2006, 03:40 AM
Also, I'm using a serial to USB adapter, so I'm using COM4

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔



Somebody said...
-Never Underestimate the power of human stupidity.


·

Bruce Bates
05-15-2006, 04:55 AM
A. C. Fishing -

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 -->

A.C. fishing
05-15-2006, 05:36 AM
I meant what is wrong with that code, and why do you suggest using PULSIN.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔



Somebody said...
-Never Underestimate the power of human stupidity.


·

Bruce Bates
05-15-2006, 06:04 AM
A. C. Fishing -

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 -->

A.C. fishing
05-15-2006, 07:38 AM
Bruce-
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

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔



Somebody said...
-Never Underestimate the power of human stupidity.


·

Bruce Bates
05-15-2006, 12:40 PM
A. C. Fishing -

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 -->

A.C. fishing
05-15-2006, 05:52 PM
I'm sorry. I said VB because it is so much like JB that I could easily transfer the code. The JB program is the program that receives the input from the stamp. Also, this would help break it dowwn whether the JB or PBASIC is wrong. If the VB can detect the stamp, then we know it is the PBASIC that is wrong. But is there a way you can use the DEBUG window to detect serout commands? This will help us see if the problem lies with the stamp. I just want to make sure where the problem is before I concentrate on one part.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔



Somebody said...
-Never Underestimate the power of human stupidity.


·

A.C. fishing
05-16-2006, 04:12 AM
Because I'm using COM4, should I change the Baud number or something? Remember this is a USB port collecting the data.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔



Somebody said...
-Never Underestimate the power of human stupidity.


·

A.C. fishing
05-16-2006, 06:07 AM
As i said, this will all clear up if I can find a way which I can telll it is the stamp, and not the program, or vice versa, that is wrong.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔



Somebody said...
-Never Underestimate the power of human stupidity.


·

Pezi_Pink!
05-16-2006, 06:28 AM
To read serial data through VB you just need to add the MSComm control, then set the properties of it to match your device's output (baud, com port, etc), and in your form startup or on a button somewhere set its PortOpen property to true to enable the connection.

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 Sub




edit; 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

A.C. fishing
05-16-2006, 07:19 AM
Everyone- I got it working. The JB run window can work as a debug window!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔



Somebody said...
-Never Underestimate the power of human stupidity.


·