Serial Port /COM Port UDF

[martin]

hello is there a fix for virtual com ports?

I have a bluetooth gps device, which works on com 8

I'm able to connect with hyperterminal and get results.

but this dll/udf errors out.

I assume because it's virtual?

thanks

No, the udf works with virtual ports, but problems with bluetooth virtual ports has been mentioned before. What error do you get?

[blitzkrg]

No, the udf works with virtual ports, but problems with bluetooth virtual ports has been mentioned before. What error do you get?

hmm. with the example, I was getting a previously mentioned error

$portlist = _CommListPorts(0);find the available COM ports and write them into the ports combo
    If @error = 1 Then 
        MsgBox(0,'trouble getting portlist','Program will terminate!')
        Exit
    EndIf

        
    For $pl = 1 To $portlist[0]

I guess _CommListPorts(0) is not returning any results

my gps is on comm 8 and works with hypterterm.

also i tried another serial udf (cfxudf) but his udf is not nearly as complete as yours and it does not recieve binary data, but it does work and does give me results.

I prefer your option because it is full featured, but i can not get it to see my comm port

[blitzkrg]

@martin

I found a very nice program called vistumbler, It uses 3 types of interface for the GPS

netcomm.ocx, your commg.dll and the kernel32 / ufx

both netcomm and the kernel32 versions work with my gps device.

(also so does hyperterm)

yours is the only one who doesn't.

I'm not saying that to complain, but i would prefer to use your UDF/dll but can't get it working.

is there some debug code i can run to help figure out why it's not working?

thanks

Edited January 16, 2010 by blitzkrg

[martin]

@martin

I found a very nice program called vistumbler, It uses 3 types of interface for the GPS

netcomm.ocx, your commg.dll and the kernel32 / ufx

both netcomm and the kernel32 versions work with my gps device.

(also so does hyperterm)

yours is the only one who doesn't.

I'm not saying that to complain, but i would prefer to use your UDF/dll but can't get it working.

is there some debug code i can run to help figure out why it's not working?

thanks

What errors or problems do you get?

[blitzkrg]

What errors or problems do you get?

The problem is it doesn't see the comm port (comm 8)

[martin]

The problem is it doesn't see the comm port (comm 8)

If you look in Device Manager do you see COM8 there? If not then my udf won't see it. If you do see it then my udf should also be able to see it.

[blitzkrg]

If you look in Device Manager do you see COM8 there? If not then my udf won't see it. If you do see it then my udf should also be able to see it.

I apologize if I'm not being clear.

yes I see comm 8 in device mgr. and every other program and udf see's it to. yours is the only one who doesn't.

[martin]

I apologize if I'm not being clear.

yes I see comm 8 in device mgr. and every other program and udf see's it to. yours is the only one who doesn't.

Then I should be able to sort it out. Give me a week.

[joseLB]

Hi Martin

On your example at first post, after initial setup, you just send the typed string when send button is pressed (CommSendstring(GUICtrlRead($Input1) & @CR)), and in the main loop you "wait" until something arrives at $instr = _CommGetString().

On my notebook all work fine, but, I just have com4, and it's used internaly I don't know for what, but it's not an external port

question: As your example au3 sends and receives the string, it's not supposed that pin 2-3 shoud be connected in "loop" in order to receive what it sent? Or by any reason your routines/dll echoes internaly what was sent?

If yes, I must take care on my program to filter what I sent, if I'm not interested in receive it?

If no, I can suppose that my com4 is internally "looped" in any form? In this case, your example should not warn that they must be in loop?

Thanks

Jose

[martin]

Hi Martin

On your example at first post, after initial setup, you just send the typed string when send button is pressed (CommSendstring(GUICtrlRead($Input1) & @CR)), and in the main loop you "wait" until something arrives at $instr = _CommGetString().

On my notebook all work fine, but, I just have com4, and it's used internaly I don't know for what, but it's not an external port

question: As your example au3 sends and receives the string, it's not supposed that pin 2-3 shoud be connected in "loop" in order to receive what it sent? Or by any reason your routines/dll echoes internaly what was sent?

If yes, I must take care on my program to filter what I sent, if I'm not interested in receive it?

If no, I can suppose that my com4 is internally "looped" in any form? In this case, your example should not warn that they must be in loop?

Thanks

Jose

Hi Jose,

the example simply transmits what is in the edit when you click the"send" button". Only data received is shown in the 'Terminal'. If you are seeing what you send then whatever your COM4 is connected to is echoing characters back. Maybe it is an internal modem, but I think (Vague) that this will also happen if you send characters to a serial mouse. It could be, as you say, that pins 2 and 3 are joined. Anyway, my udf neither expects nor cares whether 2 and 3 are joined, it simply sends and receives.

Now that you have prompted me to look at the example I am amazed that I ever posted it; it's a complete mess and I'll have to replace it.

[joseLB]

Hi Jose,

the example simply transmits what is in the edit when you click the"send" button". Only data received is shown in the 'Terminal'. If you are seeing what you send then whatever your COM4 is connected to is echoing characters back. Maybe it is an internal modem, but I think (Vague) that this will also happen if you send characters to a serial mouse. It could be, as you say, that pins 2 and 3 are joined. Anyway, my udf neither expects nor cares whether 2 and 3 are joined, it simply sends and receives.

Now that you have prompted me to look at the example I am amazed that I ever posted it; it's a complete mess and I'll have to replace it.

Thanks Martin, but..... Not so messy.... whe can understand it, and a so complete udf is what matters.

I just tried an USB/Serial cable (COM6), the serial connector not connected. There is no echo at terminal, so, by sure my COM4 (maybe modem or keyboard) echoes by itself. I think at the example, at least, you shoud mention that if there is no return path betwen 2-3, (short circuit or a "repeater"), it will not work as expected, that is, will not echo what you have typed.

Edited: - I just shorted serial connector pins 2-3 and it works ok, echoing. But, in order to see what you typed, you must substitute line

$instr =_CommGetString()

by

$instr = _CommGetLine()

Jose

Edited January 21, 2010 by joseLB

[joseLB]

Hi Martin

I continue doing my tests with a USB <->Serial cable (by the way, very cheap, "chinese" generic brand).

Now, _CommSetDTR() and _CommSetRTS(). For that, before the main loop at your example, I put this small piece of code (I tried with both DTR and RTS):

...
Events()

GUICtrlSetState($edit1,$GUI_FOCUS)

;------- new code 
Local $stat,$k
For $k=1 To 3
  $stat= _CommSetDTR(1)
  MsgBox(4096,"ON","stat=" & $stat)
  $stat= _CommSetDTR(0)
  MsgBox(4096,"OFF","stat=" & $stat)
Next
;-----end new code
While 1
....

Selecting COM6 at your setup screen (I changed nothing on it) there is no voltage change at any RS232 pin (all in 0V) in the above loop, no matter if it's 1 or 0 in the commands, but status always return OK. And, after the 3 iteractions, when it continues with the original program, echo works OK as I jumped pins 2-3.

One point to mention is that this USB<->Serial do not have any negative voltage, as stated in EIA-RS232. Instead, pins 2-3 uses 0V for "1" and 5v for "0". So, do you believe this can be your routines problem or this very cheap converter (probably) has not DTR and RTS pins conected? It's based on prolific PL-2303 chipset, and I got at prolific site the latest win XP driver, that's much newer than the ones that come in the CD. Follows prolific download site, just for reference.

http://www.prolific.com.tw/eng/Download-2.asp?ID=17

see prolific manual's specification (this don't mean the cable maker used all it's features...

---Supports RS232-like Serial Interface

o Full-duplex transmitter and receiver (TXD and RXD)

o Six MODEM control pins (RTS, CTS, DTR, DSR, DCD, and RI)

o 5, 6, 7 or 8 data bits

o Odd, Even, Mark, Space, or None parity mode

o One, one and a half, or two stop bits

o Parity error, frame error, and serial break detection

o Programmable baud rate from 75 bps to 12M bps

o External RS232 driver power down control

o Independent power source for serial interface

---- Extensive Flow Control Mechanism

o Adjustable high/low watermark level

o Automatic hardware flow control with CTS/RTS(1) or DSR/DTR(2)

o Automatic software flow control with XON/XOFF

o Inbound data buffer overflow detection

Edited January 21, 2010 by joseLB

[martin]

Hi Martin

I continue doing my tests with a USB <->Serial cable (by the way, very cheap, "chinese" generic brand).

Now, _CommSetDTR() and _CommSetRTS(). For that, before the main loop at your example, I put this small piece of code (I tried with both DTR and RTS):

...
Events()

GUICtrlSetState($edit1,$GUI_FOCUS)

;------- new code 
Local $stat,$k
For $k=1 To 3
 $stat= _CommSetDTR(1)
 MsgBox(4096,"ON","stat=" & $stat)
 $stat= _CommSetDTR(0)
 MsgBox(4096,"OFF","stat=" & $stat)
Next
;-----end new code
While 1
....

Selecting COM6 at your setup screen (I changed nothing on it) there is no voltage change at any RS232 pin (all in 0V) in the above loop, no matter if it's 1 or 0 in the commands, but status always return OK. And, after the 3 iteractions, when it continues with the original program, echo works OK as I jumped pins 2-3.

One point to mention is that this USB<->Serial do not have any negative voltage, as stated in EIA-RS232. Instead, pins 2-3 uses 0V for "1" and 5v for "0". So, do you believe this can be your routines problem or this very cheap converter (probably) has not DTR and RTS pins conected? It's based on prolific PL-2303 chipset, and I got at prolific site the latest win XP driver, that's much newer than the ones that come in the CD. Follows prolific download site, just for reference.

http://www.prolific.com.tw/eng/Download-2.asp?ID=17

see prolific manual's specification (this don't mean the cable maker used all it's features...

---Supports RS232-like Serial Interface

o Full-duplex transmitter and receiver (TXD and RXD)

o Six MODEM control pins (RTS, CTS, DTR, DSR, DCD, and RI)

o 5, 6, 7 or 8 data bits

o Odd, Even, Mark, Space, or None parity mode

o One, one and a half, or two stop bits

o Parity error, frame error, and serial break detection

o Programmable baud rate from 75 bps to 12M bps

o External RS232 driver power down control

o Independent power source for serial interface

---- Extensive Flow Control Mechanism

o Adjustable high/low watermark level

o Automatic hardware flow control with CTS/RTS(1) or DSR/DTR(2)

o Automatic software flow control with XON/XOFF

o Inbound data buffer overflow detection

Just a quick question and not a full reply as it's too late for me, but when you measure the voltages do you have anything connected to the serial port? If the signal are switched by an open collector output then you would see nothing unless there is something to pull the output high.

I disagree that I need to make any note about connecting 2 to 3. The udf reads whatever is recieved (or it should do) and usually that will be because somthing was sent by another device. If you want to echo the transmission then that should be done in the software not the hardware IMO. Connecting 2 to 3 might not work correctly for some handshaking modes.

I will look at your post in more depth at the weekend.

[joseLB]

Just a quick question and not a full reply as it's too late for me, but when you measure the voltages do you have anything connected to the serial port? If the signal are switched by an open collector output then you would see nothing unless there is something to pull the output high.

Good question! It wasconected to nothing, and, who knows, it can be open collector. I will check that with some load at RTS and post the result here.

Thanks

Jose

Edited January 22, 2010 by joseLB

[martin]

I apologize if I'm not being clear.

yes I see comm 8 in device mgr. and every other program and udf see's it to. yours is the only one who doesn't.

What OS blitzkrg?

I have tried a USB to Serial converter using ports 1, 11 then 25 etc and no problems. I am using XP SP3.

I made a small change to the example in post #1 but not related to this unless the message box saying "error=" was taken to mean that there was an error when in fact it means there is no error! That's one bit I changed.

Edited January 24, 2010 by martin

[blitzkrg]

win 7 x64

[Akshay07]

Hi Martin,

I am trying to use your script step by step and I had a problem.

In my script, I am using the _CommSetDllPath function to indicate the location of the commg.dll:

Call ("_CommSetDllPath", "C:\MyFolder\commg.dll")

But when I run it, I get this msgbox error message:

'Failed to open commg.dll'

Looking at CommMG.au3, I see that I reach this message when running through the following statements in the function _CommSetPort:

If Not $fPortOpen Then
        $hDll = DllOpen('commg.dll')

        If $hDll = -1 Then
            SetError(2)
            $sErr = 'Failed to open commg.dll'
            Return 0;failed
        EndIf
        $fPortOpen = True
    EndIf

If I change the second line into

If Not $fPortOpen Then
        $hDll = DllOpen($DLLNAME)

        If $hDll = -1 Then
            SetError(2)
            $sErr = 'Failed to open commg.dll'
            Return 0;failed
        EndIf
        $fPortOpen = True
    EndIf

I don't have any errors and I can open the port.

Shouldn't it be $DLLNAME instead of 'commg.dll'?

Global $DLLNAME = 'commg.dll'

;===============================================================================
;
; Function Name:  _CommSetDllPath($sFullPath)
; Description:    Sets full path to th edll so that it can be in any location.
;
; Parameters:     $sFullPath -  Full path to the commg.dll e.g. "C:\COMMS\commg.dll"
; Returns;  on success 1
;           on error -1 if full path does not exist
;===============================================================================
Func _CommSetDllPath($sFullPath)
    If not FileExists($sFullPath) then return -1

    $DLLNAME = $sFullPath
    return 1

EndFunc

PS: I also get an error when I check the syntax of CommgExample.au3:

C:\(...)\CommgExample.au3(16,31) : ERROR: OnAutoItExitRegister(): undefined function.

OnAutoItExitRegister("alldone")

If I comment out

OnAutoItExitRegister("alldone")

I don't have any error message.

Edited January 27, 2010 by Akshay07

[jchd]

Shouldn't it be $DLLNAME instead of 'commg.dll'?

Certainly.

PS: I also get an error when I check the syntax of CommgExample.au3:

C:\(...)\CommgExample.au3(16,31) : ERROR: OnAutoItExitRegister(): undefined function.

That's surprising. Which version of AutoIt are you running? You really should run 3.3.4.0 (latest release) and probably the latest beta 3.3.5.1 on top of it.

Be sure to install on top of the full fledged version of AutoIt + Scite, there are many goodies included.

In short: make sure you have it in this order: AutoIt+full Scite then latest release then (optional but recomended as it's stable AFAIK) latest beta.

[Akshay07]

Updating to 3.3.4.0 solved the OnAutoItExitRegister() issue, thanks for the tip.

[blitzkrg]

@Martin

Can you compile a 64 bit version?