JMRI Model Railroad Interface

On Nov 11, 2011, at 2:49 AM, Kevin Dickerson wrote:

> However this does open a small can of worms as to how to deal with
> other places within the code that simply access the default command
> station to send packets out of...
> 
> This includes
> Loconet throttle, for sending function group 3.
> Abstract throttle, for sending function group 4.

Should probably pick the command station through the current ThrottleManager.

> Raw turnout operator (this doesn't work correctly with the new
> configurations user defined prefixes)
> Abstract Turnout Manager, for Valid turnout operations.

(Not really sure what the first of those does)

Should probably pick the command station through the current TurnoutManager.

The idea here is that those are working in parallel with other operations on the layout, e.g. need to be consistent with other Throttle operations or other Turnout operations.

Bob

--
Bob Jacobsen
rgj1927@... +1-510-486-7355 AIM, Skype JacobsenRG

On 11/11/2011 22:23, Bob Jacobsen wrote:
>
> On Nov 11, 2011, at 2:49 AM, Kevin Dickerson wrote:
>
>> However this does open a small can of worms as to how to deal with
>> other places within the code that simply access the default
>> command station to send packets out of...
>>
>> This includes Loconet throttle, for sending function group 3.
>> Abstract throttle, for sending function group 4.
>
> Should probably pick the command station through the current
> ThrottleManager.
>
>> Raw turnout operator (this doesn't work correctly with the new
>> configurations user defined prefixes) Abstract Turnout Manager, for
>> Valid turnout operations.
>
> (Not really sure what the first of those does)
>
> Should probably pick the command station through the current
> TurnoutManager.
>
> The idea here is that those are working in parallel with other
> operations on the layout, e.g. need to be consistent with other
> Throttle operations or other Turnout operations.
>
> Bob

So in both cases, we need to pass into the turnout or throttle manager 
the correct command station manager, or find a suitable way to get the 
correct command station manager.

Regards
Kevin

On Nov 11, 2011, at 2:39 PM, Kevin Dickerson wrote:

> On 11/11/2011 22:23, Bob Jacobsen wrote:
>> 
>> The idea here is that those are working in parallel with other
>> operations on the layout, e.g. need to be consistent with other
>> Throttle operations or other Turnout operations.
>> 
>> Bob
> 
> So in both cases, we need to pass into the turnout or throttle manager 
> the correct command station manager, or find a suitable way to get the 
> correct command station manager.


Yes, I think that's right.  It's a bit of a pain because of the number of concrete classes, but I think that's necessary for these cases.

Eventually, lots of code will be capable of using non-default managers for things, as the Power Control does now.  In that case, _all_ the necessary context has to be accessible through the selected manager, because that's the only thing that's being selected.

Bob
--
Bob Jacobsen
rgj1927@... +1-510-486-7355 AIM, Skype JacobsenRG

My thought of how this should work:

1. The turnout/signal has a system name.
2. If the system connection for that has a command station, use it.
3. If the system connection does not have a command station, then use the 'default' command station.

So this way the user can control where the traffic goes by picking the system name.


-ken cameron
Syracuse Model Railroad Club http://www.SyracuseModelRr.org/
CNY Modelers http://www.cnymod.com/
Finger Lakes Live Steamers http://www.fingerlakeslivesteamers.org/
Member JMRI Developer Team http://www.jmri.org/
mailto: kcameron@...
In the Upstate New York US area of the world

On 11 Nov, Bob Jacobsen wrote:
>> Raw turnout operator (this doesn't work correctly with the new
>> configurations user defined prefixes)
> 
> (Not really sure what the first of those does)

What it was designed to do was to send raw DCC packets instead of using
the turnout commands associated with the command station.  

I put this into place originally because XPressNet commands do not give
you an accurate way to control the number of DCC packets sent.  I was
trying to toggle CVP accessory decoder outputs (when configured as 8
individual outputs).  To do this, you need to reliably send an odd
number of DCC packets to the decoder.  Unfortunately, the Lenz packet
sending interface doesn't let this work reliably either.... so I put the
project on hold for a while (and have yet to get back to it).

It needs to be using the command station the turnout is associated with.

Paul
-- 
______________________________________________________________________________

	"Quality is a Characteristic of thought and statement that 
	is recognized by a nonthinking process. Because 
	definitions are a product of rigid formal thinking, 
	quality cannot be defined."
		Robert M. Pirsig
			Zen and The Art of Motorcycle Maintenance

On Nov 11, 2011, at 10:09 PM, paul.bender@... wrote:

> On 11 Nov, Bob Jacobsen wrote:
>>> Raw turnout operator (this doesn't work correctly with the new
>>> configurations user defined prefixes)
>> 
> 
> What it was designed to do was to send raw DCC packets instead of using
> the turnout commands associated with the command station.  
> 
> I put this into place originally because XPressNet commands do not give
> you an accurate way to control the number of DCC packets sent.  I was
> trying to toggle CVP accessory decoder outputs (when configured as 8
> individual outputs).  To do this, you need to reliably send an odd
> number of DCC packets to the decoder.  Unfortunately, the Lenz packet
> sending interface doesn't let this work reliably either…. 

Would it make sense for that to be a different turnout type, rather than an operator?

Bob

--
Bob Jacobsen
rgj1927@... +1-510-486-7355 AIM, Skype JacobsenRG

On Nov 12, 2011, at 12:32 AM, Bob Jacobsen <rgj1927@...> wrote:
> On Nov 11, 2011, at 10:09 PM, paul.bender@... wrote:
>> On 11 Nov, Bob Jacobsen wrote:
>>>> Raw turnout operator (this doesn't work correctly with the new
>>>> configurations user defined prefixes)
>> What it was designed to do was to send raw DCC packets instead of using
>> the turnout commands associated with the command station.  
>> 
>> I put this into place originally because XPressNet commands do not give
>> you an accurate way to control the number of DCC packets sent.  I was
>> trying to toggle CVP accessory decoder outputs (when configured as 8
>> individual outputs).  To do this, you need to reliably send an odd
>> number of DCC packets to the decoder.  Unfortunately, the Lenz packet
>> sending interface doesn't let this work reliably either…. 
> 
> Would it make sense for that to be a different turnout type, rather than an operator?

I personally do not believe so.  This is a situation where we want to acknowledge the turnout is connected to a specific system, but we want to override the default behavior of the turnout.  That is what all of the operators do.

Paul

On Nov 12, 2011, at 7:30 AM, Paul Bender wrote:
> On Nov 12, 2011, at 12:32 AM, Bob Jacobsen <rgj1927@...> wrote:
>> On Nov 11, 2011, at 10:09 PM, paul.bender@... wrote:
>>> On 11 Nov, Bob Jacobsen wrote:
>>>>> Raw turnout operator 
>>> What it was designed to do was to send raw DCC packets instead of using
>>> the turnout commands associated with the command station.  
>>> 
>> 
>> Would it make sense for that to be a different turnout type, rather than an operator?
> 
> I personally do not believe so.  This is a situation where we want to acknowledge the turnout is connected to a specific system, but we want to override the default behavior of the turnout.  That is what all of the operators do.


Good enough for me. Thanks.

Bob
--
Bob Jacobsen
rgj1927@... +1-510-486-7355 AIM, Skype JacobsenRG

On 11 November 2011 23:03, Bob Jacobsen <rgj1927@...> wrote:
>
> On Nov 11, 2011, at 2:39 PM, Kevin Dickerson wrote:
>
>> On 11/11/2011 22:23, Bob Jacobsen wrote:
>>>
>>> The idea here is that those are working in parallel with other
>>> operations on the layout, e.g. need to be consistent with other
>>> Throttle operations or other Turnout operations.
>>>
>>> Bob
>>
>> So in both cases, we need to pass into the turnout or throttle manager
>> the correct command station manager, or find a suitable way to get the
>> correct command station manager.
>
> Yes, I think that's right.  It's a bit of a pain because of the number of concrete classes, but I think that's necessary for these cases.
>
> Eventually, lots of code will be capable of using non-default managers for things, as the Power Control does now.  In that case, _all_ the necessary context has to be accessible through the selected manager, because that's the only thing that's being selected.
>

Bob,

I'm looking through all of this, I think it is easier to pass around
the SystemConnectionMemo around, as this includes access to other bits
that the throttles use, so it makes sense to just pass one item rather
than three or four.

One thing that I have come across in the Loconet throttles is that
they are still referencing LnTrafficController.instance(), shouldn't
they be referencing the specific traffic controller for the
connection?  Therefore should the traffic controller instance() be
down as depreciated?

Regards
Kevin

On 12 November 2011 06:09,  <paul.bender@...> wrote:
> On 11 Nov, Bob Jacobsen wrote:
>>> Raw turnout operator (this doesn't work correctly with the new
>>> configurations user defined prefixes)
>>
>> (Not really sure what the first of those does)
>
> What it was designed to do was to send raw DCC packets instead of using
> the turnout commands associated with the command station.
>
> I put this into place originally because XPressNet commands do not give
> you an accurate way to control the number of DCC packets sent.  I was
> trying to toggle CVP accessory decoder outputs (when configured as 8
> individual outputs).  To do this, you need to reliably send an odd
> number of DCC packets to the decoder.  Unfortunately, the Lenz packet
> sending interface doesn't let this work reliably either.... so I put the
> project on hold for a while (and have yet to get back to it).
>
> It needs to be using the command station the turnout is associated with.

Paul,

If I make the necessary changes, would you be in a position to test
that it operates correctly?

Regards
Kevin

On Nov 14, 2011, at 1:58 AM, Kevin Dickerson wrote:

> I'm looking through all of this, I think it is easier to pass around
> the SystemConnectionMemo around, as this includes access to other bits
> that the throttles use, so it makes sense to just pass one item rather
> than three or four.

Not sure what you're saying here.  

Passing the SystemConnectionMemo around does give access.

But the selection part of the Power Control works by allowing the user to select from the available Power Managers, or using the default.  PowerManagers are not isomorphic to the SystemConnectionMemos (not all systems have one, they may be separately connected (esp for other cases like throttles)), etc.

So having a PowerManager give access to everything needed for power, a ThrottleManager give access for everything needed to implement a throttle (e.g. a command station), etc seems like a simpler pattern.

> One thing that I have come across in the Loconet throttles is that
> they are still referencing LnTrafficController.instance(), shouldn't
> they be referencing the specific traffic controller for the
> connection?  Therefore should the traffic controller instance() be
> down as depreciated?

Yes and yes.

Bob
--
Bob Jacobsen
rgj1927@... +1-510-486-7355 AIM, Skype JacobsenRG

On 14 November 2011 14:56, Bob Jacobsen <rgj1927@...> wrote:
>
> On Nov 14, 2011, at 1:58 AM, Kevin Dickerson wrote:
>
>> I'm looking through all of this, I think it is easier to pass around
>> the SystemConnectionMemo around, as this includes access to other bits
>> that the throttles use, so it makes sense to just pass one item rather
>> than three or four.
>
> Not sure what you're saying here.
>
> Passing the SystemConnectionMemo around does give access.
>
> But the selection part of the Power Control works by allowing the user to select from the available Power Managers, or using the default.  PowerManagers are not isomorphic to the SystemConnectionMemos (not all systems have one, they may be separately connected (esp for other cases like throttles)), etc.

I should have been a bit clearer, I have so far just been looking at
the throttles and throttle manager.  Certainly with the throttles in
most instances access to the traffic controller is required, which can
be accessed from the SystemConnectionMemo, so rather than passing the
SystemConnectionMemo and the traffic controller in at the constructor
stage, we can pass the one item in.

> So having a PowerManager give access to everything needed for power, a ThrottleManager give access for everything needed to implement a throttle (e.g. a command station), etc seems like a simpler pattern.

One thought I have had at is to provide either access to a power
manager from each of the specific system menus and/or provide access
to all of the power managers from a single window.  Also the throttle
window GUI power button will need to match up to the power manager
that is related to the throttle.

>> One thing that I have come across in the Loconet throttles is that
>> they are still referencing LnTrafficController.instance(), shouldn't
>> they be referencing the specific traffic controller for the
>> connection?  Therefore should the traffic controller instance() be
>> down as depreciated?
>
> Yes and yes.

Might as well sort that out at the same time.

Regards
Kevin

On Nov 14, 2011, at 7:09 AM, Kevin Dickerson wrote:

> 
> I should have been a bit clearer, I have so far just been looking at
> the throttles and throttle manager.  Certainly with the throttles in
> most instances access to the traffic controller is required, which can
> be accessed from the SystemConnectionMemo, so rather than passing the
> SystemConnectionMemo and the traffic controller in at the constructor
> stage, we can pass the one item in.

Agree, the SCM is the preferred way to pass those things around when e.g. constructing a ThrottleManager.  if something is missing from the (system-specific or abstract) SCM, it should be added so that pattern continues to work.

I was thinking more of how an individual throttle should work.

> 
>> So having a PowerManager give access to everything needed for power, a ThrottleManager give access for everything needed to implement a throttle (e.g. a command station), etc seems like a simpler pattern.
> 
> One thought I have had at is to provide either access to a power
> manager from each of the specific system menus and/or provide access
> to all of the power managers from a single window.  Also the throttle
> window GUI power button will need to match up to the power manager
> that is related to the throttle.

The Power Manager already does this, I think.  That window has a menu that allows you to select which of the active PowerManagers it'll work with.  If you have two systems, you can have two power managers open, one talking to each.


Bob
--
Bob Jacobsen
rgj1927@... +1-510-486-7355 AIM, Skype JacobsenRG

On 14 November 2011 14:56, Bob Jacobsen <rgj1927@...> wrote:
>
> On Nov 14, 2011, at 1:58 AM, Kevin Dickerson wrote:
>> One thing that I have come across in the Loconet throttles is that
>> they are still referencing LnTrafficController.instance(), shouldn't
>> they be referencing the specific traffic controller for the
>> connection?  Therefore should the traffic controller instance() be
>> down as depreciated?
>
> Yes and yes.
>

Bob,

I'm just looking at other things that call the
LnTrafficController.instance(), the two that I'm not sure about
currently is the ALM Implementation and the Security Element.

With the ALM Implementation, I can only find the Se8AlmImplementation
extending it, and I can't find anything other than a test using the
Se8AlmImplementation.

With the Security Element, that is a little bit more involved with it
being used with an AspectGenerator within LocoNet (but nothing using
the aspect generator other than the security manager) and a security
icon in the panels section.

At the moment I don't know what should be done with either of these.

Regards
Kevin

On 14 Nov, Kevin Dickerson wrote:
> On 12 November 2011 06:09,  <paul.bender@...> wrote:
>> On 11 Nov, Bob Jacobsen wrote:
>>>> Raw turnout operator (this doesn't work correctly with the new
>>>> configurations user defined prefixes)
<snip>
>> It needs to be using the command station the turnout is associated
>> with.
> 
> If I make the necessary changes, would you be in a position to test
> that it operates correctly?

Yes, I beleive I can, but it will take a few days.

Paul
-- 
______________________________________________________________________________

	"Quality is a Characteristic of thought and statement that 
	is recognized by a nonthinking process. Because 
	definitions are a product of rigid formal thinking, 
	quality cannot be defined."
		Robert M. Pirsig
			Zen and The Art of Motorcycle Maintenance

On 16/11/2011 14:24, paul.bender@... wrote:
> On 14 Nov, Kevin Dickerson wrote:
>> On 12 November 2011 06:09,<paul.bender@...>  wrote:
>>> On 11 Nov, Bob Jacobsen wrote:
>>>>> Raw turnout operator (this doesn't work correctly with the new
>>>>> configurations user defined prefixes)
> <snip>
>>> It needs to be using the command station the turnout is associated
>>> with.
>>
>> If I make the necessary changes, would you be in a position to test
>> that it operates correctly?
>
> Yes, I beleive I can, but it will take a few days.

Thanks Paul,

I did some basic checks to see that it was identifying the correct 
command station based upon the system name of turnout.  If your able to 
confirm that it is working correctly that would be great.

Regards
Kevin

On Nov 16, 2011, at 1:43 AM, Kevin Dickerson wrote:

> I'm just looking at other things that call the
> LnTrafficController.instance(), the two that I'm not sure about
> currently is the ALM Implementation and the Security Element.
> 
> With the ALM Implementation, I can only find the Se8AlmImplementation
> extending it, and I can't find anything other than a test using the
> Se8AlmImplementation.
> 
> With the Security Element, that is a little bit more involved with it
> being used with an AspectGenerator within LocoNet (but nothing using
> the aspect generator other than the security manager) and a security
> icon in the panels section.

They're seriously obsolete, I think.  It might be best just to deprecate them and see if anybody complains, then remove them.

They were an attempt to code some very nice support for the CML signaling boards and some features of the DT40x throttles, so that it would all work together nicely with Panel Editor panels.  But I don't think anybody is using it (because I know of pretty interesting bugs that have never been reported)

Bob
--
Bob Jacobsen
rgj1927@... +1-510-486-7355 AIM, Skype JacobsenRG