Serial Port /COM Port UDF

[AUTTRY]

Hi AUTTRY,

I'm glad you found the udf useful.

Your WaitFor function is faulty. If _CommGetString returns a few characters of the string you are waiting for each time it is called then you will never get the full string received to compare to the test string.

Maybe instead of

$buff = _CommGetString()

you could have

$buff &= _CommGetString()

Martin, you're right.

I totally agree with you and I'll correct that at once.

Cheers!

Besides, I wonder if there is a file transfer UDF based on COM port using Zmodem protocol or some other.

Edited July 20, 2012 by AUTTRY

[martin]

Martin, you're right.

I totally agree with you and I'll correct that at once.

Cheers!

Besides, I wonder if there is a file transfer UDF based on COM port using Zmodem protocol or some other.

I don't know of one, maybe you could write one.

[ZiggyStardust]

I have been pulling my hair out on this one. I have a well working script that does extensive comm I/O to a virtual ComPort (USB to Serial Converter). Love this UDF and can't say enough good things about it. The problem is that if I pull the USB cable out of the computer while the script is running AutoIT crashes with the unhandled exception error "autoit.exe has encountered a problem and needs to close" at which point the script terminates.

The were early references to that problem in this thread but no real soultion. It has been a while. Has anyone found a soultion?

[atzoref]

How can I open/close a specific serial ComPort with the CommMG functions?

What should I need to do with the "commg.dll" file?

(I have Win7 X64, is it works for me?)

Edited September 19, 2012 by atzoref

[martin]

How can I open/close a specific serial ComPort with the CommMG functions?

What should I need to do with the "commg.dll" file?

(I have Win7 X64, is it works for me?)

You must compile your AutoIt script for 32 bit because the dll is 32 bit which is stated in the first post. If you use ScITE then the directive

#AutoIt3Wrapper_OutFile_X64=N

should be included in your script. In fact I aught to place that in the UDF.

The script must be able to find the dll but there is no need to register it. Place the dll in the script folder, the windows 32 bit folder or use the function _CommSetDllPath making sure you use the full path, ie add the dll name at the end like this

_CommSetDllPath("C:SomeFolderCOMMScommg.dll")

To open a specific port try the example which is in the first post..

[martin]

New version of the UDF and the dll ready for download which corrects error in closing a port. Seel the first post.

[Pepilepioux]

Hello,

When I call _CommSendString and there's an error (typically the USB cable has been unplugged) an error message box pops up. Apparently it's done within the dll ( "$vDllAns = DllCall($hDll, 'int', 'SendString', 'str', $sMGString, 'int', $iWaitComplete)" ). It says "access denied. port = <port number>. channel number = 1".

How can I deactivate this feature, please ?

(I'm using it in an application that is launched as a service, so when this happens no one will click "OK", so the application freezes)

Thanks

[ChenYangHuan]

When I using: ATD<number>; to call then i don't listen sound. Call was connected

Please help me fix it!

Edited February 5, 2013 by ChenYangHuan

[rodcrux]

Hi, and first of all great thanks for this brilliant UDF - I have used it to read the CALLER ID data from incoming phone calls & then identify any known caller from a customer database.

This works very well - thanks in no small way to your UDF.

I would like to extend the functionality of my Autoit routine in that I would like to play a welcoming message to the caller - in the same way my answer machine does. This would entail sending an mp3 or wav file direct to the active COM port.

I can see no obvious way of putting the voice modem into the correct mode to enable this.

Would this be possible with your UDF?

Regards, Rod

[martin]

Rod,

My UDF using a COM port to send and receive bytes of information. You can't send audio over a serial port. You could digitise the audio and then send the file but that would need the receiver to convert the file to audio.

I know nothing about using a modem to send audio such as a voice. Actually, I know nothing much about modems either. I imagine you need a modem which has an audio input connection, maybe a jack socket. The speaker output from a sound card can go to the audio in. (Remember I'm making this all up, it's just guesswork.)

Then you need to know when the line is connected. Maybe that is indicated by the state of the DCD line (CD line). If connected then you can play your audio using the sound card and it will be transmitted. Playing a wav file is easy with AutoIt and there will be plenty of examples around.

This could be worth reading.

[martin]

ChenYangHuam,

Either the modem has a speaker in it to play the sound or it needs to be connected to your audio in on the PC or sound card. I can't help more than that as the sound is not anything to do with my UDF, but there might be some command you need to send to your modem to turn the speaker on.

[rodcrux]

Martin,

Many thanks for your reply.

I have followed your supplied ink to read up on using the "AT" command set to control a connected modem.

I found that in order to send an announcement ie. "Hello Thank you for calling . ." . etc. to the person calling, the modem must first be set to voice mode.

The sound file is then sent as a byte stream which is converted back by the modem into audio signal and sent down the phone line to the caller.

First problem is that the sound file must be in a format which the modem can handle.

Secondly all zero bytes in the stream must be sent twice or else the modem will consider a single zero as an EOF signal and conversion / transmission will end.

So it seems I must experiment further - probably principally using the _CommSendByteArray from your UDF.

I will post progress reports here - if any!

Regards, Rod

Edited March 5, 2013 by rodcrux

[Qwerty212]

Hello Martin and thanks for the UDF.

I'm trying to use it to get data from a weighing machine.

I get the data correctly after sending to it the character "W" (it works using the Mettler protocol).

I have created a little script:

expandcollapse popup

#include <CommMG.au3>


Global $sportSetError = ''
_CommSetDllPath(@ScriptDir & "\commg.dll")

;COM Vars

Global $CMPort = 3 ; Port

Global $CmBoBaud = 19200 ; Baud

Global $CmboDataBits = 8 ; Data Bits

Global $CmBoParity = "none" ; Parity

Global $CmBoStop = 1 ; Stop

Global $setflow = 2 ; Flow

_CommSetPort($CMPort, $sportSetError, $CmBoBaud, $CmboDataBits, $CmBoParity, $CmBoStop, $setflow)
Sleep (100)
_CommSetRTS(0)
Sleep (100)
_CommSetDTR(0)
Sleep (100)

Global $senyal = "W"; the data to send to the weighing machine to get a response

_CommsendString($senyal & @CR,1)

Sleep (100)

Global $buff = _CommGetLine()

Sleep (100)

_CommClosePort()

Msgbox(0,"",$buff)


Exit

I'm using the latest udf and the latest .dll

I have noticed the high CPU usage posted by other users so sometimes the script hangs while waiting for the data from the weighing machine. Sometimes it shows the MSgbox as soon as I press F5 and other times it freezes.

The data recived from the machine is just: [sTX] The weigh with one decimal position and [ETX].

When I compile the script the CPU usage is even bigger. I'm doing some tests in a Windows XP Netbook (1 Asus EEEPC 1000HD, not the greatest computer ever).

Any idea to reduce CPU usage would be really apreciatted.

Greets from Barcelona

Edited March 5, 2013 by adolfito121

[adrianhudson]

HI Martin,

Thank you for producing this excellent UDF!

Adrian

[martin]

@ Adolfito121,

I believed I had fixed th ehigh CPU usage after version 2.88. There is only one line in your script which can cause th edelay I think which is the _CommGetLine statement. In the UDF at the end of the function _CommGetLine there is a line

if $snextchar = '' then sleep(20)

 before a Wend.

You could try increasing the sleep from 20 to 40 say.

I wouldn't expect that the _CommSendString was the problem, though you could try not asking it to wait until the string is sent.

It is possible that the character W isn't sent correrctly and you will wait forever for a reply. So I suggest that you send the 'W' then wait a limited amount of time for a reply, and try up to 4 times for example.

 $res = ''
for $n = 1 to 4
  _CommsendString($senyal & @CR,0)
 
 $res &= _CommGetLine(@CR, 50,2000) ; wait until @CR received, or 50 characters received or 2 seconds
 if @error = 0 then exitloop
next
 
if $res <> '' then
  msgbox(262144, 'Answer is' , $res)
else
  msgbox(262144,'ERROR', 'No answer from weighing machine in 8 seconds!')
endif
 

[Qwerty212]

Thanks a lot for the code sugestion Martin. I will try it next monday.

Greets from Barcelona

[sentry07]

Martin,

Many thanks for your reply.

I have followed your supplied ink to read up on using the "AT" command set to control a connected modem.

I found that in order to send an announcement ie. "Hello Thank you for calling . ." . etc. to the person calling, the modem must first be set to voice mode.

The sound file is then sent as a byte stream which is converted back by the modem into audio signal and sent down the phone line to the caller.

First problem is that the sound file must be in a format which the modem can handle.

Secondly all zero bytes in the stream must be sent twice or else the modem will consider a single zero as an EOF signal and conversion / transmission will end.

So it seems I must experiment further - probably principally using the _CommSendByteArray from your UDF.

I will post progress reports here - if any!

Regards, Rod

 

I just experienced the 0x00 byte causing an EOT. I've been racking my brains over this issue and this kinda makes sense but I still don't understand it. Is using a null character part of the COM spec or was it something that Martin just put in the DLL? If I send the hex string x34x08x01x00x14x00x5A, the other end only receives x34x08x01. So basically I need to replace all single null bytes with double null bytes to solve this issue?

[Qwerty212]

@Martin.

Thanks a lot for the loop sugestion.

It solved the problem (i get the data everytime) just doing:

$res = ''
for $n = 1 to 20
  _CommsendString($senyal & @CR,0)
 
 $res &= _CommGetLine(@CR, 50,500) ; wait until @CR received, or 50 characters received or 2 seconds
 if @error = 0 then exitloop
next
 
if $res <> '' then
  msgbox(262144, 'Answer is' , $res)
else
  msgbox(262144,'ERROR', 'No answer from weighing machine in 8 seconds!')
endif

I the msgbox I get a little square before the weigh. I guess is the STX command. How can I get only the weigh?

Thanks again for your UDF and help.

Greets from Barcelona

[martin]

@ rodcrux

0x00 doesn't cause EOT and it isn't a fault in my dll. 0x00 indicates the end of a string and any other bytes after the 0x00 will be ignored by AutoIt or C, so if you want to send binary data you must not send strings. This is the whole reason this udf was developed because someone wanted to send binary data and other tools were a problem.

To send binary data which might include NULLs you must use _CommSendByte to send one byte at a time, or use _CommSendByteArray to send a lot of data which is very much faster but a little more complicated to use. There are examples I have given in previous posts I think. Have a look and ask again if you need help with it.

 

@ Adolfito121

I'm gladd you managed to get it working. The little square will be some control character I expect. Maybe a line feed.  I would add some debuuging like

 ConsoleWrite('Reply = ' & $res & @CR)
for $n = 1 to stringlen($res)
    $cc = stringmid($res,$n , 1)
    ConsoleWrite('   ' & $cc & ' [' & Asc($cc) & ']' & @CR)
Next

 

 

Then when you have worked out what the square is you can remove any of those characters using

StringReplace($res,chr($squareCode), '')

[mesale0077]

link broken new link please

http://www.mosaiccgl.co.uk/AutoItDownloads/confirm.php?get=COMMGvv2.zip

500 - Internal Server Error
This is a temporary server error.
Please try to reload the webpage later

thank you now

Edited June 16, 2013 by mesale0077