|
I am trying to implement a timed control of an uncoupler, which is actuated by a servo (the servo moves a permanent magnet so it is either near to the track or distant from the track).? The JMRI documentation says that 'lights' are specifically designed for uncouplers, but Im struggling to get the combination of lights/sensors to do what I want.
?
What I want is
1. to push a 'button' (sensor?) on my layout panel to activate the uncoupler (light)
2. for the uncoupler (light) to stay on for a period of time then switch off
3. for the colour of the button (sensor?) to change when I first push it, and then to change back when the uncoupler (light) switches off after the programmed period of time (so the button colour at all times reflects the state of the uncoupler)
?
I can get (1) to work using a sensor which controls the light.? I can get( 2) to work by setting the light controller type to timed on and setting the on duration accordingly.? What I cant do is to get the button(sensor) colour to change back when the uncoupler (light) switches off.
?
Can anyone tell me what I am missing?
?
?
|
Within the panel, the simplest is to make the "sensor" a momentary action sensor, so it reverts to its original (off) state when the click is removed.? ?But this means the uncoupler being "on" isn't shown.??
If not happy with this visually, and want a visual representation of the uncoupler staying "on" for a period of time, then this(*) should work:??
a)? ?use the momentary sensor icon, and edit it's "level" to a high number in the panel.? ?Then, change the sensor icon to be a transparent square (ie. invisible).? But an invisible icon can still be clicked to cause an action.? ?
b)? ?place the light on the panel, on a level lower than the sensor, and visually underneath the transparent icon.? Set that to have no click action (so it only displays, doesn't respond to click).??
You may find it easier to construct the above in stages, and the final step is to make the two elements overlap each other in the same place.??
?
(* I can think of other ways of achieving the same ).?
- Nigel
toggle quoted message
Show quoted text
------ Original Message ------
Date 08/09/2024 10:36:04
Subject [jmriusers] Timed control of (servo actuated) uncoupler
I am trying to implement a timed control of an uncoupler, which is actuated by a servo (the servo moves a permanent magnet so it is either near to the track or distant from the track).? The JMRI documentation says that 'lights' are specifically designed
for uncouplers, but Im struggling to get the combination of lights/sensors to do what I want.
?
What I want is
1. to push a 'button' (sensor?) on my layout panel to activate the uncoupler (light)
2. for the uncoupler (light) to stay on for a period of time then switch off
3. for the colour of the button (sensor?) to change when I first push it, and then to change back when the uncoupler (light) switches off after the programmed period of time (so the button colour at all times reflects the state of the uncoupler)
?
I can get (1) to work using a sensor which controls the light.? I can get( 2) to work by setting the light controller type to timed on and setting the on duration accordingly.? What I cant do is to get the button(sensor) colour to change back when the
uncoupler (light) switches off.
?
Can anyone tell me what I am missing?
?
?
|
I would use a simple LogixNG.
Dave Sand
? ? ? ? ? ? ? ? ? ?
----- Original message -----
Subject: [jmriusers] Timed control of (servo actuated) uncoupler
Date: Sunday, September 08, 2024 4:36 AM
I am trying to implement a timed control of an uncoupler, which is actuated by a servo (the servo moves a permanent magnet so it is either near to the track or distant from the track).? The JMRI documentation says that 'lights' are specifically designed for uncouplers, but Im struggling to get the combination of lights/sensors to do what I want.
?
What I want is
1. to push a 'button' (sensor?) on my layout panel to activate the uncoupler (light)
2. for the uncoupler (light) to stay on for a period of time then switch off
3. for the colour of the button (sensor?) to change when I first push it, and then to change back when the uncoupler (light) switches off after the programmed period of time (so the button colour at all times reflects the state of the uncoupler)
?
I can get (1) to work using a sensor which controls the light.? I can get( 2) to work by setting the light controller type to timed on and setting the on duration accordingly.? What I cant do is to get the button(sensor) colour to change back when the uncoupler (light) switches off.
?
Can anyone tell me what I am missing?
?
?
|
Nigel that idea seemed to work.? I couldn't create a light icon in layout editor but I could create another sensor tied to the hardware address activated by the first sensor.? It does seem overkill to use two sensors and a light however, when the 'lights' function is specifically described as being designed for controlling un-couplers.??
|
James,??
this is what I'd describe as a "classic mistake" - wrong editor/panel type.?
Historically:?
?- Layout Editor is for producing a logical model of the layout; which turnouts connect to which, how the signals interwork, where the block boundaries may lie.??
?- Panel Editor is for producing a control panel where the designer has control over visual appearance and user-interface behaviour.??
There's been a fair bit of blurring of the lines in more recent years, but that starting point seems to still hold true; as you've found with not being able to add a "light" to a Layout Editor Panel.??
Its quite possible, and I'd suggest sensible, to do the logical model in Layout Editor, and then create the actual control panel(s) which will be used to operate things in Panel Editor.??
( The alternative approach of some LogixNG, as suggested by Dave Sand, may be as easy to do - depends how many uncouplers you have.? ?If lots, there will be ways of writing a generic piece of LogixNG which can apply to any of the uncouplers
which?are relevant.? ? ? It could also do away with needing "lights" for the time-out, the time-out would happen in the LogixNG ).??
- Nigel
toggle quoted message
Show quoted text
------ Original Message ------
Date 08/09/2024 17:35:24
Subject Re: [jmriusers] Timed control of (servo actuated) uncoupler
Nigel that idea seemed to work.? I couldn't create a light icon in layout editor but I could create another sensor tied to the hardware address activated by the first sensor.? It does seem overkill to use two sensors and a light however, when the 'lights'
function is specifically described as being designed for controlling un-couplers.??
|
So, Nigel, how do two different based panels operate together to control and display one layout? Are they automatically linked somehow? Won't there be conflicts?
I've had enough trouble trying to represent my layout in Layout Editor, without the added complication of also doing a Panel Editor representation....
Don W
-- Don Weigt Connecticut
|
Don,
Both types of panel displays show the same basic table entries
(turnouts, sensors, signals, etc.) in graphic form on a "panel"
window. Because both types of display rely on the same underlying
tables, there is no conflict in the data being displayed. The main
differences are in how the displays are created, not in the data
content itself. There are some tables that are only used by one
method or the other, but obviously that in itself doesn't cause
conflicts.
There are some use cases where you are only interested in storing
the table data, and you may be saving a "panels" file with no
panel window defined at all.
Dick :)
On 9/8/2024 4:11 PM, Don Weigt wrote:
toggle quoted message
Show quoted text
So, Nigel, how do two
different based panels operate together to control and display
one layout? Are they automatically linked somehow? Won't there
be conflicts?
I've had enough trouble
trying to represent my layout in Layout Editor, without the
added complication of also doing a Panel Editor
representation....
Don W
--
Don Weigt
Connecticut
|
Nigel
?
I had a feeling this might be the case ("this is what I'd describe as a "classic mistake" - wrong editor/panel type.").
?
Your point is well noted however I'm trying to keep things as simple and self explanatory as possible, basically a drawing of the layout where the things you need to 'press' are represented on the drawing at the same place they are on the layout, or at the bottom -? hence using layout editor.? I'm not (at this stage) aiming to simulate, in the control panel, real railway signalling/operation, just to be able to control all the turnouts, signals and uncouplers in more or less the same was as I would with physical switches.
?
I will likely end up with 6 - max 10 un-couplers for my terminus layout (Helston in Cornwall).? I haven't yet worked out the uncoupling plan, I need first to get the 'prototype' uncoupler design working.? I am toying with having just one or two switches that operate all the uncouplers (or a defined subset of them - eg all the ones on any physical board) simultaneously.? ?It seems simpler just to press a button to uncouple rather than having to worry about which to press; obviously I will be likely be limited by the current draw (which I have yet to measure).
?
For now I will stick with the two overlaid sensors and a light, but might try the logix approach if it turns out I do need lots of separate switches.? Thanks both Nigel and Dave.
|
Don W,
A good way to think about the editors is this: they all pull from the
same tables for what they display or allow interaction. That's the
basic idea. Now the Layout Editor is building a number of those tables
by collection lots of interconnection and interaction details about
different table elements while also making a graphical display. That
building of additional information is the prime difference of Layout
Editor.
An example would be both editor types can draw a line. In Panel Editor
it is just a graphic thing going from here to there. But a line in the
Layout Editor establishes that one element at one location is
connected in some way to another element. Some of these connection
ideas don't even create lines. An example here would be signal masts
being connected to block boundaries. That establishes what sort of
things the logic for that signal should consider in figuring out the
aspect to be displayed.
But a sensor, turnout, etc... may be displayed on either or both types
of panels at the same time. With care you can even have two Layout
Editor panels sharing parts like a master display and a local display
of just one part. You could have one panel that shows a layout as a
physical map with curves, tunnels, etc... which a different panel
shows it as a strictly logic layout like the model board part of a CTC
panel.
-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
|
James P,
I would say a good example of one button operating a number of
uncoupling magnets would be along a yard ladder. In some places on
Bruce Chubb's layout do this. One button and a dotted line to some
spots on the panel showing there be uncoupling magnets here. Other
places there are single buttons for single uncoupling magnets. Both
methods fit different needs and can be used as wanted.
One layout made sure people knew where those uncoupling magnets were.
If you saw a yellow barrel, it was an electric magnet type. But a red
barrel meant there was a fixed magnet at that spot. I think that is
important so the operators know exactly where to lineup and do the
uncoupler dance.
-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
|
Thank you, Ken. I got much of the same information from Nigel. I think I understand what you are saying. My primary concern is from my experience having carefully entered tables disappear when opening a panel where I had changed from simulation to a hardware interface that wasn't yet there.
It would be frustrating if an error in one panel or opening one caused deletion of good information in the tables. It's tedious to build or rebuild them, and they have to be perfect...
Don W
-- Don Weigt Connecticut
|
Don,
as per the other replies.? ?The editors are a presentation of the underlying data.? ? There are no conflicts, it is all one set of data.??
It is only an "added complication" if you view it that way.? ?An alternative view is that a Panel Editor allows you to have exactly what you want on the displays, whilst the Layout Editor allows easier creation of rules for blocks, routes, signals, etc..?
? ? I find it easier to split things up and achieve the desired end results.?
You could try it fairly trivially by creating a Panel Editor "panel" with a handful of icons on it,? those icons work with turnouts/blocks/sensors/whatever on your Layout Editor.? ? An possible design exercise to learn how this behaves might be a small
area panel, designed for a phone screen without any scrolling.? The end result should be something which can display well on a phone, with active icons large enough for use with fingers.? ?
The harder work is the graphic appearance, designing the background visual, and then individual icons.??
- Nigel
toggle quoted message
Show quoted text
------ Original Message ------
Date 08/09/2024 21:11:17
Subject Re: [jmriusers] Timed control of (servo actuated) uncoupler
So, Nigel, how do two different based panels operate together to control and display one layout? Are they automatically linked somehow? Won't there be conflicts?
I've had enough trouble trying to represent my layout in Layout Editor, without the added complication of also doing a Panel Editor representation....
Don W
--
Don Weigt
Connecticut
|
Don W,
It is strongly recommended that only one file is used for JMRI to hold
all the tables and different panels. If you are reading in multiple
files, what you end up with is a merge of all of them, with the final
result being whatever was the last change of something. I'm meaning if
the same sensor system name was in two files, but different user
names, the result would be the user name from the second file.
Anything in the second file will overwrite what was done by the first
file.
The multiple files always add, they won't delete but will change to
the values from the last file loaded. Only using a single file insures
what you have in the load.
Generally it is much safer and easier to use a simulated interface
when developing for eventual hardware. Now I've started designs using
all internal when we haven't picked the hardware yet. But if we have
decided on the hardware system and figured out what we would be
buying, then I use a simulated connection while developing that
layout.
-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
|
Nigel,
Thank you for the suggestion and encouragement.
Don W
-- Don Weigt Connecticut
|
Ken Cameron