No announcement yet.

Communication problems

  • Filter
  • Time
  • Show
Clear All
new posts

  • Communication problems

    I'm working on a program translation from old TurboBasic to PB/DOS 3.50 (some 20 thousand lines - the reason I do the translation is just I can't more compile the program under TurboBasic!).

    The program intensively uses a serial communication channel (1 line, 4800 baud, records of 10-64 chars each). With the PB/DOS version of the program I get some communication errors the TurboBasic version of the program didn't show.

    Note the following: the PC and the connetced items are always the same - no way to say the problem is outside the program itself. I changed the program as slitght as possible to accomplish to the PB/DOS syntax - the TurboBasic program has worked for years without problems. The PC is a Pentium 300MHz.

    The question is, is there some tricks to know when programming communications under PB/DOS? Is it possible the system can lose characters at a speed as slow as 4800 baud? May be the problem is Windows?


    Rgds, Aldo

  • #2
    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.

    There are no atheists in a fox hole or the morning of a math test.
    If my flag offends you, I'll help you pack.


    • #3

      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).]


      • #4
        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:
        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.

        Rgds, Aldo


        • #5
          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:
           ' 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.

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


          • #6

            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.


            Rgds, Aldo


            • #7

              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]


              • #8

                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!

                Rgds, Aldo


                • #9
                  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).]
                  There are no atheists in a fox hole or the morning of a math test.
                  If my flag offends you, I'll help you pack.


                  • #10

                    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.

                    Rgds, Aldo


                    • #11
                      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).]
                      "Not my circus, not my monkeys."


                      • #12
                        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

                        Tom Hanlin
                        PowerBASIC Staff


                        • #13
                          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.



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