I made a GUI by PhaB. It’s a simulator. It displays incoming information,
and generates outputs. To do this, I wrote a non-photon application (an IO
process) too, which does the communication with the I/O card (reads and
writes values to the port). The two process communicate via pulses and
Send/Receive/Reply messages. When there is something to display the IO
process sends a pulse to the GUI, the GUI does a Send to get the data and
displays it. It works fine. But I have a problem: till the GUI is waiting
for IO pulses it can’t handle user interactions: the user can’t push
buttons, generate outputs and can’t stop simulation.
Have somebody a good idea how to solve this problem?
Why not using an extra thread for the communication?
Of course, you should not use Photon calls in this thread
since Photon is not thread safe, but you can handle all
the IO in this extra thread and then buffer the information
for the Photon thread.
Do you use PtAppAddInput() to receive your pulses?
Why your app. is blocked for such a long time if you have
a ‘notify’ mechanism I would assume, the data is available?
cheers, peter
Polczer Eszter wrote:
Hi all!
I made a GUI by PhaB. It’s a simulator. It displays incoming information,
and generates outputs. To do this, I wrote a non-photon application (an IO
process) too, which does the communication with the I/O card (reads and
writes values to the port). The two process communicate via pulses and
Send/Receive/Reply messages. When there is something to display the IO
process sends a pulse to the GUI, the GUI does a Send to get the data and
displays it. It works fine. But I have a problem: till the GUI is waiting
for IO pulses it can’t handle user interactions: the user can’t push
buttons, generate outputs and can’t stop simulation.
Have somebody a good idea how to solve this problem?
“peter” <pw@_remove_inclusive_underscore_dolphin.de> wrote in message
news:bo59oe$1fs$1@inn.qnx.com…
Why not using an extra thread for the communication?
Of course, you should not use Photon calls in this thread
since Photon is not thread safe, but you can handle all
the IO in this extra thread and then buffer the information
for the Photon thread.
Do you think it is better to use an extra thread? Than I will try it that
way.
Do you use PtAppAddInput() to receive your pulses?
Should I use it? I used MsgReceivePulse() for that. Why is yours better?
Why your app. is blocked for such a long time if you have
a ‘notify’ mechanism I would assume, the data is available?
I have to read periodically (100ms), and examine if the data is valid or not
(there is a flag bit for it). And the whole 32 bit data is multiplexed, so I
have to read two times for one data. Blocked, becasue the IO thread should
have time to run. Or have you got a better idea?
Polczer, if you use MsgReceivePulse within you Photon GUI app.
you will of course block. The PtAppAddInput() hooks into the main
loop of Photon so, that you have a central point receiving Photon
draw events and your pulses (messages).
What I understand from your description is: You are polling the
IO process every 100ms and if a flag is set, the data is valid ?
Uhhh, sounds not so good.
Why your IO process sends a pulse if there is no valid data available ?
Polczer Eszter wrote:
“peter” <pw@_remove_inclusive_underscore_dolphin.de> wrote in message
news:bo59oe$1fs$> 1@inn.qnx.com> …
Why not using an extra thread for the communication?
Of course, you should not use Photon calls in this thread
since Photon is not thread safe, but you can handle all
the IO in this extra thread and then buffer the information
for the Photon thread.
Do you think it is better to use an extra thread? Than I will try it that
way.
Do you use PtAppAddInput() to receive your pulses?
Should I use it? I used MsgReceivePulse() for that. Why is yours better?
Why your app. is blocked for such a long time if you have
a ‘notify’ mechanism I would assume, the data is available?
I have to read periodically (100ms), and examine if the data is valid or not
(there is a flag bit for it). And the whole 32 bit data is multiplexed, so I
have to read two times for one data. Blocked, becasue the IO thread should
have time to run. Or have you got a better idea?
“peter” <pw@_remove_inclusive_underscore_dolphin.de> wrote in message
news:bo5dpl$439$1@inn.qnx.com…
Polczer, if you use MsgReceivePulse within you Photon GUI app.
you will of course block. The PtAppAddInput() hooks into the main
loop of Photon so, that you have a central point receiving Photon
draw events and your pulses (messages).
It sounds good. I will do it that way. Thanks!
What I understand from your description is: You are polling the
IO process every 100ms and if a flag is set, the data is valid ?
Uhhh, sounds not so good.
Sounds not so good, but I must do it that way. The data comes from a PLC, I
can’t rewrite it’s program. I’m polling the IO process every 100ms, because
I can’t loose any data. Better idea?
Why your IO process sends a pulse if there is no valid data available ?
No. The IO process doesn’t send any pulse if there is no valid data
avalibale.
Sounds not so good, but I must do it that way. The data comes from a PLC,
I
can’t rewrite it’s program. I’m polling the IO process every 100ms,
because
I can’t loose any data. Better idea?
Of course I’m pooling in every 100ms NOT the IO perocess! The IO process
polling the PLC port to determine if there is any valid data available.
It’s sound not so bad, isn’t it?
right sounds much better.
Your problems should be solved if you register a callback
via PtAppAddInput() and receive the pulse on ‘demand’.
Of course, if the IO proc fires the pulse and your GUI
fetches the data via MsgSend(), the IO proc. should
reply quickly.
happy polling, cheers, peter
Polczer Eszter wrote:
Sorry I made a mistake in my last letter:
Sounds not so good, but I must do it that way. The data comes from a PLC,
I
can’t rewrite it’s program. I’m polling the IO process every 100ms,
because
I can’t loose any data. Better idea?
Of course I’m pooling in every 100ms NOT the IO perocess! The IO process
polling the PLC port to determine if there is any valid data available.
It’s sound not so bad, isn’t it?
sounds much better.