Async Pro for serial communications

[Godfrey]

Hi All

I need to communicate with a petrol pump. I am using D2006 and Async Pro
but I cannot get a response
from the device. I am uograding an old dos package written in Turbo Pascal
which works well but is
just too outdated. I suspect that it may be something to do with the
Encoding(character set) the
format of the data send. Can anyone out there please advise me, give me
some examples.

Thanks
Godfrey

[Stephen Boyd]

If you go to the Async Pro area on sourceforge and download the latest
distribution there are example programs.

https://sourceforge.net/projects/tpapro

[Charles Collins]

If you're still looking for info, I have an old Delphi 5 project that polled
Gasboy (r) pumps on a serial com port and then forwarded the data for posting
to accts receivable on a mini computer via direct network connect, modem
dial up or internet connection. It was built with Asynch Pro, Raize components
and standard Delphi 5 stuff. I also made a fake gas pump program that communicated
from one PC to another via a straight through cable on the com ports. The
source may be incomplete, as I don't think the internet connection version
is on the backup I have.

[Godfrey]

I would be interested to have a look at your app. I will contact you by
email.

Is async pro the best comport component to use for this type of
communications? I have been told it is not
so good for comms where you run a loop polling muliple devices. It is
better for event driven comms.

Thanks
Godfrey

"Charles Collins" <cc...@houstonyellowcab.com> wrote in message
news:c793cc9d18e408...@newsgroups.borland.com...

[John Herbster]

"Godfrey" <none> wrote
> Is Async Pro the best comport component to use
> for [serial] communications?

> I have been told it is not so good for comms

> where you run a loop polling multiple devices.

Are you doing RS232 point-to-point or host-slave
multi-drop?

I prefer Dejan Crnila's TComport, because it is
(or was) updated as new OS's came about.

> It [AsyncPro?] is better for event driven comms.

For either point-to-point or multi-drop, I would
prefer to use event driven reception of the chars
and with timeouts to detect lost packets.

HTH, JohnH

[Charles Collins]

You should have the project.

As far as it goes, Async Pro is still supported by Sourceforge, and it was
reliable for my projects. I have it still, to do automated routines connecting
across networks to trigger events from PCs to the company's legacy mini.
Simple stuff, simple solution. Best of luck.

[Godfrey]

Hi John

>Are you doing RS232 point-to-point or host-slave
multi-drop?

It is more like a host-slave type of communication. I poll the pumps and
depending on what pump
I am addressing in the loop, that pump responds. The pump will only respond
if
it is addressed otherwise it just stays idle.

>I prefer Dejan Crnila's TComport, because it is
(or was) updated as new OS's came about.

I like the look of TComport but it does not seem to be updated anymore.

>For either point-to-point or multi-drop, I would
prefer to use event driven reception of the chars
and with timeouts to detect lost packets.

I am looking for more detailed examples using triggers and timeouts, do you
have any?

Thanks
Godfrey

[David J Taylor]

Godfrey wrote:
> Hi John
[]

> I like the look of TComport but it does not seem to be updated
> anymore.

[]
> Thanks
> Godfrey

Godfrey, it works very well on XP, so I would not be looking for any
updates. I've not had the chance or need to test on Vista, nor on Delphi
2007.

What sort of updates were you hoping for?

David

[Godfrey]

Hi David

Thanks for the prompt replys. I have not been on the delphi forums for a
while and it is nice to see that
there are still that same support as before. I am rambling on a bit off
topic, but due to the market I have
been forced to start using C# and sometimes I feel like I am going
backwards. There are so many things in Delphi
that I could do visually but in C# I either have to buy expensive components
or do it in code. Are there other
people out there who feel the same way. Go Delphi!

> What sort of updates were you hoping for?

I am not looking for any new features. I am starting a new app and I just
want a component that will be around for a while
and if I update my Delphi version, that it will be compatible. I am
currently using D2006.

Can you advise me on the best way to do this using TComport. I am sending 5
bytes to the pump and the pump responds
with 18 bytes back. I must then read a certain byte to check the status of
the pump and act on that. There can be up
to 32 pumps so I need a continous loop to keep checking for a status change.
There are diffent pump types which can
be faster or slower to respond to the communication.

Thanks
Godfrey

[John Herbster]

"Godfrey" <none> wrote

> I poll the pumps and depending on what pump I am addressing
> in the loop, that pump responds. The pump will only respond
> if it is addressed otherwise it just stays idle.

>>For either point-to-point or multi-drop, I would
>> prefer to use event driven reception of the chars
>> and with timeouts to detect lost packets.

> I am looking for more detailed examples using triggers and
> timeouts, do you have any?

Here is a sophisticated example:
_Inside-out programming for serial ports_
http://cc.codegear.com/Item/23954

Here below is the beginning of a simple example with a ComPort1
and a Timer1.

HTH, JohnH

Timer1 is not Enabled.
Define port state type maybe like this:
Type tPortState =
(psIdle, psXmitting, psWaitingResp, psReceiving);

procedure SetupAndStartTransmittingRequest:
If State <> psIdle then raise Error.
ClearReceiverBuffer;
Prep request string.
Set State to psXmitting; Start timer to wait for response in 200 milliseconds.
StartComportTransmission;
Exit;
end;

procedure Timer1.Timer();
Timer1.Enabled := false;
Case State of
psIdle: {nothing};
psXmitting: Log transmiting timeout;
psWaitingResp: Log no reception;
psReceiving:Log receiving timeout;
end;
end;

procedure Comport1.OnTransmitBufEmpty;
Set State to psWaitingResp; Start timer to wait for response in 300 milliseconds
end;

procedure Comport1.OnReceivedChars
For each received char:
Case State of
psXmitting, psWaitingResp:
If char signals beginning of message from pump
then State := psReceiving;
Set received buffer to first char.
psReceiving:
If char signals end of message from pump
then begin
Timer1.Enabled := false;
State := psIdle;
Process received message.
end
else accumulate char to received buffer.
end;
end;

[David J Taylor]

Godfrey wrote:
> Hi David
>
[]

> I am not looking for any new features. I am starting a new app and I
> just want a component that will be around for a while
> and if I update my Delphi version, that it will be compatible. I am
> currently using D2006.
>
> Can you advise me on the best way to do this using TComport.

[]
> Thanks
> Godfrey

Godfrey,

I've avoided C# and VB.net so far - thank goodness! The folk here remain
helpful and knowledgeable.

John H is the expert in TComPort - at least in my opinion - so I'll let
him answer your questions.

I would like to know if the TComPort component works with Vista (I see no
reason it should not), and whether it works with Delphi 2006 (for you) and
hence Delphi 2007 (for me).

Cheers,
David

[Benedictum]

Sorry to butt in. I have been using AsyncPro since D5 and now D2006. If you
know what type of response you get from the pumps, e.g. the startstring and
the endstring (or bytes) or the length of string, then using the
apdDataPacket is all you need. I use the combination of TapdComPort and
TapdDataPacket to poll RFID modules and these work very well.

"Godfrey" <none> wrote in message news:4877...@newsgroups.borland.com...

[John Herbster]

"Benedictum" <Bened...@dominusvobis.com> wrote
> Sorry to butt in. ...

Benedictum,

Thanks for your information.

> I have been using AsyncPro since D5 and now D2006.

Now, who knows about AsyncPro with D2007?
And, about Dejan's TComport with D2007?

Rgds, JohnH

[-]

> Now, who knows about AsyncPro with D2007?

I use it in several programs without any troubles.

Mark

[Godfrey]

Hi

I have not done much work on serail comms and need some pointers.

There is a RS232 link to an interface box and from the interface box is a
current loop to the pumps. I send
a string of 5 bytes to the pump(includes the pump number) starting with #00
and ending with #FF. Because this is a current loop I get
an echo back (same 5 bytes I sent) together with a 13 byte message which
also starts with #00 and ends with #FF. This
means, I cannot use the start and end byte as there are duplicates. I could
use the length which I have tried successfully.

My problem comes in with timing. I have tried running a loop in a separate
thread and communicating with the pumps
in the loop but I am battling to get a answer from the pumps for each
loop(pump number). I think my timing may be a problem.

Any suggestions would be welcome. Code examples would be greatly
appreciated.

Thanks
Godfrey

"Benedictum" <Bened...@dominusvobis.com> wrote in message
news:4879...@newsgroups.borland.com...

[Benedictum]

You do not need multithreaded loops. All you have to do is insert a delay in
a loop. Play with the numbers. write an empty loop to create a delay, e.g.
For i:=1 to n do; // nothing play with n.
--B

"Godfrey" <none> wrote in message news:487a...@newsgroups.borland.com...

[Benedictum]

Just install AsyncPro to D2007. Should be no problem.

"John Herbster" <herb-sci1_AT_sbcglobal.net> wrote in message
news:4879e7c3$1...@newsgroups.borland.com...

[Godfrey]

The pump comms need to carry on in the backround while the operator
continues to use the form. The best way I would think, is to create a
separate
thread for the comms. The only problem is to get everything to work.

Thanks
Godfrey

"Benedictum" <Bened...@dominusvobis.com> wrote in message

news:487b...@newsgroups.borland.com...

[Stephen Boyd]

With AsyncPro you really shouldn't need to write loops at all. APro was
designed to be event driven. It usually works best in this mode. When
I use Apro I generally implement the program as a state machine and wait
for APro events or timers to change from one state to another.

[Godfrey]

Hi stephen

Could you post me an example. How do you communicate with multiple devices
without
using a loop? Each device has a unique id.

Thanks
Godfrey

"Stephen Boyd" <sboy...@gmail.com> wrote in message
news:487b6377$1...@newsgroups.borland.com...

[Stephen Boyd]

Godfrey wrote:
> Hi stephen
>
> Could you post me an example. How do you communicate with multiple devices
> without
> using a loop? Each device has a unique id.
>
>

Multiple devices on one com port or multiple com ports?

[Godfrey]

I need to communicate with multiple devices from one comm port. Each device
has its
own unique ID number. I need to poll then continuosly looking for a change
in status.
If there is a change in status I must act on that, which could mean a
further request
for information before continuing polling.

"Stephen Boyd" <sboy...@gmail.com> wrote in message

news:487b8e2f$1...@newsgroups.borland.com...

[Stephen Boyd]

Godfrey wrote:
>>> Hi stephen
>>>
>>> Could you post me an example. How do you communicate with multiple
>>> devices without
>>> using a loop? Each device has a unique id.
>>>
>>>
>> Multiple devices on one com port or multiple com ports?
>
>

I have placed a sample program on my FTP site.

ftp://ftp.lnssoftware.ca/apro/example.zip

It isn't exactly your situation but it shows how I use triggers and
events to drive a state machine.