|
I'm just starting to delve into LogixNG. It certainly looks ingenious and powerful. But I wonder, how does it compare in performance to performing the same tasks in a Jython program? Is there any overhead?
?
Thanks
George
|
George,
That is an interesting question.
Here is a simple LogixNG. ?It waits for a sensor state change and then replicates that change to another sensor.
?
Here is the same logic using Jython.
import java
import jmri
class Bridge(java.beans.PropertyChangeListener):
??? def propertyChange(self, event):
??????? t1 = java.util.Calendar.getInstance().getTimeInMillis()
??????? print 'start event :: {}'.format(t1)
??????? src = sensors.getSensor(str(event.getSource()))
??????? srcname = src.getDisplayName()
??????? destname = 'LCC' + srcname[3:]
??????? dest = sensors.getSensor(destname)
??????? dest.setCommandedState(src.getKnownState())
??????? t2 = java.util.Calendar.getInstance().getTimeInMillis()
??????? print 'event done :: {}'.format(t2)
b = Bridge()
s = sensors.getSensor('LNT-Jython')
s.addPropertyChangeListener(b)
print 'pcl added to {}'.format(s.getDisplayName())
Here is the console log output.
16:14:58,525 jmri.jmrit.logixng.actions.LogData??? WARN? - start [JMRI LogixNGThread]
16:14:58,531 jmri.jmrit.logixng.actions.LogData??? WARN? - done [JMRI LogixNGThread]
start event :: 1742332499718
event done :: 1742332499720
16:15:38,074 jmri.jmrit.logixng.actions.LogData??? WARN? - start [JMRI LogixNGThread]
16:15:38,075 jmri.jmrit.logixng.actions.LogData??? WARN? - done [JMRI LogixNGThread]
start event :: 1742332539710
event done :: 1742332539711
There is extra overhead to capture the run times. ?There is also some "first time" overhead.
Of course, there will be differences depending on the actual logic. ?Another issue is selecting how to implement the logic.
For example, the LogixNG uses the "Listen on beans" action. ?This is very efficient. ?This can also be done using a a very long if-then-else-if statement. ?This would not be efficient.
I have not seen any noticeable differences in performance.
Dave Sand
----- Original message -----
Subject: [jmriusers] LogixNG vs Jython performance #logixng #jython
Date: Tuesday, March 18, 2025 10:00 AM
I'm just starting to delve into LogixNG. It certainly looks ingenious and powerful. But I wonder, how does it compare in performance to performing the same tasks in a Jython program? Is there any overhead?
?
Thanks
George
|
Thanks Dave
As I am just learning LogixNG a lot of your reply is a bit beyond my understanding at the moment. For example I am not understanding why legumes are involved. However I believe that your answer indicates that any overhead involved when using LogixNG is small or can be made small if programmed wisely.
?
George
|
George,
A "bean" is a Java object that has a set of characteristics. ?In the JMRI, most of the table items, such as turnouts, sensors, etc., are implement as Java beans.
Dave Sand
----- Original message -----
Subject: Re: [jmriusers] LogixNG vs Jython performance #jython #logixng
Date: Thursday, March 20, 2025 10:02 AM
Thanks Dave
As I am just learning LogixNG a lot of your reply is a bit beyond my understanding at the moment. For example I am not understanding why legumes are involved. However I believe that your answer indicates that any overhead involved when using LogixNG is small or can be made small if programmed wisely.
?
George
|
George,
?
After remaining as a silent observer on this thread, at least one observation seems worth floating.
?
"But I wonder, how does it compare in performance to performing the same tasks in a Jython program? Is there any overhead?"
?
In fact there is some overhead in all of the options that JMRI offers for customizing any installation to a particular layout.? In most cases, that overhead is slight, perhaps even undetectable.
?
Chasing through all of the "time used" vs "dynamic memory used" vs "storage memory used" vs "I/O bandwidth needed" vs "operational connivence" or any of the other kinds of optimization metrics is not likely to provide us with any warm-fuzzy feelings.? Nor is it even slightly useful with today's technology.??
?
What is important boils down to only a few questions:
- Is the method used easily accessible to the person doing the modification?
- Will it be understandable to someone needing to do future maintenance, as in a club environment??
- Is the result easily understandable to the people running the layout?
?
It is your hobby, do what you enjoy.
?
Others may have strongly held preferences.
?
Cliff in Baja SoCal
?
|
On Fri, Mar 21, 2025 at 02:02 AM, George Hofmann wrote:
For example I am not understanding why legumes are involved.
Pay that!
I find myself using LogixNG more and more and I did wonder what the overhead was.
What does catch me out occasionally is Execute on Change vs. Always Execute. The conditional doesn't execute even though I reckon it should have. Sometimes I give up trying to figure out why and just make it Always Execute.
?
Therefore, what is the performance penalty of one over the other? I assume in either case it still has to test the conditions.
--
H.O. Australia (Layout in Progress)
Digikeijs DR5000 LocoNet
JMRI v5.10 DecoderPro/Warrants/CPE/SML/LogixNG
Java: OpenLogic jre-17.0.12.7 ? Windows 10
|
On Thu, Mar 20, 2025 at 10:33 AM, Cliff Anderson wrote:
What is important boils down to only a few questions:
- Is the method used easily accessible to the person doing the modification?
- Will it be understandable to someone needing to do future maintenance, as in a club environment??
- Is the result easily understandable to the people running the layout?
- ?
Cliff
Well said! I am trying to get that point across to my club members. We have a complex Train Controller installation that nobody understands. LogixNG might replace part of it and allow for better understanding and maintenance.
?
George
|
Nags,
The test still occurs, but the issue is what happens after the test. ?A related factor is what causes a ConditionNG to execute.
With the exception of ConditionalNGs configured to run after file loading, most of them are activated by a change to an item in an If-then-else action. ?The default is that items added to the "if" have the "listen" setting enabled. ?A change to one of these will start the ConditionalNG. ?Items that have "listen" disabled will not start the ConditionalNG but will be evaluated to determine the true/false state of the if-then-else.
It can help to separate the trigger events from checks for item states. ?For example, think of a yard ladder with sensor buttons for each track and an occupancy sensor for the turnout ladder. ?The sensor button will trigger a ConditionalNG for the selected track. ?The sensor is defined as "listen" and the if-then-else is "on change". ?When that test is true, a second if-then-else checks for other items, such as ladder block occupancy, etc. ?These are defined as "no listen" which prevents unplanned running of the ConditionalNG. ?This if-then-else is also set to "always execute" since the occupancy might not have changed since the last run. ?When this is true, the turnouts can be set.
For this example, a "sensor group" is used to make sure that only one track button is active. ?One ConditionalNG will run when its sensor becomes inactive resulting in the first test being false which does nothing. ?Another ConditionalNG will run when its sensor becomes active. ?This one will do more work.
Dave Sand
----- Original message -----
Subject: Re: [jmriusers] LogixNG vs Jython performance #jython #logixng
Date: Thursday, March 20, 2025 4:11 PM
On Fri, Mar 21, 2025 at 02:02 AM, George Hofmann wrote:
For example I am not understanding why legumes are involved.
Pay that!
I find myself using LogixNG more and more and I did wonder what the overhead was.
What does catch me out occasionally is Execute on Change vs. Always Execute. The conditional doesn't execute even though I reckon it should have. Sometimes I give up trying to figure out why and just make it Always Execute.
?
Therefore, what is the performance penalty of one over the other? I assume in either case it still has to test the conditions.
--
H.O. Australia (Layout in Progress)
Digikeijs DR5000 LocoNet
JMRI v5.10 DecoderPro/Warrants/CPE/SML/LogixNG
Java: OpenLogic jre-17.0.12.7 ? Windows 10
|
Thanks Dave.
I can understand why one might not want to repeat an action or have an item trigger an evaluation.?
However, in most of my CNGs either of these don't matter, so I'm more comfortable with Always Execute.
If the overhead is insignificant then it's probably much of a muchness.
--
H.O. Australia (Layout in Progress)
Digikeijs DR5000 LocoNet
JMRI v5.10 DecoderPro/Warrants/CPE/SML/LogixNG
Java: OpenLogic jre-17.0.12.7 ? Windows 10
|
Regarding George's question about efficiency and the observations that followed, I'll add some of my own perhaps practical observations.? I'm addressing the larger aspects of developing a signal system.?
?
I'm finally close to having a finished switchable ABS/CTC LogixNG layout control application, that has five controlled sidings, a dozen intermediate signals, and at least a hundred occupancy sensors.? It is controlled by a JMRI-graphics CTC lever panel that properly emulates a Western Pacific office machine, including all the panel lamps and levers and working US&S 506 Time-Code code lamps and recorded relay audio, with proper time delays doing field I/O.? This covers half our club layout, and I'll finish the other half in the next year or so.? I'm using CMRI hardware on a 56Kbaud serial bus to several cpNode controllers in the "field" (layout room) for I/O.? The turnout controllers are custom, and can emulate both Dual Control and Electric Locked switches;? each have 6 I/O pins for control and position/lock feedback.? There are several hundred items in the JMRI sensor and turnout tables, and many in the Heads, Masts and audio tables.? All the signal logic is done in LogixNG (vs. SML, SSL, CTC, etc).? In other words, I did everything with LogixNG.? There are two large graphics panels (the CTC office panel and a "field" monitor panel) and a couple minor ones.
?
So, how big is the software?? The XML file is 12MB, which has 250K lines of code in the file (all generated with PanelPro).? I don't know how this compares to other large layouts.? I'm guessing the final build-out will be 50% larger.? I'm using the latest production release of PanelPro and JAVA 17.? I'm developing this on my newer Windows laptop (in SIM mode), and running the layout-connected app on a newer modest Windows desktop machine, both on Win11.?
?
How does it run?? It starts on both platforms very rapidly (a few seconds), and runs below 10% of the CPU.? I'm not seeing any real-time lags in doing anything.? I haven't seen any odd behavior in the aspects of the ~50 signal masts over several hours of use during ops, nor seen any lockups or odd System Console errors being thrown.? Not sure why I'd want or need to make it more efficient.? I'm not seeing anything that's a problem, and those I've issues I've reported get fixed pretty quick (other than my request for a feature to clear the clipboard... bump).
?
How about ability to maintain this monster app??? That's perhaps the big challenge, even for the developer (me).? While I'm actively working on it and have the full context in my brain, it's easy to do.? On the other hand, if months go by I do forget a lot of how things are being done and where.? To mitigate that I've maintained WORD, EXCEL, and VISIO docs as I've gone along that covers tables, contents, functions, strategies and flows that get me back up to speed.? It also has notes on how LogixNG does things (not always intuitive or well documented online).? As always, a straight-forward elegant design is always going to be easier to learn/maintain than a chaotic undocumented design.? I've tried to be clear and consistent doing things vs. clever and inconsistent.? I think I've used almost all the LogixNG features except for Modules, Sensor Groups and Servers.? Regarding others doing the maintaining?? That's going to be a big lift.?
?
Even if a club has programing members, few are going to be experienced in LogixNG.? I've talked to a lot of guys, some railroad signalmen, that learned and are using the original Logix and consider the jump to LogixNG would be difficult, and that the older Logix is closer to the railroad relay logic they know well.? Knowing both (relay logic and programming languages), I'm not so sure the latter is true, but LogixNG does have more "stuff" it can do and has more to learn to get that power.? It has taken months to figure out how to use the "new" features I needed, so they have a point.? BUT, no way would I want to try to do everything I'm doing with Logix.? In the end, learning the features paid off but it was a lift.? Makes a lot of us wish there were classes on this stuff, but in their absence we have this GIO group.? *Lots* of times the regulars on this forum got me unstuck, and I'm not sure what the alternative is.
?
Long term viability?? The older versions of JMRI and JAVA stick around, so I don't see big risk in letting a production machine run for years without updating.? This is more like a machine controller application that will work fine for a long time once solid and left alone, vs. something that's dynamically being pushed along over time.? Now, if the layout changes, then that's a functionally driven change.? Our layout computer is strictly offline (standalone) so that I don't have to worry about Microsoft updating and breaking something, which is a real thing.? We also have strict change control since operations is a key part of the club.?
?
Nor do I think the JMRI team is at risk of going away any time soon.? The team is strong from what I can see, and use good procedures.
?
Alternative JMRI approaches?? I don't know anything about the "packaged" signal solutions to comment.? I do know I'm approaching the signal control points and signal aspects the way the railroad signal department does, regarding input factors and control outputs.? I also have a prototype in mind and want to emulate that operation precisely, both in the field (layout) and in the DS office (CTC control panel).? I'm doing route signaling so don't have a huge set of aspects.? My goal was to have the flexibility to do what I wanted vs. take what the "package" provides (and assuming it has tradeoffs I don't want).? No doubt these "packaged" solutions will get better and perhaps at some point overtake the complex if-then-else digital formulas approach I'm doing.? Lots (most?) layout owners probably don't feel a need for precise control and are happy for all the help they can get with signals... they *are* hard.? From what I've seen, the JMRI team knows railroad signaling, so I'm assuming the "packaged" solutions are going to be pretty good, albeit generic else slanted to certain prototypes.?
?
Like everything about a hobby, there are tradeoffs... what makes you happy, and how much time/money you have for a task.? Signals are a big task no matter how you do them and not quick.? JMRI LogixNG is a safe and effective choice small or large, and I suspect the "packaged" signaling solutions will also work fine.
?
--
Jim Moomaw
Portland, OR
- Willamette Model Railroad Club (WMRC)
- NMRA, Pacific NW
|
Jim,
The signal systems used by signal mast logic (SML) are usually based on prototype rule books. ?The quality of the implementation does vary. ?SML implements ABS. ?APB and CTC are then implemented with other logic such as LogixNG.
Dave Sand
----- Original message -----
Subject: Re: [jmriusers] LogixNG vs Jython performance #jython #logixng
Date: Saturday, March 22, 2025 5:01 AM
Regarding George's question about efficiency and the observations that followed, I'll add some of my own perhaps practical observations.? I'm addressing the larger aspects of developing a signal system.?
?
I'm finally close to having a finished switchable ABS/CTC LogixNG layout control application, that has five controlled sidings, a dozen intermediate signals, and at least a hundred occupancy sensors.? It is controlled by a JMRI-graphics CTC lever panel that properly emulates a Western Pacific office machine, including all the panel lamps and levers and working US&S 506 Time-Code code lamps and recorded relay audio, with proper time delays doing field I/O.? This covers half our club layout, and I'll finish the other half in the next year or so.? I'm using CMRI hardware on a 56Kbaud serial bus to several cpNode controllers in the "field" (layout room) for I/O.? The turnout controllers are custom, and can emulate both Dual Control and Electric Locked switches;? each have 6 I/O pins for control and position/lock feedback.? There are several hundred items in the JMRI sensor and turnout tables, and many in the Heads, Masts and audio tables.? All the signal logic is done in LogixNG (vs. SML, SSL, CTC, etc).? In other words, I did everything with LogixNG.? There are two large graphics panels (the CTC office panel and a "field" monitor panel) and a couple minor ones.
?
So, how big is the software?? The XML file is 12MB, which has 250K lines of code in the file (all generated with PanelPro).? I don't know how this compares to other large layouts.? I'm guessing the final build-out will be 50% larger.? I'm using the latest production release of PanelPro and JAVA 17.? I'm developing this on my newer Windows laptop (in SIM mode), and running the layout-connected app on a newer modest Windows desktop machine, both on Win11.?
?
How does it run?? It starts on both platforms very rapidly (a few seconds), and runs below 10% of the CPU.? I'm not seeing any real-time lags in doing anything.? I haven't seen any odd behavior in the aspects of the ~50 signal masts over several hours of use during ops, nor seen any lockups or odd System Console errors being thrown.? Not sure why I'd want or need to make it more efficient.? I'm not seeing anything that's a problem, and those I've issues I've reported get fixed pretty quick (other than my request for a feature to clear the clipboard... bump).
?
How about ability to maintain this monster app??? That's perhaps the big challenge, even for the developer (me).? While I'm actively working on it and have the full context in my brain, it's easy to do.? On the other hand, if months go by I do forget a lot of how things are being done and where.? To mitigate that I've maintained WORD, EXCEL, and VISIO docs as I've gone along that covers tables, contents, functions, strategies and flows that get me back up to speed.? It also has notes on how LogixNG does things (not always intuitive or well documented online).? As always, a straight-forward elegant design is always going to be easier to learn/maintain than a chaotic undocumented design.? I've tried to be clear and consistent doing things vs. clever and inconsistent.? I think I've used almost all the LogixNG features except for Modules, Sensor Groups and Servers.? Regarding others doing the maintaining?? That's going to be a big lift.?
?
Even if a club has programing members, few are going to be experienced in LogixNG.? I've talked to a lot of guys, some railroad signalmen, that learned and are using the original Logix and consider the jump to LogixNG would be difficult, and that the older Logix is closer to the railroad relay logic they know well.? Knowing both (relay logic and programming languages), I'm not so sure the latter is true, but LogixNG does have more "stuff" it can do and has more to learn to get that power.? It has taken months to figure out how to use the "new" features I needed, so they have a point.? BUT, no way would I want to try to do everything I'm doing with Logix.? In the end, learning the features paid off but it was a lift.? Makes a lot of us wish there were classes on this stuff, but in their absence we have this GIO group.? *Lots* of times the regulars on this forum got me unstuck, and I'm not sure what the alternative is.
?
Long term viability?? The older versions of JMRI and JAVA stick around, so I don't see big risk in letting a production machine run for years without updating.? This is more like a machine controller application that will work fine for a long time once solid and left alone, vs. something that's dynamically being pushed along over time.? Now, if the layout changes, then that's a functionally driven change.? Our layout computer is strictly offline (standalone) so that I don't have to worry about Microsoft updating and breaking something, which is a real thing.? We also have strict change control since operations is a key part of the club.?
?
Nor do I think the JMRI team is at risk of going away any time soon.? The team is strong from what I can see, and use good procedures.
?
Alternative JMRI approaches?? I don't know anything about the "packaged" signal solutions to comment.? I do know I'm approaching the signal control points and signal aspects the way the railroad signal department does, regarding input factors and control outputs.? I also have a prototype in mind and want to emulate that operation precisely, both in the field (layout) and in the DS office (CTC control panel).? I'm doing route signaling so don't have a huge set of aspects.? My goal was to have the flexibility to do what I wanted vs. take what the "package" provides (and assuming it has tradeoffs I don't want).? No doubt these "packaged" solutions will get better and perhaps at some point overtake the complex if-then-else digital formulas approach I'm doing.? Lots (most?) layout owners probably don't feel a need for precise control and are happy for all the help they can get with signals... they *are* hard.? From what I've seen, the JMRI team knows railroad signaling, so I'm assuming the "packaged" solutions are going to be pretty good, albeit generic else slanted to certain prototypes.?
?
Like everything about a hobby, there are tradeoffs... what makes you happy, and how much time/money you have for a task.? Signals are a big task no matter how you do them and not quick.? JMRI LogixNG is a safe and effective choice small or large, and I suspect the "packaged" signaling solutions will also work fine.
?
--
Jim Moomaw
Portland, OR
- Willamette Model Railroad Club (WMRC)
- NMRA, Pacific NW
|
On Thu, Mar 20, 2025 at 02:11 PM, Nags wrote:
What does catch me out occasionally is Execute on Change vs. Always Execute. The conditional doesn't execute even though I reckon it should have. Sometimes I give up trying to figure out why and just make it Always Execute.
Nags
I was having the same problem. It turned out that I was just not thinking through the logic properly. Once I realized my foolishness the execute on change started working as advertised. In my case I was expecting the If to trigger when the condition became false, but it turned out that that condition was usually false due to other inputs, so that when the input I was trying to catch turned false, nothing happened because there was no logical change to the set of monitored inputs taken as a whole. So my advice is to study your logic thoroughly and maybe you can fix the issue.
?
George
|
On 3/22/2025 0:01 AM11:06 AM, Jim Moomaw wrote: _So, how big is the software?_? The XML file is 12MB, which has 250K lines of code in the file (all generated with PanelPro).? I don't know how this compares to other large layouts.? I'm guessing the final build- out will be 50% larger. I have implemented two GRS Type K Model M Coded CTC implementations, prototypically. One has a 5-column office machine, and was my first attempt at prototypical signaling. I am currently working on a second GRS CTC implementation, with an office machine with 23 populated columns, with 35 CTC-controlled signal masts and 8 ABS signal masts, with about 45 occupancy blocks. It is implemented largely by un-modified JMRI "SML", with some "overrides" of certain signal mast aspects via Logic. The "code line" and "logic" that is nearest the code line is implemented in Jython, much in the same way that GRS had implemented its "boxes" in the "Field" and in the "Office". For my second CTC solution, the JMRI XML file is less than 3 MBytes, and the Jython is another ~400 KBytes. So I might _guess_ that my solution is smaller than your implementation, (This assumes that you do not have any "other" JMRI features that take up lots of space in the XML file...) The idea that (prototype) "signaling is hard" is an understatement! Getting signaling "right" is not for the faint of heart! The second CTC solution I mentioned has taken 2-plus years of development and debugging, so far, and still LOTS of things to "fix"...
|
On Sun, Mar 23, 2025 at 02:39 AM, George Hofmann wrote:
Nags
I was having the same problem. It turned out that I was just not thinking through the logic properly. Once I realized my foolishness the execute on change started working as advertised. In my case I was expecting the If to trigger when the condition became false, but it turned out that that condition was usually false due to other inputs, so that when the input I was trying to catch turned false, nothing happened because there was no logical change to the set of monitored inputs taken as a whole. So my advice is to study your logic thoroughly and maybe you can fix the issue.
?
George
Yep, I've encountered that myself and I do get the 'if the state doesn't change do nothing' logic.
I figure unless there's a compelling reason why not,? just go with Always Execute since it seems to always work. Also many of mine are nested ifs and therefore Always Execute is recommended.
--
H.O. Australia (Layout in Progress)
Digikeijs DR5000 LocoNet
JMRI v5.10 DecoderPro/Warrants/CPE/SML/LogixNG
Java: OpenLogic jre-17.0.12.7 ? Windows 10
|
George Hofmann