Serial Port /COM Port UDF

[AmnonS]

Martin.

I'm new in this forum and not quite skilled in Auto and UDFs.

What i'm trying to do is to control a balance device thru a com port.

I took the files you load up and put the dll file at the script directory.

Also i have put the commMG file at the #INCLUD directory.

When I run the script the AotuIt recognized the connected port and let me entered to the CommMG Example Interface.

But the feedback is not good.

Please let me know what could be not correct ?

Thanks

Amnon

[martin]

Martin.

I'm new in this forum and not quite skilled in Auto and UDFs.

What i'm trying to do is to control a balance device thru a com port.

I took the files you load up and put the dll file at the script directory.

Also i have put the commMG file at the #INCLUD directory.

When I run the script the AotuIt recognized the connected port and let me entered to the CommMG Example Interface.

But the feedback is not good.

Please let me know what could be not correct ?

Thanks

Amnon

Amnon,

I need more information to begin to make any suggestions. What you have done with the files is fine.

• What does "feedback not good" mean?
• Do you have the information on how to control the balance through a serial port and are you sure that you have all the settings as they should be?
• Have you tried different flow settings?

[AmnonS]

Martin, hello.

First thanks for the reply.

And for your questions :

1. For example when I'm connecting to the device balance thru the RS232 and use the balance manufacturer S.W., and sending the character "Q" I get as a feedback the displayed weight value, and when I'm sending the character "R" it zero the displayed value.

2. The flow setting I'm using are : Baud - 9600 , No. of Data Bits - 8 , No. Stop bits = 1 , Parity - none.

3. When I'm sending those characters thru the AutoIt the feedback I get is "EC,E03", these exact feedback I'm also getting when I'm using the manufacturer S.W. but with different flow settings : Baud - 9600 , No. of Data Bits - 7 , No. Stop bits = 2 , Parity - none.

4.Also the functions in the script like "_CommGetline" etc. painted in "Black" instead of "Sky blue" the regular paint in my scripts.

I hope I'm clear.

Thanks a lot.

Amnon

[martin]

Martin, hello.

First thanks for the reply.

And for your questions :

1. For example when I'm connecting to the device balance thru the RS232 and use the balance manufacturer S.W., and sending the character "Q" I get as a feedback the displayed weight value, and when I'm sending the character "R" it zero the displayed value.

2. The flow setting I'm using are : Baud - 9600 , No. of Data Bits - 8 , No. Stop bits = 1 , Parity - none.

3. When I'm sending those characters thru the AutoIt the feedback I get is "EC,E03", these exact feedback I'm also getting when I'm using the manufacturer S.W. but with different flow settings : Baud - 9600 , No. of Data Bits - 7 , No. Stop bits = 2 , Parity - none.

4.Also the functions in the script like "_CommGetline" etc. painted in "Black" instead of "Sky blue" the regular paint in my scripts.

I hope I'm clear.

Thanks a lot.

Amnon

I can't say if point 3 is a problem. Presumably you've tried 8 data bits and 1 stop bit, but if it works why worry?

Point 4 is to do with settings in Scite and not relevant to this thread.

[AmnonS]

Martin.

Again thanks,

And what I'm understood that there is no problem with the script with those flow setttings ?

If so do yuo have any idea what could be the problem ?

Thanks

Amnon

[martin]

Martin.

Again thanks,

And what I'm understood that there is no problem with the script with those flow setttings ?

If so do yuo have any idea what could be the problem ?

Thanks

Amnon

I can't help you because I don't understand what your problem is. It may be that the translation is the problem but it looks to me as though you are saying

"I receive the characters I should. How do I fix it?"

So far I think what you have told me should have been included in the first post and you still haven't told me what happens if you set 8 data 1 stop, what flow settings you have tried, what flow settings the device is supposed to have if you know.

8 data bits plus 1 stop is the same number of bits as 7 data + 2 stop and both might work depending on the parity and flow control used by the device. Presumable the device does not set paraity and you have parity set to none, otherwise you will have problems. But you can also have problems if the flow control is not set correctly.

If the device only has 3 wires connected then it uses either no flow control or XON/XOFF.

[AmnonS]

Martin, Hi.

I'll try to clear my self again.

The flow setting I'm using are : Baud - 9600 , No. of Data Bits - 8 , No. Stop bits = 1 , Parity - none.

But with AutoIt script it doesn't work.

I try to change the settings all, but it still not work.

Thanks

Amnon

[martin]

Martin, Hi.

I'll try to clear my self again.

The flow setting I'm using are : Baud - 9600 , No. of Data Bits - 8 , No. Stop bits = 1 , Parity - none.

But with AutoIt script it doesn't work.

I try to change the settings all, but it still not work.

Thanks

Amnon

In post 343 you said

3. When I'm sending those characters thru the AutoIt the feedback I get is "EC,E03", these exact feedback I'm also getting when I'm using the manufacturer S.W. but with different flow settings : Baud - 9600 , No. of Data Bits - 7 , No. Stop bits = 2 , Parity - none.

But it's not obvious to me that that agrees with your last post so I am still confused. So answer these questions please.

When using my dll is there any setting you have tried which gets anything to appear as received?

If Yes

then tell me what those settings are.

If No

then maybe it's because of the flow settings. What flow settings have you tried.?

It could be for all sorts of other reasons. Maybe the manufacturers expect a line to be held high or low before they will transmit data and maybe they don't use standard methods or maybe they are send data in a special way using some protocol which you don't know about. It could be that I can't help you with this because there might be too many unknowns.

Is there a link you can provide to the device where the manufacture gives useful information? If so then give me the link.

If the device works with th emanufacturer's program do you know if they claim it can be usd with other programs? Have you tried something like Hyperterminal or any other terminal emulater?

[dpryan]

I am having a problem where I lose data in a transmission.

I'm transmitting about 3.5 Mbytes of data at 921600 baud and I seem to always lose approximately 30 kbytes (but it varies).

I'm looping and receiving the data via _CommReadByteArray(). That seems to work most of the time, but a few times during the transfer I'll drop data.

Usually, the function will return 512 bytes, but sometimes it will return the whole 4kB buffer (which probably means the buffer overflowed). (See below for example of a data transfer log.)

It would be difficult for me to implement hardware flow control on the device that is sending the data, so it would be nice if the PC could keep up with the transfer.

Could the receive buffer in the driver be made bigger than 4kB?

$NumBytes = 4096
$Struct = DllStructCreate("byte[" & $NumBytes & "]")
$waitComplete = False

;Inside the while loop:
$bytesReceived = _CommReadByteArray(DllStructGetPtr($Struct), $NumBytes, $waitComplete)

Here are some excerpts of a receive log generated by my autoit program.

(Start of transfer, then a place where more data than usual gets returns, then a place where the receive buffer overflowed.)

;**** Receive Log ****
Total: 512, bytesReceived: 512
Total: 1024, bytesReceived: 512
Total: 1536, bytesReceived: 512
Total: 2048, bytesReceived: 512
;(skip a bunch of lines)
Total: 102400, bytesReceived: 512
Total: 102912, bytesReceived: 512
Total: 103936, bytesReceived: 1024
Total: 105472, bytesReceived: 1536
Total: 106496, bytesReceived: 1024
Total: 107008, bytesReceived: 512
Total: 107520, bytesReceived: 512
;(skip a bunch of lines)
Total: 1987584, bytesReceived: 512
Total: 1988096, bytesReceived: 512
Total: 1991168, bytesReceived: 3072
Total: 1995264, bytesReceived: 4096
Total: 1999360, bytesReceived: 4096
Total: 2003456, bytesReceived: 4096
Total: 2007552, bytesReceived: 4096
Total: 2011648, bytesReceived: 4096
Total: 2013696, bytesReceived: 2048
Total: 2014720, bytesReceived: 1024
Total: 2015232, bytesReceived: 512
Total: 2015744, bytesReceived: 512

Edited May 4, 2011 by dpryan

[dpryan]

So, it would be really nice if the receive buffer was many megabytes big (>4MB) so I could capture all the data at once (and be sure not to miss any).

Or even better if the buffer size was user definable in the init function (_CommSetPort) or a separate "set buffer size" function.

[martin]

So, it would be really nice if the receive buffer was many megabytes big (>4MB) so I could capture all the data at once (and be sure not to miss any).

Or even better if the buffer size was user definable in the init function (_CommSetPort) or a separate "set buffer size" function.

No plans to do that mainly because I don't think it's sensible. If you are missing data then you aren't checking whether there's data in the input buffer often enough and there is something wrong with the handshaking.

[dpryan]

No plans to do that mainly because I don't think it's sensible. If you are missing data then you aren't checking whether there's data in the input buffer often enough and there is something wrong with the handshaking.

Thanks Martin. Is the 4k buffer size tied to Windows?

I can't check the input buffer much faster. As mentioned in my previous post, I was able to read fast enough *most* of the time, but occasionally something would happen that causes me to lose data.

If I require that the computer send an 'ack' after each block of data before sending the next block, then I am able to capture all of the data without slowing the transfer by too much (10-15% slower). I guess this is an acceptable solution. I used a block size of 640 bytes (which is the TX buffer size of the SiLabs CP2102 that I'm using) so that I'm sure that all of the buffers are big enough to hold the block. I guess I could probably get away with a 4kB block size since the computer buffer seems to be the problem, but I'll leave it as 640 bytes to be safe.

[martin]

Thanks Martin. Is the 4k buffer size tied to Windows?

I can't check the input buffer much faster. As mentioned in my previous post, I was able to read fast enough *most* of the time, but occasionally something would happen that causes me to lose data.

If I require that the computer send an 'ack' after each block of data before sending the next block, then I am able to capture all of the data without slowing the transfer by too much (10-15% slower). I guess this is an acceptable solution. I used a block size of 640 bytes (which is the TX buffer size of the SiLabs CP2102 that I'm using) so that I'm sure that all of the buffers are big enough to hold the block. I guess I could probably get away with a 4kB block size since the computer buffer seems to be the problem, but I'll leave it as 640 bytes to be safe.

4k is just a number I liked at the time I expect.

I will send you a pm with a version of the udf version 2.83 and the dll version 2.72 to try. I have added a function

_CommSetBufferSizes(InputLength, OutputLength=2048)

I haven't tested it but what can possibly go wrong

Please let me know what you find. If it does what you want then I will make it the standard version.

[dpryan]

4k is just a number I liked at the time I expect.

I will send you a pm with a version of the udf version 2.83 and the dll version 2.72 to try. I have added a function

_CommSetBufferSizes(InputLength, OutputLength=2048)

I haven't tested it but what can possibly go wrong

Please let me know what you find. If it does what you want then I will make it the standard version.

Hi Martin. That works perfectly, thanks!

I did have to comment out some of your debugging code (something about $OldMDV at the beginning) and also some stuff around Line 1027... _ComGetPortNames.

I guess you may want to do the same before you release.

Thanks again.

[martin]

Hi Martin. That works perfectly, thanks!

I did have to comment out some of your debugging code (something about $OldMDV at the beginning) and also some stuff around Line 1027... _ComGetPortNames.

I guess you may want to do the same before you release.

Thanks again.

Glad it works.

I hadn't realized there was some unwanted code so I'll remove it. Probably I payed with some idea then forgeot to clean up. Thanks.

EDIT: I found the code around line 1027, it was left there when I tested _ComGetPortNames, but I can't find $OldMDV in the udf or the dll. Where did you find that?

Edited May 6, 2011 by martin

[dougmoran]

Hi Martin,

I'm using your com udf library with great success except for one little problem. I've embedded a small hyperterminal into an application for driving an rfid reader system. The terminal connects to the reader hardware via a USB port. Everthing works great, but something strange happens when I enter data into the command line (hyper terminal). Here's an example:

"rfoff @CR" entered into control input and sent to the reader using _CommSendString()

"CLI:rof" is the response of the reader as captured by _CommGetLine()

The response should look like:

"CLI:"

So it looks like the comm interface is somehow capturing every other character of the outbound data and including it into the inbound buffer (i.e. "rfoff" --> "rof").

When I use a generic hyperterminal this does not happen, so I know the problem is either in my code or possibly the dll?

I'm running Windows 7 professional, 64 bit version.

Here's the code to my simple command line hyperterm:

;function cliChange is executed when input control $cli is triggered with a CR

Func cliChange()

$cliInput = GUICtrlRead($cli) ;reads input control

GUICtrlSetData($cli,"")

_CommSendString($cliInput & @CR) ; send the reader a command

wait() ;waits 20mS

$_news=_CommGetLine(@CR, 0, 0) ;retrieves the reader response.

News($_news) ; writes the reader response into the list control.

EndFunc

[N0RVLL]

Martin,

I find your CommMg to be quite useful, but (obviously) I need some assistance.

For my first project using your stuff, I simply modified the example to fit my purposes. I would like to limit the total number of lines visible in the edit box by clearing the the oldest data (first line) while still adding the newest data to the bottom of the edit box. Is there a 'good' way to accomplish this?

Thanks

N0RVLL

[martin]

Hi Martin,

I'm using your com udf library with great success except for one little problem. I've embedded a small hyperterminal into an application for driving an rfid reader system. The terminal connects to the reader hardware via a USB port. Everthing works great, but something strange happens when I enter data into the command line (hyper terminal). Here's an example:

"rfoff @CR" entered into control input and sent to the reader using _CommSendString()

"CLI:rof" is the response of the reader as captured by _CommGetLine()

The response should look like:

"CLI:"

So it looks like the comm interface is somehow capturing every other character of the outbound data and including it into the inbound buffer (i.e. "rfoff" --> "rof").

When I use a generic hyperterminal this does not happen, so I know the problem is either in my code or possibly the dll?

I'm running Windows 7 professional, 64 bit version.

Here's the code to my simple command line hyperterm:

;function cliChange is executed when input control $cli is triggered with a CR

Func cliChange()

$cliInput = GUICtrlRead($cli) ;reads input control

GUICtrlSetData($cli,"")

_CommSendString($cliInput & @CR) ; send the reader a command

wait() ;waits 20mS

$_news=_CommGetLine(@CR, 0, 0) ;retrieves the reader response.

News($_news) ; writes the reader response into the list control.

EndFunc

I can't explain why you should appear to receive every other character. I would play around a bit and see what changes have what effect. Eg

Try

_CommSendString($cliInput & @CR,1) ; send the reader a command but wait untill string has been sent

also add some debugging to convince yourself, and me, that th eerror is really with the received dat because I can't tell what your News function does.

Func cliChange()
        $cliInput = GUICtrlRead($cli)               ;reads input control
        GUICtrlSetData($cli,"")
        _CommSendString($cliInput & @LF,1) ; send the reader a command. Does @LF instead of @CR work or change anything
        wait() ;waits 20mS; I assume that wait is just sleep(20), but it should not be needed because the next command waits for a @CR. It doesn't do any harm either.
        $_news=_CommGetLine(@CR, 0, 0) ;retrieves the reader response.
ConsoleWrite($_news & @CR) does it really receive what you think?
        News($_news) ; writes the reader response into the list control.
EndFunc

I would expect that it is more likely that the device you are connecting to is sending the extra characters back. The difference between Hyperterminal and your script is that with Hyperterminal the characters are sent one at a time as you type them I suspect. Maybe that has something to do with it. Try doing something to delay things in the script like this perhaps

Func cliChange()
        $cliInput = GUICtrlRead($cli)               ;reads input control
        GUICtrlSetData($cli,"")
      _DripFeed($cliInput)
        wait() ;waits 20mS; I assume that wait is just sleep(20), but it  should not be needed because the next command waits for a @CR. It  doesn't do any harm either.
        $_news=_CommGetLine(@CR, 0, 0) ;retrieves the reader response.
ConsoleWrite($_news & @CR) does it really receive what you think?
        News($_news) ; writes the reader response into the list control.
EndFunc

Func _DripFeed($sS, $iDelay = 200)
Local $n

for $n = 1 to stringLen($sS)
  _CommSendString(STringMid($sS,$n,1) 
sleep($iDelay
next

endfunc

Don't forget to try the @LF.

Do check that you have the flow control correctly set, the number of data bits, number of stop bits and the parity.

I don't think the extra characters are coming from some sort of mix up in either the serial port or my dll. If there was such a fundamental problem then I believe I would have known about it before know, but of course I am not so stupid as to believe I can't be wrong.

[martin]

Martin,

I find your CommMg to be quite useful, but (obviously) I need some assistance.

For my first project using your stuff, I simply modified the example to fit my purposes. I would like to limit the total number of lines visible in the edit box by clearing the the oldest data (first line) while still adding the newest data to the bottom of the edit box. Is there a 'good' way to accomplish this?

Thanks

N0RVLL

I understand the problem. I've tried a method I thought would work but something strange happens so there will be a delay in my reply, then I'll add something to this post.

EDIT:

Rover found a fix to get round a bug with GuiCtrlSetState so here is the idea

expandcollapse popup

#include <EditConstants.au3>
#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>
#include <guiedit.au3>

#region ### START Koda GUI section ### Form=
$Form2 = GUICreate("Form2", 443, 298, 302, 218)
$Edit1 = GUICtrlCreateEdit("", 119, 46, 185, 204)
GUICtrlSetData(-1, "")
$Edit2 = GUICtrlCreateEdit("", 119, 46, 185, 204);318
GUICtrlSetData(-1, "")
$Btn = GUICtrlCreateButton("halt/run",10,100)
GUISetState(@SW_SHOW)
#endregion ### END Koda GUI section ###
Local $sA, $sB, $startA, $startB

$Eda = $Edit1
$EdB = $Edit2
$MAXLINES = 100 ;the max number of lines we want in an edit
$CHOP = 50;how many lines we will loose at a time
$count = 0
$startA = 0
$startB = $CHOP;we start edit2 $CHOP lines after Edit1
GUICtrlSetState($Edit2, $GUI_DISABLE+$GUI_HIDE) ;hide and disable the second edit
$add = true
While 1
    $msg = GUIGetMsg()
    If $msg = -3 Then Exit
    if $msg = $Btn then $add = not $add

if $add then
        $count += 1; the number of lines which have been added, though lines are continually lost
        $s = "------------> " & $count & @CRLF; add lines to the edit

        GUICtrlSetData($Eda, $s, "1")
        If $count >= $startB  Then GUICtrlSetData($EdB, $s, "1");now $EdB has lost the first $CHOP lines

        If $count >=  $MAXLINES - $chop + $startB Then  ;
            _SwitchSeens($Eda, $EdB)
             GUICtrlSetData($Edb, '')
            GUICtrlSetData($Eda, $s, "1")
            $startB = $count + $CHOP; + 50
        EndIf
    EndIf

   Sleep(100)
WEnd


Func _SwitchSeens(ByRef $Edj, ByRef $Edk)
    Local $temp, $sF
    $temp = $Edj
    $Edj = $Edk
    $Edk = $temp
    GUICtrlSetState($Edj, $GUI_ENABLE+$GUI_SHOW);if you don't disable then data will get lost due to some bug in GuiCtrlSetState

    GUICtrlSetState($Edk, $GUI_DISABLE+$GUI_HIDE)

EndFunc   ;==>_SwitchSeens

You can see the scroll bar thumbs change in size as the data in the edit grows and shrinks, but the data appears to be added continually. Maybe this approach would work for you.

Edited May 7, 2011 by martin

[dougmoran]

I can't explain why you should appear to receive every other character. I would play around a bit and see what changes have what effect. Eg

Try

_CommSendString($cliInput & @CR,1) ; send the reader a command but wait untill string has been sent

also add some debugging to convince yourself, and me, that th eerror is really with the received dat because I can't tell what your News function does.

Func cliChange()
        $cliInput = GUICtrlRead($cli)               ;reads input control
        GUICtrlSetData($cli,"")
        _CommSendString($cliInput & @LF,1) ; send the reader a command. Does @LF instead of @CR work or change anything
        wait() ;waits 20mS; I assume that wait is just sleep(20), but it should not be needed because the next command waits for a @CR. It doesn't do any harm either.
        $_news=_CommGetLine(@CR, 0, 0) ;retrieves the reader response.
ConsoleWrite($_news & @CR) does it really receive what you think?
        News($_news) ; writes the reader response into the list control.
EndFunc

I would expect that it is more likely that the device you are connecting to is sending the extra characters back. The difference between Hyperterminal and your script is that with Hyperterminal the characters are sent one at a time as you type them I suspect. Maybe that has something to do with it. Try doing something to delay things in the script like this perhaps

Func cliChange()
        $cliInput = GUICtrlRead($cli)               ;reads input control
        GUICtrlSetData($cli,"")
      _DripFeed($cliInput)
        wait() ;waits 20mS; I assume that wait is just sleep(20), but it  should not be needed because the next command waits for a @CR. It  doesn't do any harm either.
        $_news=_CommGetLine(@CR, 0, 0) ;retrieves the reader response.
ConsoleWrite($_news & @CR) does it really receive what you think?
        News($_news) ; writes the reader response into the list control.
EndFunc

Func _DripFeed($sS, $iDelay = 200)
Local $n

for $n = 1 to stringLen($sS)
  _CommSendString(STringMid($sS,$n,1) 
sleep($iDelay
next

endfunc

Don't forget to try the @LF.

Do check that you have the flow control correctly set, the number of data bits, number of stop bits and the parity.

I don't think the extra characters are coming from some sort of mix up in either the serial port or my dll. If there was such a fundamental problem then I believe I would have known about it before know, but of course I am not so stupid as to believe I can't be wrong.

Thanks for your suggestions & sorry for not responding sooner. I've been in airports most of the last few days. Whew. Anyway, I'll try your suggestions this morning and get right back to you. -ddm