Announcement

**Mel Bishop** · 27 Jun 2002, 07:44 AM

It would really help to know what kind of errors you are getting,
under what circumstances (if known) and what version of windows
are you using.

------------------

**Davide Vecchi** · 27 Jun 2002, 07:46 AM

Aldo,

i' ve been using PB/DOS for years to connect to many kinds of serial devices and PCs, even simultaneously txing/rxing on 2 ports, or continuously and quickly closing COM1 to open COM3 and back, etc., and i can tell i never got problems related to PB/DOS, it always worked as it was supposed to. However i' m talking about running under DOS without Windows; under Windows, several times i' ve had no-apparent-sense problems directely from VB/Win apps; if i was in your shoes i' d investigate first at the Windows side, regardless of the fact that the old program has been succesfully running under the same conditions.

Is it possible to test the program in plain DOS ?
The data are lost while transmitting or receiving ?
Can you post the OPEN "COM..." statement ?
Does your program have error trapping that resume the execution after "Device I/O error"s ?

[This message has been edited by Davide Vecchi (edited June 27, 2002).]

**Aldo Cavini** · 27 Jun 2002, 08:06 AM

Mel, Davide,

thanks for the replies. I'm working under Windows NT 4.0 SP5 and yes, I trap all the errors inside my program. THe OPEN statement is the following:

Code:

OPEN "COM1:4800,n,8,1,rs,cs,ds,cd" AS #1

Davide, your idea to run the program under plain DOS is good, I'll try it and let you know the results. Unfortunately, this program must run on my customer PCs also, hence I can't ask them to use such "old-fashion" computers (which I really preferred... ).

My program can be enabled to generate a complete report of the COM activity. What I see is I'm losing some RX chars. In effect I'm conveinced the problem is within Windows, or in that area within PB/DOS and Windows.

------------------

**Lance Edmonds** · 27 Jun 2002, 08:44 AM

Windows can interfere with XON/XOFF transmissions, so hardware handshaking is highly recommended.

However, you might try placing the comms code in a DOS-level critical section, using the following code:

Code:

 ' Enable the Critical Section
 ! MOV AX,&H1681
 ! INT &H2F
 
 ' Do the comms
 OPEN "COM1:.."
 ...
 CLOSE #1
  
 ' Release the CS
 ! MOV AX,&H1682
 ! INT &H2F

This code virtually disables Windows for the duration, but if the PC needs multi-tasking to remain in operation... well...

In any case, try to avoid running the CS for very long durations, or Windows might not love you anymore.

------------------
Lance
PowerBASIC Support
mailto:[email protected]om [email protected]</A>

**Aldo Cavini** · 28 Jun 2002, 05:16 AM

Lance,

thanks for the suggestions. I verified the serial port settings (control panel) - the handshake is disabled (both XON/XOFF and hardware). Is it possible this setting is not sufficient to avoid handshake problems?

The critical section is a good idea, but I preferred to continue "been loved by Windows" I use the serial port too intensively to try this strategy.

Inside my program I use the following:

A Serial port
The TIMER function, to check against time-outs
The PLAY statement, to warn the user something is happening to the system

I did a try, and disabling the PLAY statements make the program run perfectly. Some other tests make me think the problem is somewhere between the PC timers and the OS. I'd like to know if someone else has ever got this kind of problems. For the moment, I'll left the PLAY statements commented out, waiting for a good way to use them without creating problems to the program.

Aldo

------------------

**Davide Vecchi** · 28 Jun 2002, 05:57 AM

Aldo,

maybe one try might be reducing the size of FIFO buffer, or disabling FIFO buffering at all (from "Device manager" (? "Gestione periferiche" ), advanced properties of COM port), even though i' m not 100% sure that it affects DOS apps too.

Does your program do handshaking internally, or no handshaking takes place at all ? In this second case, was the old program working fine without any handshaking too ?

Out of curiosity, when you have PLAY statements not commented out, does the data loss occurr even if they are never executed ?

------------------
Davide Vecchi
[email protected]

**Aldo Cavini** · 28 Jun 2002, 06:45 AM

Davide,

1- Of course one of the first attempet I did is to check the serial port settings - I disabled the FIFO, the program worked even worse.

2- The items the PC is connected to can't manage the handshake at all. Two active lines only, TX and RX. Nothing about XON/XOFF.

3- The communication errors occur only for a little while (max 1-2 seconds) after each PLAY statement execution. This is the reason I investigate on the PLAY statements. It looks as though the TIMER is sometimes accelerated after a PLAY - What really fails is the time-out check on the receive.

I still hope to read about someone else had the same problems - and solved them!

------------------

**Mel Bishop** · 28 Jun 2002, 07:39 AM

Originally posted by Aldo Cavini:
...The communication errors occur only for a little while
(max 1-2 seconds) after each PLAY statement execution...

It sounds to me that your COM buffer is filling up while the PLAY
statement(s) are doing their job. Try increasing the COM buffer
size by using $COM 1024 metastatement.

This may or may not work since, if your com buffer fills up, the
program will most likely crash. However.....

------------------

[This message has been edited by Mel Bishop (edited June 28, 2002).]

**Aldo Cavini** · 28 Jun 2002, 07:47 AM

Mel,

the problem is not there. The records are 64 chars max (see my first post). By default the stacks are 256 byte wide, and the communication is half duplex - no way to overflow the stacks. Thanks anyway.

------------------

**Eric Pearson** · 28 Jun 2002, 08:10 AM

Aldo --

I have done a great deal of work with PB/DOS serial communications, and I think I know what your problem is. You said that removing the PLAY statements fixes the problem, which is "missing characters". This appears to be a classic symptom of what I call "distracting" the system.

I first encountered this problem when I wrote a program that attempted to do a screen-BLOAD operation while data was coming in to the serial port. It would glitch every single time, and drop between 1 and 3 characters in the middle of the stream. PowerBASIC support confirmed that when a "large" operating system request is made, the internal PB functions which transfer characters from the serial port to the com buffer may be disabled for an unacceptably long time. This can't be helped, because once you ask DOS to do something it doesn't return control to your program until the operation is finished.

I was able to fix the program by sending an XOFF character to the remote device, waiting for the data to stop, performing the BLOAD, and then sending XON.

I have always pictured the problem this way... this may or may not be a technically accurate description...

The serial port's incoming data is actually represented by a single byte of memory. The PB/DOS runtime library is responsible for constantly monitoring that byte, and whenever a new character is received it must "shovel" that byte into its own internal buffer. That way when your program eventually decides to GET the data, it will be available. If the serial data comes in too fast, the byte will be overwritten before PB can place it in the buffer. And when you perform a time-consuming operation like a BLOAD (or apparently a PLAY) the runtime library (or the operating system) is too busy performing the requested operation to maintain the serial buffer properly, and one or more characters are lost.

The use of Windows complicates this situation even more, because your PB/DOS program will not be able to use 100% of the CPU cyles to do its job, as it can on a DOS machine. All programs that are run under Windows are "frozen" for at least part of each second, so it would not surprise me if an operation like PLAY became a problem.

Hope this helps.

-- Eric

------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

[This message has been edited by Eric Pearson (edited June 28, 2002).]

**Tom Hanlin** · 28 Jun 2002, 11:04 AM

Modern comm hardware provides a fair buffer, and PB has its own
interrupt-driven software comm buffering. This does not seem likely
to be a comm buffering issue. It's more likely a quirk in the NT
virtual machine support for low-level hardware access. It may prove
possible to fix by changing a registry setting. It would be useful to dig
around in the Microsoft Knowledgebase for ideas on tuning the DOS box
support.

------------------
Tom Hanlin
PowerBASIC Staff

**Aldo Cavini** · 29 Jun 2002, 09:30 AM

Eric, Tom,

thanks for the replies. Since the program without PLAYs is still working correctly, I'm taking into consideration to leave them commented out! Anyway, the problems I noticed with the PLAYs enabled are two:

Sometimes I lose some RX chars
The PLAY statements corrupt the TIMER functionality

I think Eric's system distracting explanation is correct. But, if the problem belongs to Windows/DOS/(and whatever else), why the program worked correctly when compiled with TurboBasic? The TurboBasic version has worked without problems for years!

Of course what I'm saying is not TurboBasic is better than PowerBasic - PowerBasic for DOS compiler is very-very more powerful and better than TurboBasic. The different functionality of the two compiled programs (same PC and OS) seem to point out how difficult will be to identify and solve the problem! For this reason, the PLAYs will remain commented-out. I havn't the time (weeks? months?) to spend on it, nor want the Powerbasic staff spend his precious time on this marginal problem.

Aldo

------------------

[This message has been edited by Aldo Cavini (edited June 29, 2002).]

Announcement

Communication problems

Communication problems

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment