Serial Port /COM Port UDF

[martin]

Only a small question:

I have to test some products with two serial ports.

In testmode, all Bytes which I send to the first port of this product are directly redirected to the second port. (Without any measurable delay)

At the moment I use two AutoIt programms: One for sending, and one for receiving. Because I want only one EXE I installed the "receive.exe" into the "send.exe" (FileInstall).

(I have to use EXE because this program should work on different computers)

Is there a better way?

Is it possible to send and receive in the same program?

Kind Regards

Veronesi

Yes you can send and receive with the same program. _CommSwitch to the port you want, send some data, switch to another port, read some data, switch to another port send or read data. You should be able to deal with up to 50 different ports though I have never tried. But you can recieve data on one port and send it out on another no problem.

It could be that it would be sensible to make a set of wrapper functions like this

Func ReadByte($iPort,$iWait)

 _CommSwitch($iPort)
 REturn _CommReadByte($iWait)

EndFunc

Maybe having 2 exe's is faster though, and it might or might not make the programming simpler.

EDIT: added missing Return in wrapper function example.

Edited April 21, 2010 by martin

[veronesi]

Yes you can send and receive with the same program. _CommSwitch to the port you want, send some data, switch to another port, read some data, switch to another port send or read data. You should be able to deal with up to 50 different ports though I have never tried. But you can recieve data on one port and send it out on another no problem.

It could be that it would be sensible to make a set of wrapper functions like this

Func ReadByte($iPort,$iWait)

 _CommSwitch($iPort)
 _CommReadByte($iWait)

EndFunc

Maybe having 2 exe's is faster though, and it might or might not make the programming simpler.

Wonderfull! It's working great!

It's much faster than 2 exe's, because I don't have to wait till the second exe is ready!

Thank you very much!

Regards

Veronesi

[martin]

Wonderfull! It's working great!

It's much faster than 2 exe's, because I don't have to wait till the second exe is ready!

Thank you very much!

Regards

Veronesi

That's good. I'm not sure how to deal with so much going right

(I corrected my example in my previous post.)

[joseLB]

Hi Martin

Dealing with more than one channel (let's say 2 channels ), and after opening them:

1- do you have one "internal" in buffer for each channel, I mean, if I'm not switched to that channel it still acumulates the received chars and when I switch to it I will read all those chars physically received while I was swittched to the other channel, withou losing them?

2- the same for sending chars, can I send a string, switch channels, send other string in the other channel and both channels will be doing the real transmition at the same time?

3- all above can hapen at the same time? I mean, can physical transmitions being done in both channels, and at the same time physical transmitions being received in the other 2 channels?

I'm asking that as I'm doing a kind of serial repeater betwen 2 PC's, so, transmitions and receptions can be hapening in all directions at the same real time.

Thanks

Jose

[martin]

Hi Martin

Dealing with more than one channel (let's say 2 channels ), and after opening them:

1- do you have one "internal" in buffer for each channel, I mean, if I'm not switched to that channel it still acumulates the received chars and when I switch to it I will read all those chars physically received while I was swittched to the other channel, withou losing them?

2- the same for sending chars, can I send a string, switch channels, send other string in the other channel and both channels will be doing the real transmition at the same time?

3- all above can hapen at the same time? I mean, can physical transmitions being done in both channels, and at the same time physical transmitions being received in the other 2 channels?

I'm asking that as I'm doing a kind of serial repeater betwen 2 PC's, so, transmitions and receptions can be hapening in all directions at the same real time.

Thanks

Jose

Sorry I missed your post joseLB.

Once you have set up a serial port it stays active and working untill you close it. So yes, while you are looking at one channel other channels can be receiving or sending data and you can read them later. You need to check every so often to make sure an input buffer doesn't overflow and you loose data, although th ehandshaking should prevent that.

Similarly you can send out data which might take some time to transmit, and while that data is being sent you can switch to another channel and receive or send other data.

I didn't provide any control over the buffer sizes, but when a port is opened the input buffer is 4096 bytes and the output buffer is 2048 bytes (for each channel).

[joseLB]

Once you have set up a serial port stays active and working untill you close it.

So, while you are looking at one channel other channels can be receiving or sending data and you can read them later.

You need to check so often to make sure an input buffer doesn't overflow and you loose data, although buffer handshaking (when exists) should prevent that.

Similarly you can send out data which might take some time to transmit, and while that data is being sent you can switch to another channel and receive or send other data.

I didn't provide any control over the buffer sizes, but when a port is opened the input buffer is 4096 bytes and the output buffer is 2048 bytes (for each channel).

Thanks, Martin, your UDF is greatest!

I don't think ist's essential to have control over the buffers size, maybe doing them a bit larger? At 9600, that means about 4 secs read unatended and 2 secs transmiting whitout any intevention. And, that the biggest transmission must be smaller than 2K. Maybe 6K for in and 4K for out?

I use lots of serial comm to connect PC's and microcontrolers projects(PIC). And normally there is no buffer overflow handshake, to make PIC systems simpler. I never got the case that 4K/2K be small, but... who knows?

thanks

Jose

[dillonlim]

Martin,

Many thanks for this great UDF. I've used it in the past without any problems until I tried to connect to an Avocent Cyclades. I keep getting these extra characters which I can't seem to filter out. See attached picture.

.

I don't see these extra characters while viewing through HyperTerminal. How do I clean up those extra characters without messing up the output format? Thanks again.

[martin]

Martin,

Many thanks for this great UDF. I've used it in the past without any problems until I tried to connect to an Avocent Cyclades. I keep getting these extra characters which I can't seem to filter out. See attached picture.

.

I don't see these extra characters while viewing through HyperTerminal. How do I clean up those extra characters without messing up the output format? Thanks again.

They might be linefeed or carriage returns but I don't know. You need to read one character one at a time and decide what to do with it.

I would expect that they are some control characters. You could write the ascii codes for each character to a file to see what's there.

[zetjaro]

hi Martin! it's grat topic and also great job!

My problem is that i'm trying to communicate with Arduino micro controller which I've programmed to turn on LED if it gets number "1" on Rx or turn it off if it receives number "2".

I did it over hyperterminal panel and it works fine but I would like to do it in AutoIT so I can implement it in my previous project which reads inputs from USB gamepad )) basically I could turn on my light in my room over USB gamepad over serial port

Maybe the problem is that arduino is connected over USB cable but it has USB-RS232 converter on PCB

this is the code that I tried to use, I took it from some user which I thank I've just changed it a little bit

#include <CommMg.au3>
Local $ComError
;~ Dialog to request Com port#, i.e. 1 for Com1
$ComPort = InputBox("Comport#", "Enter Com port number")
$ComBaud = 9600
$ComDataBits = 8
$ComParity = 0
$ComStopBits = 1
$ComFLow = 2
;~ Configure Com port settings
_CommSetPort($ComPort,$ComError,$ComBaud,$ComDataBits,$ComParity,$ComStopBits,0)
MsgBox(0,'Com Set',"Com"&$ComPort&" @"&$ComBaud&" baud "&$ComDataBits&$ComParity&$ComStopBits)
$Bytes = "00000001"
MsgBox(0,'Data to Send',$Bytes)
$Numbytes = BinaryLen(Binary($Bytes))
MsgBox(0,'Data Length',$NumBytes)
$Struct1 = DllStructCreate("byte[" & $Numbytes & "]")
DllStructSetData($Struct1, 1, $Bytes)
MsgBox(0,"DllStruct","Struct Size: " & DllStructGetSize($Struct1) & @CRLF & _
"Struct pointer: " & DllStructGetPtr($Struct1) & @CRLF & _
"Data:" & @CRLF & _
DllStructGetData($Struct1,1))
$ComOut = _CommSendByteArray(DllStructGetPtr($Struct1), $Numbytes, 1)
MsgBox(0,'Data Sent',$ComOut)

can you please help me, just to make it work, it is COM3, and Flow control is None

Many thanks!!

[martin]

hi Martin! it's grat topic and also great job!

My problem is that i'm trying to communicate with Arduino micro controller which I've programmed to turn on LED if it gets number "1" on Rx or turn it off if it receives number "2".

I did it over hyperterminal panel and it works fine but I would like to do it in AutoIT so I can implement it in my previous project which reads inputs from USB gamepad )) basically I could turn on my light in my room over USB gamepad over serial port

Maybe the problem is that arduino is connected over USB cable but it has USB-RS232 converter on PCB

this is the code that I tried to use, I took it from some user which I thank I've just changed it a little bit

#include <CommMg.au3>
Local $ComError
;~ Dialog to request Com port#, i.e. 1 for Com1
$ComPort = InputBox("Comport#", "Enter Com port number")
$ComBaud = 9600
$ComDataBits = 8
$ComParity = 0
$ComStopBits = 1
$ComFLow = 2
;~ Configure Com port settings
_CommSetPort($ComPort,$ComError,$ComBaud,$ComDataBits,$ComParity,$ComStopBits,0)
MsgBox(0,'Com Set',"Com"&$ComPort&" @"&$ComBaud&" baud "&$ComDataBits&$ComParity&$ComStopBits)
$Bytes = "00000001"
MsgBox(0,'Data to Send',$Bytes)
$Numbytes = BinaryLen(Binary($Bytes))
MsgBox(0,'Data Length',$NumBytes)
$Struct1 = DllStructCreate("byte[" & $Numbytes & "]")
DllStructSetData($Struct1, 1, $Bytes)
MsgBox(0,"DllStruct","Struct Size: " & DllStructGetSize($Struct1) & @CRLF & _
"Struct pointer: " & DllStructGetPtr($Struct1) & @CRLF & _
"Data:" & @CRLF & _
DllStructGetData($Struct1,1))
$ComOut = _CommSendByteArray(DllStructGetPtr($Struct1), $Numbytes, 1)
MsgBox(0,'Data Sent',$ComOut)

can you please help me, just to make it work, it is COM3, and Flow control is None

Many thanks!!

Looks ok at a quick read provided you enter 3 for the port number and not COM3, but you have passed 0 for the flow control; you should use your variable $ComFLow which is correctly set to 2 for no flow control.

You only want to send 1 or 2 so the byte array approach is too complicated. Try using

_CommSendByte(1) ;to send 1

_CommSendByte(2);to send 2 obviously

Are you sure that your controller expects a byte? If you ype 1 or 2 in Hyperterminal then you are not sending a byte of value 1 or 2 but you are sending a byte with the ascii value of 31 or 32. So instead use

_CommSendByte(Asc('2')) ;to send 2

OR more intuitively,

_CommSendString("2")

Then, if you actually type 1 or 2 followed by Enter to make your controller work with Hyperterminal you need to add the CR character, so

_CommSendString("2" & @CR)

EDIT:

Welcome to the forums zetjaro

Edited September 7, 2010 by martin

[zetjaro]

Looks ok at a quick read provided you enter 3 for the port number and not COM3, but you have passed 0 for the flow control; you should use your variable $ComFLow which is correctly set to 2 for no flow control.

You only want to send 1 or 2 so the byte array approach is too complicated. Try using

_CommSendByte(1) ;to send 1

_CommSendByte(2);to send 2 obviously

Are you sure that your controller expects a byte? If you ype 1 or 2 in Hyperterminal then you are not sending a byte of value 1 or 2 but you are sending a byte with the ascii value of 31 or 32. So instead use

_CommSendByte(Asc('2')) ;to send 2

OR more intuitively,

_CommSendString("2")

Then, if you actually type 1 or 2 followed by Enter to make your controller work with Hyperterminal you need to add the CR character, so

_CommSendString("2" & @CR)

when I enter Crtl+a I receive in hyperterminal panel "I received 1", program in Arduino sends back what did he received

thanks for your advice, I'll try it tommorow when I come to my collegue and let you know what did I accomplished

[zetjaro]

Unfortunately, I can't find Edit button so just wanted to thank you for the welcoming

[Dana]

First, thanks to Martin for the great UDF. It works great, except for one small problem.

I'm using it to read information from Mitutoyo drop gages with a Gageway serial interface, and a USB to serial adapter, which shows up as COM6.

First, I read in the COM port parameters from an ini file, then check for the presence of the port and the connected gagea:

expandcollapse popup

$set = _CommSetPort($comport, $sErr, $combaud, $combits, $comparity, $comstop, $comflow)
    If (@error <> 0) Then
        SplashOff()
        $ret = MsgBox(4096 + 1 + 16, "Error", "COM Port " & $comport & " not found!    You can still select a file for viewing or printing," & @CRLF & "or click CANCEL to close, then connect COM Port and restart program.")
        If ($ret == 2) Then Exit
        $gages = 0
    EndIf
    If ($gages) Then
        $result = _CommClearInputBuffer()
        _CommSendString("<RA", 1) ; trigger gage A to see if it's there
        $found[1] = _CommGetLine(@CR, 0, 2000)
        If (@error <> 0) Then $found[1] = "Not Found,"
        $found[1] = StringLeft($found[1], StringInStr($found[1], ",") - 1)
        _CommClearInputBuffer()
        $splashtext = $splashtext & @CRLF & "Gage A: " & $found[1]
        SplashTextOn("Shaft Length Measurement v" & $version, $splashtext, 400, 200)

        _CommSendString("<RB", 1) ; trigger gage B to see if it's there
        $found[2] = _CommGetLine(@CR, 0, 2000)
        If (@error <> 0) Then $found[2] = "Not Found,"
        $found[2] = StringLeft($found[2], StringInStr($found[2], ",") - 1)
        _CommClearInputBuffer()
        $splashtext = $splashtext & @CRLF & "Gage B: " & $found[2]
        SplashTextOn("Shaft Length Measurement v" & $version, $splashtext, 400, 200)

        _CommSendString("<RC", 1) ; trigger gage C to see if it's there
        $found[3] = _CommGetLine(@CR, 0, 2000)
        If (@error <> 0) Then $found[3] = "Not Found,"
        $found[3] = StringLeft($found[3], StringInStr($found[3], ",") - 1)
        _CommClearInputBuffer()
        $splashtext = $splashtext & @CRLF & "Gage C: " & $found[3]
        SplashTextOn("Shaft Length Measurement v" & $version, $splashtext, 400, 200)

        _CommSendString("<RD", 1) ; trigger gage D to see if it's there
        $found[4] = _CommGetLine(@CR, 0, 2000)
        If (@error <> 0) Then $found[4] = "Not Found,"
        $found[4] = StringLeft($found[4], StringInStr($found[4], ",") - 1)
        _CommClearInputBuffer()
        $splashtext = $splashtext & @CRLF & "Gage D: " & $found[4]
        SplashTextOn("Shaft Length Measurement v" & $version, $splashtext, 400, 200)
        ;MsgBox(4096, "debug", "1: " & $found[1] & @CRLF & "2: " & $found[2] & @CRLF & "3: " & $found[3] & @CRLF & "4: " & $found[4])

        If (($found[1] == "Not Found") And ($found[2] == "Not Found") And ($found[3] == "Not Found") And ($found[4] == "Not Found")) Then
            SplashOff()
            $ret = MsgBox(4096 + 1 + 16, "Error", "No Gages Found!    You can still select a file to view or print," & @CRLF & "or check setup and restart program.")
            If ($ret == 2) Then Exit
            $gages = 0
        EndIf
    EndIf

Then, the program does a bunch of irrelevant (to this discussion) stuff, prompting for files, setting up the GUI, etc., then it gets to the main while loop where I read the data:

expandcollapse popup

While 1
    If ($gages) Then
        $rawdata = _CommGetLine(@CR, 0, 2000)
        $instring = StringStripWS($rawdata, 8)
        If ($instring <> "") Then
            GUICtrlSetBkColor($indicator, 0xff0000) ; Red
            GUICtrlSetData($indicator, "Wait")
            $gageno = StringLeft($instring, StringInStr($instring, ",") - 1) ; read number from gage; not using this
            $value = StringTrimLeft($instring, StringInStr($instring, ","))

            ;debug box
            ;$return = MsgBox(4097, "data received", "Reading: " & $readnum & @CRLF & "Value: " & $value & @CRLF & "Gage: " & $gageno)
            ;If ($return == 2) Then Exit

            If ($gageno == $gageA) Then
                $anum = $anum + 1
                $plungerdepth[$anum] = $value
                If ($anum > $bnum) Then ; new line
                    $linearray[$anum] = GUICtrlCreateListViewItem($anum & "|" & $plungerdepth[$anum] & "|-| |-", $datalist) ; create a new line
                    $balldepth[$anum] = "-"
                EndIf
                $dataline = $anum
                GUICtrlSetData($ano, $anum + 1)
                SoundPlay(@WindowsDir & "\media\Windows XP Balloon.wav", 1) ; tiny beep for data received


            ElseIf ($gageno == $gageB) Then
                $bnum = $bnum + 1
                $balldepth[$bnum] = $value
                If ($bnum > $anum) Then ;new line
                    $linearray[$bnum] = GUICtrlCreateListViewItem($bnum & "|-|" & $balldepth[$bnum] & "| |-", $datalist) ; create a new line
                    $plungerdepth[$bnum] = "-"
                EndIf
                $dataline = $bnum
                GUICtrlSetData($bno, $bnum + 1)
                SoundPlay(@WindowsDir & "\media\Windows XP Balloon.wav", 1) ; tiny beep for data received

            Else
                If ($instring <> "") Then MsgBox(4096, "Error", "Invalid data received:" & @CRLF & $rawdata)
            EndIf

            If ($plungerdepth[$dataline] <> "-" And $balldepth[$dataline] <> "-") Then
                $shaftlength[$dataline] = $plungerdepth[$dataline] + $balldepth[$dataline] + $clearance
                $itemtext = $dataline & "|" & $plungerdepth[$dataline] & "|" & $balldepth[$dataline] & "| |" & $shaftlength[$dataline]
                GUICtrlSetData($linearray[$dataline], $itemtext)
                FileWriteLine($file, $dataline & "," & $plungerdepth[$dataline] & "," & $balldepth[$dataline] & "," & $shaftlength[$dataline])
                SoundPlay(@WindowsDir & "\media\Windows Feed Discovered.wav")
            EndIf
            _GUICtrlListView_EnsureVisible($datalist, $dataline - 1)
            _GUICtrlListView_SetItemSelected($datalist, $dataline - 1, True, True)
            Sleep(500)
            _CommClearInputBuffer()

            GUICtrlSetData($indicator, "Ready")
            GUICtrlSetBkColor($indicator, 0x00ff00) ; Green
        EndIf
    Else
        Sleep(500)
    EndIf
WEnd

It's running in GUIOnEventMode=1, which provides the means to exit the while 1 loop when buttons are clicked.

The problem is: If the USB cable is unplugged while it's in the while loop waiting for data, the program crashes, every time ("shaftlength.exe encountered an error and must exit..."). The users reported random crashes, could be a flaky USB serial adapter cable, though I personally didn't observe the crash unless I actually unplugged the cable.

Now, here's an odd thing: I created a stripped down version of the program for testing in my office, since I don't have the connected gages available. In this version, on this computer, which is identical in the com handling, unplugging the USB serial cable doesn't crash it, but causes the program to immediately exit.

Here's the stripped version:

expandcollapse popup

$version = "1.10"
$debugnogages = 0 ; 0 for normal use, 1 to skip gage presence checks for program debug only


#include <CommMg.au3>
#include <GUIConstantsEx.au3>
#include <ListviewConstants.au3>
#include <GuiListView.au3>
#include <EditConstants.au3>
#include <File.au3>
#include <StaticConstants.au3>


;Read ini file
$datadir = IniRead("shaftlength.ini", "Directories", "datadir", ".\")
If (StringRight($datadir, 1) <> "\") Then $datadir = $datadir & "\" ; add trailing backslash if it's missing
$paramdir = IniRead("shaftlength.ini", "Directories", "paramdir", ".\")
If (StringRight($paramdir, 1) <> "\") Then $paramdir = $paramdir & "\" ; add trailing backslash if it's missing
$comport = IniRead("shaftlength.ini", "Port", "comport", 1)
$combaud = IniRead("shaftlength.ini", "Port", "baud", 9600)
$combits = IniRead("shaftlength.ini", "Port", "bits", 8)
$comparity = IniRead("shaftlength.ini", "Port", "parity", 0)
$comstop = IniRead("shaftlength.ini", "Port", "stop", 1)
$comflow = IniRead("shaftlength.ini", "Port", "flow", 0)

Opt("TrayIconDebug", 1)
$nocomport = 0
$splashtext = "Initializing, please wait..."
SplashTextOn("Shaft Length Measurement v" & $version, $splashtext, 400, 200)
Dim $balldepth[256]
Dim $plungerdepth[256]
Dim $shaftlength[256]
Dim $linearray[256]
Dim $found[5]
Dim $sErr
$gages = 1
SplashOff()

$set = _CommSetPort($comport, $sErr, $combaud, $combits, $comparity, $comstop, $comflow)
If (@error <> 0) Then
    SplashOff()
    $ret = MsgBox(4096 + 1 + 16, "Error", "COM Port " & $comport & " not found!    You can still select a file for viewing or printing," & @CRLF & "or click CANCEL to close, then connect COM Port and restart program.")
    If ($ret == 2) Then Exit
    ;$gages = 0
EndIf


MsgBox(4096, "debug", "port set")

While 1
    If ($gages) Then
        $rawdata = _CommGetLine(@CR, 0, 2000)
        $instring = StringStripWS($rawdata, 8)
        If ($instring <> "") Then
            $gageno = StringLeft($instring, StringInStr($instring, ",") - 1) ; read number from gage; not using this
            $value = StringTrimLeft($instring, StringInStr($instring, ","))

            ;debug box
            ;$return = MsgBox(4097, "data received", "Reading: " & $readnum & @CRLF & "Value: " & $value & @CRLF & "Gage: " & $gageno)
            ;If ($return == 2) Then Exit

            Sleep(500)
            _CommClearInputBuffer()
        EndIf
    Else
        Sleep(500)
    EndIf
WEnd

[murfaul]

Hi,

I have been using this UDF for some time now and have been very happy with it. I have recently found another application where I would like to use it, however the baud rate I require is 31250. The comments in the UDF say the following:

"; $iBaud - integer: the baud rate required. With commg.dll v2.3 and later any value allowed up to 256000.

; With v2.4 any value??

; If using commg.dll before V2.3 then only allowed values are one of

; 50, 75, 110, 150, 600, 1200, 1800, 2000, 2400, 3600, 4800, 7200, 9600, 10400,

; 14400, 15625, 19200, 28800, 38400, 56000, 57600, 115200, 128000, 256000"

From what I gather V2.3 or earlier can only operate at the baud rates listed, however I am not clear as to whether V2.4+ will allow other baud rates. I have tried 31250 but receive an error message when executing setport. Could someone confirm whether 31250 does or does not work?

Martin, If you happen to read this could you let me know if it would be possible to implement 31250 in a future release of the COMMG.dll?

Thanks

[Dana]

Still getting strange issues, different on three different computers. Here's a much stripped down version:

#include <CommMg.au3>

$portlist = _CommListPorts()
;MsgBox(4096, "debug", $portlist)
Local $sErr
$set = _CommSetPort(6, $sErr, 9600, 8, 0, 1, 0)
msgbox(4096, "debug", "port set" & @CRLF & $set)
_CommClearInputBuffer()
MsgBox(4096, "debug", "ready to read data")
$rawdata = _CommGetLine(@CR, 0, 0)
MsgBox(4096, "debug", "should not get here")

On my desktop computer (Win XP Pro x64, if I unplug the USB-Serial converter after acknowledging the "ready to read data", the program simply exits (I never see the final box). If I run it from SciTE, I get an exit code 250477278.

On the customer's computer (Win XP Pro 32bit), if I unplug the USB-Serial converter after acknowledging the "ready to read data", the program instantly crashes with a standard Windows "...has encountered an error and must close. We are sorry for the inconvenience..." This happens whether I run the compiled version or run it from SciTE.

On my own laptop (also XP Pro 32bit), I get "FormCommg: test.exe - Application Error The execption unknown software exception (0x0eedfade) occurred in the application at location 0x7c812afb." (test.exe is the compiled version). This also happens in both the compiled exe or from SciTE, though the addresses given are different.

The same thing happens if I start the program without the USB connected, so both _CommSetPort and _CommGetLine cause the problem (but _CommListPorts doesn't).

The real problem on the customer's end isn't (necessarily) that the USB cable isn't being unplugged; he's just getting random crashes. Since unplugging the cable also causes the same crash, I suspect, but am not certain, that the cable may be flaky... but still, it shouldn't crash, no?

It also takes up nearly 100% of CPU time while waiting for data.

Any ideas, anybody?

-Dana

[martin]

Hi,

I have been using this UDF for some time now and have been very happy with it. I have recently found another application where I would like to use it, however the baud rate I require is 31250. The comments in the UDF say the following:

"; $iBaud - integer: the baud rate required. With commg.dll v2.3 and later any value allowed up to 256000.

; With v2.4 any value??

; If using commg.dll before V2.3 then only allowed values are one of

; 50, 75, 110, 150, 600, 1200, 1800, 2000, 2400, 3600, 4800, 7200, 9600, 10400,

; 14400, 15625, 19200, 28800, 38400, 56000, 57600, 115200, 128000, 256000"

From what I gather V2.3 or earlier can only operate at the baud rates listed, however I am not clear as to whether V2.4+ will allow other baud rates. I have tried 31250 but receive an error message when executing setport. Could someone confirm whether 31250 does or does not work?

Martin, If you happen to read this could you let me know if it would be possible to implement 31250 in a future release of the COMMG.dll?

Thanks

31250 should be ok with the udf V2.4 and the dll v2.3 or later.What version of the dll are you using?

What errors do you get?

Can you set rates like 28800 and 38400 without errors?

[martin]

Still getting strange issues, different on three different computers. Here's a much stripped down version:

#include <CommMg.au3>

$portlist = _CommListPorts()
;MsgBox(4096, "debug", $portlist)
Local $sErr
$set = _CommSetPort(6, $sErr, 9600, 8, 0, 1, 0)
msgbox(4096, "debug", "port set" & @CRLF & $set)
_CommClearInputBuffer()
MsgBox(4096, "debug", "ready to read data")
$rawdata = _CommGetLine(@CR, 0, 0)
MsgBox(4096, "debug", "should not get here")

On my desktop computer (Win XP Pro x64, if I unplug the USB-Serial converter after acknowledging the "ready to read data", the program simply exits (I never see the final box). If I run it from SciTE, I get an exit code 250477278.

On the customer's computer (Win XP Pro 32bit), if I unplug the USB-Serial converter after acknowledging the "ready to read data", the program instantly crashes with a standard Windows "...has encountered an error and must close. We are sorry for the inconvenience..." This happens whether I run the compiled version or run it from SciTE.

On my own laptop (also XP Pro 32bit), I get "FormCommg: test.exe - Application Error The execption unknown software exception (0x0eedfade) occurred in the application at location 0x7c812afb." (test.exe is the compiled version). This also happens in both the compiled exe or from SciTE, though the addresses given are different.

The same thing happens if I start the program without the USB connected, so both _CommSetPort and _CommGetLine cause the problem (but _CommListPorts doesn't).

The real problem on the customer's end isn't (necessarily) that the USB cable isn't being unplugged; he's just getting random crashes. Since unplugging the cable also causes the same crash, I suspect, but am not certain, that the cable may be flaky... but still, it shouldn't crash, no?

It also takes up nearly 100% of CPU time while waiting for data.

Any ideas, anybody?

-Dana

Unplugging the usb port is known to cause a nasty effect and I have no plans to try and do anything about that. It could be that there is a faulty cable as you suggest and the easiest test is to try another device. There is no reason that I know of for the udf and dll to have any problem running continually.

100% CPU time is not good. What code is being executed when that happens?

[murfaul]

31250 should be ok with the udf V2.4 and the dll v2.3 or later.What version of the dll are you using?

What errors do you get?

Can you set rates like 28800 and 38400 without errors?

Hi Martin,

I can set rates 28800 and 38400 without errors. However as soon as I set the baud rate to 31250 I get: "Setport error =" "unknown error accessing port". I am using DLL version 2.6 with UDF version 2.7.

Thanks,

Murray

[martin]

Hi Martin,

I can set rates 28800 and 38400 without errors. However as soon as I set the baud rate to 31250 I get: "Setport error =" "unknown error accessing port". I am using DLL version 2.6 with UDF version 2.7.

Thanks,

Murray

I think a standard PC cannot set the baud rate to 31250. See

http://www.repairfaq.org/filipg/LINK/F_midi2.html

for the reason and how you could get round it.

[jimg]

I'm in a hotel room with a very slow link, so forgive me if I'm posting this to the wrong place. I'm not near my code nor an AutoIt3 installation, so I can't reproduce my exact code or even the exact Commg function name.

I'm using commg in an application working with a Redbee RFID reader, and everything is working just fine except my .exe file keeps hogging all the cpu time (shown in Task Monitor/Services.

Code snippet:

--------------

while 1

sleep(200)

$data = _commg_getline(...,2000) ; I know this isn't the actual syntax except for the last parameter.

"parse data"

wend

--------------

The rest of the code is all event driven from GUI controls. I've played with the sleep() parameter which doesn't change the CPU utilization. I'm guessing the getline is the problem, since the utilization is a problem with no incoming traffic.

My goal is to process whole "lines" of asynchronous input.

Is there a better way to handle this? My next try is to read strings instead of lines, contcatenate them, and wait for a @CR within the string?