Communication channels in Photon

Hi

I’m trying to send pulses from a non-photon application to a photon
application. In order to send the pulses using MsgPulseSend(), I need to
know the pid and channel id of the photon application. Is there a way to
find out what channel Photon is using?

The returns of PhGetConnectInfo() and PhGetConnectId() do not seem to be the
answer I need. It is also awkward for me to use the PtPulseArm to setup the
pulse and send it to the non-photon application. What I want to do is send
the channel ID to the non-photon application and let the non-photon
application to create the pulse. So all I need is the channel number Photon
is using.

Thanks.

Shouqin Huo
Quantum Magnetics

Shouqin Huo <huo@qm.com> wrote:

I’m trying to send pulses from a non-photon application to a photon
application. In order to send the pulses using MsgPulseSend(), I need to
know the pid and channel id of the photon application. Is there a way to
find out what channel Photon is using?

Yes, by calling PtChannelCreate(). But see below.

The returns of PhGetConnectInfo() and PhGetConnectId() do not seem to be the
answer I need. It is also awkward for me to use the PtPulseArm to setup the
pulse and send it to the non-photon application. What I want to do is send
the channel ID to the non-photon application and let the non-photon
application to create the pulse. So all I need is the channel number Photon
is using.

I don’t see why you find it awkward – the purpose of PtPulseArm() is
to produce a sigevent structure that can be given to another process and
used by that process with MsgDeliverEvent().

If you prefer using MsgPulseSend() instead of MsgDeliverEvent(), that’s
fine; but I would still recommend using PtPulseArm() to generate the
pulse code and value for you. This will allow you to use the pulse’s
“pid” to attach an input proc in the Photon application.

The alternative is to use a pulse code from the “avaliable for apps”
range and any value you wish, and attach your input proc to pid 0. The
advantage is that this lets you pass information in the pulse value; the
down side is that Photon offers you absolutely no help in allocating
unique pulse codes. This is not an issue if you know ahead of time how
many different pulse codes your app will possibly ever need, but can be
non-trivial if you’re writing a library and want it to co-operate with
other libraries nicely.

Oh, and there’s one other thing that you may or may not care about: an
input proc attached to a non-zero “pid” is slightly more efficient than
an input proc attached to pid zero, especially if you have many input
procs attached to pid zero.

Now I got the channel number by calling PtChannelCreate(). However, when I
sent the pulse using MsgPulseSend, the pulse was received by the sender, not
the receiver. This is very strange.

“Wojtek Lerch” <wojtek_l@yahoo.ca> wrote in message
news:b2167o$lt2$1@nntp.qnx.com

Shouqin Huo <> huo@qm.com> > wrote:
I’m trying to send pulses from a non-photon application to a photon
application. In order to send the pulses using MsgPulseSend(), I need to
know the pid and channel id of the photon application. Is there a way to
find out what channel Photon is using?

Yes, by calling PtChannelCreate(). But see below.

The returns of PhGetConnectInfo() and PhGetConnectId() do not seem to be
the
answer I need. It is also awkward for me to use the PtPulseArm to setup
the
pulse and send it to the non-photon application. What I want to do is
send
the channel ID to the non-photon application and let the non-photon
application to create the pulse. So all I need is the channel number
Photon
is using.

I don’t see why you find it awkward – the purpose of PtPulseArm() is
to produce a sigevent structure that can be given to another process and
used by that process with MsgDeliverEvent().

If you prefer using MsgPulseSend() instead of MsgDeliverEvent(), that’s
fine; but I would still recommend using PtPulseArm() to generate the
pulse code and value for you. This will allow you to use the pulse’s
“pid” to attach an input proc in the Photon application.

The alternative is to use a pulse code from the “avaliable for apps”
range and any value you wish, and attach your input proc to pid 0. The
advantage is that this lets you pass information in the pulse value; the
down side is that Photon offers you absolutely no help in allocating
unique pulse codes. This is not an issue if you know ahead of time how
many different pulse codes your app will possibly ever need, but can be
non-trivial if you’re writing a library and want it to co-operate with
other libraries nicely.

Oh, and there’s one other thing that you may or may not care about: an
input proc attached to a non-zero “pid” is slightly more efficient than
an input proc attached to pid zero, especially if you have many input
procs attached to pid zero.

Shouqin Huo <huo@qm.com> wrote:

Now I got the channel number by calling PtChannelCreate(). However, when I
sent the pulse using MsgPulseSend, the pulse was received by the sender, not
the receiver. This is very strange.

How are you creating the connection you’re sending the pulse to?

“Wojtek Lerch” <wojtek_l@yahoo.ca> wrote in message
news:b28dl6$a76$1@nntp.qnx.com

Shouqin Huo <> huo@qm.com> > wrote:
Now I got the channel number by calling PtChannelCreate(). However, when
I
sent the pulse using MsgPulseSend, the pulse was received by the sender,
not
the receiver. This is very strange.

How are you creating the connection you’re sending the pulse to?

First I called PtChannelCreate and PhChannelAttach. Then I send the channel

ID and pid to the non-photon application. The non-photon application first
uses the pid and channel id to create a connection id by calling
ConnectAttach(). After that, the pulses are generated by calling
MsgSendPulse().

I tested the mechanism with two non-photon applications. I got the same
results, i.e. the sender got the pulse, not the intended receiver. So it
seems I’m doing something wrong with the non-photon application.

Shouqin Huo <huo@qm.com> wrote:

“Wojtek Lerch” <> wojtek_l@yahoo.ca> > wrote in message
news:b28dl6$a76$> 1@nntp.qnx.com> …
Shouqin Huo <> huo@qm.com> > wrote:
Now I got the channel number by calling PtChannelCreate(). However, when
I
sent the pulse using MsgPulseSend, the pulse was received by the sender,
not
the receiver. This is very strange.

How are you creating the connection you’re sending the pulse to?

First I called PtChannelCreate and PhChannelAttach. Then I send the channel

PtChannelCreate and PhChannelAttach?

That’s not necessary. Both do the same thing. If you call
PhChannelAttach() after you have created a channel, it will either do
nothing and fail, or do nothing and succeed, depending on whether you
give it a conflicting channel or connection ID or not.

In a program that uses the Pt functions to read events from Photon, just
call PtChannelCreate(). PhChannelAttach() is meant for applications
that must create their own channel or use an unusual method of event
notification – but since we don’t really document how to do that
without breaking the Pt-level stuff, it’s only really safe in apps that
don’t use the Pt-level stuff.

ID and pid to the non-photon application. The non-photon application first
uses the pid and channel id to create a connection id by calling
ConnectAttach(). After that, the pulses are generated by calling
MsgSendPulse().

I tested the mechanism with two non-photon applications. I got the same
results, i.e. the sender got the pulse, not the intended receiver. So it
seems I’m doing something wrong with the non-photon application.

Right.

For the purpose of the test, the non-photon application doesn’t even
need to have a channel – have you tried a simple test where the Photon
app prints out its pid and channel ID, and you then pass them to the
non-Photon app on command line? If the non-Photon app doesn’t have a
channel, there’s no way the pulses will be sent to it, right?..

Thanks for all the help. I got it to work. The reason the non-photon
application got its own pulses back was that the connection was detached
inadvertently by the class destructor I’m using. (I had a class to manage
the pulse related things.)

“Wojtek Lerch” <wojtek_l@yahoo.ca> wrote in message
news:b2bcd9$at2$1@nntp.qnx.com

Shouqin Huo <> huo@qm.com> > wrote:
“Wojtek Lerch” <> wojtek_l@yahoo.ca> > wrote in message
news:b28dl6$a76$> 1@nntp.qnx.com> …
Shouqin Huo <> huo@qm.com> > wrote:
Now I got the channel number by calling PtChannelCreate(). However,
when
I
sent the pulse using MsgPulseSend, the pulse was received by the
sender,
not
the receiver. This is very strange.

How are you creating the connection you’re sending the pulse to?

First I called PtChannelCreate and PhChannelAttach. Then I send the
channel

PtChannelCreate and PhChannelAttach?

That’s not necessary. Both do the same thing. If you call
PhChannelAttach() after you have created a channel, it will either do
nothing and fail, or do nothing and succeed, depending on whether you
give it a conflicting channel or connection ID or not.

In a program that uses the Pt functions to read events from Photon, just
call PtChannelCreate(). PhChannelAttach() is meant for applications
that must create their own channel or use an unusual method of event
notification – but since we don’t really document how to do that
without breaking the Pt-level stuff, it’s only really safe in apps that
don’t use the Pt-level stuff.

ID and pid to the non-photon application. The non-photon application
first
uses the pid and channel id to create a connection id by calling
ConnectAttach(). After that, the pulses are generated by calling
MsgSendPulse().

I tested the mechanism with two non-photon applications. I got the same
results, i.e. the sender got the pulse, not the intended receiver. So it
seems I’m doing something wrong with the non-photon application.

Right.

For the purpose of the test, the non-photon application doesn’t even
need to have a channel – have you tried a simple test where the Photon
app prints out its pid and channel ID, and you then pass them to the
non-Photon app on command line? If the non-Photon app doesn’t have a
channel, there’s no way the pulses will be sent to it, right?..