I am running? Win10 (1909) , Java 1.8.0_231, JMRI 4.17.6, Digitrax PR4 (COM2),? DCS100.

What does the InstallTest report this time around ?

Marc

开云体育

?

Hello

J am using JMRI in France and it's an very beautiful soft

I have two questions to submit to you

First point:

As you say in the documentation, the dispatcher works perfectly with a single train. Yes! it's checked!

It also works with two trains if the transits are different in the positioning of the turnout. Yes it's also true!

There is a problem with the turnout core when the next train switches it when the preceding train is not fully removed from the turnout

This is related to the detection of the train by power consumption that does not always work on both boggies

I found several solutions but imperfect that only works in one direction of circulation

? ?? Enlarge the block (or section) at the heel of the turnout on the network

? ?? for crossover, delay the turnout movement with a logix

Do you have better solution ?

Second point:

I think that a general solution would be to permanently allocate the epending section

For example

? ?? transit with Sect0 - Sect1 - Sect2 - Sect3 etc.

? ?? train with two reserved sections forward

? ?? the train being in Sect1, then allocate Sect0 Sect1 Sect2 Sect3

? ?? the train being in Sect2, then allocate Sect1 Sect2 Sect3 Sect4

Is that possible, and difficult?

sorry for my English?!

Thank you for your answers

A good day

luc

OK, I reverted just the changes which affected $widget.id, and client-side panels are working for me again.
Andy, here is the new version of panel.js if you could test it:??Just replace the version in your JMRI/web/js folder with this one.

@BobJacobsen, if you could put this quick-fix into 4.17.7, that would be great. Or wait until George has a chance to provide a more permanent solution.

Looks like this commit of panel.js is the problem:?
The one before it looks fine, this one does not.
I'm guessing it has something to do with the change to $widget.id. Still looking.....

On Thu, Dec 5, 2019 at 10:36 AM, Andy Brown wrote:

when I loaded the web the labels and sensor are all overlaid onto one spot!!

I see the same thing with my panel. Something is definitely broken. I'll investigate.

Hi? George
I followed (just about!) all the background chatter regarding this issue and I like the final decisions - thanks for your (and others) perseverance!

I just tried an 'early' 4.17.7 (not yet announced) with the changes and was admiring it on the native panel, but when I loaded the web the labels and sensor are all overlaid onto one spot!! The slips looks just fine though! I've uploaded a screenshot so you can see what I mean - /g/jmriusers/files/ProblemsBeingWorkedOn/Andy%20Brown%20-%20161045//CrossoverBlockOccupancyIssue03.pdf?

I tried deleting the cache and even tried it in a 'virgin' Opera browser - same result.

Have I jumped the gun with the version, done something stupid, or is there an issue here?

Thanks
Andy

Ken,

You are correct, for perishable loads, you shouldn't use the alternate track feature.? Instead you could have a yard track for the cars with perishable loads, and operate that yard in the FIFO flow, one of the options for a yard track.? The program when delivering a car with a custom load to a spur, and finds the spur full, will send the car to the nearest yard.? If the driver for cars is staging, the program will limit the number of cars with perishable loads to be created out of staging, thus preventing the overloading of the spur and the yard tracks.

The "Alternate track" feature works for any type of load including the defaults, where the "use a ;yard track when spur full" feature only works for custom loads.

The alternate track feature works best when there's a reasonable number of cars that could be used for the spur and alternate track.? So if you had room for say 3 cars on the alternate, and 1 for the spur, having 6 or possibly less cars servicing that industry could give the program to opportunity to pull cars off the alternate track instead of delivering new ones.

Dan

Thank's all the group !? !? !

Fran?ois?

Dan,

The way you describe the off-spot track would work poorly for any form of
perishable cars. You only 'sometimes' you have extra cars and sometimes not,
the schedule sequence sounds like it would place the newer car at the
off-spot then expect the next train (providing it didn't have that type/load
of car) to move it to the real spot.

The issue I'd see is that it should consider which car is older in terms of
when it got loaded. Then the alternate would get picked at least when it was
older than the car in the train. Most industries tend to use a first-in
first-out flow. Also consider what the normal demurrage rules would be.
Leaving that car on the alternate is going to rack up charges. Quick
rotating them in and out will limit that and if the usual allowance is a
couple of days, it might mean no demurrage charges.

I would expect this behavior might be a bit of a challenge to program. But
from what I've seen, that's more likely what happens in industry.

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

Thanks. It is up and running now. Im going to try to tweak a couple of things. Ie file output and add credit to you in the notes and reupload over ne next couple of days. Thanks again!

Steve N.

Steve,

This has tripped over another method deprecation - this time, the now outdated form of writing to CVs as numerical values (this change was needed to support so-called indexed CVs in many newer decoders).

I've changed the file and uploaded a new version:

/g/jmriusers/files/ProblemsBeingWorkedOn/Speed%20Match%20Loop%20Problem/USpeedMatch_v1.3.3.py

Let's hope that works better for you.

Best regards,

Matt H

Thanks Matt, I might be over my head on this one.? It kicked out another Error.? I believe it applies to all the CV changes. If anyone knows how to get this error to clear I can apply those changes to future ones. (I Hope)
Thanks For Looking at this
Steve N.


i2019-12-05 07:51:58,259 sprog.SprogCommandStation? ? ? ? ? ? ?INFO? - Changing currentSprogAddress (for pseudo-idle packets) to 1(L) [Automated Speed Table]

Hello,

This email message is a notification to let you know that the following files have been uploaded to the Files area of the [email protected] group.

• /ProblemsBeingWorkedOn/dsand/list routes.py

Uploaded By: Dave Sand <ds@...>

Description:
List the output turnouts and sensors in all of the defined Routes.

Cheers,
The Groups.io Team

That’s the issue for me running MTH with other locos not MTH. Got rid of mine.?

Russ A

I am using Panel Pro and have set a number of different routes across my layout. I would like to print the point settings for each of these routes but cannot find a way of doing that. When I edit a route the point settings for that route are shown in a small window which I need to scroll through to see all the points which need to be set for that route. Is there a way of printing the point settings in a table/list?

Jeff,

As you have noted, if the supply of cars with wood chips is available to the train at an earlier location, the program will deliver new cars directly to the spur and bypass the ones sitting on the alternate track. Cars on the alternate have wood chips, and the car in the train also has wood chips, the efficient move is the deliver the car in the train directly to the spur.

Since you have lots of cars with wood chips, and you want to rotate your stock from the "off spot", I would recommend that you not use the alternate track feature but instead create a sequence where new cars are delivered to the "off spot" first, and then to the spur for unloading.? The unloading spur should only accept a load called "wood chips-offspot". The off spot spur track would have a schedule demanding cars with "wood chips" and would change the load to "wood chips-offspot".? Now the program will always deliver new cars to the off spot track, and then move an old one to the spur for unloading.? Since you have a many wood chip cars, the alternate track is never going to get empty, and the delivery directly to the unloading spur is never needed.

Dan

Clark,

You are correctly describing how the alternate track works.? ?The program will only pull a car from the alternate when the train servicing that location doesn't have a car for the spur.

The program normally doesn't deliver a new car to the alternate, and then pull an old one from the alternate to deliver to the spur, instead it simply delivers the car in the train to the spur.? The car in the train and the cars on the alternate have the same "load", so the program doesn't create the "extra" work of rotating the stock from the alternate.

And yes, cars can sit on the alternate for a long time if there's an ample supply of cars with the appropriate load that the spur is requesting.

If you want the sequence of cars sent to the alternate first, then the spur, you could create a simple schedule that did that.? In this case, you wouldn't use the program's alternate track feature.

Dan

Is it possible that the reason for bypassed cars is due to number of moves on the car? As an example, if the car on the alternate has 200 moves, and the yard car has 10 moves, JMRI will tend to move the car with fewer moves first.?