?

Alberto,

?

Since you have a BDL168, you have the chance to test at a couple of places:

1st on the board. Using the tester on the header block, it will light/dark

the leds to show where the detectors think something exists.

2nd is looking in the sensor table. Here is the first place a detector shows

up in JMRI. Everything else watches the sensors.

3rd is the block table. It is driven from the sensors.

4th is the panel. It follows the blocks.

?

So start at the first stage and walk your way though. One note: faulty gaps

or mis-placed feeders will cause some weird detection issues now and then.

So where the problem exists may not be isolated to a single block but be an

interaction of more than one. Insuring they are isolated (remove a

connection at the BDL for example) should kill the track power at that, and

only, that block.

?

-Ken Cameron, Member JMRI Dev Team

www.jmri.org

www.fingerlakeslivesteamers.org

www.cnymod.com

www.syracusemodelrr.org

?

?

?

?

?

?

?

Digitrax PR4 Stand Alone Programming Track Issues

?

?

I recently entered the world of JMRI and am having some issues programming decoders.? I have listed as much system information as I can think of, the issue I am having and finally the trouble shooting steps I have taken in rough order.

My system.

DCC System:? Digitrax DC210 command station with a DB210 Booster

Scale: N

Programming:? I have two separate programming tracks, both are isolated from the mainline.? One is connected to the programming connection on the DCS210 and the other is connected to the PR4.? The PR4 and the dedicated programming track are mounted to a small board for mobility.

PR4 Power Supply: Digitrax PS4 70W Universal AC/DC Power Adapter with adjustable output voltage.? Originally I used the Digtrax PS14 300ma, 14 Volt power supply.?

PC:? Windows 10 64 bit, Intel Core i7-2600K CPU? 3.40GHz 3.70 GHz, 16.0 GB RAM

Lap Top PC: Windows 10 64 bit, Intel Core i7-5500U CPU 2.40GHz 2.40 GHz, 16 GB Ram

Programs:? JMRI Decoder Pro 4.12+Rb6a9bb1, Digitrax Sound Loader 2.0

Decoders:? Digitrax DN163K2 (Kato SD 80MAC), Digitrax SDXN146K2 (Kato SD 80MAC), Digitrax DN163KOA (Kato Alco PA-1/ PB-1), SDN144KOA (Kato Alco PA-1), and I have a couple unknown make and model decoders that were pre-installed that I have tried to read.? I have multiples of each decoder that I have tried.

Problem

I have been able to program a couple decoders but have been experiencing the following issues in no obvious order.? Because the issues occur intermittently, I have not been successful in isolating a specific cause.? Problems occur with both read and write actions.

·?????? A new decoder will not acknowledge using the new loco readback.

·?????? Using new loco read back or read all sheets from a roster entry a Previously programmed (using decoder pro) decoder will not acknowledge

·?????? Previously programmed (using decoder pro) decoder will not acknowledge or run on the mainline, as if no connection to the track.

·?????? Previously programmed (using decoder pro) decoder will not acknowledge but will run fine as programmed on the mainline.

·?????? A decoder will acknowledge and accept programing but will stop acknowledging in the middle of write all sheets or write changes on sheets.

·?????? JMRI will indicated that the programmer is not present or is busy when attempting to read or write a decoder.

·?????? JMRI will fail to recognize the PR4 but the device manager shows the device for COM port 4 working correctly.?

·?????? The oddest thing is, all these problems will cease momentarily and a decoder will read and write but these functioning periods are few and far in-between.

·?????? After attempting programming with JMRI via the PR4, the Digitrax DCS210 programming track reads back No AK (No acknowledgment or No Decoder) when I attempt to program a new address.? I did this as part of the trouble shooting just to see if the other programming track would work.? It works, but not with anything that has been on the JRMI and PR4 programming track.

My Trouble Shooting

·?????? I have tried two different PC, both with the same issues listed above.

·?????? I have restarted the PCs several times during trouble shooting.

·?????? I have deleted the PR4 from the device manager and removed JMRI and have re-installed both on both computers with same results more than one time.

·?????? I have cleaned wheels, cleaned contacts, soldiered connections, changed decoders and even have tried to connect the lead wire from the PR4 directly to a decoder’s contacts.

·?????? I have attempted to read two decoders that I previously programed and speed matched successfully using JMRI but neither will acknowledge at this time.

·?????? When attempting some of the above I will sometimes get flashing and clicking of the locomotive as if it were acknowledging and accepting programming but still get an error message that indicates the opposite.

·?????? I have tried input voltages from 14 to 20 using the above listed power supplies.?

·?????? I have multiples of the same decoders and have tried installing new ones and swapping them from loco to loco with no success.

·?????? I have installed the Digtrax Soundloader program, it worked for one decoder but now is unable to see any decoder I place on the programming track.? Sometimes

My conclusion is that something is wrong with the PR4 and it needs sent to Digitrax for testing.? Does anyone have any ideas as to what could be going wrong before I ship this thing off?

I've shared some photos of my setup and screenshots of some errors if anyone would like to view them via Dropbox link

On Jan 5, 2019, at 2:55 PM, whmvd <vandoornw@...> wrote:

Hi Bob,

Those are wise words, I'm sure of it. That's the sort of sentence that usually builds up to 'but...', isn't it? Well, no. Not this time. I'll get out of python altogether, as my way of thinking about what I want to achieve isn't going to change. And when my way and a tool's way don't match, then I won't persist with pressing the square peg down the round hole. And one of the python Zen principles you linked to ('Although that way may not be obvious at first unless you're Dutch') makes me, as a Dutchman, even more sure that it's the wrong track!

I'll have a good old think about what I do want instead. From the options you mention, which I'm certain aren't exhaustive, but which I'm also certain are the most obvious and therefore wisest choices to make, Java is by far the most appealing. Because I know it, because it's native to JMRI, because others do it. All good reasons adding up to a compelling argument. I think that part of the choice is really already a given.

In a small way that'll mean starting over, but honestly - I hadn't got far down this blind alley and I can chuck it with no hard feelings. Better to find out really early.

I will ask for more advice, though. And that is: what's good tooling for me to start out with (on Linux)? I'm familiar with Eclipse, but not so in-depth that I'd hate to use anything else. And what are gotchas with how I set up my coding bit separately enough so that a new JMRI-release slots in nicely and easily?

I do not, at the moment, think that what I want to do is generic enough to be something deliverable back to the project (I might surprise myself, but that's just the current feeling). On the other hand, it might be handy to have a setup that allows me to chase and fix JMRI bugs when I encounter them. Again, I'll be happily led by your expertise.

[Just so you have an idea about what I can do/have done: Java certified for J5, 25+ years as a professional programmer and occasional tech writer, last 10-15 years exclusively OO (Java and C++), C and (ka/b)sh at guru level up to some 5 years ago - that sort of thing. Retired into B&B business, continued professionally for a year or two on the side until that turned too much into uniquely javascript, which hates me about as much as I detest it... :-) ]

Thank you for the reality check. I think that was perfectly timed.
Wouter

On Sat, 5 Jan 2019 at 20:05, Bob Jacobsen <rgj1927@...> wrote:
Can I give some advice that’s meant to be constructive?

Stop with the complexity. Just stop.

If you’re already thinking in terms of a future with "three separate util-scripts that may import one another”, you’re trying to approach this in a way that simply doesn’t work in Python.

Python is fundamentally a scripting language where things are meant to be built up as needed. In that sense, it’s have a lot of things that make that approach simple, but will (of necessity) make more Big Program Waterfall approaches hard. That’s a deliberate choice on the part of the Python community:

You can’t change this. There are ten’s of millions of people who like the way Python works, and Python’s approach is not going to change. There are hundreds or perhaps thousands of people who use Python scripting as embedded in JMRI, in a straight-forward way, and that embedding is not going to change.

So what now? Well, there are alternatives: You can try JMRI’s embedded JavaScript, which might have a structure you like more. Or you can interface Java of your own to JMRI as quite a few other people do. You can even write code for JMRI in Scala or PHP; though those seem odd choices to me, people have done it. Or, if you’d prefer something that’s native C/C++, you should check out RocRail (RocRail changed to a proprietary software license in 2015, from GPL, but the source is perhaps still available by request: ) Or you could write standalone code that talks to JMRI, RocRail or Railroad & Co over network connections.

If you want to stay with Python scripting in JMRI, which for many people is a great choice, you should reconsider your approach.

When you see "it works for this example”, that shouldn’t cause doubt and search for further issues. Instead, that should be followed by “great, I can now move on the next thing”.

Large, very powerful Python system are built as sequence of “this examples” that are sequentially completed in the simplest possible way (the Minimal Viable Product idea), without worrying about lots of future details (the You Ain’t Gonna Need It principle). If something comes up later, yes, you might have to redo something; that’s expected. The idea of Python is to make the first part so fast and easy that you have time for the second, which by the way is also fast and easy.

Specifically, I recommend you start over. Throw out (or archive) your JMRI preferences directory, your scripts, even install a new JMRI download to make sure that you haven’t gotten any modified JMRI configuration files and scripts. Then start writing simple scripts that do simple things, one at a time, individually, with the least possible complexity. Forget about joins or importing your utility files or anything beyond “what does this do on the railroad right now?". As each one works, _declare_ _victory_ and move on to the next.

I understand that this is a hobby, believe me I understand that, and that some people don’t like to code that way for their hobby. That’s fine, everybody has preferences. If you don’t like Python’s approach, well, you’re not going to like Python’s approach. In that case, you might be better off picking another tool set.

Bob

On Jan 5, 2019, at 10:32 AM, whmvd <vandoornw@...> wrote:

Dave,

It does in that it works for this example.

When I think of what's going to happen when my util-script becomes (it is already, I just gave the simplified version that reproduced the error) three separate util-scripts that may import one another, then my mind gives up and I sort of lose the will to live.

What I need to figure out first and foremost is why my original works in Bob's environment and yours, but not in mine. That must be the real key to my problem. As a total python beginner, I am unfortunate in not being qualified at all to begin figuring it out.

I guess I am beyond help in this. I'll keep on experimenting for a few days, but I do need to see myself make some progress soon or, instead of a hobby, this will have become a pain. That's not the plan!

Thanks for your thoughts!
Wouter

On Sat, 5 Jan 2019 at 17:35, Dave Sand <ds@...> wrote:
Wouter,

I have uploaded two new files to your folder: test_ds.py and util_ds.py.

The execfile loads the util contents as global methods.

See if this approach makes sense.

Dave Sand

On Jan 5, 2019, at 10:49 AM, whmvd <vandoornw@...> wrote:

Dave,

Not nice of me, but I'm almost happy to report that I get an error that I rather like the look of:
2019-01-05 16:45:13,187 automat.AbstractAutomaton WARN - Unexpected Exception ends AbstractAutomaton thread [__builtin__$Tester$0]
Traceback (most recent call last):
File "<script>", line 7, in handle
NameError: global name 'setSignalHeld' is not defined

at org.python.core.Py.NameError(Py.java:284)
at org.python.core.PyFrame.getglobal(PyFrame.java:265)
at org.python.pycode._pyx2.handle$2(<script>:9)
at org.python.pycode._pyx2.call_function(<script>)
at org.python.core.PyTableCode.call(PyTableCode.java:167)
at org.python.core.PyBaseCode.call(PyBaseCode.java:307)
at org.python.core.PyBaseCode.call(PyBaseCode.java:198)
at org.python.core.PyFunction.__call__(PyFunction.java:482)
at org.python.core.PyMethod.instancemethod___call__(PyMethod.java:237)
at org.python.core.PyMethod.__call__(PyMethod.java:228)
at org.python.core.PyMethod.__call__(PyMethod.java:218)
at org.python.core.PyMethod.__call__(PyMethod.java:213)
at org.python.core.PyObject._jcallexc(PyObject.java:3626)
at org.python.core.PyObject._jcall(PyObject.java:3658)
at org.python.proxies.__builtin__$Tester$0.handle(Unknown Source)
at jmri.jmrit.automat.AbstractAutomaton.run(AbstractAutomaton.java:151)
at java.lang.Thread.run(Thread.java:748)

Maybe it was trimmed just a bit too much?

Wouter

On Thu, 3 Jan 2019 at 18:42, Dave Sand <ds@...> wrote:
Wouter,

I have uploaded 2 files to your folder.

It appears to me that the issue deals with scope and how import actually works. I don’t think it is a JMRI issue. Most likely something with Jython or maybe how you are structuring your program.

miniTest DS.py uses the AbstractAutomaton class to handle the threading. It does not import util and the method calls to util where changed.

The existing def in util DS.py was changed to act as static method.

To run miniTest, util DS is run first which sets up the util environment with the util methods becoming global, then miniTest DS is run.

This approach works but I am sure there are others.

Dave Sand

On Jan 3, 2019, at 10:14 AM, whmvd <vandoornw@...> wrote:

Indeed, Dave, I have.

I've now created a WoutersPythonbug directory in ProblemsBeingWorkedOn which contains just three tiny scripts, together showing that there is, as far as I can make out, really a bug here.

1) jmriShortCuts.py
Simply prints all the objects that should be predefined according to the following documentation link:

(it turns out that 'programmers' (or indeed 'programmer') is not present, which is probably a very minor documentation buglet, but masts, the one I focus on, is. So my environment does set it up correctly for me.

2) miniTest.py
A main test program that simply runs, in its own thread, my object under test.

3) util.py
Totally useless as is, but that's because it has been pruned of everything that could go while still showing the bug. As uploaded, it works, but only because of the assignment statement that creates a valid 'masts' variable. Comment that out, and things go horribly wrong, which they shouldn't if masts were properly preset. Also, edit a signalmast name into this file that is a valid one in your panelfile, instead of EastNorthOuter. I've also included my panelfile, should that be handier to use instead.

Put the three scripts into the resources directory and run:
1) jmriShortCuts.py
proving that the environment sets up the masts variable
2) miniTest.py
proving that that test shows a validly retrieved signalMast

Comment out the line that should not be in miniTest.py (masts=...)
Restart JMRI to get rid of possibly remaining classes in memory (that bit me at some point)
3) miniTest.py
proving that now it does not work anymore, with all the symptoms listed in the file itself.

I'm using JMRI 4.14 under Linux Mint 18.3

Anything more I can do to help explain why I think this is a bug?

Thanks,
Wouter

On Thu, 3 Jan 2019 at 15:02, Dave Sand <ds@...> wrote:
Wouter,

Do you have "import java" and "import jmri" at the beginning of each python file?

Dave Sand

On Jan 3, 2019, at 5:37 AM, whmvd <vandoornw@...> wrote:

Hello again, Bob,

Thanks for bearing with me on this.

It didn't go quite as planned when I went looking for the global variables 'turnouts', 'masts' and 'sensors'. Weirdly, turnouts and sensors are there, but masts is not. That is now the only little niggle left. Considering where I was only yesterday, that's a nnumber of huge leaps forward. The error reported is "global name 'masts' is not defined". I can bypass the problem easily by including the following line in my code:

masts = jmri.InstanceManager.getDefault(jmri.SignalMastManager)

but that's really cheating, shouldn't be necessary and keeps the back of my mind worried at what else could go wrong when I continue. Any advice on this?masts = jmri.InstanceManager.getDefault(jmri.SignalMastManager)

Wouter

On Wed, 2 Jan 2019 at 20:31, Wouter van Doorn <vandoornw@...> wrote:
Hi Bob,

Re 1) Not only did I think that was the way to do it, I was also (and am still) just building my 'library of tricks' to use in the proper, big script later on. This is one of the stages of learning! I have now removed the join, and made the spawned threads daemons, and that now works a *lot* better! Not only do I now get error messages when I need them (hurray!), the user interface no longer locks up, as you predicted (double hurray!).

Re 2) The line you mention is there. I'll see next what happens when I do not create that 'sensors' variable myself. IF it still goes wrong, at least I have an error message now to tell me where and how I goofed.

It's a lot better already, so thank you very much for the help so far. I'll let you know the result of the test once I get to it, which won't be today, but I hope to find time tomorrow.

Thanks again,
Wouter

On Wed, 2 Jan 2019 at 20:03, Bob Jacobsen <rgj1927@...> wrote:
1) Why make the main thread wait with a join? What does that do for you?

2) I’m not a Bash expert, but that looks like it should work. Somehow, Jython isn’t initializing properly for you. Are you getting a line like this in the log?

2019-01-02 11:58:29,512 script.JmriScriptEngineManager INFO - python 2.7 is provided by jython 2.7.0 [AWT-EventQueue-0]

When I force an error, I get output that starts like:

2019-01-02 11:58:41,099 jython.InputWindow ERROR - Error executing script [AWT-EventQueue-0]
javax.script.ScriptException: NameError: name 'xo' is not defined in <script> at line number 1
at org.python.jsr223.PyScriptEngine.scriptException(PyScriptEngine.java:202)
at org.python.jsr223.PyScriptEngine.eval(PyScriptEngine.java:42)
at org.python.jsr223.PyScriptEngine.eval(PyScriptEngine.java:31)
at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)

Bob

On Jan 2, 2019, at 8:24 AM, whmvd <vandoornw@...> wrote:

Hi Bob ,

Thanks for the quick reaction.
Re 1: I actually do that in a separate thread - but then the first thread waits while 'join'ing the subthread, so that remains the same problem, really. Do I need to make the subthread a daemon one and let the main thread just go? That would seem to make sense?

Re 2: I use 'Run script...' from the Tables menu. If it helps, this is the script I use to start jmri (which should be good enough):
=============================
#!/bin/bash

cd $HOME/JMRI
nohup ./PanelPro >>$HOME/Desktop/.PanelPro.log 2>&1 &
=============================
Everything I log neatly shows up in the file on the desktop. The install is squeaky-clean; everything I do is in the user files area, nothing in the installation directory. VERY interesting that 'sensors' and 'turnouts' should have been predefined...

Wouter



On Wed, 2 Jan 2019 at 15:52, Bob Jacobsen <rgj1927@...> wrote:
1) There are ways to do this. They start off looking complicated, but you have to remember that asking the program to sleep _actually_ _works_: If you do that in the main program, the main program sleeps so that you can’t click, etc. Instead, you have to hive your turnout activity into a little separate item (called a “thread”) which can run and sleep independently.



2) How are you running your scripts? When I run something (i.e. while debugging) from a Script Entry window, the syntax error and runtime error messages show up nicely on JMRI System console window. Perhaps you’re running them a different way or there’s something else wrong?

Another clue that something is wrong is not seeing “turnouts” and “sensors” predefined. They _definitely_ should be.

Bob

On Jan 2, 2019, at 7:42 AM, whmvd <vandoornw@...> wrote:

Hello scripting-gurus,

For quite a while now, I've been fighting python/jython rather than using it, and frustration is building up. I want to like it, I want to work with it - but it's not making it easy. For now, I'd like to focus on two things that make life very hard:

1) A small test script that looks up a turnout (successfully) checks its status (thrown or closed), logs it and sleeps for 0.2 seconds before checking again until it is what I want it to be does not allow me to operate any of my four panels (3x Panel Editor, 1x Layout Editor). The only things that can be operated are the resize buttons on the window and the positioning. So I can't throw the turnout to let the test program complete (the log line appears every 0.2 seconds, so it sort of seems to work). I would have thought that the time.sleep(200/1000.0) would allow me to do things instead of the whole interface being locked up? (BTW: specifically not looking for different ways to do this; I know I should add a listener and make that react, and I will end up doing that anyway - I am trying to understand why the simple thing I'd like to do cannot work)

2) When I make one of my frequent coding errors, the result is the same as described above - interface locked up except for the sizing/positioning of windows). I get no error logged. Nothing on standard output or standard error, and nothing in the console. Zilch. This leaves me having to guess where I could have gone wrong, instead of being able to look at a stack dump. For instance: I thought in my optimism that the variables 'turnouts' and 'sensors' where predefined when importing jmri, so I was happily using them. That caused the lock-up with no message at all. Finding the cause of that took me several frustrating days. I hope to turn this back into a hobby!

Any help will be greatly appreciated.

Wouter

PS: using JMRI 4.14 on Linux Mint 18.3.

--
Bob Jacobsen
rgj1927@...

--
Bob Jacobsen
rgj1927@...

--
Bob Jacobsen
rgj1927@...