521 replies to this topic

[martin]

Although serial ports are disappearing, they can still be useful.
Here is a COMMs UDF. It provides an easy way to use serial ports without the restrictions and problems some methods have. USB to serial is ok, binary data is ok.

This UDF requires my comMG.dll which can be in either the script folder or the Windows folder by default, or in the path specified using the function _CommSetDllPath.

Note the following shortcomings:

the dll is 32 bit so it will not work with a 64 bit app.
The strings and character functions are all AnsiChar.


Functions in the UDF are

_CommVersion
_CommListPorts
_CommSetPort
_CommPortConnection
_CommClearOutputBuffer
_CommClearInputBuffer
_CommGetInputcount
_CommGetOutputcount
_CommSendString
_CommGetString
_CommGetLine
_CommReadByte
_CommReadChar
_CommSendByte
_CommSendBreak; not tested!!!!!!!!!!
_CommCloseport
_CommSwitch
_CommReadByteArray
_CommSendByteArray
_CommsetTimeouts
_CommSetXonXoffProperties
_CommSetRTS (NB these will not work if Hardware handshaking is selected because
_CommSetDTR then these lines are controlled by the data being sent.)
_CommSetDllPath
_CommGetLineStates
--------------------------------------------------------------------------------------------------------------------------------
Go to Download Page For Commgv2
Download includes the dll, udf and example.
27th September 2012
Correct error closing port. New versio of UDF if V2.90, new dll is commg.dll V2.79. Thanks to tfabris.
18th January 2012
Corrected typo in UDF V 2.87, and uploaded as V2.88
Increased max baud allowed by the dll from 200000 to 256000. New version now V2.78
17th January 2012
Modified thesleep addition to _CommGetLine so that reading data is not slowed down.

14th January 2012
Corrected _CommReadByte in UDF.
Added sleep(20) to while loop in _CommGetLine to reduce CPU usage
20th December 2011
UDF version 2.86. - Changed function GetByte so it returned the error string given by the dll.
Dll version 2.77 - removed an unwanted erro message dialogue from GetByte function. (Thanks funkey)

4th December 2011
New dll and example versions. Dll function SetPort corrected because it was not using the parameters passed for DTR and RTS.
The example was setting flow control incorrectly: the settings for hardware handshaking and XON./XOFF were reversed.

25th August 2011 corrected function _CommClosePort.






mgrefcommg

Attached Files

•  CommgExample.au3   8.63KB   6748 downloads

Edited by martin, 27 September 2012 - 07:49 PM.

[Obi-w00t]

Although serial ports are disappearing, they can still be useful.
Here is a COMMs UDF. It provides an easy way to use serial ports without the restrictions and problems some methods have. USB to serial is ok, binary data is ok.

This could be useful, by why not use the COM method talked about in this thread?

[martin]

This could be useful, by why not use the COM method talked about in this thread?

I haven't tried the COM method but it looks quite good.
I posted put my UDF on the forum is because AutoitSteve tried using the COM method and other methods but couldn't send binary data because a byte of value 0 is seen as the end of a string. I offered him my method and he got his application working, and his opinion was that it was easier. So I thought it might help somene else. Also, you don't need to have any special software installed; just have my dll in the script dir.

There are plenty of things my UDF/dll doesn't do, but on the other hand they could be added. ('Could' <> 'Will' of course).

[ConsultingJoe]

looks very cool, I wish I would have tried this when I have my bluetooth gps. I could have made a nice gui for it.

[Michel Claveau]

Hi!

bluetooth gps

Bluetooth & USB are emulating COM. Tests will are interesting.

[martin]

I am surpised that there are a about 70% more downloads of the dll than the udf. Can anyone tell me why that is? An undocumented dll cannot be very useful I would have thought.

[Lazycat]

Very nice. I'll try to get log data from PBX with it.

COM method is nice, but (for me) have two disadvantages: require installing (registering) library in system, and won't work without license key. Anyway, I'm always prefer not use COM, when exists standalone dll alternative.

[bhoar]

Martin -

I am seeing an odd "off by one" behavior with the DLL where:

1. The last character received by the port isn't being picked up using either the _CommGetString() or the _CommGetOutputCount()/_CommReadChar() combination. The string I am reading up to that point is good.

2. If only one character has been received, I end up reading ascii 16 (hexadecimal 0x10 or octal 020) instead. Further reads return a blank string.

I tried strategically placing the output and input buffer clear calls to see if they would have an impact, but there was none.

One thing that might be unusual about the data I am working with: the sender never sends CR or LF. Is it possible there's an assumption related to that which causes an off-by-one error?

-brendan

[sshrum]

I'm currently using a free netcomm.OCX for serial communications which works.

I made a monitor swivel switch so I can have my PC automatically rotate my screen orientation (ala the old Radius CRTs) when I swivel my monitor from landscape to portrait. I use the COM port to send a string and if the string comes back, then the switch is closed, otherwise open. Pretty straightforward. I made an smal GUI that allows the user to define an app to launch when the state changes. Since most vid cards support orientation switching via hotkeys, I create a couple of one-liner exe's that can be used to send the appropriate hotkeys to activate the rotation.

Dets on the project including step-by-step instructions on making the hardware ($5-8 in parts) and the program source can be found here:

http://www.shrum.net/cats.php?dir=/code/autoorient

Edited by sshrum, 11 December 2011 - 11:13 PM.

[bhoar]

Sean - thanks for that. I'm also using the netcomm.ocx as well, which isn't giving me the same off-by-one troubles, but I want to have the flexibility to use multiple methods depending on the security constraints of the current workstation. And off-topic, I emailed you about this, but: the Auto(IT)mator link on that page always seems to redirect back to the listing instead of the actually Auto(IT)mator page.

-brendan

[martin]

Martin -

I am seeing an odd "off by one" behavior with the DLL where:

1. The last character received by the port isn't being picked up using either the _CommGetString() or the _CommGetOutputCount()/_CommReadChar() combination. The string I am reading up to that point is good.

2. If only one character has been received, I end up reading ascii 16 (hexadecimal 0x10 or octal 020) instead. Further reads return a blank string.

I tried strategically placing the output and input buffer clear calls to see if they would have an impact, but there was none.

One thing that might be unusual about the data I am working with: the sender never sends CR or LF. Is it possible there's an assumption related to that which causes an off-by-one error?

-brendan

I will look into this but at the moment I don't know the answer; I won't have time for at least 24 hours. Meanwhile, can you tell me anything about the baud rate, parity, stop bits etc. Is it only the one character that's missing? For example, if 1000 characters are sent do you get the fist 999, and if later one more character is sent do you get the 100th?

Do you have any literature about the transmitter related to the serial port and data transmission? Can you send me a diagram of the pin connections on the serial cable? or if it is just a null modem cable then tell me that

It is possible the fault is with the transmitter. Can you tell me what it is? Is it a PC or some special hardware? I assume you know what is being transmitted which is why you think a character is missed, but have you been able to check that the last character has actually been sent? In other words, what do you know which has made you conclude that the last recieved character is not being read?

Do you have any sample code I could see?


I am sure the lack of CR characters is not related to the problem.

[bhoar]

I will look into this but at the moment I don't know the answer; I won't have time for at least 24 hours. Meanwhile, can you tell me anything about the baud rate, parity, stop bits etc. Is it only the one character that's missing? For example, if 1000 characters are sent do you get the fist 999, and if later one more character is sent do you get the 100th?

Do you have any literature about the transmitter related to the serial port and data transmission? Can you send me a diagram of the pin connections on the serial cable? or if it is just a null modem cable then tell me that

It is possible the fault is with the transmitter. Can you tell me what it is? Is it a PC or some special hardware? I assume you know what is being transmitted which is why you think a character is missed, but have you been able to check that the last character has actually been sent? In other words, what do you know which has made you conclude that the last recieved character is not being read?

Do you have any sample code I could see?
I am sure the lack of CR characters is not related to the problem.

I never get the missing character for strings > 1 char, even on later reads. I get the "wrong" character when there's only one pending incoming character to be read.

The connection is as follows:

PC -> USB cable -> 7-port USB 2.0 hub -> Prolific USB-to-serial adapter -> Microboards MicroOrbit Disc Duplication controller. I know, I know, I'd point to the USB-to-serial adapter as the culprit, except it works with other COMx port loving software just fine.

Three interesting bits of data:

1. No problem at all getting the right results out of Hyperterminal, e.g.:

Send        V
Receive:    "Microboards" "MicroOrbit" "v1.2"
Desc:       Identification string

Send:       C
Receive:    X
Desc:       Successful Reset

Send:       I
Receive:    E
Desc:       no disc found to insert

Just a reminder, the data comes back without LF or CR chars.

2. If I use the CommgExample.au3, modified slightly to read strings instead of lines since my data doesn't come on separate lines (by replacing the code in the main loop with the change below), I also have the problem (I set your app to COM6, 9600 8-N-1, no x-on/x-off flow control).

CODE

$instr = _CommGetstring()
;$scroll = StringInStr($instr,@CR)
If $instr <> '' Then;if we got something
If GUICtrlRead($Checkbox1) = $GUI_CHECKED Then $instr = StringReplace($instr,@CR,@CRLF)
$lines = GUICtrlRead($edit1)
$charcount = StringLen($lines)
_GUICtrlEditSetSel($edit1, $charcount, $charcount)
If $charcount > 10000 Then GUICtrlSetData($edit1,StringRight($lines & $Instr,8000))
_GUICtrlEditReplaceSel($edit1, False, $instr)
_GUICtrlEditScroll($edit1,$SB_SCROLLCARET)
;If $scroll Then _GUICtrlEditLineScroll($edit1,0,_GUICtrlEditGetLineCount($edit1) - 14)
EndIf

3. Like Hyperterminal, AutoIT calls to the port via the Netcomm.ocx do not have the problem either.

One further note...the virtual COM6 port that is created to communicate via the USB<->Serial converter does have a panel in the device manager for adjusting the FIFO buffers of the 16550 compatible UART. By default the buffers are enabled and are set to 14 for Receive and 16 for Transmit. Not sure if that is useful or not.

All testing on XP Pro Service Pack 2.

-brendan

Edited by bhoar, 13 June 2007 - 12:16 AM.

[martin]

I never get the missing character for strings > 1 char, even on later reads. I get the "wrong" character when there's only one pending incoming character to be read.

When there's one character to be read do you mean like the reply to sending 'C' which should be 'X'?, and when you say you get the wrong character what do you get?

Send        V
Receive:    "Microboards" "MicroOrbit" "v1.2"
Desc:       Identification string

Send:       C
Receive:    X
Desc:       Successful Reset

Send:       I
Receive:    E
Desc:       no disc found to insert

This is what should happen, can you show the same for what you get with commg.dll

Just a reminder, the data comes back without LF or CR chars.

I'm still sure this isn't a problem. But I will test tonight with a usb to serial device on WIndows XP SP2.

3. Like Hyperterminal, AutoIT calls to the port via the Netcomm.ocx do not have the problem either.

Yes, you must be right that commg is the problem. But What do you actually see in Hyperteminal? If there are no LF or CR characters then I assume you see this

"Microboards" "MicroOrbit" "v1.2"XE

One further note...the virtual COM6 port that is created to communicate via the USB<->Serial converter does have a panel in the device manager for adjusting the FIFO buffers of the 16550 compatible UART. By default the buffers are enabled and are set to 14 for Receive and 16 for Transmit. Not sure if that is useful or not.

Since the problem can occur with just a single character transmission I would not think that the buffer size is the problem. But just to be sure, could you try increasing the buffer size and see if it makes any difference?


When you use Hyperterminal and you send I or C or V, do you just type the letter or do you type the letter and then press the Enter key?
If you don't press Enter then the problem could be the Btn1 event function because I have added @CR, so could you try this

Func Btn1Event()
    _CommSendstring(GUICtrlRead($Input1) )
    GUICtrlSetData($Input1,'')
EndFunc

[bhoar]

Since the quoting is about to get out of hand, I'm going to do it manually:

> When there's one character to be read do you mean like the reply to sending 'C' which should be 'X'?

Yes - one byte out, one byte returned.

> ... and when you say you get the wrong character what do you get? This is what should happen, can you show the same for what you get with commg.dll

I send a "C" and what appears on screen when I read the input buffer is not an "X" but instead is a strange "cross" symbol. It's the same if I send a "Z" which isn't a command and should return a "?". If I get the ascii value of the cross symbol, via "ASC($returnedvalue)", I get the number 16.

[quote name='martin' date='Jun 13 2007, 04:39 AM' post='356570']

> I'm still sure this isn't a problem. But I will test tonight with a usb to serial device on WIndows XP SP2.

Thanks. If using a prolific-based usb<->serial bridge, I strongly suggest pulling down their most recent drivers - drivers on the older CDs that accompanied their products gave me BSOD occassionally under Win2k. On the other hand, if it is a FTDI chip, I've never had problems with those.

> Yes, you must be right that commg is the problem. But What do you actually see in Hyperteminal?
> If there are no LF or CR characters then I assume you see this
> "Microboards" "MicroOrbit" "v1.2"XE

Yes, exactly.

> Since the problem can occur with just a single character transmission I would not think that the buffer size is the problem.
> But just to be sure, could you try increasing the buffer size and see if it makes any difference?

Well, the buffers were already at the maximum. I tried reducing the sizes but that appeared to make no difference.

> When you use Hyperterminal and you send I or C or V, do you just type the letter or do you type the letter and then press the Enter key?

Just type the letter.

> If you don't press Enter then the problem could be the Btn1 event function because I have added @CR, so could you try this...

Unfortunately, the same problem occurs in my own code where I don't send CR, so that's not the problem. I mostly brought up the Commgexample.au3 code just so that I could avoid having to code up a test case that didn't rely on the dozen libraries I'm already using.

...

The USB to serial bridge I am using is actually inside the device in this case, so it's hard to swap out without removing all sorts of sealant. If I find time tonight, I am going to test a handful of other bridges with other robots tonight to see if that's a common thread and/or if it somehow relates to the driver or chipset involved.

-brendan

[bhoar]

FYI, I used PortMon to compare the I/O transactions of Hyperterminal vs. those of the COMMG.DLL using the same setup as before. It appears that the I/O is working correctly in both cases, so the issue appears to be somewhere inside commg.dll...

Hyperterminal (note that the notification-based system it uses ends up showing the send transaction after the receive in the monitor log - just in case that was confusing)...

CODE

2 0.02816950 hypertrm.exe IRP_MJ_CREATE Serial2 SUCCESS Options: Open
3 0.00000754 hypertrm.exe IOCTL_SERIAL_SET_QUEUE_SIZE Serial2 SUCCESS InSize: 8192 OutSize: 8192
4 0.00000223 hypertrm.exe IOCTL_SERIAL_CONFIG_SIZE Serial2 SUCCESS Size: 0
5 0.00000196 hypertrm.exe IOCTL_SERIAL_GET_BAUD_RATE Serial2 SUCCESS
6 0.00000223 hypertrm.exe IOCTL_SERIAL_GET_LINE_CONTROL Serial2 SUCCESS
7 0.00000251 hypertrm.exe IOCTL_SERIAL_GET_CHARS Serial2 SUCCESS
8 0.00000196 hypertrm.exe IOCTL_SERIAL_GET_HANDFLOW Serial2 SUCCESS
9 0.00000196 hypertrm.exe IOCTL_SERIAL_GET_BAUD_RATE Serial2 SUCCESS
10 0.00000196 hypertrm.exe IOCTL_SERIAL_GET_LINE_CONTROL Serial2 SUCCESS
11 0.00000196 hypertrm.exe IOCTL_SERIAL_GET_CHARS Serial2 SUCCESS
12 0.00000196 hypertrm.exe IOCTL_SERIAL_GET_HANDFLOW Serial2 SUCCESS
13 0.05002982 hypertrm.exe IOCTL_SERIAL_SET_BAUD_RATE Serial2 SUCCESS Rate: 9600
14 0.00031512 hypertrm.exe IOCTL_SERIAL_SET_RTS Serial2 SUCCESS
15 0.00020869 hypertrm.exe IOCTL_SERIAL_SET_DTR Serial2 SUCCESS
16 0.00036401 hypertrm.exe IOCTL_SERIAL_SET_LINE_CONTROL Serial2 SUCCESS StopBits: 1 Parity: NONE WordLength: 8
17 0.00021343 hypertrm.exe IOCTL_SERIAL_SET_CHAR Serial2 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13
18 0.00000391 hypertrm.exe IOCTL_SERIAL_SET_HANDFLOW Serial2 SUCCESS Shake:80000001 Replace:80000040 XonLimit:80 XoffLimit:200
19 0.00000223 hypertrm.exe IOCTL_SERIAL_SET_TIMEOUTS Serial2 SUCCESS RI:10 RM:0 RC:0 WM:0 WC:5000
20 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_WAIT_MASK Serial2 SUCCESS Mask: RLSD ERR
21 73.94005132 hypertrm.exe IOCTL_SERIAL_WAIT_ON_MASK Serial2 SUCCESS
22 1.93020258 hypertrm.exe IRP_MJ_READ Serial2 TIMEOUT Length 33: "Microboards" "MicroOrbit" "v1.2"
23 0.00024752 hypertrm.exe IRP_MJ_WRITE Serial2 SUCCESS Length 1: V
24 18.57749071 hypertrm.exe IRP_MJ_READ Serial2 TIMEOUT Length 1: X
25 0.00037854 hypertrm.exe IRP_MJ_WRITE Serial2 SUCCESS Length 1: C
26 16.04672577 hypertrm.exe IRP_MJ_READ Serial2 TIMEOUT Length 1: E
27 0.00023550 hypertrm.exe IRP_MJ_WRITE Serial2 SUCCESS Length 1: I
28 37.38510733 hypertrm.exe IRP_MJ_READ Serial2 CANCELLED Length 80
29 0.00005811 hypertrm.exe IOCTL_SERIAL_SET_WAIT_MASK Serial2 SUCCESS Mask: RLSD ERR
30 0.00001453 hypertrm.exe IOCTL_SERIAL_PURGE Serial2 SUCCESS Purge: TXABORT RXABORT
31 0.03023736 hypertrm.exe IRP_MJ_CLEANUP Serial2 SUCCESS
32 0.14646470 hypertrm.exe IRP_MJ_CLOSE Serial2 SUCCESS

Commg.dll (note: I trimmed out repetitive polling lines)...

CODE

0 0.02787002 AutoIt3.exe IRP_MJ_CREATE Serial2 SUCCESS Options: Open
1 0.00000726 AutoIt3.exe IOCTL_SERIAL_PURGE Serial2 SUCCESS Purge: RXABORT RXCLEAR
2 0.00000223 AutoIt3.exe IOCTL_SERIAL_PURGE Serial2 SUCCESS Purge: TXABORT TXCLEAR
3 0.00000196 AutoIt3.exe IOCTL_SERIAL_SET_QUEUE_SIZE Serial2 SUCCESS InSize: 4096 OutSize: 2048
4 0.00000196 AutoIt3.exe IOCTL_SERIAL_GET_BAUD_RATE Serial2 SUCCESS
5 0.00000196 AutoIt3.exe IOCTL_SERIAL_GET_LINE_CONTROL Serial2 SUCCESS
6 0.00000196 AutoIt3.exe IOCTL_SERIAL_GET_CHARS Serial2 SUCCESS
7 0.00000196 AutoIt3.exe IOCTL_SERIAL_GET_HANDFLOW Serial2 SUCCESS
8 0.00000196 AutoIt3.exe IOCTL_SERIAL_GET_BAUD_RATE Serial2 SUCCESS
9 0.00000196 AutoIt3.exe IOCTL_SERIAL_GET_LINE_CONTROL Serial2 SUCCESS
10 0.00000196 AutoIt3.exe IOCTL_SERIAL_GET_CHARS Serial2 SUCCESS
11 0.00000196 AutoIt3.exe IOCTL_SERIAL_GET_HANDFLOW Serial2 SUCCESS
12 0.00000307 AutoIt3.exe IOCTL_SERIAL_SET_BAUD_RATE Serial2 SUCCESS Rate: 9600
13 0.00031149 AutoIt3.exe IOCTL_SERIAL_SET_RTS Serial2 SUCCESS
14 0.00024081 AutoIt3.exe IOCTL_SERIAL_SET_DTR Serial2 SUCCESS
15 0.00000196 AutoIt3.exe IOCTL_SERIAL_SET_LINE_CONTROL Serial2 SUCCESS StopBits: 1 Parity: NONE WordLength: 8
16 0.00022405 AutoIt3.exe IOCTL_SERIAL_SET_CHAR Serial2 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13
17 0.00000223 AutoIt3.exe IOCTL_SERIAL_SET_HANDFLOW Serial2 SUCCESS Shake:1 Replace:40 XonLimit:0 XoffLimit:0
18 0.00000168 AutoIt3.exe IOCTL_SERIAL_GET_TIMEOUTS Serial2 SUCCESS
19 0.00000196 AutoIt3.exe IOCTL_SERIAL_SET_TIMEOUTS Serial2 SUCCESS RI:0 RM:0 RC:0 WM:0 WC:0
20 0.00000251 AutoIt3.exe IOCTL_SERIAL_SET_WAIT_MASK Serial2 SUCCESS Mask: RXCHAR
21 0.00284561 AutoIt3.exe IOCTL_SERIAL_WAIT_ON_MASK Serial2 SUCCESS
22 0.00000251 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
23 0.00024696 AutoIt3.exe IRP_MJ_WRITE Serial2 SUCCESS Length 1: V
24 0.00000223 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
25 0.00000670 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
26 0.00000223 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
27 0.00000196 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
28 0.00000754 AutoIt3.exe IRP_MJ_READ Serial2 SUCCESS Length 33: "Microboards" "MicroOrbit" "v1.2"
29 0.00000196 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
30 0.00000587 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
31 0.00000223 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS

(duplicative lines 32 through 84 removed)

85 0.00000196 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
86 0.00000223 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
87 0.00000810 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
88 0.00028830 AutoIt3.exe IRP_MJ_WRITE Serial2 SUCCESS Length 1: C
89 0.00000363 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
90 0.00000726 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
91 0.00000279 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
92 0.00000279 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
93 0.00000782 AutoIt3.exe IRP_MJ_READ Serial2 SUCCESS Length 1: X
94 0.00000279 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
95 0.00001034 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS

(duplicative lines 95 through 319 removed - time is longer now since I keep polling longer after a C than after a V)

319 0.00000251 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
320 0.00000698 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
321 0.00000279 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
322 0.00000251 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS

As you can see,

1. {"Microboards" "MicroOrbit" "v1.2"} was delivered to commg.dll, but commg.dll returned a truncated by one character modification of that string.
2. {X} was delivered to commg.dll, but commg.dll did not deliver that back to the calling program for some reason and delivered a weird character instead.

I hope this is useful...

-brendan

[martin]

FYI, I used PortMon to compare the I/O transactions of Hyperterminal vs. those of the COMMG.DLL using the same setup as before. It appears that the I/O is working correctly in both cases, so the issue appears to be somewhere inside commg.dll...

Hyperterminal (note that the notification-based system it uses ends up showing the send transaction after the receive in the monitor log - just in case that was confusing)...

CODE

2 0.02816950 hypertrm.exe IRP_MJ_CREATE Serial2 SUCCESS Options: Open
3 0.00000754 hypertrm.exe IOCTL_SERIAL_SET_QUEUE_SIZE Serial2 SUCCESS InSize: 8192 OutSize: 8192
4 0.00000223 hypertrm.exe IOCTL_SERIAL_CONFIG_SIZE Serial2 SUCCESS Size: 0
5 0.00000196 hypertrm.exe IOCTL_SERIAL_GET_BAUD_RATE Serial2 SUCCESS
6 0.00000223 hypertrm.exe IOCTL_SERIAL_GET_LINE_CONTROL Serial2 SUCCESS
7 0.00000251 hypertrm.exe IOCTL_SERIAL_GET_CHARS Serial2 SUCCESS
8 0.00000196 hypertrm.exe IOCTL_SERIAL_GET_HANDFLOW Serial2 SUCCESS
9 0.00000196 hypertrm.exe IOCTL_SERIAL_GET_BAUD_RATE Serial2 SUCCESS
10 0.00000196 hypertrm.exe IOCTL_SERIAL_GET_LINE_CONTROL Serial2 SUCCESS
11 0.00000196 hypertrm.exe IOCTL_SERIAL_GET_CHARS Serial2 SUCCESS
12 0.00000196 hypertrm.exe IOCTL_SERIAL_GET_HANDFLOW Serial2 SUCCESS
13 0.05002982 hypertrm.exe IOCTL_SERIAL_SET_BAUD_RATE Serial2 SUCCESS Rate: 9600
14 0.00031512 hypertrm.exe IOCTL_SERIAL_SET_RTS Serial2 SUCCESS
15 0.00020869 hypertrm.exe IOCTL_SERIAL_SET_DTR Serial2 SUCCESS
16 0.00036401 hypertrm.exe IOCTL_SERIAL_SET_LINE_CONTROL Serial2 SUCCESS StopBits: 1 Parity: NONE WordLength: 8
17 0.00021343 hypertrm.exe IOCTL_SERIAL_SET_CHAR Serial2 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13
18 0.00000391 hypertrm.exe IOCTL_SERIAL_SET_HANDFLOW Serial2 SUCCESS Shake:80000001 Replace:80000040 XonLimit:80 XoffLimit:200
19 0.00000223 hypertrm.exe IOCTL_SERIAL_SET_TIMEOUTS Serial2 SUCCESS RI:10 RM:0 RC:0 WM:0 WC:5000
20 0.00000335 hypertrm.exe IOCTL_SERIAL_SET_WAIT_MASK Serial2 SUCCESS Mask: RLSD ERR
21 73.94005132 hypertrm.exe IOCTL_SERIAL_WAIT_ON_MASK Serial2 SUCCESS
22 1.93020258 hypertrm.exe IRP_MJ_READ Serial2 TIMEOUT Length 33: "Microboards" "MicroOrbit" "v1.2"
23 0.00024752 hypertrm.exe IRP_MJ_WRITE Serial2 SUCCESS Length 1: V
24 18.57749071 hypertrm.exe IRP_MJ_READ Serial2 TIMEOUT Length 1: X
25 0.00037854 hypertrm.exe IRP_MJ_WRITE Serial2 SUCCESS Length 1: C
26 16.04672577 hypertrm.exe IRP_MJ_READ Serial2 TIMEOUT Length 1: E
27 0.00023550 hypertrm.exe IRP_MJ_WRITE Serial2 SUCCESS Length 1: I
28 37.38510733 hypertrm.exe IRP_MJ_READ Serial2 CANCELLED Length 80
29 0.00005811 hypertrm.exe IOCTL_SERIAL_SET_WAIT_MASK Serial2 SUCCESS Mask: RLSD ERR
30 0.00001453 hypertrm.exe IOCTL_SERIAL_PURGE Serial2 SUCCESS Purge: TXABORT RXABORT
31 0.03023736 hypertrm.exe IRP_MJ_CLEANUP Serial2 SUCCESS
32 0.14646470 hypertrm.exe IRP_MJ_CLOSE Serial2 SUCCESS

Commg.dll (note: I trimmed out repetitive polling lines)...

CODE

0 0.02787002 AutoIt3.exe IRP_MJ_CREATE Serial2 SUCCESS Options: Open
1 0.00000726 AutoIt3.exe IOCTL_SERIAL_PURGE Serial2 SUCCESS Purge: RXABORT RXCLEAR
2 0.00000223 AutoIt3.exe IOCTL_SERIAL_PURGE Serial2 SUCCESS Purge: TXABORT TXCLEAR
3 0.00000196 AutoIt3.exe IOCTL_SERIAL_SET_QUEUE_SIZE Serial2 SUCCESS InSize: 4096 OutSize: 2048
4 0.00000196 AutoIt3.exe IOCTL_SERIAL_GET_BAUD_RATE Serial2 SUCCESS
5 0.00000196 AutoIt3.exe IOCTL_SERIAL_GET_LINE_CONTROL Serial2 SUCCESS
6 0.00000196 AutoIt3.exe IOCTL_SERIAL_GET_CHARS Serial2 SUCCESS
7 0.00000196 AutoIt3.exe IOCTL_SERIAL_GET_HANDFLOW Serial2 SUCCESS
8 0.00000196 AutoIt3.exe IOCTL_SERIAL_GET_BAUD_RATE Serial2 SUCCESS
9 0.00000196 AutoIt3.exe IOCTL_SERIAL_GET_LINE_CONTROL Serial2 SUCCESS
10 0.00000196 AutoIt3.exe IOCTL_SERIAL_GET_CHARS Serial2 SUCCESS
11 0.00000196 AutoIt3.exe IOCTL_SERIAL_GET_HANDFLOW Serial2 SUCCESS
12 0.00000307 AutoIt3.exe IOCTL_SERIAL_SET_BAUD_RATE Serial2 SUCCESS Rate: 9600
13 0.00031149 AutoIt3.exe IOCTL_SERIAL_SET_RTS Serial2 SUCCESS
14 0.00024081 AutoIt3.exe IOCTL_SERIAL_SET_DTR Serial2 SUCCESS
15 0.00000196 AutoIt3.exe IOCTL_SERIAL_SET_LINE_CONTROL Serial2 SUCCESS StopBits: 1 Parity: NONE WordLength: 8
16 0.00022405 AutoIt3.exe IOCTL_SERIAL_SET_CHAR Serial2 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13
17 0.00000223 AutoIt3.exe IOCTL_SERIAL_SET_HANDFLOW Serial2 SUCCESS Shake:1 Replace:40 XonLimit:0 XoffLimit:0
18 0.00000168 AutoIt3.exe IOCTL_SERIAL_GET_TIMEOUTS Serial2 SUCCESS
19 0.00000196 AutoIt3.exe IOCTL_SERIAL_SET_TIMEOUTS Serial2 SUCCESS RI:0 RM:0 RC:0 WM:0 WC:0
20 0.00000251 AutoIt3.exe IOCTL_SERIAL_SET_WAIT_MASK Serial2 SUCCESS Mask: RXCHAR
21 0.00284561 AutoIt3.exe IOCTL_SERIAL_WAIT_ON_MASK Serial2 SUCCESS
22 0.00000251 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
23 0.00024696 AutoIt3.exe IRP_MJ_WRITE Serial2 SUCCESS Length 1: V
24 0.00000223 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
25 0.00000670 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
26 0.00000223 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
27 0.00000196 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
28 0.00000754 AutoIt3.exe IRP_MJ_READ Serial2 SUCCESS Length 33: "Microboards" "MicroOrbit" "v1.2"
29 0.00000196 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
30 0.00000587 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
31 0.00000223 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS

(duplicative lines 32 through 84 removed)

85 0.00000196 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
86 0.00000223 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
87 0.00000810 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
88 0.00028830 AutoIt3.exe IRP_MJ_WRITE Serial2 SUCCESS Length 1: C
89 0.00000363 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
90 0.00000726 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
91 0.00000279 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
92 0.00000279 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
93 0.00000782 AutoIt3.exe IRP_MJ_READ Serial2 SUCCESS Length 1: X
94 0.00000279 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
95 0.00001034 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS

(duplicative lines 95 through 319 removed - time is longer now since I keep polling longer after a C than after a V)

319 0.00000251 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
320 0.00000698 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
321 0.00000279 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS
322 0.00000251 AutoIt3.exe IOCTL_SERIAL_GET_COMMSTATUS Serial2 SUCCESS

As you can see,

1. {"Microboards" "MicroOrbit" "v1.2"} was delivered to commg.dll, but commg.dll returned a truncated by one character modification of that string.
2. {X} was delivered to commg.dll, but commg.dll did not deliver that back to the calling program for some reason and delivered a weird character instead.

I hope this is useful...

-brendan

Yes, I can get similar problems. A single character never gets through even though the dll receives it ok and returns it to the script.
I have sent you a PM with a link to new versions to try.
As a temporary fudge, I have added '{{{{{{{{{{' to a string if it is 1,2 or 3 characters long. In the UDF I have copied the left part of a string before '{{{{'. This means that if you want to receive a string which has a sequence of '{' characters then they will get lost. I assumed this was unlikely.

[martin]

@bhoar

Thanks for all your information and patience.
I have updated the initial post to have links to new versions.
(The temporary fudge with '{' characters has been removed)

Edited by martin, 16 June 2007 - 05:55 PM.

[fealgr]

Hi. I'm new in this forum and first of all I'd like to say hello to everybody!
Second ... sorry for my english and third ... I explain my problem:

I'm trying to interfacing with a flowcounter and doing it with this nice COMMs UDF.
The flowcounter has a serial port connection and the microcontroller returns the counter's value when it receive the character 'a' (0x61).
I've tested it with many application (f.ex. LookRS232) and the communication works.

At this moment my problem is that I should set the flow control to "None" instead of "hardware" or "XON XOFF". It is possible?
I have anyway a doubt: the _CommSetPort returned @error is 0. What does it means?


Cheers

[martin]

Hi. I'm new in this forum and first of all I'd like to say hello to everybody!
Second ... sorry for my english and third ... I explain my problem:

I'm trying to interfacing with a flowcounter and doing it with this nice COMMs UDF.
The flowcounter has a serial port connection and the microcontroller returns the counter's value when it receive the character 'a' (0x61).
I've tested it with many application (f.ex. LookRS232) and the communication works.

At this moment my problem is that I should set the flow control to "None" instead of "hardware" or "XON XOFF". It is possible?
I have anyway a doubt: the _CommSetPort returned @error is 0. What does it means?
Cheers

If @error = 0 then it should mean there was no error.

If you need NONE for the handshaking then I will need to check this, but it could be I need to set another option for this to work.

I won't be able to look at this until tomorrow, but if it does need a new option I will post an upadate.
Do you get any communication at the moment? I have a suspicion that you might get nothing until I fix it for NONE.

[martin]

If @error = 0 then it should mean there was no error.

If you need NONE for the handshaking then I will need to check this, but it could be I need to set another option for this to work.

I won't be able to look at this until tomorrow, but if it does need a new option I will post an upadate.
Do you get any communication at the moment? I have a suspicion that you might get nothing until I fix it for NONE.

Untill I get some time on this, try this version of [link removed 28th July 2007]

and let me know if it helps.

Edited by martin, 28 July 2007 - 10:56 AM.