Announcement

Collapse

Maintenance

The forum could be offline for 30-60 minutes in the very near future for maintenance (said 3pm Pacific). I was behind on getting this notice. I do apologize.
See more
See less

Summary of Serial / Comm I/O problems

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Summary of Serial / Comm I/O problems

    hi everyone,

    after a very thourough review of these forums and all the documentation for pbdos3.5, i decided to start this thread as a place to try to summarize and clarify a few tricky issues concerning serial communications. there have been many and varied threads concerning various issues in the past, but i think this topic needs to be well condensed and in the end turned into a faq for future generations (to laugh at or forget ). i see three main categories of interest:

    1. reliable operation under dos, win9x, winnt, win2k, & winxp.

    2. reliable operation in spite of variations in 'standard' hardware, especially when dealing with dumb devices flooding/sticking com ports (eg. gps's).

    3. summary of available comm libraries, utilities, helpers, etc. , and also of available information (preferably free) on these topics.

    so come one and all and put in your two cent's worth. i will be working on summarizing what i have found so far, and would gladly turn the results into a faq when it's all over.

    here are a few of the links that i found so far to prior threads in the forum:

    serial interface problems - powerbasic forums
    com problem ! - powerbasic forums
    why in vdm a com program do not work? - powerbasic forums
    tsr programms - powerbasic forums
    serial activity stops - powerbasic forums
    powerbasic multiport serial support - powerbasic forums

    why am i doing this?
    i write the in-house data collection / processing software that our small hydrographic survey company needs to cope with our eclectic equiptment mix and our strange jobs. i spent many years plauged with problems in m$ qb4. when i finally looked i found powerbasic 3.5 (hooray) to solve many of my problems. but i can now see clearly a few common and not-so-obvious issues involved in carefully dealing with the os/hardware environment, which are at least as important as the programming language chosen (duh). so when i was perusing these forums i realised that a proper summary of this topic was due, this information being the necessary counterpart to reliable operation, especially across the diverse platforms that are the home and calling of pbdos. i have not found this info all together in one place yet, and i hope that in putting it together any last details will be remembered/addressed/included. i didn't want to start coding/recoding at random only to encounter the same ambiguous problems agian. my next project is data collection from a digital sounder that runs 9600,n,8,1 on 2 wires, tx and grnd, merged with positions from either gps or transit+edm, displayed on a moving map with a running depth display. the sounder runs about 6 * 10 char 'pings' per second, always on. must run either in dos or under win9x. data loss is absolutely unacceptable, so i must do it right the first time. my initial tests with qb4 a year back would stick the com port sometimes in dos, loose them in win9x. etc. etc. etc...

    ------------------
    what can go wrong will go wrong.
    anything can go wrong.
    what hasn't?!?!

    [this message has been edited by criss french (edited december 08, 2001).]
    What can go wrong will go wrong.
    Anything can go wrong.
    What hasn't?!?!

  • #2
    Criss, do you have some specific questions that these threads have not answered? if so, please feel free to ask us! Thanks!


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

    Comment


    • #3
      Request to all: Please Post info: Serial I/O DOS WIN Tricks & Tips

      ...anything that comes to mind. Juicy/obscure details especially.

      Lance, you wrote:
      Criss, do you have some specific questions that these threads have not answered? If so, please feel free to ask us! Thanks!
      ...very important maybe. Those threads and others have probably answered most of my questions, in a scattered sort of way. This forum is excellent, but inherently scattered and un-systematic. I would like to try to get everyone going on a fresh ante-up of their best real world know how (school of hard knocks), with an eye to capturing the info in a more concise FAQ or somesuch. It took me two or three days to read the semi-randomly titled threads in this forum until I felt I hadn't missed anything much re. Serial/Comms , but this is very far from a handy reference guide.

      PB comes with a Users Guide and a Reference Guide. I know you didn't leave out any fundamental data types or important key words from those books. You would never substitute this forum for any category of the information in them (including overviews). We will (or should) never see a thread called "Is LINE a reserved keyword?", or "What are the built in data-types?". Well, I could live without LINE, but I fear what I don't know, when it comes to the nitty-gritty of PB+DOS+hardware+WIN. I know it's a great combo, but the Devil is in the Details. The good folks at PB drew a reasonable line on where there manuals end, but if there were a book called "Hardware Programming for PowerBASIC DOS 3.5" I would buy it for $50 easy, although I don't see a Sybex or Que or Sams sized market. So I'll try to post a proto-FAQ here soon from the old threads, and ask again for everyone to post here anything that comes to mind on the topic.

      Thanks.


      ------------------
      What can go wrong will go wrong.
      Anything can go wrong.
      What hasn't?!?!
      What can go wrong will go wrong.
      Anything can go wrong.
      What hasn't?!?!

      Comment


      • #4
        Simple (I hope) nubie firstbasic question: I'm testing the
        below script as a simple way to send the serial port TD pin
        high for a brief period to operate a relay. With a multimeter
        connected to the TD pin, when I run the below in qbasic or
        quick basic, the pin appropriately goes high for a ~second.
        When I run the script in firstbasic, there is no action on
        the pin and I'm left with a blank dos box. This is being
        done on a win95 machine. I guess my main question is can
        firstbasic programs operate in a windows environment, or is
        it DOS only? I have another program for controlling servos
        via the serial port that I would like to compile with
        firstbasic instead of quickbasic, but it looks like firstbasic
        may not be able to access the serial port. Any info or info
        links would be much appreciated. thanks!

        'a$ = COMMAND$
        a$ = "1"
        IF a$ = "" THEN GOTO FINI
        sec! = VAL(a$)
        IF sec! < 0 THEN GOTO FINI
        OPEN "com2:9600,N,8,1,CD0,CS0,DS0,OP0" FOR OUTPUT AS #2
        now! = TIMER
        DO
        PRINT #2, "A";
        LOOP UNTIL TIMER > (now! + sec!)
        CLOSE #2
        END
        FINI:
        BEEP
        END

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

        Comment


        • #5
          Zoom,
          I've always had problems accessing COM ports in dos boxes
          with QB and PB. As I understand it, 32-bit Windows intercepts
          data from these before a dos-box program can get it. I don't
          know that it simply CAN'T be done though.
          ...Tony


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


          [This message has been edited by Tony Burcham (edited December 25, 2001).]
          TheirCorp's projects at SourceForge

          TheirCorp's website

          sigpic

          Comment


          • #6
            I know win95 and later are more restrictive than DOS and win31,
            but I'm running win95 and have both firstbasic and qbasic
            sitting side by side. Qbasic appears to open the port as
            expected, while firstbasic does not. I can compile this type
            of program with quickbasic and it apparently runs OK even under
            win2K. Maybe windows knows that qbasic is "family" and lets
            it do its thing, or maybe some routine in windows is actually
            being used by qbasic. I've tried writing bytes directly to
            the serial port register using qbasic, and that seems to be
            prevented by win95.

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

            Comment


            • #7
              Dear Mr Zoom Kat. Please note that the rules of this BBS require you to register with your real name (First + Last) -- aliases and handles are not permitted.

              Please reregister correctly before making any further posts. Thank you!

              Reponding to your "family" comments: If you have code that does not open the com port under Windows, then something is wrong with your code, or the setup of the port under Windows... there is no reason why (even under NT/2000) that a DOS app cannot open a valid and correctly configured COM port. Heck, even my PBFax library or PB/DOS can send faxes under Windows 95/98/ME/NT/2K/XP.

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

              Comment


              • #8
                dear chris,

                i was interested in your work on hydrographic applications
                because i have worked in that area for many years. i'm writing to
                you because i hope you have solved some of the same problems
                i am facing. perhaps i can help you in some way.

                right now
                i'm working on a magnetic gradiometer program for some marine
                archeologists. they have two independent magnetometers producing
                10 readings a second at 9600 baud on two separate com lines. the
                messages are like "$ 88764.987,7654,789(crlf)", and like your
                applications, nothing should be lost. at the same time, they
                want to receive $gga and $vtg messages at 5hz from a gps receiver this
                has to be at 4800 baud for compatability with their nobeltec navigation
                software. since this is about 125 characters, this nav data is almost
                a continuous stream at 4800 baud. finally, they have a simple sounder
                the sends "$dpddd, 34.2,xxx(crlf)" or something like that at 1 hz.

                well, i've been trying to use labview to get all this data in, and
                i can't seem to do it--let alone display and store it!. i decided
                that maybe the way to do it is with a pre-procesing computer that
                handles the serial inputs and combines them into a single 9600 baud\
                message with just the essential data in a comma-delimited string.

                then, a second computer (laptop) could handle display and storage.

                i though that pb for dos would be an ok choice for the "data concentrator"
                unit, but it supposedly only handles 4 serial ports. i think i need
                five. anyway, it occurs to me that you might have solved this data
                concentration problem yourself. if you have the need, we have apps
                that can draw survey lines on nobeltec charts, convert degrees to utm
                as ocx, etc. we also build integrated hardware systems (gps+radio modem+ navigation
                (guidance) computer + sensor loggger computer + 100 baset ethernet + laptop +
                power management) into pelican cases.

                any thoughts about using pbdos to acquire multiple serial ports would
                be much appreciated.

                best,
                charlie


                originally posted by criss french:
                hi everyone,

                after a very thourough review of these forums and all the documentation for pbdos3.5, i decided to start this thread as a place to try to summarize and clarify a few tricky issues concerning serial communications. there have been many and varied threads concerning various issues in the past, but i think this topic needs to be well condensed and in the end turned into a faq for future generations (to laugh at or forget ). i see three main categories of interest:

                1. reliable operation under dos, win9x, winnt, win2k, & winxp.

                2. reliable operation in spite of variations in 'standard' hardware, especially when dealing with dumb devices flooding/sticking com ports (eg. gps's).

                3. summary of available comm libraries, utilities, helpers, etc. , and also of available information (preferably free) on these topics.

                so come one and all and put in your two cent's worth. i will be working on summarizing what i have found so far, and would gladly turn the results into a faq when it's all over.

                here are a few of the links that i found so far to prior threads in the forum:

                serial interface problems - powerbasic forums
                com problem ! - powerbasic forums
                why in vdm a com program do not work? - powerbasic forums
                tsr programms - powerbasic forums
                serial activity stops - powerbasic forums
                powerbasic multiport serial support - powerbasic forums

                why am i doing this?
                i write the in-house data collection / processing software that our small hydrographic survey company needs to cope with our eclectic equiptment mix and our strange jobs. i spent many years plauged with problems in m$ qb4. when i finally looked i found powerbasic 3.5 (hooray) to solve many of my problems. but i can now see clearly a few common and not-so-obvious issues involved in carefully dealing with the os/hardware environment, which are at least as important as the programming language chosen (duh). so when i was perusing these forums i realised that a proper summary of this topic was due, this information being the necessary counterpart to reliable operation, especially across the diverse platforms that are the home and calling of pbdos. i have not found this info all together in one place yet, and i hope that in putting it together any last details will be remembered/addressed/included. i didn't want to start coding/recoding at random only to encounter the same ambiguous problems agian. my next project is data collection from a digital sounder that runs 9600,n,8,1 on 2 wires, tx and grnd, merged with positions from either gps or transit+edm, displayed on a moving map with a running depth display. the sounder runs about 6 * 10 char 'pings' per second, always on. must run either in dos or under win9x. data loss is absolutely unacceptable, so i must do it right the first time. my initial tests with qb4 a year back would stick the com port sometimes in dos, loose them in win9x. etc. etc. etc...



                ------------------
                charlie
                Charlie

                Comment


                • #9
                  Hi Criss,

                  I read Ean-codes from a barcode-scanner over com-port:

                  'Pb 3.5 Dos

                  defint a-z
                  shared sk
                  sk%=1
                  cls
                  open "com2:9600,N,8,1,rs" as #sk% 'open Port
                  shared ean$ 'contains the data
                  '--------Main
                  do
                  call liesean
                  loop until ean$<>""
                  ?ean$



                  sub liesean

                  dim e as local string
                  dim ee as local string
                  dim eee as local string
                  dim i as local integer
                  do While loc(sk)>=1 'if data in the buffer

                  input#sk,ee$ 'input it
                  '?ee$,len(ee$)

                  'test the incoming string byte by byte if the signs are true and
                  'without errors

                  for i=1 to len(ee$) step 1
                  e$=mid$(ee$,i,1)
                  '?i,e$
                  select case e$ 'take only numbers
                  case "1","2","3","4","5","6","7","8","9","0"
                  eee$=eee$+e$
                  end select
                  next i

                  'if the len of the incoming string is not correct then change it
                  'or forget it

                  e$=""
                  '8 -stellig eancodes auf 13 stellen richten
                  if len(eee$)=8 then
                  eee$="00000"+left$(eee$,8)
                  elseif len(eee$)=12 then
                  eee$="0"+left$(eee$,12)
                  else
                  eee$=string$(13-len(eee$),"0")+eee$
                  end if

                  'only if len=13 then exit function otherwise go on

                  if len(eee$)=13 then
                  ean$=eee$: eee$=""
                  funktion$="EAN"
                  sound 2500,1
                  '?ean$,funktion$
                  else
                  ?"wrong len ";eee$:stop 'error
                  end if
                  'else nicht n”tig da ean$ nicht belegt wird
                  wend

                  That sub worked over years with practial no errors.

                  Ask Lance for a command to tell windows that your dos-app is
                  very nessesary before and after the prog. He used it on his
                  PB-fax for dos.

                  Regards

                  Matthias Kuhn



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

                  Comment

                  Working...
                  X