[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: RE: xAP and JMRI naming
--------------040201050404080107070905
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
This is pretty workable I think.. although it is kinda NWE controller
centric and other controllers have differing addressing flexibilities.
I made a couple of comments inserted below that particularly relate to
this - including supporting named sub addresses. It's hard to convey
what I'm meaning here but for flexibility I am not sure the section name
(Catskill) should only be matched against a segment within the main
source address but should alternatively be an allowed match against a
sub address segment... This then permits multiple xAP controllers for
one section or several different sections using one controller which I
think might be a frequent need.
On 17/03/2010 11:53, Neil Wrightson wrote:
>
> Hi Kevin,
>
> How does this look?
>
> The uid used in the heart beats should be something like FF123400.
> Where FF
> and 00 are delimiters.
> *** With the above set and a valid IP address, I get valid JMRI
heartbeats
> in the xAP (xFx) message viewer. (I'm running winodws XP) ***
>
> I have not done to much with the JMRI application yet.
> So bare with me.
> I (NWE) have made a Interface PCB that has 8 inputs and 8 outputs.
This
> connects to the LAN and uses xAP as the protocol.
> Prior to attempting to interface the hardware to JMRI. The interface
card
> would be given the following configuration
> - UID = 1234 (Full UID would look as per
> above i.e. FF123400)
>
Only point here is that you used 1234 for JMRI so it couldn't be the
same here for the interface card
>
> - xAP instance ID= "CatsKill" (I borrowed this name from a
> tutorial on the JMRI site)
>
> To select a turnout you would use the following style of naming
convention
> target=NWE.MultiIO.Catskill
> Where "NWE" is the manufacturer of the interface card that
has all
> of the inputs & outputs (Cannot be changed)
> Where "MultiIO" is the model of the interface card
> (Cannot be changed)
> Where "CatsKill" is the system name given to this actual
interface
> card by the user.
>
> Now if I had a passing siding at the Catskill section of track. It
> would be
> configured as -
> Northern Turnout - "xAPT.Catskill.1" Where OP1 = Relay
Output 1
> on the interface card
> Southern Turnout - "xAPT.Catskill.2" Where OP2 = Relay
Output 2
> on the interface card
>
Does JMRI require and enforce this dot notation and three levels or is
that your suggestion ? It's a leading question for something I raise
later ;-)
>
> Because the turnout had a prefix of xAP, JMRI would know to send the
> command
> via the xAP interface and specifically targeting the
"Catskill" interface.
>
Is it actually specifically the Catskill xAP interface or the Catskill
segment of track ? One of your interface cards might be servicing
several sections of track - not just Catskill or several controllers be
used for one section so you might need some flexibility here in naming
within JMRI for sharing/aliasing different section names to controllers
. Maybe more usefully you could allow the 'catskill' segment to be
substituted in the sub address which would then support this flexibility
, if you can name sub addresses on your controller ? Not all
controllers can.
target=NWE.MultiIO.instance:CatsKill.>
target=NWE.MultiIO.instance:DogBite.>
target=ACME.Control.instance:Catskill.>
>
>
> Now if there were a panel button that either selected the mainline or
> passing siding. The system would send a message to change both points
at
> once.
> So then I thought we could decode this into the following message.
>
> {
> v=12
> hop=1
> uid=FF123400
> class=xAPBSC.cmd
> source=JMRI.DecoderPro.Central { Note the source name, I think
something
> like this would be appropriate. Perhaps the "Central" bit
editable}
> target=NWE.MultiIO.CatsKill:>
> }
> output.state.1 { This is just a sequential command
> number }
> {
> ID=01 { Northern turnout } {Note
> these are hexadecimal numbers }
> State=ON { Select passing siding }
> }
> output.state.2
> {
> ID=02 { Southern turnout }
> State=ON { Select passing siding }
> {Note - if set to OFF the points would be set for straight through
(Main
> Line) }
> }
>
That works well. In order to build that target line I assume somewhere
in JMRI your are configuring a mapping between Catskill and
"NWE.MultIO"
or is it "NWE.MultIO.Catskill:>" perhaps ? Just wondering
where the
'Catskill' in that target address actually derives from - is it the
mapping or from the turnout naming ?
If it's from the turnout name then you might need more flexibility in
how you name these turnouts within JMRI (hence the earlier question) as
some xAP devices have more addressing segments to the left of the : and
also it might be wise to include the > in the turnout name rather than
forcibly appending it later ... then users could instead opt to use the
full (not wildcarded) name which will speed address matching. Hmmm..
maybe you require the addresses be wildcarded in order to issue
concatenated commands like the example above. There may also be some
BSC devices that don't implement wildcarding although I don't actually
know of any.
>
> So now that the train is moving into the passing siding, the a train
> sensor
> picks up the loco. This changes an input IP1 on the interface card.
> The interface card then broadcasts the following xAP message to the
> network.
>
> {
> v=12
> hop=1
> uid=FF123409 { Note the 09 at the end. This is the first
> input. 01..08 are the outputs } {Again this is a hexadecimal number
> string}
> class=xAPBSC.event
> source=NWE.MultiIO.CatsKill:IP1
> }
> input.state
> {
> State=ON { Train detected }
> }
>
> Use the uid i.e. FF123409 as the actual address to link to the sensor
> "xAPS.Catskill.9"
> Another example would be FF12340A as the actual address to link to the
> sensor "xAPS.Catskill.10" Note the conversion from hex
"0A" to ".10"
>
> Thoughts??
>
This is elegant in its simplicity but has that restriction that you are
again requiring 'Catskill' in the main address portion - i.e.
restricting to one controller per section and one section per controller
and so it might be better to allow it optionally to be in the sub
address portion . However this would then make the incoming
xapbsc.event parsing more difficult as it would not obvious where the
section name is located (in the sub address or main address - and main
might have several segments eg acme.controller.rail.catskill.system).
I'll think a little more....
> Doable ???
>
It's very close ...
>
>
> Regards,
>
> Neil Wrightson.
> N.W.Electronics
> ABN 76 768 513 867
> Embedded Controllers and Home Automation Products
> Web : www.nwe.net.au
>
> >>-----Original Message-----
> >>From: Bob Jacobsen [mailto:jacobsen@xxxxxxx
> <mailto:jacobsen%40berkeley.edu>]
> >>Sent: Wednesday, 17 March 2010 2:35 AM
> >>To: Automation; Neil Wrightson
> >>Subject: xAP and JMRI naming
> >>
> >>I think we're pretty close to getting the xAP connection to
> >>work, so it's time to start thinking about the next step in
> >>connecting JMRI and xAP.
> >>
> >>Normally, when connecting JMRI and external systems, we
> >>connect status messages from the system to
"Sensors", and use
> >>"Turnouts" to send status change commands to the
external system.
> >>
> >>Using the Insteon control system as an example, when we see a
> >>status report on Insteon address 12.34.56, we create a JMRI
> >>sensor with the name PS12.34.56 that matches that status.
> >>Another Insteon unit with address 45.A3.11 will get matched
> >>to a JMRI sensor called PS45.A3.11, etc. All the JMRI tools
> >>then interact with those. You can give them simpler user
> >>names, set options with them, etc. Similarly for outputs,
> >>where the names are PTsomething.
> >>
> >>So what's the corresponding thing for an xAP name?
> >>
> >>xap-hbeat
> >>{
> >>source=JMRI.test.1
> >>interval=60
> >>port=10000
> >>hop=1
> >>v=12
> >>uid=FFFFFFFF
> >>class=xap-hbeat.alive
> >>}
> >>
> >>I can construct a name string from this entire message (class,
uid,
> >>source, etc) but is that all needed? Or is just
"source"
> >>sufficient?
> >>Or perhaps source+class?
> >>
> >>If we can get a trace of a xAP installation doing something,
> >>perhaps that'll help us figure out what a convenient, but
> >>sufficiently powerful, name convention would be.
> >>
> >>Bob
>
>
--------------040201050404080107070905
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<head>
<style type="text/css">
<!--
/* start of attachment style */
.ygrp-photo-title{
clear: both;
font-size: smaller;
height: 15px;
overflow: hidden;
text-align: center;
width: 75px;
}
div.ygrp-photo{
background-position: center;
background-repeat: no-repeat;
background-color: white;
border: 1px solid black;
height: 62px;
width: 62px;
}
div.photo-title
a,
div.photo-title a:active,
div.photo-title a:hover,
div.photo-title a:visited {
text-decoration: none;
}
div.attach-table div.attach-row {
clear: both;
}
div.attach-table div.attach-row div {
float: left;
/* margin: 2px;*/
}
p {
clear: both;
padding: 15px 0 3px 0;
overflow: hidden;
}
div.ygrp-file {
width: 30px;
valign: middle;
}
div.attach-table div.attach-row div div a {
text-decoration: none;
}
div.attach-table div.attach-row div div span {
font-weight: normal;
}
div.ygrp-file-title {
font-weight: bold;
}
/* end of attachment style */
-->
</style>
</head>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<!-- **begin egp html banner** -->
<br><br>
<!-- **end egp html banner** -->
This is pretty workable I think.. although it is kinda
NWE controller
centric and other controllers have differing addressing
flexibilities.
I made a couple of comments inserted below that particularly
relate to
this - including supporting named sub addresses. It's
hard to convey
what I'm meaning here but for flexibility I am not sure the section
name (Catskill) should only be matched against a segment within the
main source address but should alternatively be an allowed match
against a sub address segment... This then permits multiple xAP
controllers for one section or several different sections using one
controller which I think might be a frequent need.<br>
<br>
On 17/03/2010 11:53, Neil Wrightson wrote:
<blockquote
cite="mid:B905174A0F204EA0BBD73EB3C1B49F10@xxxxxxx"
type="cite"><span style="display:
none;"> </span>
<div id="ygrp-text">
<p>Hi Kevin,<br>
<br>
How does this look?<br>
<br>
The uid used in the heart beats should be something like FF123400.
Where FF<br>
and 00 are delimiters.<br>
*** With the above set and a valid IP address, I get valid JMRI
heartbeats<br>
in the xAP (xFx) message viewer. (I'm running winodws XP) ***<br>
<br>
I have not done to much with the JMRI application yet.<br>
So bare with me.<br>
I (NWE) have made a Interface PCB that has 8 inputs and 8 outputs.
This<br>
connects to the LAN and uses xAP as the protocol.<br>
Prior to attempting to interface the hardware to JMRI. The interface
card<br>
would be given the following configuration<br>
- UID = 1234 (Full UID would look as per<br>
above i.e. FF123400)<br>
</p>
</div>
</div>
</div>
</blockquote>
Only point here is that you used 1234 for JMRI so it couldn't be the
same here for the interface card<br>
<blockquote
cite="mid:B905174A0F204EA0BBD73EB3C1B49F10@xxxxxxx"
type="cite">
<div id="ygrp-mlmsg" style="position: relative;">
<div id="ygrp-msg" style="z-index: 1;">
<div id="ygrp-text">
<p> - xAP instance ID= "CatsKill" (I borrowed this name
from a<br>
tutorial on the JMRI site)<br>
<br>
To select a turnout you would use the following style of naming
convention<br>
target=NWE.MultiIO.<wbr>Catskill<br>
Where "NWE" is the manufacturer of the interface card that has
all<br>
of the inputs & outputs (Cannot be changed)<br>
Where "MultiIO" is the model of the interface card<br>
(Cannot be changed)<br>
Where "CatsKill" is the system name given to this actual
interface<br>
card by the user. <br>
<br>
Now if I had a passing siding at the Catskill section of track. It
would be<br>
configured as -<br>
Northern Turnout - "xAPT.Catskill.<wbr>1" Where OP1 = Relay
Output 1<br>
on the interface card<br>
Southern Turnout - "xAPT.Catskill.<wbr>2" Where OP2 = Relay
Output 2<br>
on the interface card <br>
</p>
</div>
</div>
</div>
</blockquote>
<br>
Does JMRI require and enforce this dot notation and three levels or is
that your suggestion ? It's a leading question for something I raise
later ;-)<br>
<p><wbr></p>
<blockquote
cite="mid:B905174A0F204EA0BBD73EB3C1B49F10@xxxxxxx"
type="cite">
<div id="ygrp-mlmsg" style="position: relative;">
<div id="ygrp-msg" style="z-index: 1;">
<div id="ygrp-text">
<p><br>
Because the turnout had a prefix of xAP, JMRI would know to send the
command<br>
via the xAP interface and specifically targeting the "Catskill"
interface.<br>
</p>
</div>
</div>
</div>
</blockquote>
Is it actually specifically the Catskill xAP interface or the Catskill
segment of track ? One of your interface cards might be servicing
several sections of track - not just Catskill or several
controllers
be used for one section so you might need some flexibility here in
naming within JMRI for sharing/aliasing different section names
to
controllers . Maybe more usefully you could
allow the 'catskill'
segment to be substituted in the sub address which would then support
this flexibility , if you can name sub addresses on your controller
?
Not all controllers can.<br>
<br>
target=NWE.MultiIO.instance:CatsKill.><br>
target=NWE.MultiIO.instance:DogBite.><br>
target=ACME.Control.instance:Catskill.><br>
<blockquote
cite="mid:B905174A0F204EA0BBD73EB3C1B49F10@xxxxxxx"
type="cite">
<div id="ygrp-mlmsg" style="position: relative;">
<div id="ygrp-msg" style="z-index: 1;">
<div id="ygrp-text">
<p><br>
Now if there were a panel button that either selected the mainline
or<br>
passing siding. The system would send a message to change both points
at<br>
once.<br>
So then I thought we could decode this into the following
message.<br>
<br>
{<br>
v=12<br>
hop=1<br>
uid=FF123400<br>
class=xAPBSC.<wbr>cmd<br>
source=JMRI.<wbr>DecoderPro.<wbr>Central { Note the source
name, I
think something<br>
like this would be appropriate. Perhaps the "Central" bit
editable}<br>
target=NWE.MultiIO.<wbr>CatsKill:<wbr>><br>
}<br>
output.state.<wbr>1 { This is just a sequential command<br>
number }<br>
{<br>
ID=01 { Northern turnout } {Note<br>
these are hexadecimal numbers }<br>
State=ON { Select passing siding }<br>
}<br>
output.state.<wbr>2<br>
{<br>
ID=02 { Southern turnout }<br>
State=ON { Select passing siding }<br>
{Note - if set to OFF the points would be set for straight through
(Main<br>
Line) }<br>
}<br>
</p>
</div>
</div>
</div>
</blockquote>
<br>
That works well. In order to build that target line I assume
somewhere
in JMRI your are configuring a mapping
between Catskill and "NWE.MultIO" or is it
"NWE.MultIO.Catskill:>"
perhaps ? Just wondering where the 'Catskill' in that
target address actually derives from - is it the mapping or from the
turnout naming ? <br>
<br>
If it's from the turnout name then you might need more
flexibility in
how you name these turnouts within JMRI (hence the earlier question) as
some xAP devices have more addressing segments to the left of the : and
also it might be wise to include the > in the turnout name rather
than forcibly appending it later ... then users could instead opt to
use the full (not wildcarded) name which will speed address
matching.
Hmmm.. maybe you require the addresses be wildcarded in order to issue
concatenated commands like the example above. There may also be
some
BSC devices that don't implement wildcarding although I don't actually
know of any. <br>
<br>
<blockquote
cite="mid:B905174A0F204EA0BBD73EB3C1B49F10@xxxxxxx"
type="cite">
<div id="ygrp-mlmsg" style="position: relative;">
<div id="ygrp-msg" style="z-index: 1;">
<div id="ygrp-text">
<p><br>
So now that the train is moving into the passing siding, the a train
sensor<br>
picks up the loco. This changes an input IP1 on the interface
card.<br>
The interface card then broadcasts the following xAP message to the
network.<br>
<br>
{<br>
v=12<br>
hop=1<br>
uid=FF123409 { Note the 09 at the end. This is the first<br>
input. 01..08 are the outputs } {Again this is a hexadecimal number
string}<br>
class=xAPBSC.<wbr>event<br>
source=NWE.MultiIO.<wbr>CatsKill:<wbr>IP1<br>
}<br>
input.state<br>
{<br>
State=ON { Train detected }<br>
}<br>
<br>
Use the uid i.e. FF123409 as the actual address to link to the
sensor<br>
"xAPS.Catskill.<wbr>9"<br>
Another example would be FF12340A as the actual address to link to
the<br>
sensor "xAPS.Catskill.<wbr>10" Note the conversion from hex
"0A" to
".10"<br>
<br>
Thoughts??<br>
</p>
</div>
</div>
</div>
</blockquote>
This is elegant in its simplicity but has that restriction that you are
again requiring 'Catskill' in the main address portion - i.e.
restricting to one controller per section and one section per
controller and so it might be better to allow it optionally to be in
the sub address portion . However this would then make the
incoming
xapbsc.event parsing more difficult as it would not obvious where
the
section name is located (in the sub address or main
address - and
main might have several segments eg
acme.controller.rail.catskill.system). I'll think a little
more....<br>
<br>
<blockquote
cite="mid:B905174A0F204EA0BBD73EB3C1B49F10@xxxxxxx"
type="cite">
<div id="ygrp-mlmsg" style="position: relative;">
<div id="ygrp-msg" style="z-index: 1;">
<div id="ygrp-text">
<p>Doable ???<br>
</p>
</div>
</div>
</div>
</blockquote>
<br>
It's very close ...<br>
<blockquote
cite="mid:B905174A0F204EA0BBD73EB3C1B49F10@xxxxxxx"
type="cite">
<div id="ygrp-mlmsg" style="position: relative;">
<div id="ygrp-msg" style="z-index: 1;">
<div id="ygrp-text">
<p><br>
Regards, <br>
<br>
Neil Wrightson. <br>
N.W.Electronics <br>
ABN 76 768 513 867 <br>
Embedded Controllers and Home Automation Products <br>
Web : <a class="moz-txt-link-abbreviated" href="http://www.nwe.net";>www.nwe.net</a>.<wbr>au
<br>
<br>
>>-----Original Message-----<br>
>>From: Bob Jacobsen [mailto:<a
moz-do-not-send="true"
href="mailto:jacobsen%40berkeley.edu";>jacobsen@berkeley.<wbr>edu</a>]
<br>
>>Sent: Wednesday, 17 March 2010 2:35 AM<br>
>>To: Automation; Neil Wrightson<br>
>>Subject: xAP and JMRI naming<br>
>><br>
>>I think we're pretty close to getting the xAP connection to
<br>
>>work, so it's time to start thinking about the next step in
<br>
>>connecting JMRI and xAP.<br>
>><br>
>>Normally, when connecting JMRI and external systems, we
<br>
>>connect status messages from the system to
"Sensors", and use <br>
>>"Turnouts" to send status change commands to the
external
system.<br>
>><br>
>>Using the Insteon control system as an example, when we see
a <br>
>>status report on Insteon address 12.34.56, we create a JMRI
<br>
>>sensor with the name PS12.34.56 that matches that status.
<br>
>>Another Insteon unit with address 45.A3.11 will get matched
<br>
>>to a JMRI sensor called PS45.A3.11, etc. All the JMRI tools
<br>
>>then interact with those. You can give them simpler user
<br>
>>names, set options with them, etc. Similarly for outputs,
<br>
>>where the names are PTsomething.<br>
>><br>
>>So what's the corresponding thing for an xAP
name?<br>
>><br>
>>xap-hbeat<br>
>>{<br>
>>source=JMRI.<wbr>test.1<br>
>>interval=60<br>
>>port=10000<br>
>>hop=1<br>
>>v=12<br>
>>uid=FFFFFFFF<br>
>>class=xap-<wbr>hbeat.alive<br>
>>}<br>
>><br>
>>I can construct a name string from this entire message
(class,
uid, <br>
>>source, etc) but is that all needed? Or is just
"source" <br>
>>sufficient? <br>
>>Or perhaps source+class?<br>
>><br>
>>If we can get a trace of a xAP installation doing
something, <br>
>>perhaps that'll help us figure out what a convenient, but
<br>
>>sufficiently powerful, name convention would be.<br>
>><br>
>>Bob<br>
<br>
</p>
</div>
<!-- end group email --></blockquote>
<br>
<!-- **begin egp html banner** -->
<br>
<br>
<!-- **end egp html banner** -->
<div width="1" style="color: white; clear:
both;"/>__._,_.___</div>
<!-- Start Recommendations -->
<!-- End Recommendations -->
<!-- **begin egp html banner** -->
<img src="http://geo.yahoo.com/serv?s=97476590/grpId=9674343/grpspId=1705007709/msgId=4625/stime=1268838892";
width="1" height="1"> <br>
<!-- **end egp html banner** -->
<!-- **begin egp html banner** -->
<br>
<div style="font-family: verdana; font-size: 77%; border-top: 1px
solid #666; padding: 5px 0;" >
Your email settings: Individual EmailTraditional <br>
<a href="http://groups.yahoo.com/group/xap_automation/join;_ylc=X3oDMTJmNmkxbmo5BF9TAzk3NDc2NTkwBGdycElkAzk2NzQzNDMEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzEyNjg4Mzg4OTI-";>Change
settings via the Web</a> (Yahoo! ID required) <br>
Change settings via email: <a href="mailto:xap_automation-digest@xxxxxxx?subject=Email
Delivery: Digest">Switch delivery to Daily Digest</a> <a
href = "mailto:xap_automation-fullfeatured@xxxxxxx?subject=Change
Delivery Format: Fully Featured">Switch to Fully Featured</a>
<br>
<a href="http://groups.yahoo.com/group/xap_automation;_ylc=X3oDMTJkbnRnMGdtBF9TAzk3NDc2NTkwBGdycElkAzk2NzQzNDMEZ3Jwc3BJZAMxNzA1MDA3NzA5BHNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMjY4ODM4ODky";>
Visit Your Group
</a>
<a href="http://docs.yahoo.com/info/terms/";>
Yahoo! Groups Terms of Use
</a>
<a href="mailto:xap_automation-unsubscribe@xxxxxxx?subject=Unsubscribe";>
Unsubscribe
</a>
<br>
</div>
<br>
<!-- **end egp html banner** -->
<div style="color: white; clear:
both;"/>__,_._,___</div>
</body>
</html>
--------------040201050404080107070905--
xAP_Automation Main Index |
xAP_Automation Thread Index |
xAP_Automation Home |
Archives Home
|