Results 1 to 9 of 9

Thread: [RESOLVED] MSComm Woes

  1. #1

    Thread Starter
    Member
    Join Date
    Oct 2002
    Posts
    54

    Resolved [RESOLVED] MSComm Woes

    When the user plugs a USB device into the computer, my program checks in the registry for the Port the driver has used (usually the next available, on my system Comm 5).

    I use the MSComm control to open a communication with a chip on an electronic device. It works great, I use a GUI to perform hyperTerminal operations.

    My customers OS (XP Pro) tries to use port 17, and the program fails to communicate with the device, although HyperTerminal will work.
    According to the VB Helpfile the MSComm control can only use ports 1 - 16. Is there any other way around this??

    I need a fix which doesn't involve users messing around with hardware settings, I need to do it all via my program.

    Thank you

  2. #2
    Just Married shakti5385's Avatar
    Join Date
    Mar 2006
    Location
    Udaipur,Rajasthan(INDIA)
    Posts
    3,747

  3. #3

    Thread Starter
    Member
    Join Date
    Oct 2002
    Posts
    54

    Re: MSComm Woes

    Thanks for the link, but I'm familiar with basic MSComm settings. I was really needing a windows API I can use, or another way of communicating via the comm ports if anyone knows another way of doing it besides MSComm.

    Thanks.

  4. #4

    Thread Starter
    Member
    Join Date
    Oct 2002
    Posts
    54

    Re: MSComm Woes

    I can now open the port using an API. Can anyone tell me the method for sending strings to a com port without using the MScomm control?

  5. #5
    old fart Frans C's Avatar
    Join Date
    Oct 1999
    Location
    the Netherlands
    Posts
    2,926

    Re: MSComm Woes

    Have a look at this thread
    Frans

  6. #6

    Thread Starter
    Member
    Join Date
    Oct 2002
    Posts
    54

    Re: MSComm Woes

    Thanks Frans,

    that link has been a great help, I can now open a port higher than 16 and send characters to a chip onboard an electronic device via that port.

    The example in the link sends a character array. My chip is expecting a string in a specific format. Using the MSComm control I simply had to send the string "C1103345123401" & chr(13) for the device to be happy and respond accordingly.

    I can't work out how to do this using the writefile function as in the examples in the link. Can you or anyone else please point me in the right direction. I need to pick up the string returned by the embedded chip also.

    Thank you.

  7. #7
    old fart Frans C's Avatar
    Join Date
    Oct 1999
    Location
    the Netherlands
    Posts
    2,926

    Re: MSComm Woes

    It should be as simple as calling the Write2Port function, with "C1103345123401" & chr(13) for the strData parameter. The conversion to byte array is already in there. I have never tested it though. I just remembered the thread from a previous visit, and found it back with the search function.

    Doesn't it work?
    Frans

  8. #8

    Thread Starter
    Member
    Join Date
    Oct 2002
    Posts
    54

    Re: MSComm Woes

    The chip is expecting a string followed by the chr(13). If successful it replies with an audible beep and sends back an "OK" & chr(13) string.

    I can only get it to beep if I send a single "control" character to it. For example an "X" & chr(13) forces a beep and a 52 character string return string with all current settings and its set serial number.

    Also I'm not sure how to retrieve the return string using the API's. I may have to abandon the API approach.

    Thanks for your help though.

  9. #9
    PowerPoster
    Join Date
    Feb 2006
    Location
    East of NYC, USA
    Posts
    5,691

    Re: MSComm Woes

    VB Code:
    1. Declare Function ReadFile Lib "kernel32" Alias "ReadFile" (ByVal hFile As Long, lpBuffer As Any, ByVal nNumberOfBytesToRead As Long, _
    2.                                                            lpNumberOfBytesRead As Long, lpOverlapped As OVERLAPPED) As Long
    may be of some help. http://www.allapi.net/apilist/ReadFile.shtml
    The most difficult part of developing a program is understanding the problem.
    The second most difficult part is deciding how you're going to solve the problem.
    Actually writing the program (translating your solution into some computer language) is the easiest part.

    Please indent your code and use [HIGHLIGHT="VB"] [/HIGHLIGHT] tags around it to make it easier to read.

    Please Help Us To Save Ana

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width