开云体育

Hi,


I found the answer to importing division and csv modules in to JMRI script:


Place:


from __future__ import division
import csv



as the first lines in the script.




Regards


Nick

I have not used JMRI for several months and the only chnage to my layout since its last use is the introduction of NCE EB1 circuit breaker. ?Since fitting the EB1, I have been able to operate everything with my Power/Pro Cab and SB3a booster but now find that I cannot operate anything through JMRI. ?JMRI loads properly; there are no error codes or messages in red; I can display the panel and the roster but cannot get either the throttles or the points to work. ?On screen, the points change but nothing happens on the layout - equally, the throttle functions highlight and the slider works but nothing moves. ?Can anyone iddentify the problem and tell me how to overcome it pleas?
Harold.

[Non-text portions of this message have been removed]

Group:


The public beta of the newest Mac OS came up Thursday. My "spare" Mac is now up on it and initial JMRI start is good, more as I test.


Jim Albanowski

Hi,


As part of some tests I'm doing on RFID tag reading at speed I'd like to use the division and csv functions in my JMRI script.


Does anyone know how to import/ turn on these modules?.


Also which version of Jython does JMRI 3.8 and 4.6 use?.




Regards


Nick

With these steps the train's manifest appears in preview.
>Operations?>trains>build>preview>
Is it possible to print this preview manifest to file? If so how is this
done please?
James (Gil) Oakes


[Non-text portions of this message have been removed]

Is anyone else having this issue? After installing 4.7.5, I see the Java logo, and then the JMRI logo, but then nothing. No error messages, nothing. It just goes away.


So I tried 4.7.6, but get the same result. Then I tried 4.6 production with same result. Next, I uninstalled Java and JMRI, wiped out the directories, and rebooted. Installed 4.6 again but still no launch.


I am running Windows 10 Pro on a 64 bit machine, and I have had numerous successful prior versions on this machine for years.


Any ideas?


Thanks,


Richard

If the bell on 5629 was ringing or its headlight was on prior to selecting CON 5203, you will not be able to turn either off using CON 5203. You will need to select CON 5629, turn them off and then reselect CON 5203.

You can only operate switches in the loco cab you currently occupy (the CON xxxx you currently have selected), same applies to a real loco.

If all locos need to respond to the command (e.g. Sound On, Mute, Brake) that is when you set that F key bit in CVs 21/22)
--
Dave in Australia

Have you Read Sheets to confirm the CV21&22 settings?
--
Dave in Australia

Silly question, what consist address are you using?
Jay-AT&SF

Dave,

Nothing changed. All fields for both locos in JMRI Consist Tab, are set to "Locomotive Address Only. Wrote the sheets to both locos. And CV's 21 - 24 are all set to "0".

Something strange, when I select CON 5203, and ring the bell, it only rings once then shuts off. Loco 5629's bell continues to ring.

Still scratching my head on this one.

Ted

George,

You need the latest version of Decoder Pro -Ver 4.7.6

Gerry


On 1/07/2017 8:41 AM, decals@... [jmriusers] wrote:

Writing an article for the Trolleyville Times and the decoder of
choice was the Tsunami2 TSU-1100 Digital Sound Decoder. This decoder
is versatile but requires medium to extensive reprogramming for the
various features. My version of Decoderpro, 4-6, would not even
recognize the decoder although it seems to respond as expected. What
is my proble,, please?

George Huckaby
Custom Traxx

[Non-text portions of this message have been removed]

--
Gerry Hopkins MMR #177 FNMRA
Great Northern Downunder




NMRA Australasian Region
Contest & AP Chairman
Web Administrator

Writing an article for the Trolleyville Times and the decoder of choice was the Tsunami2 TSU-1100 Digital Sound Decoder. This decoder is versatile but requires medium to extensive reprogramming for the various features. My version of Decoderpro, 4-6, would not even recognize the decoder although it seems to respond as expected. What is my proble,, please?

George Huckaby
Custom Traxx

Correct. The port you want will not appear on a Mac until you plug in the USB cable for the device and its driver loads. I usually find it necessary to do that before starting DecoderPro.

Another way to check what port is being loaded by your device is:

Unplug your device. Open a Terminal Window (from /Applications/Utilities), copy and paste the following command in EXACTLY (including spaces and punctuation) then press Enter.

while : ;do clear;ls -lt /dev|head;i=$((i+1));echo $i;sleep 1;done

This command should show about 10 lines of output and then sit looping, with a counter incrementing every second.

Plug your device back in and wait a few seconds. Two new items with names like cu.xxx and tty.xxx should appear in the list. They should disappear if you unplug your device. If this does not happen, you do not have the correct drivers installed for your device and you will need to solve that before proceeding further. Once you have found your device, write down the name you see.You want the cu.xxx version not the tty.xxx version.

If you have got this far you know your device is be being seen by the Mac, that it has a matching driver installed and the name of the connection port "cu.xxx" you need to select in JMRI. If you cannot get this far, there's no way JMRI can find your device until the driver issue is resolved.

Note that in the latest test versions of JMRI we have changed the external library we use for serial ports and you may not see the tty. device any more (or even the cu. prefix).
--
Dave in Australia

Trying to create the switchboard through PanelPro 4.7 and it will no detect any turnouts, however they can be controlled if done through the turnout table, any ideas, thanks?

Hi Dave,.
Decoder pro works quickly and well.
I think the following is important:
Start DCC station
Connect USB cable to Mac
run decoder pro
Then, following connection options appear under Preferences:
CU.usbserial...
CU.Bluetooth...
Thank you
Greetings from Weil am Rhein Germany

Am 29.06.2017 um 20:41 schrieb Dave Heap dgheap@... [jmriusers] <jmriusers@...>:

The presence of "cu.Bluetooth-Incoming-Port" indicates the chosen port is certainly not correct. What other choices are available in the Preferences dropdown list?

A Lenz user with a Mac should be able to indicate what the correct port name looks like.

Sent from my iPad
--
Dave in Australia

On 30 Jun 2017, at 3:29 AM, Wolfgang Grehn grehnwolfgang@... <mailto:grehnwolfgang@...> [jmriusers] <jmriusers@... <mailto:jmriusers@...>> wrote:

Hello Dave,
Thank you for your answer.
You will find the desired information from Decoder Pro below:

1. Computer operating system: MAC OS Sierra version 10.12.5 - IMac27 "
2. DCC
Lenz LZ100 - LV101 - Version 3.6 - USB Interface 23150

Wolfgang Weil am Rhein Germany

2017-06-29 12:29:33,046 util.Log4JUtil INFO - * JMRI log ** [main]
2017-06-29 12:29:34,464 util.Log4JUtil INFO - This log is appended to file: /Users/wolfganggrehn_iMac/Library/Preferences/JMRI/log/messages.log [main]
2017-06-29 12:29:34,465 util.Log4JUtil INFO - This log is stored in file: /Users/wolfganggrehn_iMac/Library/Preferences/JMRI/log/session.log [main]
2017-06-29 12:29:34,470 apps.AppsBase INFO - DecoderPro version 4.7.6+R570b2bc starts under Java 1.8.0_131 on Mac OS X x86_64 v10.12.5 at Thu Jun 29 12:29:34 CEST 2017 [main]
2017-06-29 12:29:34,683 gui3.Apps3 INFO - Starting with profile My_JMRI_Railroad.3f09e17c [main]
2017-06-29 12:29:34,751 node.NodeIdentity INFO - Using jmri-8863DFBB063B-3f09e17c as the JMRI Node identity [main]
2017-06-29 12:29:37,006 liusb.LIUSBAdapter INFO - cu.Bluetooth-Incoming-Port port opened at 57600 baud with DTR: true RTS: true DSR: false CTS: false CD: false [main]

[Non-text portions of this message have been removed]

Not real familiar with that code any more, but here are some thoughts (lots of log pieces dropped, you might have to go back to the earlier note for complete context)

2017-06-30 12:31:54,469 jdom.CdiMemConfigReader WARN - Error reading CDI: 100 [Timer-5]
2017-06-30 12:31:54,504 ConfigRepresentation WARN - Failed to parse CDI output: org.jdom2.input.JDOMParseException: Error on line 2: XML document structures must start and end within the same entity. [Timer-5]

The timeout (1st line above) truncated reading the CDI, hence it couldn’t be parsed.

2017-06-30 12:31:54,554 MemoryConfigurationService WARN - Could not find a matching memo for MemCfg response datagram from 05.01.01.01.31.FF payload 20 53 00 00 00 40 53 63 68 65 6D 61 2D 69 6E 73 74 61 6E 63 65 22 20 78 73 69 3A 6E 6F 4E 61 6D 65 73 70 61 63 65 53 63 68 65 6D 61 4C 6F 63 61 74 69 6F 6E 3D 22 68 74 74 70 3A 2F 2F 6F 70 65 6E 6C 63 62 2E 6F [AWT-EventQueue-0]

I think this is a follow-on to the above. It’s saying that by the time that Datagram arrived, there was no longer anything waiting for it.

12:31:51.588: [[1dc6e123] 32 30 30 31 2F 58 4D 4C] R: 05.01.01.01.31.FF - 02.01.12.FE.03.DF Datagram: (70) 20.53.0.0.0.0.3C.3F.78.6D.6C.20.76.65.72.73.69.6F.6E.3D.22.31.2E.30.22.3F.3E.A.3C.63.64.69.20.78.6D.6C.6E.73.3A.78.73.69.3D.22.68.74.74.70.3A.2F.2F.77.77.77.2E.77.33.2E.6F.72.67.2F.32.30.30.31.2F.58.4D.4C
12:31:51.589: [[19a28c6e] 01 23 ] S: 02.01.12.FE.03.DF - 05.01.01.01.31.FF DatagramReceivedOK with no payload

Looks to me like the datagram was received and acknowledged. Then nothing.

12:31:54.450: [[1a123c6e] 20 43 00 00 00 40 40 ] S: 02.01.12.FE.03.DF - 05.01.01.01.31.FF Datagram: (7) 20.43.0.0.0.40.40
12:31:54.464: [[19a28c6e] 01 23 80 00 00 00 00 00] R: 02.01.12.FE.03.DF - 05.01.01.01.31.FF DatagramReceivedOK with payload 80

Does anyone have any ideas why the pause between 12:31:51.589 and 12:31:54.450 is happening?

Decode the original read request from JMRI and see what the requested length is. Was it satisfied by that first datagram? If so, JMRI should have made another read request. But if it’s longer than that, the remote should have kept on sending.

Subsidiary question: is there any publicly available documentation on how the CDI exchange and configuration works?

What you’re looking for is “how do the two nodes work together to read a bunch of content from the node using the memory transfer protocol?” That’s not specific to reading CDI.

There used to be some example memory read and write exchanges in a document on the OpenLCB web site. There was also some Arduino C/C++ code and some Python test code that could serve as examples.

Unfortunately, my bookmarks date from before their group politics improved the site, so I don’t have specific links.

I don't mean the Standards and Technical notes; they are horrible to work with and don't give the details on how JMRI expects things to happen.

If you’re writing an OpenLCB node (which seems a little masochistic now, but everybody gets to pick their own hobby), then you shouldn’t just be thinking about what “JMRI expects to happen”. (A) That might change, so long as it stays within the spec and (B) some other code might do things differently, so long as it’s within the spec. Try to get your node to properly handle big reads from memory (there’s a JMRI tool that can help test that), then use that for the specific case of CDI.


Bob

--
Bob Jacobsen
rgj1927@...

From the NCE Power Pro manual:
AIU BROADCAST ENABLE

The system can be set to have any connected AIU (Auxiliary Input Unit) automatically outputs its status via the RS232 port on the system box whenever an AIU input changes. This is disabled by default. Press ENTER to skip setting this parameter.

As Ken has said, the design of JMRI is such that it cannot cope with unsolicited broadcast messages from the NCE command station while it is waiting for a response to another command it has sent to the NCE command station.

So when you add AIU sensors, JMRI sends regular 0x8A yy (Return status of AIU yy) commands for all known AIUs. This process is known as polling and is subject to your computer and JMRI being free enough to send a command and accept a response.
--
Dave in Australia

RJ,



If you research the prototype, you will find they used a number of different
ways over the years. And then if you add multiple tracks, trains that
approach but back up, trains that stop, etc. it gets even more fun.



-Ken Cameron, Member JMRI Dev Team

www.jmri.org

www.fingerlakeslivesteamers.org

www.cnymod.com

www.syracusemodelrr.org

Nick,



Two things to keep in mind:

1. Most sensors do have some internal delay, at least track sensors do.
Optic sensors are quicker usually. Which do you have??

2. The delays tend to be consistent and average out over time.



As said by others, this sort of issue, stopping the train at a station, is
harder than it looks. When I wrote RobotThrottle, I had the train slowing
down for the approach to the station and then generally creep along the
platform. I found that the stopping point was usually plus/minus 5 inches of
the ideal spot.



Many other issues seemed to come into play biggest of which was the change
in a given train over time, meaning as it warmed up, the response time would
change. Some trains would stop quick while others would stop slower. During
a 6 hour show, I'd have to tweak the response (or keep the trains short)
about twice.



Anyway the NCE command station has to run with AIU broadcast off.
Unfortunately the way it was coded JMRI couldn't identify the difference
between some normal responses it was looking for from the AUI broadcasts and
other things would get messed up.



-Ken Cameron, Member JMRI Dev Team

www.jmri.org

www.fingerlakeslivesteamers.org

www.cnymod.com

www.syracusemodelrr.org

Ken B,



Somewhere along the 4.7.* development cycle, we started pretesting the panel
file and trapping errors like duplicates where they don't belong. In your
case a signal LH82 is mentioned more than once in a panel and it raised the
complaint.



If you could post the file to the user group space under 'Problems being
worked on' we can take a look at the file and see if the complaint is valid
and help fix it.



-Ken Cameron, Member JMRI Dev Team

www.jmri.org

www.fingerlakeslivesteamers.org

www.cnymod.com

www.syracusemodelrr.org