BX-35 using Com3 on multiple lines

Started by Bob Roos April 6, 2004
I am having a bit of a difficulty using Com3 to talk to more than 1 serial
device at the same (sort of) time.

The devices I am trying to communicate with only speak when spoken to.
There are no unsolicited responses.

I define the comport and then open it for the new line:

If XmitPin <> LastUsedOutputPin then
' If we are not reusing the same pin close old and open new
If LastUsedOutputPin <> 0 then
' skip this the first time in
Call WaitForClearedBuffer
Call CloseCom(3,InputBuffer,OutputBuffer)
End If

' open new comport for output
LastUsedOutputPin = XmitPin
LastUsedInputPin = RcvPin
Call DefineCom3(RcvPin,XmitPin,bx00001000)
Call OpenQueue(InputBuffer,InputBufferSize)
Call OpenQueue(OutputBuffer, OutputBufferSize)
Call OpenCom(3, 19200, InputBuffer, OutputBuffer)
Else
Call WaitForClearedBuffer
' using the same com pins as last time
End If

do the output

wait for cleared buffer

get response (1st time for new buffers is timeout. I don't think the
first output really went out)

----

The first output after this always gives me a timeout on the response. If
I just put out 1 byte (my normal stream is 7) and then to the normal 7 it
seems to work OK.

Am I missing something in the output setup? Even before I started
switching lines the first output gave me an error, but I didn't care then
because it would get repeated. Now I care!

Thanks,

Bob Roos




From: Bob Roos <>

> I am having a bit of a difficulty using Com3 to talk
> to more than 1 serial device at the same (sort of)
> time.
>
> [...]
>
> If LastUsedOutputPin <> 0 then
> ' skip this the first time in
> Call WaitForClearedBuffer
> Call CloseCom(3,InputBuffer,OutputBuffer)
> End If
>
> ' open new comport for output
> LastUsedOutputPin = XmitPin
> LastUsedInputPin = RcvPin
> Call DefineCom3(RcvPin,XmitPin,bx00001000)
> Call OpenQueue(InputBuffer,InputBufferSize)
> Call OpenQueue(OutputBuffer, OutputBufferSize)
> Call OpenCom(3, 19200, InputBuffer, OutputBuffer)
> [...]

One concern is what happens if LastUsedOutputPin is not zero. If
that's true, CloseCom is not called. The question is whether the
port is still open at that point.

You next redefine the I/O pins, which is OK, even if the port is
open. But next you open both queues, which could be an issue. I
could see where a problem might occur here if the port is still
open.

In other words, you don't want to re-open either of the queues
while a port is open.

If the port is not open when you open the queues, then ignore
this message...

-- Frank Manning
-- NetMedia, Inc.



Sorry to jump in but I am soon trying something similar.
Frank, Are you saying there needs to be a timeout
or another close fuction (which I am not aware of)
to be sure the port is closed?

thank you for the breaker 1-9
Don Lewis

--- In , "Frank Manning" <fmanning@n...> wrote:
> From: Bob Roos <roosbob@w...>
>
> > I am having a bit of a difficulty using Com3 to talk
> > to more than 1 serial device at the same (sort of)
> > time.
> >
> > [...]
> >
> > If LastUsedOutputPin <> 0 then
> > ' skip this the first time in
> > Call WaitForClearedBuffer
> > Call CloseCom(3,InputBuffer,OutputBuffer)
> > End If
> >
> > ' open new comport for output
> > LastUsedOutputPin = XmitPin
> > LastUsedInputPin = RcvPin
> > Call DefineCom3(RcvPin,XmitPin,bx00001000)
> > Call OpenQueue(InputBuffer,InputBufferSize)
> > Call OpenQueue(OutputBuffer, OutputBufferSize)
> > Call OpenCom(3, 19200, InputBuffer, OutputBuffer)
> > [...]
>
> One concern is what happens if LastUsedOutputPin is not zero. If
> that's true, CloseCom is not called. The question is whether the
> port is still open at that point.
>
> You next redefine the I/O pins, which is OK, even if the port is
> open. But next you open both queues, which could be an issue. I
> could see where a problem might occur here if the port is still
> open.
>
> In other words, you don't want to re-open either of the queues
> while a port is open.
>
> If the port is not open when you open the queues, then ignore
> this message...
>
> -- Frank Manning
> -- NetMedia, Inc.




Whoa! Frank is still here ... Good. ;-)

But - the NetMedia web pages look very out of date (BX-35??? SitePlayer
internal language or serial connection???) and email to support (basically
probing to see if there's still life) goes unanswered.

Be nice if the News pages could be updated with current status.

Cheers,
James


On Tue, 6 Apr 2004 12:39:41 -0700, Frank Manning <>
wrote:

> From: Bob Roos <>
>
>> I am having a bit of a difficulty using Com3 to talk
>> to more than 1 serial device at the same (sort of)
>> time.
>>
>> [...]
>>
>> If LastUsedOutputPin <> 0 then
>> ' skip this the first time in
>> Call WaitForClearedBuffer
>> Call CloseCom(3,InputBuffer,OutputBuffer)
>> End If
>>
>> ' open new comport for output
>> LastUsedOutputPin = XmitPin
>> LastUsedInputPin = RcvPin
>> Call DefineCom3(RcvPin,XmitPin,bx00001000)
>> Call OpenQueue(InputBuffer,InputBufferSize)
>> Call OpenQueue(OutputBuffer, OutputBufferSize)
>> Call OpenCom(3, 19200, InputBuffer, OutputBuffer)
>> [...]
>
> One concern is what happens if LastUsedOutputPin is not zero. If
> that's true, CloseCom is not called. The question is whether the
> port is still open at that point.

Hi Frank, I think you mean "is zero"?

LastUsedOutputPin is initially 0 so that the wait and close are skipped
once. After that LUOP is set to the pin number actually used for output.
I just double checked the code and I do specifically initialize it to 0
;-) I put the check for LUOP in there so that I could skip the close and
open if the output was to be on the same pin as before.
>
> You next redefine the I/O pins, which is OK, even if the port is
> open. But next you open both queues, which could be an issue. I
> could see where a problem might occur here if the port is still
> open.
>
> In other words, you don't want to re-open either of the queues
> while a port is open.

What if I make up 3 queues (I have 3 lines) and use CASE logic to decide
which one to use. Maybe I don't need to close a queue (there is not such
thing is there?) or re-open the same one for a different line.

>
> If the port is not open when you open the queues, then ignore
> this message...

as far as I know the port is closed because LUOP is non zero after the
first time. Also I get the same condition the very first time I try to
output to com3. After that it works fine until I try to change pins.

I can try putting all the opens and closes for the 2 lines in straight
line code so that there are no other conditions that could be involved.

I am lost (can you tell?).

Bob
>
> -- Frank Manning
> -- NetMedia, Inc.



From: Don Lewis <>

> Are you saying there needs to be a timeout
> or another close fuction (which I am not
> aware of) to be sure the port is closed?

No, I'm saying you should not open I/O queues if a port is
already open.

But it was a moot point in this particular case, because the port
was closed, if I understand it correctly.

-- Frank Manning
-- NetMedia, Inc.


From: Bob Roos <>

>> One concern is what happens if LastUsedOutputPin
>> is not zero. [...]
>>
> I think you mean "is zero"?

Right. My error.

-- Frank Manning
-- NetMedia, Inc.



From: James Mansion <>

> But - the NetMedia web pages look very out of date

I shall inform our web guy.

-- Frank Manning
-- NetMedia, Inc.


I have it running! I found 2 things.

1) I think I may have been short of RAM. I noticed that sometimes a
constant was clipped in the debug.print. When I went to multiple buffers
it became very clear I was out of RAM.

2) I increased my SLEEP time before checking the queue:

Sleep(5)
If (GetQueueCount(OutputBuffer) > 0) ' wait for clearing of the buffer
....

Calculate the sleep time before checking the queue count (512 *
(2+8*BYTES)/ 9600 baud) + a couple of fudge ticks

When I applied this to the program it all worked perfectly.

Bob


From: Bob Roos <>

> I have it running! I found 2 things.

Glad to hear it.

> 1) I think I may have been short of RAM. I noticed
> that sometimes a constant was clipped in the
> debug.print. When I went to multiple buffers it
> became very clear I was out of RAM. [...]

One thing that could help make memory use more efficient is to
use local variables instead of static variables for I/O queues.

In other words, rather than put queues in module-level code, put
them inside a procedure. While you're inside the procedure, open
the port, do whatever I/O is required, then close the port.

When the procedure returns, all that memory taken up by the
queues is reclaimed by the system and is made available for other
uses.

One caution -- if you do this, you have to be very careful to
close the port before returning from the procedure. Otherwise the
OS may try to write to queues that don't exist any more, and you
may crash the program.

-- Frank Manning
-- NetMedia, Inc.