COMM stuff 
Author Message
 COMM stuff

One of the main reasons for me getting PB/CC was the way it can handle com
ports in a Windows environment. The task at hand is to have 5 computers
communicate with a 6th device. Six com ports altogether. The 5 computers
will connect to this one system and see it as the 1 analyzer the software is
looking for. The analyzer has one com port and can handle 5 inputs rather
than the 1 the software looks for. I intend to utilize all 5 inputs to the
analyzer and output (emulate) the info to COM1 - COM5 appearing as only one
device. The emulation is flawless. It has been tested and written in
accordance with the manufacturers spec.s. Stand alone, all modules/subs are
working correctly. Combined, things get REAL weird.
1. Communication with the other systems gets intermittent and sketchy.
2. If communication is established, info is missing.
3. When only using one system (output), wait states or print statements must
be added to allow multi-threading otherwise no info is received from the
analyzer.
4. Pointers don't work the way they are explained. (This happens always)
5. When multi-threaded, connection info seems to get lost as well as
control.
6. Hopelessly locks up when heavily used. All info is lost. System must be
rebooted.
I have tried this on other systems with the same results. I'm extremely
disappointed and feel as if I may have to hire a professional to write it in
C++ or something else. Any input is welcome.


Thu, 16 Jan 2003 03:00:00 GMT  
 COMM stuff
What sort of serial card are you using on the server? or are you using multiple
cards ?
Quote:

> One of the main reasons for me getting PB/CC was the way it can handle com
> ports in a Windows environment. The task at hand is to have 5 computers
> communicate with a 6th device. Six com ports altogether. The 5 computers
> will connect to this one system and see it as the 1 analyzer the software is
> looking for. The analyzer has one com port and can handle 5 inputs rather
> than the 1 the software looks for. I intend to utilize all 5 inputs to the
> analyzer and output (emulate) the info to COM1 - COM5 appearing as only one
> device. The emulation is flawless. It has been tested and written in
> accordance with the manufacturers spec.s. Stand alone, all modules/subs are
> working correctly. Combined, things get REAL weird.
> 1. Communication with the other systems gets intermittent and sketchy.
> 2. If communication is established, info is missing.
> 3. When only using one system (output), wait states or print statements must
> be added to allow multi-threading otherwise no info is received from the
> analyzer.
> 4. Pointers don't work the way they are explained. (This happens always)
> 5. When multi-threaded, connection info seems to get lost as well as
> control.
> 6. Hopelessly locks up when heavily used. All info is lost. System must be
> rebooted.
> I have tried this on other systems with the same results. I'm extremely
> disappointed and feel as if I may have to hire a professional to write it in
> C++ or something else. Any input is welcome.



Fri, 17 Jan 2003 03:00:00 GMT  
 COMM stuff
This is really a parallel thread running in alt.lang.powerbasic

Quote:

>1. Communication with the other systems gets intermittent and sketchy.
>2. If communication is established, info is missing.
>3. When only using one system (output), wait states or print statements must
>be added to allow multi-threading otherwise no info is received from the
>analyzer.

This has to be in the design of your code, but unless we are able to
see the code, we are not able to offer anything more then general
suggestions.  
For example, I would suspect your code is not releasing timeslices to
the O/S, and therefore the COMM driver is probably being starved of
processor cycles.  

Quote:
>4. Pointers don't work the way they are explained. (This happens always)

This is clearly a problem in your code as pointers *work fine*...
using them correctly is another kettle of fish! (smile).  Problems can
easily happen when you use a pointer incorrectly.  For example, if a
function returns a pointer to a variable (or string) and that variable
(or string) is local to the Sub or Function returning the handle, then
by the time the calling code receives the pointer the LOCAL storage
for the variable has been released back to windows... this is one
certain way of guaranteeing a GPF.  If you have to return a variable
or string, then return the variable or string directly, rather than
returning a pointer.  

Alternatively, store the variable or string in a GLOBAL variable, and
then the pointer will remain valid after the Sub/Function terminates.
However, if two or more threads access the same data "simultaneously"
then you are going to get unpredictable "clashes" or "collisions" when
the same data is partically written at the point a context switch
(thread switch) occurs - at that point the data becomes "undefined"
until the data write is completed when the context switch reverts
back.  This type of problem is easily solved by using a
CRITICALSECTION around the code that reads or writes to the GLOBAL
variable.  This is difficult to explain, but a good programming book
like "Win32 Programming" (Rector/Newcomer) explain the theory in
detail and this book is worth it's weight in gold, especially if you
want to write bullet-proof Win32 code.

Quote:
>5. When multi-threaded, connection info seems to get lost as well as
>control.
>6. Hopelessly locks up when heavily used. All info is lost. System must be
>rebooted.

These are likely to be a combination of my answers above.

Quote:
>I have tried this on other systems with the same results. I'm extremely
>disappointed and feel as if I may have to hire a professional to write it in
>C++ or something else. Any input is welcome.

Don;t feel lost!  You are welcome to post your code here or email it
to Tech Support for a confidential overview... we will not write your
code for you, but we *may* be able identify potential problems with
your code, or suggest areas to work on.  The code will need to be in a
compilable state... snippets are often worthless for us to examine as
they do not tell the whole story).

I hope this helps.

Lance
PowerBASIC Support

-------------------------------------------------------------------------
PowerBASIC, Inc.      | 800-780-7707 Sales | "We put the Power in Basic!"
316 Mid Valley Center | 831-659-8000 Voice | http://www.powerbasic.com



Sat, 25 Jan 2003 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. POS Comm Port Stuff

2. Comm Ports over comm 10

3. problem with using the [::comm::comm send] command

4. FS/A: Cool rare SMALLTALK stuff, don't miss out, NeXT and BeOS stuff too

5. How can I ask LV to leave my design time stuff separate from runtime stuff

6. JSObject stuff & stuff

7. Latest Fortran stuff and other stuff

8. Using Comm ports in APL

9. watching comm ports

10. Linux/Unix Comm Port

11. CLACOM by GAP Comm.

12. Comm port access on NT

 

 
Powered by phpBB® Forum Software