Summary of Serial / Comm I/O problems

[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...

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

[Lance Edmonds]

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>

[Criss French]

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?!?!

[zoom kat]

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

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

[Tony Burcham]

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

[zoom kat]

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.

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

[Lance Edmonds]

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>

[Charlie Burnham]

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

[Matthias Kuhn]

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



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