|
My layout is DC cab control, servo points, neither occupation sensors nor signals. Windows JMRI + MERG CBUS. Panel editor panel. NX routing to set and show points, routes and block cab allocation.
Early days, layout under construction, JMRI being understood.
?
On a simple simulated test panel I've been able to set and show points, routes and allocated blocks with NX. I would like also to use this process to allocate and show the (one of five) route control cab. It looks like LogixNG (user level currently novice!) might do this. I might click a one-of-five cab select sensor button group before setting an NX route. This selection is then available during the NX setting process. Is there a way to vary the block alternate colour used to indicate an allocated block during this process, please?
?
It's nagging at me that I've seen a forum query on exactly this subject but despite quite deep digging and repeated searching I can't find it (or indeed anything). I suspect there is a rune to cast that will unlock my current very limited understanding!
|
Hi,
?
I remember asking on here about this, and got an answer from Dave.
?
In LogixNG, in a 'set block' action, you have the left box where you select which block, then in 'to' and in the middle box, a drop down. In that drop down you have options to set alternate colour on or off.
?
So I'm guessing you'd have a LogixNG starting with an 'if then else', if your sensor changes to on then the action would be block - to alternate colour on, and if the sensor is off, block - to alternate colour off.
?
Chris
|
Thanks Chris.
I think you're describing turning a chosen alternate colour on or off not how to choose the colour.
What I need/want to do however is that the alternate colour for a block is a variable (of five) dependent on which cab is allocated.
As I understand it the alternate colour is chosen in the block edit dialogue during panel design then the on/off is actioned with NX. There is no opportunity that I have found to vary the alternate colour during operation/on the fly/ad hoc - choose your technical term!
?
Example:
I click a cab sensor group button, say cab C (of A-E). I use NX block entry exit sensors to set a route, the block colour changes from normal to alternate, say, green. If I had selected cab A the alternate colour would be, say, red. By this means it is clear that a route is controlled by cab C, or A or whichever. Without this (or some other means) it is difficult to follow which cab is controlling which route.
|
I don¡¯t know if LogixNG can change the alternate color of a block all by itself. The alternate color can be changed via a script. Perhaps LogixNG could run a script fragment that would change the color: block.setBlockTrackColor(java.awt.Color(190, 190, 255)) That¡¯s the color code for light blue, as an example. ¡°block¡± in the case is a variable that points to the specific Block you want to have the new color. Bob On May 25, 2025, at 5:23?AM, colin smith via groups.io <colinsmithwork@...> wrote:
My layout is DC cab control, servo points, neither occupation sensors nor signals. Windows JMRI + MERG CBUS. Panel editor panel. NX routing to set and show points, routes and block cab allocation.
Early days, layout under construction, JMRI being understood.
On a simple simulated test panel I've been able to set and show points, routes and allocated blocks with NX. I would like also to use this process to allocate and show the (one of five) route control cab. It looks like LogixNG (user level currently novice!) might do this. I might click a one-of-five cab select sensor button group before setting an NX route. This selection is then available during the NX setting process. Is there a way to vary the block alternate colour used to indicate an allocated block during this process, please?
It's nagging at me that I've seen a forum query on exactly this subject but despite quite deep digging and repeated searching I can't find it (or indeed anything). I suspect there is a rune to cast that will unlock my current very limited understanding! ¡ª Bob Jacobsen rgj1927@...
|
Thanks, Bob.
Another subject on which may rating is novice (at best!) - Java, I used to be somewhat competent with C but last used nearly 20years ago. I assume that setBlockTrackColor is a Java snippet/function/expression/class, again choose your technical term :)
I found the class in
setBlockAlternativeColor
I've a long way to go before I can understand the running/syntax/use of LogixNG let alone a script yet.
Does that give the ability to set a block's (or blocks') alternate colour(s) on demand?
I've further yet to discover where in the process of an NX route set such a process may run.
It would be desirable (to me!) to minimise the interference/duplication with/of existing JMRI processes.
Maybe on clicking my cab selection button all unallocated blocks (currently displaying their normal colour) would have their alternate colour set to that associated with that cab. Then the NX process runs normally.
?
Useful to discuss regardless :)?
|
I don¡¯t know enough about the NX process to know where there are hooks for doing extra processing. Perhaps somebody who knows more about that will point out where LogixNG or scripts can be added in? The script fragment I quoted is actually Jython. That¡¯s a sub-variant of Python that can access JMRI¡¯s internal objects and classes. In many ways it¡¯s a simpler way to add code to JMRI, rather than writing in Java itself. If there is a way to trigger a script after NX processing is done, you could do something like: 1) NX allocates the blocks, setting them to use their alternate color, with that alternate color being some default e.g. yellow. 2) A script is then started which scans the blocks to find any that are that default color. Those are the ones that are just allocated. It changes the alternate color on those to the color that corresponds to the allocated cab. (I don¡¯t know how the script would find out which cab was just allocated. Some other setting?) You¡¯d also have to have a little script that listens to the blocks and determines when they are _de_allocated so that their alternate color could be returned to yellow. Neither of these are hard to create, except for the part about knowing what color to set and the part about getting them run after NX allocation. I don¡¯t know how to do those two things. Bob On May 25, 2025, at 8:15?AM, colin smith via groups.io <colinsmithwork@...> wrote:
Thanks, Bob.
Another subject on which may rating is novice (at best!) - Java, I used to be somewhat competent with C but last used nearly 20years ago. I assume that setBlockTrackColor is a Java snippet/function/expression/class, again choose your technical term :)
I found the class in setBlockAlternativeColor I've a long way to go before I can understand the running/syntax/use of LogixNG let alone a script yet.
Does that give the ability to set a block's (or blocks') alternate colour(s) on demand?
I've further yet to discover where in the process of an NX route set such a process may run.
It would be desirable (to me!) to minimise the interference/duplication with/of existing JMRI processes.
Maybe on clicking my cab selection button all unallocated blocks (currently displaying their normal colour) would have their alternate colour set to that associated with that cab. Then the NX process runs normally.
Useful to discuss regardless :)
¡ª Bob Jacobsen rgj1927@...
|
Yes, a lot to discover!
?
I had considered whether the block alternate-colour-choice/change-on-cab-selection would be better operating before, during or after the NX process.
?
I discarded the during first as already said to avoid duplicating an existing process.
Second the after as one would need to work out/keep track of which blocks have just been NX allocated but not yet cab allocated. As you have touched on in order to apply the cab-specific alternate colour only to them and not to any other routes already allocated (to other cabs). Although it would have the advantage that the additional state of NX-but-not-cab-allocated might be shown.
I felt doing the colour choice first meant minimal LogixNG and no interference with the existing NX process.
|
Colin,
You started this thread indicting that you are using a "Panel editor panel". ?NX is only supported when using Layout Editor panels.
The "ManageBlocks2.py" script provides the ability to change normal and occupied block track colors. ?If the "reserve" or "release" action is selected, it can also change the alternate color, however this would create a conflict with NX. ?This script might provide some ideas on color management.
If I understand the concepts, you need four block colors, two are track colors and two are alternate track colors. - Default
- Cab assigned
- NX allocated
- NX allocated and Cab assigned
Actually there are 12 colors since there are five cabs.
How do you manage the "cab to block" assignments? ?Is there a sensor group for each block or is a set of blocks assigned to a cab?
One of the features of LogixNG is the ability to send parameters to a script and get results back. ?See?
I would create a script to handle color management based on calls from LogixNG when block events happen, such as cab assignment, NX allocation, etc.
Dave Sand
----- Original message ----- Subject: Re: [jmriusers] Ad Hoc Changing Block Alternate Colour - Means of Showing Cab Allocation with DC Cab Control Date: Sunday, May 25, 2025 8:09 AM
Yes, a lot to discover! ? I had considered whether the block alternate-colour-choice/change-on-cab-selection would be better operating before, during or after the NX process. ? I discarded the during first as already said to avoid duplicating an existing process. Second the after as one would need to work out/keep track of which blocks have just been NX allocated but not yet cab allocated. As you have touched on in order to apply the cab-specific alternate colour only to them and not to any other routes already allocated (to other cabs). Although it would have the advantage that the additional state of NX-but-not-cab-allocated might be shown. I felt doing the colour choice first meant minimal LogixNG and no interference with the existing NX process.
|
Yes Layout Editor, it's all I've used, forgot there are multiple Panel types/editing means.
?
Had a look at the "ManageBlocks2.py" script. Wow, that's quite a deep end into which to be thrown! I dabbled very, very briefly with Python also 20 years ago so any understanding is long forgotten!
Anyway, hopefully moderately sensible questions below :)
?
There appears to me to be setting (or choosing) and using (with changes to release/reserved) the block extra colour (or alternate colour as it is called elsewhere) in that script. If the use bit and changes to release/reserved were avoided leaving only the setting would that avoid NX conflicts? It is that separating of the setting (or choice) of alternate colour from its use that I had envisioned.
In a similar way to the existing means of setting a block's alternate colour in the block edit dialog being separate from the use of the alternate colour in the NX process.
?
You say: "If I understand the concepts, you need four block colors, two are track colors and two are alternate track colors.
- Default
- Cab assigned
- NX allocated
- NX allocated and Cab assigned
Actually there are 12 colors since there are five cabs."
?
My vision is simpler (perhaps!) states 2&3 do not exist except perhaps as a transient or unseen/don't care combination of other conditions while the assignment process runs.
My cab choice sensor group button (1 of 5) being selected before an NX setting process might set but not use a cab-dependent alternate colour for all unreserved (by NX) blocks. In this state, two above in your example, those blocks will still be displaying their default track colour as there has not been any NX route allocation (or change in actual cab relays) for them. When an NX assignment is made NX uses the alternate colour. That change in block reservation status might be the trigger which then sets a turnout for that block's cab selection relays. i.e. the colours/states for my system are 1&4 only.
?
You say "How do you manage the "cab to block" assignments? ?Is there a sensor group for each block or is a set of blocks assigned to a cab?"
The latter I think as each block becomes part of an NX set route.
|
Colin,
See if what follows makes sense.
Traditionally, cab control consists of a rotary switch that routes the power from a number of cabs to a section of track.
The goal is to have JMRI handle the power switching using some unspecified type of hardware. ?The power routing would be based on selecting a cab and then a NX route. ?When the NX route is activated, the hardware would be notified of the cab setting for each affected block and the NX route on the panel would have the allocated track color changed based on which cab was selected.
---------------
Don't worry about ManageBlocks2.py. ?For your purpose, a new script integrated with LogixNG would work much better.
Dave Sand
----- Original message ----- Subject: Re: [jmriusers] Ad Hoc Changing Block Alternate Colour - Means of Showing Cab Allocation with DC Cab Control Date: Sunday, May 25, 2025 1:22 PM
Yes Layout Editor, it's all I've used, forgot there are multiple Panel types/editing means. ? Had a look at the "ManageBlocks2.py" script. Wow, that's quite a deep end into which to be thrown! I dabbled very, very briefly with Python also 20 years ago so any understanding is long forgotten! Anyway, hopefully moderately sensible questions below :) ? There appears to me to be setting (or choosing) and using (with changes to release/reserved) the block extra colour (or alternate colour as it is called elsewhere) in that script. If the use bit and changes to release/reserved were avoided leaving only the setting would that avoid NX conflicts? It is that separating of the setting (or choice) of alternate colour from its use that I had envisioned. In a similar way to the existing means of setting a block's alternate colour in the block edit dialog being separate from the use of the alternate colour in the NX process. ? You say: "If I understand the concepts, you need four block colors, two are track colors and two are alternate track colors. - Default
- Cab assigned
- NX allocated
- NX allocated and Cab assigned
Actually there are 12 colors since there are five cabs." ? My vision is simpler (perhaps!) states 2&3 do not exist except perhaps as a transient or unseen/don't care combination of other conditions while the assignment process runs. My cab choice sensor group button (1 of 5) being selected before an NX setting process might set but not use a cab-dependent alternate colour for all unreserved (by NX) blocks. In this state, two above in your example, those blocks will still be displaying their default track colour as there has not been any NX route allocation (or change in actual cab relays) for them. When an NX assignment is made NX uses the alternate colour. That change in block reservation status might be the trigger which then sets a turnout for that block's cab selection relays. i.e. the colours/states for my system are 1&4 only. ? You say "How do you manage the "cab to block" assignments? ?Is there a sensor group for each block or is a set of blocks assigned to a cab?" The latter I think as each block becomes part of an NX set route.
|
On Mon, May 26, 2025 at 12:20 AM, Dave Sand wrote:
Traditionally, cab control consists of a rotary switch that routes the power from a number of cabs to a section of track.
?
The goal is to have JMRI handle the power switching using some unspecified type of hardware. ?The power routing would be based on selecting a cab and then a NX route. ?When the NX route is activated, the hardware would be notified of the cab setting for each affected block and the NX route on the panel would have the allocated track color changed based on which cab was selected.
A pithy summation, yes it makes sense, thanks for getting into the depth of this user's head :)
A detail adjustment and splitting the last sentence if I may...
When a cab is selected the allocated track colour associated with that cab is selected for all unallocated blocks. When the NX route is activated, the hardware would be notified of the cab setting for each activated block and the NX route on the panel uses the now cab dependent allocated track colour.
?
I feel that reflects, clarifies and separates the selection of the alternate colour and the use of it. This in a similar way to the separation of alternate colour selection in the edit block dialog and use of the alternate colour in NX route setting. The end result is the same as your description, just a slightly different order of getting there.
Is there any advantage/disadvantage you see in either method?
?
|
Oh and it is good to have seen that block managing script, where and how it is described and syntax. All part of learning.
|
Colin,
Here is a demo that sort of implements what you are looking at doing.
After expanding the zip file, move the xml and py files and custom icons to an existing profile. ?Everything is internal so there is no requirement for a specific connection.
Comments
EntryExit dynamically builds the block list based on the active sensor pair. ?You cannot build a list of blocks that will be allocated. ?Since you will not have signals, it is also not possible to predict the "possible" block set from the signal mast logic. ?
The demo inverts the process. ?There is a LogixNG that is triggered when EntryExit has allocated a block. ?It runs the set-alternate-color.py script. ?The script has access to the LogixNG symbol table which provides the block name and cab name. ?
The cab sensor group triggers a LogixNG which updates a global LogixNG variable. ?The script has a Python dictionary that maps the cab names to the color for each cab name.
Since you don't have occupancy detection, you will need to "cancel" the EntryExit routes.
Setting unallocated blocks to a selected cab is probably not a good idea. ?That would require changing the normal block color.
Dave Sand
----- Original message ----- Subject: Re: [jmriusers] Ad Hoc Changing Block Alternate Colour - Means of Showing Cab Allocation with DC Cab Control Date: Monday, May 26, 2025 6:02 AM
Oh and it is good to have seen that block managing script, where and how it is described and syntax. All part of learning.
|
Fantastic. I'll give it go.
?
One query on your "what not to do" -?
On Mon, May 26, 2025 at 09:47 PM, Dave Sand wrote:
Setting unallocated blocks to a selected cab is probably not a good idea. ?That would require changing the normal block color
I don't follow, why does the normal block colour have to change? I would not want to change them.
It is possible using the edit block dialogue to independently change normal, occupied and alternate colours independently (!) also of the block's state. Is it not possible to do this in script?
?
Yes, if the colour being changed is applicable to the block's current allocation state it will appear on the panel. But if the block is in a different state to the colour being changed there's neither allocation state or visible block colour change.
e.g. if the block is unallocated it is possible to change the allocated colour without changing either the currently displaying normal colour or the block's allocation state. It is only when that block becomes allocated that the new setting is used and the new alternate colour shows on the panel.
?
A block's cab setting when unallocated is independent of displayed block colour and similarly no changes occur in any output, block states or other parameters or panel appearance at time of setting.
It is only when the block is allocated by NX that the block state, displayed colour and cab relays change as I see it.
?
?
|
Colin,
I was responding to this statement.
When a cab is selected the allocated track colour associated with that cab is selected for all unallocated blocks
While certainly possible, it does not "do" anything visible since the unallocated blocks continue to show the normal color.
However, your idea does make sense. ?Instead of setting the cab color when a NX route is selected, the last selected cab color would become visible when the NX route allocates its blocks. ?That is actually a cleaner approach. ?I will put together a demo of this solution.
There is a potential problem with the new approach. ?If a NX route is active for Cab A when Cab B is selected, the blocks will still have the Cab A allocation color when the NX route is cancelled. ?If those are included in a new NX route, they will still have the Cab A color. ?To address this issue, the allocation color will have to be updated to the current cab color when the blocks are deallocated.
Dave Sand
----- Original message ----- Subject: Re: [jmriusers] Ad Hoc Changing Block Alternate Colour - Means of Showing Cab Allocation with DC Cab Control Date: Tuesday, May 27, 2025 12:54 PM
Fantastic. I'll give it go. ? One query on your "what not to do" -? On Mon, May 26, 2025 at 09:47 PM, Dave Sand wrote: Setting unallocated blocks to a selected cab is probably not a good idea. ?That would require changing the normal block color I don't follow, why does the normal block colour have to change? I would not want to change them. It is possible using the edit block dialogue to independently change normal, occupied and alternate colours independently (!) also of the block's state. Is it not possible to do this in script? ? Yes, if the colour being changed is applicable to the block's current allocation state it will appear on the panel. But if the block is in a different state to the colour being changed there's neither allocation state or visible block colour change. e.g. if the block is unallocated it is possible to change the allocated colour without changing either the currently displaying normal colour or the block's allocation state. It is only when that block becomes allocated that the new setting is used and the new alternate colour shows on the panel. ? A block's cab setting when unallocated is independent of displayed block colour and similarly no changes occur in any output, block states or other parameters or panel appearance at time of setting. It is only when the block is allocated by NX that the block state, displayed colour and cab relays change as I see it. ? ?
|
On the demo:
Tried, gets there but appearance while so doing is somewhat clunky. Even on this modern laptop and modest demo size panel there's a noticeable intermediate (last-used) allocated colour state at NX route acceptance. Unallocated > old allocated colour > pause > new allocated colour.
?
On your potential problem where an operator selects a cab then cancels a route with a different cab before including elements of that route in a new one:
Ah, concept meets real (as opposed to ideal) operator. Concept found to be not as clean as anticipated!
Yes your suggestion would work.
?
One other though occurs, is to set the cab after the NX process rather than before it. i.e. Operator clicks cab button after rather than before. No particular preference, just another idea.
Your earlier state numbers/needed block colours:
1). Unoccupied default (one of 2). I already am choosing alternate unallocated blocks being different colours to make boundaries most obvious.
3). NX allocated default (say white as now).
4). NX allocated cab specific (one of five). Applied when cab button is clicked.
Clicking the cab button causes the cab specific allocated colour to be applied to those reserved blocks displaying the default allocated colour. This would also be a good place to select cab relays.
?
Once I've got to grips with logixNG and to some extent scripts I might have a go doing it like that. Your examples contain a lot of experience to make it so efficient and are teaching me more with every line!
?
My hardware is MERG CBUS and block relays would be a pattern of turnout events sent to CANVOUT modules with universal software. I will try that myself when ready.
|
Colin,
I am working on a demo that addresses most of these issues. ?I should have it done later today.
Dave Sand
----- Original message ----- Subject: Re: [jmriusers] Ad Hoc Changing Block Alternate Colour - Means of Showing Cab Allocation with DC Cab Control Date: Wednesday, May 28, 2025 11:42 AM
On the demo: Tried, gets there but appearance while so doing is somewhat clunky. Even on this modern laptop and modest demo size panel there's a noticeable intermediate (last-used) allocated colour state at NX route acceptance. Unallocated > old allocated colour > pause > new allocated colour. ? On your potential problem where an operator selects a cab then cancels a route with a different cab before including elements of that route in a new one: Ah, concept meets real (as opposed to ideal) operator. Concept found to be not as clean as anticipated! Yes your suggestion would work. ? One other though occurs, is to set the cab after the NX process rather than before it. i.e. Operator clicks cab button after rather than before. No particular preference, just another idea. Your earlier state numbers/needed block colours: 1). Unoccupied default (one of 2). I already am choosing alternate unallocated blocks being different colours to make boundaries most obvious. 3). NX allocated default (say white as now). 4). NX allocated cab specific (one of five). Applied when cab button is clicked. Clicking the cab button causes the cab specific allocated colour to be applied to those reserved blocks displaying the default allocated colour. This would also be a good place to select cab relays. ? Once I've got to grips with logixNG and to some extent scripts I might have a go doing it like that. Your examples contain a lot of experience to make it so efficient and are teaching me more with every line! ? My hardware is MERG CBUS and block relays would be a pattern of turnout events sent to CANVOUT modules with universal software. I will try that myself when ready.
|
Colin,
The updated demo is attached.
When the cab selection is changed, the unallocated layout blocks get the new cab color. ?When the NX route is allocated, the colors have already been set so there is no delay. ?When the NX route is deallocated, the layout blocks get the current cab color so all of the unallocated blocks have the same cab color.
The?cab-colors.py script has the list of cab colors. ?This script is used by two other scripts.
The?set-cab-color.py script sets the alternate color for the unallocated blocks. ?This is called by the "Select Cab" LogixNG.
The?set-block-cab.py script sets the alternate color for the blocks that become unallocated. ?This is called by the "Set Block Cab" LogixNG. ?This LogixNG also has the start of the logic for the MERG actions to do the cab to track assignments.
Dave Sand
----- Original message ----- Subject: Re: [jmriusers] Ad Hoc Changing Block Alternate Colour - Means of Showing Cab Allocation with DC Cab Control Date: Wednesday, May 28, 2025 11:42 AM
On the demo: Tried, gets there but appearance while so doing is somewhat clunky. Even on this modern laptop and modest demo size panel there's a noticeable intermediate (last-used) allocated colour state at NX route acceptance. Unallocated > old allocated colour > pause > new allocated colour. ? On your potential problem where an operator selects a cab then cancels a route with a different cab before including elements of that route in a new one: Ah, concept meets real (as opposed to ideal) operator. Concept found to be not as clean as anticipated! Yes your suggestion would work. ? One other though occurs, is to set the cab after the NX process rather than before it. i.e. Operator clicks cab button after rather than before. No particular preference, just another idea. Your earlier state numbers/needed block colours: 1). Unoccupied default (one of 2). I already am choosing alternate unallocated blocks being different colours to make boundaries most obvious. 3). NX allocated default (say white as now). 4). NX allocated cab specific (one of five). Applied when cab button is clicked. Clicking the cab button causes the cab specific allocated colour to be applied to those reserved blocks displaying the default allocated colour. This would also be a good place to select cab relays. ? Once I've got to grips with logixNG and to some extent scripts I might have a go doing it like that. Your examples contain a lot of experience to make it so efficient and are teaching me more with every line! ? My hardware is MERG CBUS and block relays would be a pattern of turnout events sent to CANVOUT modules with universal software. I will try that myself when ready.
|
Works as desired and smoothly now.
Thanks also for the where-to-put-cab-relay-setting hooks.
|
Bob Jacobsen