Bizarre behavior from OPEN COM:

[GTC]

Running QB64 on Win 7 64-bit.

Having a lot of trouble with opening more than one COM port. To try to get to the bottom of the issue, I'm using the following simple program.

Ports 1 and 8 are valid on my PC. When I enter 1, COM1: is successfully opened  -- and presumably closed, as per my close instruction. The program sleeps for 3 seconds to give Windows some time to do the close (although I don't believe that is strictly is necessary).

Thereafter, any attempt to open another port (valid or not) results in Error 64 -- "Bad file name. File name contains illegal characters or exceeds 12 characters" -- neither of which allegation is true.

In fact, it won't even allow me to open port 1 again, after it has been closed. Just error 64 and goodbye.

Got me beat. Could someone please run my sample program in their environment and let me know what you get.

BTW: the open mode -- random or binary -- makes no difference to the result in my environment.

Code: QB64: [Select]

1. ON ERROR GOTO ErrorHandler:
2.  
3. Start:
4.  
5. INPUT "Com Port   #: ", Port$
6. OPEN "COM" + Port$ + ":4800,N,8,1" FOR RANDOM AS #1 ' open the serial interface
7. PRINT "Opening COM" + Port$ + ":4800,N,8,1"
8.  
9. CLOSE #1
10. SLEEP 3
11. GOTO Start
12.  
13. ErrorHandler:
14. PRINT "Error= "; ERR; " at line "; _ERRORLINE
15. RESUME NEXT

[FellippeHeitor]

Looking into it.

[FellippeHeitor]

I know nothing about COM ports or the parameters required for them to work properly. That said:

I created virtual COM ports in my Windows virtual machine. Testing your program as is gave me the same results you got: COM1 opened fine. Then no other ports worked.

Then I changed your settings to match the wiki examples:

Code: QB64: [Select]

1. ON ERROR GOTO ErrorHandler:
2.  
3. Start:
4.  
5. INPUT "Com Port   #: ", Port$
6. fh = FREEFILE
7. OPEN "COM" + Port$ + ":9600,N,8,1,CS0,DS0" FOR BINARY AS #fh ' open the serial interface
8. PRINT "Opening COM" + Port$ + ":9600,N,8,1,CS0,DS0"
9. a$ = "Hello" + CHR$(10)
10. PUT #fh, , a$
11. CLOSE #fh
12. SLEEP 3
13. GOTO Start
14.  
15. ErrorHandler:
16. PRINT "Error= "; ERR; " at line "; _ERRORLINE
17. RESUME NEXT
18.  
19.  

All worked as expected, opened the same port multiple times, opened all of them, then back.

Did you play with the settings? Do your equipments require the exact settings you had in your sample?

[GTC]

Many thanks Fellippe. Very helpful to me.

I have played around with your code sample and it seems the problem relates to the presence or absence of items CS0,DS0 (CTS and DSR) which relate to flow control.

My devices specify flow control = none and in the QB64 Help for OPEN COM it shows those items as [options] -- which they are in plain vanilla Basic, too, so I would not expect to have to use them if they are options. You might like to look into that at the compiler level as to why they are generating those specific runtime errors when they are not mandatory items.

Meantime, I'll see if I can get the devices to talk via COM ports which specify CS0 and DS0 in their OPEN statements.

[GTC]

UPDATE: I see that the the notes in Help for OPEN COM says, inter alia:

(a) If any optional CD, CS, DS or OP timeouts occur the OPEN will fail or port access will stop. Try 0 to ignore.   

(b) Four commas are required after the Speed, Parity, Bits, and Stopbit, even if none of the Options are used.

I tried (b) the four commas (i.e place holders for null items) but that made no difference. The OPEN still failed with Error 64 -- Bad file name. File name contains illegal characters or exceeds 12 characters.

So seems that either note (b) is wrong, or it is not implemented correctly in the compiler/runtime executable.

Note (a) seems to imply that there is some inconsistency in the Windows handling of COM ports that needs to be accommodated.

[luke]

I notice the original code uses RANDOM, but the working code uses BINARY. @GTC are you able to confirm which of the two changes is the one that causes the problem?

I have also opened a github issue https://github.com/QB64Team/qb64/issues/99 to track this.

[GTC]

I notice the original code uses RANDOM, but the working code uses BINARY. @GTC are you able to confirm which of the two changes is the one that causes the problem?

I have also opened a github issue https://github.com/QB64Team/qb64/issues/99 to track this.

As per my OP, "BTW: the open mode -- random or binary -- makes no difference to the result in my environment."

Nor does the mode make any difference to Fellippe's revised version.

The determining factor in my tests is the presence or absence of CD0, DS0 in the open attributes string. See my notes about the points I have labeled as (a) and (b) above.