Serial Communication using kernel32.dll

[ACalcutt]

Edit:

Testing of cfxUDF.au3 is in progress... I noticed that version just now.

Here is a slightly updated version of the cfxUDF.au3 I uploaded before. I had fixed some issues with constants to fix an error I was getting in my program.

cfxUDF.au3

[mikkokh]

This UDF is modified from V2.0 (version that is updated by Andrew Calcutt @ 05/16/2009)

• Constants in the Functions are modified to Local Constants - With these modifications, I have no problems with Opt('MustDeclareVars', 1) and Date.au3.

• Global variable $dll is renamed to $commDll, because "dll" is very common word in computer world, so it can be reason of some future conflicts with other UDF or script files.

Please note:

Only transmission of data is tested by me with Customer Display, and it works fine. Customer Display does not return any data in normal state, so I don't know how data receive works.

Also ACalcutt is reported that my modifications with transmission are working. Thanks, ACalcutt!

If you notice that conversion from V2.0 to this version (V2.1) has broke something in this UDF code, please tell me so I can try fix it...

cfxUDF.au3

Edited February 28, 2011 by mikkokh

[pierrotm777]

This UDF can only read data on a com port !

It is possible to create a virtual com port with autoit and write the same data that are read on the first com port ?

Edited March 11, 2011 by pierrotm777

[mikkokh]

This UDF can only read data on a com port !

It is possible to create a virtual com port with autoit and write the same data that are read on the first com port ?

I'm surprised that only reading of data from COM port does work with you... Which versions of UDF you have tested? - I have tested all UDF versions from this Topic and sending of data is worked fine or at least slowly (char by char). Reading of data from COM port with any of them is not tested by me.

I think that virtual COM port needs some system drivers, but I don't know where you can get them. Still... I can be wrong about need of drivers.

Edited March 21, 2011 by mikkokh

[Uwe]

Hello,

you can try com0com.

You can define pairs of virtual com ports, named CNCAx and CNCBx ( x=0,1,2,...)

Example: send data on CNCA0 and receive on CNCB0.

I use them for testing serial protocols.

It is also possible to connect some pairs together with hub4com, making it posible to test bus systems (RS485), you can also connect real COM Ports, so you can monitor communication.

Another useful thing is the combination with tcp2com.

Uwe

[CountyIT]

Very interesting thread. Finding anything to do with RS232 in this day and age is hard to come by. There seems to be 4 or 5 different versions of the UDF posted in this thread. Unfortunately function names and everything else seem to change between between the versions and more unfortunately I haven't found a version yet that seems to read from the serial port. Has anyone (the author?) come up with a newer, working version or is this UDF essentially dead?

[0x4655434b]

Hi, people. It's my first post on the forum, and I am not exactly a programmer (yet), so hopefully what I did doesn't sound too stupid.

For me the _OpenComm() function from v2.1 didn't work. And I had trouble reading 0x00 bytes from a string returned by _rxwait(). So I replaced _OpenComm() v2.1 with _OpenComm() v2.0 (and adjusted some variables). Accordingly I had to put _setrts() back, because it is required by _OpenComm v2.0. And I added an _rxwaitarray() function, which is almost identical to _rxwait(), but modified to return an array instead of a string. That way no 0x00 bytes will get lost.

I didn't do a whole lot of testing, but it seems to work perfectly for my application (reading the 17 byte long response from a device, that always has 2 - 5 0x00 bytes). I didn't try cleaning up the script, so the whole copypasta that I did might have created some mess. If you even dare to use this, do it at your own risk.

cfxUDF_mod.au3

[Lecdev]

Hi I am planning on using the kernel32 functions for communications and had a look at this thread thinking it might shorten my venture. Just FYI there is actually information on the kernel32 comm functions listed on msdn desktop dev center.

see here,

http://msdn.microsoft.com/en-us/library/windows/desktop/aa363194%28v=vs.85%29.aspx

Haz

[mikkokh]

Hi, 0x4655434b.

Have you noticed that there is two different 2.0 versions of this UDF from two different coders?

One from them is from original author of CFX and another is coded by different coder from sources of CFX v1.0.

Seems that your version contains parts of code from both of those branch... Closer inspection with WinMerge say so.

Quite good work to get codes from totaly different 2.x branch to working together... :-)

[ACalcutt]

Sorry to bring up a really old post, but i just thought I would share a fix if anyone is still using this.

For a long time I've noticed the _OpenComm functions in my version of the UDF would not open above COM9. I finally decided to look into it and it seems to be that COM10 (and above) need a different syntax for the "CreateFile" dll call ( see https://support.microsoft.com/en-us/help/115831/howto-specify-serial-ports-larger-than-com9 ).

COM1 - COM9 can be specified directly as "COM[PORT]"

However

COM10+ looks like they need to be formated "\\.\COM[PORT] "

 

So in my code I have changed 

$hSerialPort = DllCall($commDll, "hwnd", "CreateFile", "str", "COM" & $CommPort, _

to 

$hSerialPort = DllCall($commDll, "hwnd", "CreateFile", "str", "\\.\COM" & $CommPort, _

Which seems to fix the ports COM10 and above (and still works with COM1-9)

 

My current version is attached, but the fix above should work with other variations in this thread (looking i didn't see that anyone else had fixed it)

 

 

 

 

cfxUDF.au3

Edited September 11, 2020 by ACalcutt