My home brew I/O cycles through all inputs and outputs in less than 250 ms. Any slower becomes very annoying. I have 8 bytes of photodetector input data, and 16 of turnout position. These need to be read frequently, or they will lag too much.

My railroad as formerly built also had about 25 output bytes. They only need to be written to for initializing and when an output changes. But, the outputting needs to be fast, or it will delay the inputting too much.

What is realistic response time for driving signals and turnouts, and reading turnout positions and occupancy detectors? Is it really several seconds, or even longer?

You’re assuming that thread is about normal behavior. It’s not. That’s why the question was being asked.

JMRI only a reasonable PC will issue about 50-100 polls a second. Most of the delay is in node-response time and USB delays; JMRI itself takes about 1-2msec to get to the next poll (it deliberately waits a little time to see if the poll’s data generated any output it should send) For 10 nodes, that’s about 5-10 polls a second, and there’s little visible delay.

As to complexity: On one very-large layout where JMRI replaced a BASIC program, the polling rate went _up_ with the conversion; JMRI reacted significantly faster after each poll. JMRI doesn’t recompute everything after every poll, only what was needed due to the changes that came in the data. Most of the time, nothing changes, and what looks like complexity to BASIC programmers turns into speed. Certainly, different people have different hobbies. Some like to write their own one-off BASIC, and that’s great. Several people have made improving JMRI’s C/MRI support part of their hobby, and the result of that work has been benefit to everybody who uses it.

Bob

On Jan 10, 2019, at 9:04 AM, Don Weigt <dweigt47@...> wrote:


I find it hard to believe JMRI used with C/MRI is useful if it runs that slowly. It seems useless for things like scanning control panel switches and such. If that ~ 1 second cycle is to read all input data, it's too slow. If it's for each byte? Yikes!

As I recall, C/MRI boards simply respond when polled. That should be quite fast. What's causing the delay? Is C/MRI still running in BASIC? Is JMRI so complex it's slow?

My home brew I/O cycles through all inputs and outputs in less than 250 ms. Any slower becomes very annoying. I have 8 bytes of photodetector input data, and 16 of turnout position. These need to be read frequently, or they will lag too much.

My railroad as formerly built also had about 25 output bytes. They only need to be written to for initializing and when an output changes. But, the outputting needs to be fast, or it will delay the inputting too much.

What is realistic response time for driving signals and turnouts, and reading turnout positions and occupancy detectors? Is it really several seconds, or even longer?

--
Bob Jacobsen
rgj1927@...

I've not measured the local CMRI layout to see what the timing is since
we've not had any problems. Last time I was doing any real measuring was for
Dr Chubb and I was focused on the difference of USB vs native serial ports.
That was about 10 years ago and right now I'm not sure of the details. I'd
have to take new measurements.

One thing I'm suspect of is the normal loop timing in an Arduino board. They
make it very easy to add delays and timeouts for many things as you code.
How that impacts the serial port response could also impact the whole CMRI
bus. But I've not got any of those at hand, only the OP has those and we are
relating what he is seeing vs 'normal' CMRI-JMRI interaction times.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org

Ah, any gaps in the board addresses?

Jim Albanowski

开云体育

You don't need to compute the delays, use the "CMRINet metrics" under CMRI on the PanelPro control panel, it displays them for you.

From the topic Setting serial port speed for CMRI connection to JMRI
From: Ken Cameron
Date: Thu, 10 Jan 2019 08:11:39 EST
Jerry,

Keep in mind that JMRI will poll a node then give it time to reply. Then it
gets that reply or times out before polling the next node. So how fast each
node responds adds up quick. Use the Command Monitor under CMRI to watch the
traffic and do your timings. I would take a sample to a file for 10-20
seconds. Then using Excel I'd process it and compute the delays and
specifically look for how much any single delay varies. So if a given node
usually replying in 50mSec but every now and then 300mSec, I'd be curious
why.

-Ken Cameron, Member JMRI Dev Team


I find it hard to believe JMRI used with C/MRI is useful if it runs that slowly. It seems useless for things like scanning control panel switches and such. If that ~ 1 second cycle is to read all input data, it's too slow. If it's for each byte? Yikes!

?

As I recall, C/MRI boards simply respond when polled. That should be quite fast. What's causing the delay? Is C/MRI still running in BASIC? Is JMRI so complex it's slow?

?

My home brew I/O cycles through all inputs and outputs in less than 250 ms. Any slower becomes very annoying. I have 8 bytes of photodetector input data, and 16 of turnout position. These need to be read frequently, or they will lag too much.

My railroad as formerly built also had about 25 output bytes. They only need to be written to for initializing and when an output changes. But, the outputting needs to be fast, or it will delay the inputting too much.

What is realistic response time for driving signals and turnouts, and reading turnout positions and occupancy detectors? Is it really several seconds, or even longer?

-- 
Seth Neumann
Mountain View, CA

On my layout, I have 17 SMINI's and 1 SUSIC running at 19,200. I have not had any real problems with response time with JMRI. This was on a Windows 7 machine that is 7 years old. Prior to that, it was on a WIndows 2000 machine, which also was fine.
A couple of years ago, I switched over to VB6. No dissatisfaction with JMRI; just decided to have a go at VB6. It turned out I enjoyed doing the programming, which was a surprise to me. I found that there was a noticeable improvement in response time when I switched to VB6. It jumps out at you, more or less like getting a new computer does. But, JMRI was fine when I was using it.

Michael Pennie

开云体育

I am running 7 SMINIS at 28800 baud and there is no noticeable response lag at all. Using a quad core i7 Mac mini with 10 go ram and a ssd.?

Seth,

Thanks for reminding me about the metrics. I hadn't thought of them since
I've not had to go looking for stuff like that and forgot some of the other
good stuff that got put into the system last year when the whole interface
for CMRI nodes got greatly improved. It really is a nice result compared to
what we used to have.

I'll have to play with that next time at the layout.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org

开云体育

Yes the metrics was one of the things Chuck Catania worked on.??? We'll miss him!

Seth,

Thanks for reminding me about the metrics. I hadn't thought of them since
I've not had to go looking for stuff like that and forgot some of the other
good stuff that got put into the system last year when the whole interface
for CMRI nodes got greatly improved. It really is a nice result compared to
what we used to have.

I'll have to play with that next time at the layout.

-Ken Cameron, Member JMRI Dev Team

-- 
Seth Neumann
Mountain View, CA

Metrics tell me (and confirmed on the CMRI Monitor) that my Arduinos respond to a poll in 50-150ms, depending on which of my Arduino code sketches I’m running. ?None of these times seem to be a problem for JMRI as I’m getting regular polling with no extra “INIT”s. ?

What the metrics don’t tell me but is easily determinable via the CMRI Monitor is that JMRI cycles its next poll in 15-16ms (JMRI 4.15.1 running on an old Dell with Windows 7 running a single Arduino as a SMINI node). ?When I add a node to the JMRI configuration but don’t actually attach hardware, JMRI waits for 250-280ms before timing out on the phantom node before doing its next poll of the real node. ?When I had three phantom nodes (which were all there at one time or another but removed for upgrade or testing), I was seeing about a 1 second full cycle time. ?Moral of the story: ?disable polling to any nodes not physically present. ?Uncheck box to do this on the CMRI Network Manager window.

In the course of doing this testing, I found several things in the use of CMRI tools that either I don’t understand or are idiosyncratic to the use of Arduinos as CMRI nodes or possibly are real bugs, all of which I will document in a new thread tomorrow.

Jerry
___________________________________
jerryg2003@...

开云体育

With my 40 years plus in industrial automation I can tell you that when doing communications over a serial buss with one master and multiple slaves that have a slave drop off will always adversely affect the entire poling scheme. Many times it crashes the entire network and halts all communications.?

Don W -

My layout is relatively small (about 45 feet of mainline plus various sidings, etc.), but I’m working on making it “action packed” so I get what you are saying.