TComPort problem.

[Andrew Stormdog]

Hello,

I'm trying to build a program which talks with a device using COM port. But
I can't to do even simplest things with it. For some reason, none of receive
events works and even manual ReadStr function doesn't return anything.
Though I know there is a response. I checked this using third-party tools.

The strangest thing is if I send multiple commands to the COM port(and each
command returns a response) and quit my test application, then open commspy
project(from codeproject, which using simple ReadFile\WriteFile commands) I
get ALL responses immediately.

I tried to play with Timeout parameters, but this doesn't help.

What am I doing wrong?

Best Regards,
Andrew

[John Herbster]

Post by Andrew Stormdog
I'm trying to build a program which talks
with a device using COM port. But
I can't to do even simplest things with it.

Andrew,
It sounds like you just need some examples
to get you started. In this package are some
http://cc.codegear.com/Item/23954
examples. I tend to use only the most basic
features of TComport. I am dropping a zip
of the source for a small receiver program into
the attachments forum for you. Look for
T_SerialRS232_3 071102.zip
Regards, JohnH

[Andrew Stormdog]

John,

Thank you very much!

With some modifications I was able to use your basic RS232 class in my
application and get correct responses...

May I contact your directly? I'd like to understand why do we need to wrap
TComPort in other classes and write code for functionality which should be
in TComPort according to its interfaces...

Thanks again,
Andrew

"John Herbster" <herb-sci1_AT_sbcglobal.net> ???????/???????? ? ????????

Post by John Herbster

Post by Andrew Stormdog
I'm trying to build a program which talks
with a device using COM port. But
I can't to do even simplest things with it.

Andrew,
It sounds like you just need some examples
to get you started. In this package are some
http://cc.codegear.com/Item/23954
examples. I tend to use only the most basic
features of TComport. I am dropping a zip
of the source for a small receiver program into
the attachments forum for you. Look for
T_SerialRS232_3 071102.zip
Regards, JohnH

[David J Taylor]

Post by Andrew Stormdog
John,
Thank you very much!
With some modifications I was able to use your basic RS232 class in my
application and get correct responses...
May I contact your directly? I'd like to understand why do we need to
wrap TComPort in other classes and write code for functionality which
should be in TComPort according to its interfaces...
Thanks again,
Andrew

John is always very helpful!

You don't need to wrap up TComPort, by the way, it works directly. It's
probably just finding the right way to drive it. I haven't seen John's
stuff, but it probably does that for you.

Cheers,
David

[Andrew Stormdog]

John,

I played a bit more with your example and need advice again...

The full description of my problem....

The device I need to communicate with always answers with status code for
any or my requests... Before using your code I just hooked up OnRxChar
event. It never fired up in my test project. Even if I did

ComPort.WriteStr(Command)
ComPort.ReadStr(Response);

Response was empty.

Now I see what your solution does basically the same thing like I did(with
two sequential calls). You just expanded ReadStr call to a similar code to
internals of TComThread. Am I right?


To complete the story I have to say that my device can initiate talk too
firing EV_RING event. This event is fired in my test application, but I
cannot use my test application with your solution, since they are
incompatible. You create an event and calls WaitFor function, but it fails,
because my TComPort already created an event to catch up EV_RING.

So how could I unite both solutions into one? And why you solution works
while simple WriteCommand/ReadResponse doesn't work?

Do I need to create a thread using your solution, which would wait for
EV_RING and be able to stop it if I need to send commands manually? Will
this work at all? What do you think?

Best Regards,
Andrew

Post by Andrew Stormdog
John,
Thank you very much!
With some modifications I was able to use your basic RS232 class in my
application and get correct responses...
May I contact your directly? I'd like to understand why do we need to wrap
TComPort in other classes and write code for functionality which should be
in TComPort according to its interfaces...
Thanks again,
Andrew
"John Herbster" <herb-sci1_AT_sbcglobal.net> ???????/???????? ? ????????

Post by John Herbster

Post by Andrew Stormdog
I'm trying to build a program which talks
with a device using COM port. But
I can't to do even simplest things with it.

Andrew,
It sounds like you just need some examples
to get you started. In this package are some
http://cc.codegear.com/Item/23954
examples. I tend to use only the most basic
features of TComport. I am dropping a zip
of the source for a small receiver program into
the attachments forum for you. Look for
T_SerialRS232_3 071102.zip
Regards, JohnH

[John Herbster]

Before using your code, I just hooked up OnRxChar
event. It never fired up in my test project. Even
if I did
ComPort.WriteStr(Command);
ComPort.ReadStr(Response);

Andrew,
I suggest that you add an OnRxChar event handler to
notify you of characters coming into the computer.
You can use a TTimer to let you know if the event
does not come within the expected time.
Regards, JohnH

[Andrew Stormdog]

John,

That was the first thing I did... But this event never fired up... That's
why I tried

Com.WriteStr(Command)
Com.ReadStr(Command)

This didn't work too, but your project worked, though it does basically the
same thing.

Might it be because reply comes in the following form?

CR LR Reply CR LF

Regards,
Andrew
"John Herbster" <herb-sci1_AT_sbcglobal.net> ???????/???????? ? ????????

Post by John Herbster

Before using your code, I just hooked up OnRxChar
event. It never fired up in my test project. Even
if I did
ComPort.WriteStr(Command);
ComPort.ReadStr(Response);

Andrew,
I suggest that you add an OnRxChar event handler to
notify you of characters coming into the computer.
You can use a TTimer to let you know if the event
does not come within the expected time.
Regards, JohnH

[John Herbster]

Post by Andrew Stormdog

Post by John Herbster
I suggest that you add an OnRxChar event handler to
notify you of characters coming into the computer.
You can use a TTimer to let you know if the event
does not come within the expected time.

That was the first thing I did... But this event
never fired. That's why I tried
Com.WriteStr(Command)
Com.ReadStr(Command)
This didn't work too, but your project worked,
though it does basically the same thing. Might
it be because reply comes in the following form?
CR LR Reply CR LF

Andrew,

(1) I suggest that you make a S/W model of your
hardware device or at least a simplified version
of it. Then you can have it running while you
test your control program. The S/W model can
show you every input byte and every output byte
along with the associated times. It will help in
your troubleshooting and understanding of
Comports.

Regarding your specific problem or problems,
(2) I suggest that read carefully the CLIB help
file on each of the properties in the TComponent.
(3) I also suggest that you add an OnError event
handler that will catch all errors and log them,
perhaps in a TMemo box.
(4) Check particularly the setting of property
SyncMethod and read about it in the help file.

After carefully doing the above, you will be
halfway to becoming a TComPort expert.

HTH, JohnH

[Andrew Stormdog]

John,

I did tried all steps except the 1 and still cannot understand where the
problem lies.

I'm tend to try step 1 ASAP, but I need to understand one thing first. If I
emulate my device I have to "listen" COM port, but my main or test
application has to "listen" this port too. How can I achieve this
simultaneously?

Regards,
Andrew

"John Herbster" <herb-sci1_AT_sbcglobal.net> ???????/???????? ? ????????

Post by John Herbster

Post by Andrew Stormdog

Post by John Herbster
I suggest that you add an OnRxChar event handler to
notify you of characters coming into the computer.
You can use a TTimer to let you know if the event
does not come within the expected time.

That was the first thing I did... But this event
never fired. That's why I tried
Com.WriteStr(Command)
Com.ReadStr(Command)
This didn't work too, but your project worked,
though it does basically the same thing. Might
it be because reply comes in the following form?
CR LR Reply CR LF

Andrew,
(1) I suggest that you make a S/W model of your
hardware device or at least a simplified version
of it. Then you can have it running while you
test your control program. The S/W model can
show you every input byte and every output byte
along with the associated times. It will help in
your troubleshooting and understanding of
Comports.
Regarding your specific problem or problems,
(2) I suggest that read carefully the CLIB help
file on each of the properties in the TComponent.
(3) I also suggest that you add an OnError event
handler that will catch all errors and log them,
perhaps in a TMemo box.
(4) Check particularly the setting of property
SyncMethod and read about it in the help file.
After carefully doing the above, you will be
halfway to becoming a TComPort expert.
HTH, JohnH

[John Herbster]

Post by Andrew Stormdog
I'm tend to try step 1 ASAP, but I need to understand
one thing first. If I emulate my device I have to "listen"
COM port, but my main or test application has to
"listen" this port too. How can I achieve this
simultaneously?

By using two comports with a cable connecting the two
ports as a "null modem". --JohnH

[Andrew Stormdog]

Ouch! It's impossible in my case. I'm working with virtual COM port, which
is emulated by device with USB interface. I tried this COM
monitor\interceptor
(http://www.serial-port-monitor.com/free-serial-port-monitor-product-details.html)
with my test application and few general COM applications, where I can enter
my commands and check the response and didn't find any difference in sending
commands, except TComPort never gets the response. Responses are accumulated
in COM "buffer" and I can see the device sent the response for each request
when re-connecting to COM port with these 3rdParty applications.

Thank you very much for your help.

Best Regards,
Andrew

"John Herbster" <herb-sci1_at_sbcglobal.net> ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ × ÎÏ×ÏÓÔÑÈ

Post by John Herbster

Post by Andrew Stormdog
I'm tend to try step 1 ASAP, but I need to understand
one thing first. If I emulate my device I have to "listen"
COM port, but my main or test application has to
"listen" this port too. How can I achieve this simultaneously?

By using two comports with a cable connecting the two
ports as a "null modem". --JohnH

[edbored]

Post by Andrew Stormdog
Ouch! It's impossible in my case. I'm working with virtual COM port, which
is emulated by device with USB interface. I tried this COM
monitor\interceptor

(http://www.serial-port-monitor.com/free-serial-port-monitor-product-details
.html)

Post by Andrew Stormdog
with my test application and few general COM applications, where I can enter
my commands and check the response and didn't find any difference in sending
commands, except TComPort never gets the response. Responses are accumulated
in COM "buffer" and I can see the device sent the response for each request
when re-connecting to COM port with these 3rdParty applications.
Thank you very much for your help.

Check out http://com0com.sourceforge.net/

"Null-modem emulator allows you to create an unlimited number of virtual COM
port pairs and use any pair to connect one COM port based application to
another. Each COM port pair provides two COM ports. The output to one port
is the input from other port and vice versa.
The Null-modem emulator can be used to provide serial interface for device
emulators. "

Might be something there to help you out.

EdB

[John Herbster]

Post by Andrew Stormdog
Ouch! It's impossible in my case. I'm working with
virtual COM port, which is emulated by device with
USB interface.

Andrew, Why is it impossible?
I sometimes use three comports, each emulated by
a USB to serial devices plugged into a USB hub.
Rgds, JohnH

[John Herbster]

... TComPort never gets the response.

Andrew,
Are you saying that you have a TComport component
with its OnRxChar connect to an RxChar event handler
and that event handler does *not* get executed?
Rgds, JohnH

[Andrew Stormdog]

John,

Post by John Herbster
Are you saying that you have a TComport component
with its OnRxChar connect to an RxChar event handler
and that event handler does *not* get executed?

Exactly. It never fires. I played with all TComPort properties, including
SyncMethod, Events, EventChar, etc. trying implicit and explicit
reading(OnRxChar, OnRxBuf, ReadStr), but never worked as it should. I can
control device writing to the port, but I cannot read from device(except by
means of your CodeCentral project, but your solution doesn't allow to read
COM port automatically without writing to it).

Regards,
Andrew

[David J Taylor]

Andrew Stormdog wrote:
[]

Post by Andrew Stormdog
Exactly. It never fires. I played with all TComPort properties,
including SyncMethod, Events, EventChar, etc. trying implicit and
explicit reading(OnRxChar, OnRxBuf, ReadStr), but never worked as it
should. I can control device writing to the port, but I cannot read
from device(except by means of your CodeCentral project, but your
solution doesn't allow to read COM port automatically without writing
to it).
Regards,
Andrew

It's not one of these stupid RS-232 things like having hardware or
software handshaking enabled, I suppose?

Cheers,
David

[John Herbster]

Post by Andrew Stormdog

Post by John Herbster
Are you saying that you have a TComport component
with its OnRxChar connect to an RxChar event handler
and that event handler does *not* get executed?

Exactly. It never fires.

Do you have the hardware wired correctly?
Can HyperTerm see the characters coming in?

Post by Andrew Stormdog
I played with all TComPort properties,
including SyncMethod, Events, EventChar,
etc. trying implicit and explicit reading
(OnRxChar, OnRxBuf, ReadStr), ...

I do not understand "implicit and explicit
reading".

Post by Andrew Stormdog
I can control device writing to the port,
but I cannot read from device(except by
means of your CodeCentral project,
but your solution doesn't allow to read
COM port automatically without writing
to it).

If you cannot read characters coming into
the port from your external device, your
are not ready to try my inside-out project.

I have posted yet another example project
"T_ComPort_Rcv_0"
for you to try in the attachments folder.

HTH, JohnH

[Andrew Stormdog]

It seems David is right and your project from attachment proves it. It was
my stupid mistake regarding special setting of FlowControl property. I
didn't pay enough attention to it before unfortunately.

Thank you guys!

Regards,
Andrew

"John Herbster" <herb-sci1_AT_sbcglobal.net> ???????/???????? ? ????????

Post by John Herbster

Post by Andrew Stormdog

Post by John Herbster
Are you saying that you have a TComport component
with its OnRxChar connect to an RxChar event handler
and that event handler does *not* get executed?

Exactly. It never fires.

Do you have the hardware wired correctly?
Can HyperTerm see the characters coming in?

Post by Andrew Stormdog
I played with all TComPort properties,
including SyncMethod, Events, EventChar,
etc. trying implicit and explicit reading
(OnRxChar, OnRxBuf, ReadStr), ...

I do not understand "implicit and explicit
reading".

Post by Andrew Stormdog
I can control device writing to the port,
but I cannot read from device(except by
means of your CodeCentral project,
but your solution doesn't allow to read
COM port automatically without writing
to it).

If you cannot read characters coming into
the port from your external device, your
are not ready to try my inside-out project.
I have posted yet another example project
"T_ComPort_Rcv_0"
for you to try in the attachments folder.
HTH, JohnH

[David J Taylor]

Post by Andrew Stormdog
It seems David is right and your project from attachment proves it.
It was my stupid mistake regarding special setting of FlowControl
property. I didn't pay enough attention to it before unfortunately.
Thank you guys!
Regards,
Andrew

Andrew,

Great! It took me back so many years trying to get RS-232 devices to work
together. Disabling all the flow control stuff was usually a starting
point. This when we used 25-pin connectors, and some were DCE and some
DTE. Some male and some female. We even had little breakout boxes with
LEDs showing which lines were active! You don't want to know, trust me!

Cheers,
David