Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17

x
?
Solved

MScomm revisited...

Posted on 1999-08-01
28
Medium Priority
?
309 Views
Last Modified: 2013-12-25
Thanks to Rockie for pointing out my problem last time... but I have hit another - and I am sure it is just as easy!! (Maybe I should stick to databases in the future)...

OK: I am communicating with a gizmo via COM1 which has an LCD display to show bytes received/transmitted. I know the correct bytes to send to this machine to get it to respond, but when I send them via "mscomm1.output = <string>" it does nothing! I know the string is correct because if I add a 'VB watch' to the string and then copy it to the clipboard, I can open up Hyper-terminal, set it up for COM1 and then "paste to host" from the clipboard and voila! - correct response from gizmo!!

I guess my question is: Is there anything at all I need to do other than the following?

  msc1.CommPort = 1
  msc1.Settings = "1200,n,8,1"
  msc1.Handshaking = comNone
  msc1.PortOpen = True
  msc1.output = String$
  msc1.PortOpen = False

Remember: Pasting String$ through Hyperterminal works just fine. There is something I am just not understanding about VB comms - can anyone enlighten me?

In case it is relevent, String$ is a five-line text message with lines separated by &HA (linefeed) and it starts with &H02 and ends with &H03 &H0D
Thanks
0
Comment
Question by:Upland
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 14
  • 10
  • 4
28 Comments
 
LVL 9

Expert Comment

by:Dalin
ID: 1495744
Is the other device look for Binary data or text?
Sound like you need to send it Binary, because you are talking about send Bytes...
0
 
LVL 3

Expert Comment

by:kfrick
ID: 1495745
My guess is that you are closing the Serial Port before it has time to send the entire message...if you have another computer available, try running Hyperterminal on the second computer to display what you are sending out of the test PC......

Try inserting this code before closing the port...

  While msc1.OutBufferCount > 0
  Wend

This will allow all the data to get out of the port before it is closed.....

Remember that the msc1.Output does NOT automatically send a Carriage Return, and Hyperterminal probably does...you may have to use:
  msc1.Output = "Test Data" + vbCR

or even:
  msc1.Output = "Test Data" + vbCRLF

hope this helps!
-kf
0
 

Author Comment

by:Upland
ID: 1495746
Dalin,
Thanks for the comment.
It really is text (I think). Weird, I know, but a byte in this context (according to the gizmo handbook) is a pair of ASCII characters transmitted which the 'gizmo' combines to form a 2-digit decimal value.
eg. A 'byte' 07 would be transmitted as &H30 followed by &H37. The 'character' 2 or 3 mentioned above, on the other hand, is transmitted as chr(2) or chr(3).

MScomm control has an InputMode property for text/binary but not a corresponding OutputMode... what exactly were you suggesting I try in your comment?
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 

Author Comment

by:Upland
ID: 1495747
Dalin,
Thanks for the comment.
It really is text (I think). Weird, I know, but a byte in this context (according to the gizmo handbook) is a pair of ASCII characters transmitted which the 'gizmo' combines to form a 2-digit decimal value.
eg. A 'byte' 07 would be transmitted as &H30 followed by &H37. The 'character' 2 or 3 mentioned above, on the other hand, is transmitted as chr(2) or chr(3).

MScomm control has an InputMode property for text/binary but not a corresponding OutputMode... what exactly were you suggesting I try in your comment?
0
 

Author Comment

by:Upland
ID: 1495748
Kfrick,
Thanks for the answer but I have to reject it as I had considered that earlier and then dismissed it - I had already stepped through the code and it made no difference. As for the CR, I am explicitly sending a &H0D at the end of the string - this is also in the clipboard when I do the 'paste to host' from Hyperterminal.
I have tried transmitting the complete string as described above and also sending the characters one at a time... for example:
...
msc1.output = Chr(&H30)
msc1.output = Chr(&H31)
msc1.output = Chr(&H34)
msc1.output = Chr(&H30)
.... etc
Will send 0140 (exactly as described in the handbook.

Regards,
Upland
0
 
LVL 3

Expert Comment

by:kfrick
ID: 1495749
I would hook up another PC in place of your LCD gizmo, then send the "monitor" PC your Hyperterminal output, and your VB output, to discover the difference.....

If you can send it with Hyperterminal, you can send it with VB!

You may have to get ahold of a program to display not only the Text, but also any "white spaces" or control chartacters, to succesfully monitor the data. I use good old "PCPlus" for DOS when I really want to look at serial communications.

Sorry my answer didn't work....hope you can figure it out!

-kf

PS.....are you using 3-wire (RX,TX, & GND) or more (CTS/RTS/DSR/DTR) for your connection?? If you are using more that 3-wires, you may have to set the handshaking properties of your msc1 object....just a thought!
0
 

Author Comment

by:Upland
ID: 1495750
kfrick,
It is just a 3-wire... but the other information (which I believe is irrelevant) is that the 'gizmo' is actaully an RS485 connector - and it goes through an RS485/RS232 convertor (which just looks like a 9/25 convertor). I say irrelevant because it is still there when I am using the hyperterminal connection.
I will do as you suggest and set up a receiving PC locally.... watch this space.
Upland
0
 

Author Comment

by:Upland
ID: 1495751
I realize that this now has very little to do with VB and mscomm controls... but here goes anyway...

I set up a PC locally, connected the comm ports and here are the results...

Connected my VB prog to PC running DOS and captured as text.
Also, connected to PC running Win95 Hyperterminal and captured as text.

Both results were the same...
Here is Hex Dump of captured text:
02 30 31 34 30 31 30 41 42 43 44 45 46 0a 0a 0a 0a 0a 03 41 0d
.....This is exactly as it should be because it is exactly the same as the captured text, using the same methods from the original DOS program when it sends the same six characters "ABCDEF" in this case.

This however is the cut and pasted (to gizmo via Hyperterminal) 'Watch Window' text
02 30 31 34 30 31 30 41 42 43 44 45 46 0a 0a 8a 0a 8a 03 41 0d
... which, bizarre as it seems, actually gets the correct response from the gizmo.
Notice that two of the five linefeeds (0a) get turned into 8a when they get pasted. Looking at them in the clipboard they are all 0a linefeeds - so I am presuming that it is something to do with Hyperterminal.

If anyone can be *bothered* to paste the string from the hex above to Hyperterminal's "paste to host" I would be curious to see if they get the same result. Here is the code ... it will save you the typing.

  TX = Chr(&H2) & _
  Chr(&H30) & _
  Chr(&H31) & _
  Chr(&H34) & _
  Chr(&H30) & _
  Chr(&H31) & _
  Chr(&H30) & _
  Chr(&H41) & _
  Chr(&H42) & _
  Chr(&H43) & _
  Chr(&H44) & _
  Chr(&H45) & _
  Chr(&H46) & _
  Chr(&HA) & _
  Chr(&HA) & _
  Chr(&HA) & _
  Chr(&HA) & _
  Chr(&HA) & _
  Chr(&H3) & _
  Chr(&H30) & _
  Chr(&H41) & _
  Chr(&HD)

Personally, I think I need a priest!!

0
 
LVL 9

Expert Comment

by:Dalin
ID: 1495752
Upland,

If you are sending binary data, you need to have the outdata in a Byte Array instead of String.

Dim lOutData (1 to N) as Byte ' N Bytes will be send

For i = 1 to N
     lOutData(i) = somthing  "Fill your Array with Binary Value
Next i

MSComm1.OutPut = lOutData()

Now You need to know what the other machine is looking for and put the value to the byte array accordingly.

0
 

Author Comment

by:Upland
ID: 1495753
Dalin,

Many thanks once again for your comments.

I declared b(1 to 22) as byte - and then after the TX = ... (see above), I placed:

For i = 1 To 22
   b(i) = Asc(Mid(TX, i, 1))
Next i

I checked through the array and confirmed it contained the same values as above. 02, 30 .... 0d.

....but still no success with regards a response from the gizmo. Oh well...
0
 
LVL 3

Expert Comment

by:kfrick
ID: 1495754
Geez......

Just curious about the last 4 entries in your code above.....looks like you're sending

  <ETX>"0A"<CR>

with these codes

  Chr(&H3) & _
  Chr(&H30) & _
  Chr(&H41) & _
  Chr(&HD)

Is that your intention? Or is it a typo??

I am also confused by the "41" as the second last character of your captured hex data.....????

Try this as your output string.....
  Out$ = Chr$(2) + "014010ABCDEF" + vbLF + vbLF + vbLF + vbLF + vbLF + Chr$(3) + vbCR
(all one line, y'know...)
  msc1.Output = Out$

Do either of the first two data dumps actually operate the LCD gizmo??
0
 

Author Comment

by:Upland
ID: 1495755
kfrick,

Thanks once again...

You are right when you say 2 and 3 are STX and ETX. The 30 and 41, however, are part of this esoteric protocal and are actually a Block Check which is calculated on all previous characters - except STX.

The calculation of BCC is:

  BCC = 0
  For i = 1 To Len(TX$)
    BCC = (BCC Xor Asc(Mid$(TX$, i, 1))) And &HFF
  Next i

  TX$ = Chr(&H2) + TX$ + Hex(BCC \ 16) + Hex(BCC Mod 16) & Chr(&HD)

The &H0d is also part of this protocol and signals End Of Transmission.

Just for completeness:
After the initial STX......
01 Indicates the machine on the bus being addressed (1 - 8)
40 Indicates a 5 line message is to be displayed on Gizmo's LCD.
10 Indicates it should be displayed for 10 minutes then erased.

Then we're into the message itself and five linefeeds.

Many thanks.
0
 
LVL 9

Expert Comment

by:Dalin
ID: 1495756
Do you have a program that can Drive the device?
1. Run that program to make sure the Device will response so you are not beating a dead horse;

2. Look at the menu of the device to see what exactly it is look for, whether text or binary, if binary, you need to send each byte exactly the way it requres ( for example, I had a instrument that receive each character with two bytes, with the two highest bits of the second bytes set to high always.   My guess is that your device is looking for binary
in its own way... (If you have Doc and need help to figure out what it need, you can send it to me via email or FAX,my email Dalin_N@MailExcite.com)

3.  If you can not find any doc, but you have a program that make it go, you can always capture what is going back and forth, just make a T in your signal cable... (I had to do that many times).



0
 
LVL 3

Expert Comment

by:kfrick
ID: 1495757
OK on the goofy checksum, still one question.....

Your first two data strings read <ETX><&H41><CR>.
Your third data string reads <ETX><&H30><&H41><CR>.

Where did that &H30 come from, or, why is it missing in the first two examples??

-kf
0
 

Author Comment

by:Upland
ID: 1495758
Dalin,

Thanks for the response.

1. I have the DOS program that came with the device - it works just fine.
2. The device doesn't have a menu as such. What it does have (which is good) is a 'debug mode' in which you can see everything sent to the device as hex and all responses from the device as reverse video hex. So in this respect I can see everything that is going on (or not as the case may be).
The only bad thing about the device (in either regular or debug mode) is that unless the message is correctly formatted: ie [stx, addr, code, data, etx, bcc, cr] with everything present and correct - including the bcc (see message above) then it ignores the whole message.
I can capture the data from the original DOS program and then send exactly the same bytes from my program without getting any response from the device. But as I have said above a few times, if I copy the string to the clipboard from the VB Watch Window (just before I do mscomm.output) and paste-to-host via Hyperterminal then it works. (Apart from the fact that a couple of the &H0a bytes are switched to &H8a)
The only other difference I can think of is that the gizmo sits behind an RS232-RS485 convertor as it only has a 9-pin RS485 comms socket on it.
As far as documentation goes, there are five sheets of paper - page one describes the protocol above and the next four pages are simply the different 'messages' you can send it and the responses you can expect to get back.

I have briefly spoken to the guy who wrote the original DOS program without getting anywhere - unfortunately he refuses to have anything to do with MS Windows PERIOD - he even uses a DOS email client and a DOS web browser.
Thanks again....
PS - If you really think the front page of the documentation will help then I will scan and email it later (is a TIF ok?)
0
 

Author Comment

by:Upland
ID: 1495759
kfrick,

Sorry - it was my misprint/typo. It really is there as can be seen in the BCC calc code.
0
 
LVL 3

Expert Comment

by:kfrick
ID: 1495760
Just wondering, how is the 232/485 converter powered?? If, for example, it is DB25 on the RS232 side, and plugged directly into a DB25 COM2: of your PC, it might be drawing power from "unused" handshake pins that Hyperterminal might activate differently than VB......

Try playing with the DTREnable or RTSEnable properties of the msc1 object.........

Sheesh!

-kf
0
 

Author Comment

by:Upland
ID: 1495761
kfrick,

The convertor is 9-pin 485 => 25-pin 232.
I then have a 25 => 9 convertor to plug it into COM1

I have also tried it directly into my 25-pin COM2 but the results are the same.
As I said earlier, it is a 3 wire 485 (TX, RX, GND)

I'm sure a week ago this project looked like fun!   :o)
0
 
LVL 3

Expert Comment

by:kfrick
ID: 1495762
Usually those 9->25 adaptors pass all the handshaking lines thru from DB9 to DB25....the 485 converter still might be taking power from those handshaking lines.......

You might have to look at those signals with some test gear....Do you have a DVM or O'Scope available? Look at pins 4,5,6, and 20 at the DB25 connection during transmission from each session (DOS, VB, HyperTerm) to maybe see a difference there.....

I'm also a bit confused about "3-wire 485"....most 485 interfaces I have seen use 2 twisted pairs, 1 for RX+,RX- and 1 for TX+,TX-. But I don't think thats really your problem, cause the hardware all works with your DOS program.....

How far can you throw that thing???
-kf
0
 

Author Comment

by:Upland
ID: 1495763
kfrick,

The 485 output from the gizmo is in the form of a 5 hole strip connector with screws. I screwed half a metre of regular 3-core flex (which was supplied with the gizmo) into holes 2, 3 and 4 as instructed and then soldered up a 9-pin 485 from a 9-pin socket (again supplied with the gizmo for that very purpose).

Unfortunately I do not have a scope - I'm only a humble programmer! Scoping pins is out of my league I'm afraid - even soldering is pushing it for me.

I am still taking comfort about my soldering skills though from the fact that the DOS program works exactly as it should.

I could probably throw it a good 20 metres or so further than I could have done a few days ago!! I'm just regretting opening my big mouth and saying I could convert an old DOS program into a 32bit Windows app in a couple of days!


0
 
LVL 9

Expert Comment

by:Dalin
ID: 1495764
If you can capture the string and was able to make it work through HyperTerminal,  then put the string to your VB program and it should work... unless you set some of the parameters wrong for the MSComm... Try  to step through

Dim lSendString as String

lstring = " Paste the stuff that worked in hyperTerminal
 msc1.CommPort = 1
 msc1.Settings = "1200,n,8,1"
 msc1.PortOpen = True
msc1.output = lSendString
 msc1.PortOpen = False
0
 

Author Comment

by:Upland
ID: 1495765
OK.... YOU try and paste a few linefeeds into a literal string!!    :o)


0
 
LVL 3

Expert Comment

by:kfrick
ID: 1495766
OK, I DVM'ed the DB9, and here's what I've found.....

You can control the voltages on PIN4(DTR) and PIN6(DSR) via the DTREnable and RTSEnable properties of the msc1 object as follows:

   DTREnable=FALSE,  DTR = -11VDC
   DTREnable=TRUE,   DTR = +11VDC
   RTSEnable=FALSE,  DSR = -11VDC
   RTSEnable=TRUE,   DSR = +11VDC

Your 232->485 gizmo most likely requires both voltages, and the setting of these properties will not bother the serial data flow so long as the Handshake property is set to "none".

Try setting the properties to opposite values, maybe this thing will work yet!

Crimeny!
-kf

0
 

Author Comment

by:Upland
ID: 1495767
KF - YES YES YES YES YES YES YES YES YES YES !!!!!

  DTREnable=FALSE,  DTR = -11VDC
  DTREnable=TRUE,   DTR = +11VDC
  RTSEnable=FALSE,  DSR = -11VDC
  RTSEnable=TRUE,   DSR = +11VDC

Whatever it means - it works!!!
I always suspected the DB9 probably needed DVMing!

So.... I set them both to TRUE and bingo!! All the bytes displayed on the LCD as they should - and then all the reverse video responses from the gizmo.... just perfect.

Am I supposed to set them back to FALSE again sometime...? The reason for asking this is that although I see the response in the LCD, the OnComm doesn't fire (except when I set DTREnable = True) and the InBufferCount stays at zero.
By the way...I have also set the Rthreshold = 1

Anyway, many many thanks... send me an answer (Just say "See Comment") and you can have the points!!  ....and I'll even increase them by a hundred!

0
 
LVL 3

Accepted Solution

by:
kfrick earned 600 total points
ID: 1495768
Don't forget that Converters require Power!
(see the Comments....)

You don't have to set them back to FALSE at all, they just don't make a bit of difference to the data flow....

Glad it worked, Upland!

*whew!*
-kf
0
 
LVL 3

Expert Comment

by:kfrick
ID: 1495769
Oh, sorry, I see that it Might have an impact on Data Flow after all, at least on RX'ing.......

Maybe you shuold try enabling RTS Handshaking?!??

ANYWAY....play around with it, have fun, and congratulations on your superb soldering skills!

-kf


0
 

Author Comment

by:Upland
ID: 1495770
kfrick,

Many thanks once again... just let me know if you need anything soldering...

Upland
PS - I have tried the handshaking set to all four settings and none of them seem to allow me to receive - ie. msc1.InBufferCount never gets > 0.
What else can I play around with? Should I start a new question?  :o(

0
 
LVL 3

Expert Comment

by:kfrick
ID: 1495771
You can toggle those properties at will, maybe set them one way to TX to the gizmo, then set'em back to RX.......

Maybe there is a combination of all these properties that will work in both directions for you...you'll just have to figure it all out, there's no black magic here......

Glad you got it working!

-kf
0

Featured Post

On Demand Webinar: Networking for the Cloud Era

Did you know SD-WANs can improve network connectivity? Check out this webinar to learn how an SD-WAN simplified, one-click tool can help you migrate and manage data in the cloud.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Article by: Martin
Here are a few simple, working, games that you can use as-is or as the basis for your own games. Tic-Tac-Toe This is one of the simplest of all games.   The game allows for a choice of who goes first and keeps track of the number of wins for…
Since upgrading to Office 2013 or higher installing the Smart Indenter addin will fail. This article will explain how to install it so it will work regardless of the Office version installed.
As developers, we are not limited to the functions provided by the VBA language. In addition, we can call the functions that are part of the Windows operating system. These functions are part of the Windows API (Application Programming Interface). U…
Get people started with the process of using Access VBA to control Outlook using automation, Microsoft Access can control other applications. An example is the ability to programmatically talk to Microsoft Outlook. Using automation, an Access applic…
Suggested Courses

704 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question