SEROUT over COM2 to VB6 MScomm.Input

ddbcretin

Tired to find an answer to this using Search, but didn't find anything. It seems like this would be a pretty common thing to want to do so sorry if this has already been asked and answered. Anyway...

I'm using a GUI written in VB6 to set a series of variables that my BS2p will use to run a series of heater/time events. I can set the variable in VB and send them to the stamp with no problem. MSComm1.output to SERIN 16,16624, variablename yada, yada, yada... This works fine. I know the stamp is reading the variable correctly because I set a LED to flash the number of times that "variablename" is set to (I can't use DEBUG variablename because COM2 is tied up by VB).

Then I'm trying to bounce the variable back to VB. This is not working for me. SEROUT 16, 16624, [noparse][[/noparse]variablename] sends data to VB. VB captures data with the OnComm event. However, I can't consistently read the variable correctly. Sometimes I read it correctly, but most of the time garbage characters are displayed by VB. It seems like I've got some kind of data type or size mismatch. I've tried changing both the output and input variable type (string, variant, etc.) and the format of which it is sent and received (DEC variablename). No luck converting once back in VB either.

Any ideas? Is there anything unusual with the way the stamp formats and sends data over pin 16? Special settings in VB to read a stamp? Thanks for any help.

Jon Williams

This will help: http://www.parallax.com/dl/docs/cols/nv/vol3/col/nv89.pdf

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Dallas, TX· USA

allanlane5

1. Yes, one unusual thing is that everything that gets sent to the BS2 port 16 gets 'echoed' back by the BS2 hardware to the PC.

2. Your value of 16624 ( = 240 + $4000) should give you Inverted, 9600 baud, 8-data no parity. This is correct for the BS2p.

3. You are aware you can only send and recieve 8-bit values, right?

4. It is least error prone to send as strings from VB (with an ending CR), receive as DEC VarName. Going BS2 to PC, send as SEROUT 16, [noparse][[/noparse]DEC VarName, CR], recieve as string in VB, toss any echo, and convert to value.

5. Sending in 'binary' (the default -- Value '10' becomes byte 10) it can be much harder to throw away echoes, and find the 'real' data bytes.

ddbcretin

Thanks for the respone guys.

I'd really like to use the DB9 provided on the Stamp board if possible.

I think the BS2 echo when I set the variable may be what is causing my trouble. How do I "toss the echo" in VB?

allanlane5

Well, since you wrote the VB program, your VB program already should know what it sent.

Get what comes back, read that many characters, ignore what they contain, then read the BS2's response.

If that's too risky for you (and it would be too risky for me, by the way) then preface the VB outbound message with a particular character -- like a "!", and end it with a particular character, like a CR. Have the BS2 'wait' for the "!", then read its data. Have it send back to the PC with a different start character (like a "*").

Then, on the PC, read each returned line. If it starts with a "!", then read the next line. If it starts with a "*", then use the data.

Jon Williams

Allan is right: you will only get echoes when sending from VB to the BASIC Stamp. If you send three characters you will get them right back in your comm buffer -- simply erase them. By creating a little protocol you can help yourself: your app can send a header ahead of its data (and the Stamp can use the WAIT command for this value, then get the data bytes that follow). Values going from the BASIC Stamp to the PC could have a different header, so a transaction might look like this:

PC --> [noparse][[/noparse]PC Hdr] [noparse][[/noparse]data0] [noparse][[/noparse]data1]
PC <-- [noparse][[/noparse]PC Hdr] [noparse][[/noparse]data0] [noparse][[/noparse]data1] [noparse][[/noparse]Stamp Hdr] [noparse][[/noparse]data0] [noparse][[/noparse]data1]

It's now very easy to move through your input buffer to look for the Stamp's header, then grab the data that follows.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Dallas, TX· USA

ddbcretin

Thanks fellas.

My whole point to reading the values back from the stamp is to display them in a VB dialog box. That way the end user will be certain what values were programmed into the stamp. Since the stamp is alreading sending this back I'll just use it. No need to resend with a SEROUT command.

I was actually complicating things by trying send back the data.

Seems to be working now, at least for one variable. Hopefully things will hold together when I add the others. It should. Thanks again for the help!

Jon Williams

Not a good idea -- the echo is hardware based and the Stamp doesn't actually have to be running your program for the echo to occur. Better to toss the hardware echo and use data transmitted by the BASIC Stamp -- that way you actually know what values the Stamp is using.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Dallas, TX· USA

ddbcretin

Hmm. What other events would trigger an echo?

Jon Williams

Nothing. It has to do with the hardware design of the RS-232 level shifter built into the BASIC Stamp programming port. If you look up the schematic, you'll see that the design of the circuit "borrows" power from the RS-232 side, hence the echo is caused. This echo is just going through the hardware; it doesn't mean that your Stamp program actually saw the data stream.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Dallas, TX· USA