Re: DecoderPro will not read decoders

#151556

Philip,

Can you confirm that you can read these decoders without JMRI?  If you can't then it's not a JMRI issue. If you can we need to look at your settings.
Are you getting any error messages in the system console?
If you open your preferences and check the 'Defaults' tab is everything set for LocoNet and not internal.

-- 
Peter Ulvestad

JMRI Users Group Moderator -  (  )
Tam Valley Group Moderator -  (  )
Sprog-DCC Group Moderator -  (  )
Edmonton Model Railroad Association - 

Re: JMRI 4.12 Panel

#151555

Startofday can run a script.
Is it possible to use that to load the blockvalues.xml file?

From what you have said, I am not sure what practical steps I need to do to load the values.

Re: JMRI 4.12 Panel

#151554

David,

Yes, 4.12 does behave differently.  There was a change that ignored the file values if the track power is on and any referenced block sensor is not active.

If the track power is off, the value is loaded.  When the track power comes on, if the sensor goes directly to Active, the value will not be lost.  If it goes Inactive and then Active, the value is lost.

Dave Sand

Show quoted text

On Sep 5, 2018, at 9:44 AM, David Smith via Groups.Io <daversmth@...> wrote:

So I have a bit more information
If I monitor the error log file when I open the panel I see a message

15:39:10.274 ( 13441) ERROR [AWT-EventQueue-0] BlockValueFile.java:112  - block TrS3a is not occupied but has a saved value, not setting saved block values

My panel does not show which blocks are occupied when I first open the panel.
That is done when I press the StartOfDay icon on the panel which triggers all the track occupancy detectors to write their state to the panel.

So I am guessing that 4.12 behaves differently to the previous release and will not write the block value to an unoccupied block on startup.

Can anyone suggest a solution ?

Can I load the blockvalues.xml file somehow ?

Re: DecoderPro will not read decoders

#151553

开云体育

The answer for me and a lot of other folks is a Sprog V2 or Sprog V3 with a 14 or 15 Volt power supply rated for 3-4 amps. This will read and write to decoders period. If the Power off in program mode gives you heartburn switch over to command mode (POM) and program away with out worrying about charging up the caps. Rick.

On 9/5/2018 12:39 PM, crusader27529 wrote:

Show quoted text

In my experience, many of the issues with not being able to read CVs on the program track are because most command stations don't keep the DCC signal active on the program track except when actually sending and receiving data. The newer decoders, especially with sound require the onboard circuitry to stabilize and or charge before they're able to operate correctly, and many command stations don't leave the power on long enough.

Having said that, some of the theory about not keeping power on continuously is supposed to be for protection of the decoder if it's wired wrong, BUT realistically, in most cases that's a false assumption. So, if you feel better and want to power your newly installed decoder on a program track, just do it on your primary command station to verify that it doesn't make any smoke. Many command stations with program tracks have more failures than successes reading CVs from decoders.

My solution is to build a DCC++ command station, that would cost about $15 using Chinese parts, and use it to exclusively program decoders. DCC++ keeps full voltage on the program track, and I haven't found a decoder that's NMRA complient that it wouldn't read successfully.

If you use JMRI to communicate with whatever command station you use as primary, any data read from DCC++ will end up in the same roster database that both systems share. And with a simple double pole double throw switch, the program track can be quickly changed to the main track to verify that your changes actually worked as you hoped. And using a separate command station for programming won't interfere with normal operation on the main. Many command stations don't have the ability to use the program track without shutting off the main track while programming.

The ONLY negative thing with DCC++ is that it requires JMRI and therefore a computer to function. But that computer can be almost anything, and even some tablets can run it.

All this is just a thought, and it works for me, but then I use DCC++ as my primary command station with multiple power districts that can be configured individually for different over-current limits.

Re: DecoderPro will not read decoders

#151552

In my experience, many of the issues with not being able to read CVs on the program track are because most command stations don't keep the DCC signal active on the program track except when actually sending and receiving data. The newer decoders, especially with sound require the onboard circuitry to stabilize and or charge before they're able to operate correctly, and many command stations don't leave the power on long enough.

Having said that, some of the theory about not keeping power on continuously is supposed to be for protection of the decoder if it's wired wrong, BUT realistically, in most cases that's a false assumption. So, if you feel better and want to power your newly installed decoder on a program track, just do it on your primary command station to verify that it doesn't make any smoke. Many command stations with program tracks have more failures than successes reading CVs from decoders.

My solution is to build a DCC++ command station, that would cost about $15 using Chinese parts, and use it to exclusively program decoders. DCC++ keeps full voltage on the program track, and I haven't found a decoder that's NMRA complient that it wouldn't read successfully.

If you use JMRI to communicate with whatever command station you use as primary, any data read from DCC++ will end up in the same roster database that both systems share. And with a simple double pole double throw switch, the program track can be quickly changed to the main track to verify that your changes actually worked as you hoped. And using a separate command station for programming won't interfere with normal operation on the main. Many command stations don't have the ability to use the program track without shutting off the main track while programming.

The ONLY negative thing with DCC++ is that it requires JMRI and therefore a computer to function. But that computer can be almost anything, and even some tablets can run it.

All this is just a thought, and it works for me, but then I use DCC++ as my primary command station with multiple power districts that can be configured individually for different over-current limits.

Re: DecoderPro will not read decoders

Jim Thompson

#151551

开云体育

No its off topic,? but the best solution is the Soundtraxx PTB100.? I have been using it for at least 5 years with my DCS100 without a single decoder programming error.

?

Jim

?

Show quoted text

From: [email protected] <[email protected]> On Behalf Of Bob Potter
Sent: Wednesday, September 5, 2018 11:10 AM
To: [email protected]
Subject: Re: [jmriusers] DecoderPro will not read decoders

?

Phiip-
There are a few fairly recent threads about not being able to program engine decoders. Some of the problems seem to be because of low voltage to the program tracks.
If you are measuring track voltage as AC with a VOM it is not accurate for DCC. I don't know the offset.
You have a PowerPax booster to increase the voltage so it seems that your voltage at the track should be higher. Dave Heap said in a post that boosters were not recommended but I don't know why.
You might try to find a forum expressly for the DCS100 and see if you get more directed answers.
Bob

This email has been checked for viruses by Avast antivirus software.

Re: DecoderPro will not read decoders

Bob Potter

#151550

Phiip-
There are a few fairly recent threads about not being able to program engine decoders. Some of the problems seem to be because of low voltage to the program tracks.
If you are measuring track voltage as AC with a VOM it is not accurate for DCC. I don't know the offset.
You have a PowerPax booster to increase the voltage so it seems that your voltage at the track should be higher. Dave Heap said in a post that boosters were not recommended but I don't know why.
You might try to find a forum expressly for the DCS100 and see if you get more directed answers.
Bob

Re: JMRI 4.12 Panel

#151549

So I have a bit more information
If I monitor the error log file when I open the panel I see a message

15:39:10.274 ( 13441) ERROR [AWT-EventQueue-0] BlockValueFile.java:112? - block TrS3a is not occupied but has a saved value, not setting saved block values

My panel does not show which blocks are occupied when I first open the panel.
That is done when I press the StartOfDay icon on the panel which triggers all the track occupancy detectors to write their state to the panel.

So I am guessing that 4.12 behaves differently to the previous release and will not write the block value to an unoccupied block on startup.

Can anyone suggest a solution ?

Can I load the blockvalues.xml file somehow ?

Re: Logix Action to set Block Value doesn't work?

#151548

Dave,

Until I find time to add Blocks to Logix, you could try using this script:

import jmri
import java

class SetBlockFromMemory(jmri.jmrit.automat.AbstractAutomaton):
    def setup(self):
        self.memList = []
        for blk in blocks.getNamedBeanSet():
            memory = memories.getMemory(blk.getUserName())
            if memory is not None:
                self.memList.append(memory)
                memory.setValue('-None-')

    def handle(self):
        self.waitChange(self.memList)
        for mem in self.memList:
            if mem.getValue() != '-None-':
                blk = blocks.getBlock(mem.getUserName())
                blk.setValue(mem.getValue())
                mem.setValue('-None-')
        return True

sbfm = SetBlockFromMemory()
sbfm.setName("SBFM")
sbfm.setup()
sbfm.start()

If there is a memory that has the same user name as a block, it is added to the list.  When the memory is updated by Logix, the value is copied to the block.


Dave Sand

Show quoted text

On Sep 5, 2018, at 3:00 AM, Dave Short <dave@...> wrote:

Dave,

I did have Memory Variables on my panel as train describers, but changed them recently to use Block Value! Hence the problem; I could set memory variables in Logix without problem. I suppose I could revert...

I didn't want to use the layout editor signalling tools as I am modelling semaphore signalling, where the signal is only cleared when there is a train to use it, rather than just when the line is clear. So I use warrants to define my routes, OBlocks to specify my paths and signals, and I have written scripts to control the trains.

Dave

Re: SPROG and JMRI #sprog

#151547

开云体育

Have the driver files for the spring been installed ?? Need the correct ones for the spring hardware version from the spring website.

Show quoted text

From: [email protected] <[email protected]> on behalf of JerryG via Groups.Io <jerryg2003@...>
Sent: Wednesday, September 5, 2018 2:47:01 PM
To: [email protected]
Subject: Re: [jmriusers] SPROG and JMRI #mc2h104op

?

One more thought on your problem: ?if you unplug and replug the Sprog to your USB port, do you get the pleasant sound telling you hardware has been removed/added? ?If yes, then check device manager again to see which port it thinks it is on. ?Then you can bring up JMRI and add the Sprog. ?Your description seems related to how the Sprog is attaching to the new computer. ?BTW, you say you “set” the com port - you shouldn’t have to do that as it is autmagically set by Windows.

Jerry
___________________________________
jerryg2003@...

Re: SPROG and JMRI #sprog

#151546

One more thought on your problem: ?if you unplug and replug the Sprog to your USB port, do you get the pleasant sound telling you hardware has been removed/added? ?If yes, then check device manager again to see which port it thinks it is on. ?Then you can bring up JMRI and add the Sprog. ?Your description seems related to how the Sprog is attaching to the new computer. ?BTW, you say you “set” the com port - you shouldn’t have to do that as it is autmagically set by Windows.

Jerry
___________________________________
jerryg2003@...

Re: Loco position display

#151544

Dave:

As Ken said there are a number of considerations about the detection of trains.

Our club (Pacific Southern having first open house in years in October... pacificsouthern.org) will be showing a control system that not only follows the train but controls speed, pacing and stopping.

While not JMRI but home brew, I know all the features are in JMRI...

My advice on detection (as Ken said) is it has to be almost perfect. All pieces of equipment needs to have detection so no holes appear in a train. That will confuse the "ATC" one train suddenly becomes two...

Also the resolution of the detection system needs quit high. Switches should detected individually, OS sections, to help verify that the train is following it's route correctly. With any automation system more data is better than too little...

Jim Albanowski

Re: WIN 10 - Panel and Decoder Pro were working... not anymore

#151543

开云体育

COM Ports disappearing is not a JMRI problem and no amount of reinstalling JMRI will help one iota.

Unless your USB hardware has failed totally, Windows has either moved the COM port number for your SiLabs (NCE USB) or is failing to load the existing driver.

You need to go to Windows Device Manager (nothing to do with JMRI) and watch the screen while plugging/ unplugging the NCE USB. If no COM port is appearing/disappearing as you do so (or if something appears but it has error symbols) you need to make sure you have the latest Windows 10 SiLabs driver from the following site and install that one:

<>

--?

Dave in Australia

The New England Convention 2018

Show quoted text

On 5 Sep 2018, at 5:24 AM, colcjm2@... wrote:

Stopped working after a recent WIN 10 update... COM PORT 3 not found... no COM Ports found! I have done everything reinstalled twice, and not I cannot even get JMRI to start. I checked JAVA (have 1.8). I cna't figure this one out.

Re: Saving Sensors by RailCom

#151542

Dear Jan,

I have left to answer you by my right to the last word before being convicted
by the jury. Do not expect of me any well founded argument, in that follows you
will mainly be finding general wisdom, my feelings and taste.

I take your thoughts to be a first reaction giving appropriate orientation for
someone wishing to have a go at it. I would be reluctant to accept them as a
final judgement.

There are two extremes. A graph can be coloured by as many colours as its
size, by size I mean the number of vertices. This trivial colouring corresponds
to the generally accepted concept "at least one sensor to every block". Unless
the graph is complete - and complete graphs are not likely occurring as a layout
graph - fewer colours suffice, their least possible number is called the
chromatic number that may be much less than the size, allowing, occasionally, a
drastic reduction of detectors. Any number of colours, that is any number of
detectors between the chromatic number and the size is feasible. (For specific
purposes more should be installed - this topic has been touched upon in this
series - but I am restricting myself here, just as in my first post, to the
simplest case, one detecting position in every block.) I cannot rule out the
possibility but would be much surprised if - even in a highly complex layout -
the maximal number were the optimal. (I willingly concede that this may hold for
the other extreme, the minimum, as well.)

I made it clear that it was not a free lunch I was offering. But I was offering
a pudding to end the lunch with and the proof of it is in the eating.

As to your concrete objections, none of them seems to present insurmountable
difficulties.

Bugs seem to be inevitable in a software, the more sophisticated it is, the
more so. For fear of them, no railroad automation would have come to life, in
the first place.

On the other hand, I am not at all sure that my scheme would call for much
additional sophistication. The first thing is to decide which blocks should
be watched by RailCom detectors and how to group them and add a single detector
to each group. There are ready-made computer programs for colouring a graph,
but you may do it manually, taking your specific needs into account. Next, when
it comes to actually moving trains, you are faced with the same problem with the
same feed-back information available. The only difference is in the way this
information is collected. This is a matter simpler than and independent of train
movement and I feel possible bugs could easily be located and corrected.

It is true that a detector will be responsible for a larger area. Suppose we
get rid of half of the detectors, then typically two blocks are being watched
by a single detector. Let F/year be the failing rate of a detector, I mean
there occur F failures in a year on the average. If either of the two blocks
has its own detector then it amounts to 2F failures for the two blocks together.
In my case the only detector fails F times, but then both blocks are effected
that again means 2F failures for the two of them. Which is the better and which
is the worse? (In another possible modeling I have thought of, calculating
the cost of replacing faulty hardware my scheme, needing fewer detectors, is
the winner definitely.) Not to mention that we are talking about purely
electronic devices and I guess it is not them that cause the most problems in
this respect.

As no one even tastes my pudding, for the time being anyway, our dispute remains
on a purely theoretical plane.

For all this, I consider your approach positive and I thank you for your
interest.

Gabor

Re: JMRI 4.12 Panel

#151541

Sorry - it is when I use the StartOfDay that the Dispatcher Opens, not when I open the panel

Re: Logix Action to set Block Value doesn't work?

#151540

Dave,

I did have Memory Variables on my panel as train describers, but changed them recently to use Block Value! Hence the problem; I could set memory variables in Logix without problem. I suppose I could revert...

I didn't want to use the layout editor signalling tools as I am modelling semaphore signalling, where the signal is only cleared when there is a train to use it, rather than just when the line is clear. So I use warrants to define my routes, OBlocks to specify my paths and signals, and I have written scripts to control the trains.

Dave

JMRI 4.12 Panel

#151539

Hi All,

I updated to JMRI 4.12 but I have two problems with the panel.

Firstly, there is an issue where I have assigned block value text? to display the name of the train in each block.

It all works fine except for when I use the panel in the new version it does not remember the values that were previously assigned in the last session.
It did do that in the previous version.
I can see that there is a blockvalues.xml file written ( which I assume is how the panel remembers block values assigned in the previous session ) - but that file is not loaded when I open a new session.

Secondly, whenever I open the panel, the dispatcher window is also opened.
It did not do that before.
How do I prevent that from happening ?

Re: JMRI 4.13.2 and Webserver

John Swanson

#151538

Alternatively, Leo, you can probably reserve the IP address on the computer.? In that case the tablet - regardless it's age, will always be able to find the JMRI web server.? Please check with your internet service provider, or that of the router hardware for details on IP reservations.
John

Re: Loco position display

#151537

Ah, yes, the panel must be built in Layout Editor to build all the
interconnection details the software uses to track and follow the trains by
watching the blocks.

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

Re: Loco position display

#151536

Dave,

Without a system like RailCom or transponding, you will have to enter the
loco id into the block to get started. Then the system could keep the id
following the train. But that only works if you have everything working
'just right', meaning the block detection works very well. Next it doesn't
work if you let trains get too close. The issue becomes which train moved
into the block in between two trains, the one in front moving back or the
one behind moving forward. And of course two trains can never be in the same
block, it wouldn't know which moved.

At least this has been my experience with the software way to track the
trains.

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