开云体育

I can't find a CATS users group to send this to, if someone can suggest....

I am converting over from JMRI CTC to CATS. As I write my own software using Jython scripts, I can "get away with anything".

I have a situation whereby a mail line goes into a yard area. I want the SC8C signal there to only display two things: Flashing Red (restricting) or Red, no matter what is beyond. Restricting if NOT occupied, Red if occupied (the yard that is).

I defined a "signal template" for a one head signal so that all aspects are Flashing Red in the "matrix" area, along with Restricting, "Halt" is still Red.

For the signals "details" (signal head definition):
Flashing Red" Decoder "NONE"
Red: LT 441 Throw / Green LT 441 Close, Off: LT442 Close
"Software Flashing" is checked.

When I look at the Loconet messages, I see ONLY the "turn off" (LT442 Closed On/off) commands at 1/2 the flash rate, CATS never send the "turn on the Red Led" command out.

Help!

Gregory Bedlek

Big thanks Bob.All sorted

Reply to self - just realised that it appears your two panel-pro machines are independent. I'd assumed that the second computer was connected to the same JMRI instance and data.



- Nigel

Can you use a memory variable for it ?
Computer-1 puts the string into a memory variable, and Computer-2 reads the result out of it ?
You may need the internal sensor/listener to indicate to Computer-2 that there is something worth reading.

It depends a bit whether you want/need acknowledgement of reading at the receiving end, and how rapidly the messages need to be sent, etc., but if the requirement is fairly relaxed, then I think that works without needing lots of work.

Logix may be able to do all you are asking from the description below.


- Nigel

Thanks Bob

The message would be generated by a JMRI script. I'll attached a sensor listener and will need to transfer the information between the machines running panel pro. So if computer No 1 has a train named 3P45 on track section BB, when sensor BB goes occupied I need to send a message to computer No 2 that the train on BB track is 3P45.


Sorry to ask more of you but how would it look in a script? I'm happy with adding listeners to sensors but what would the peer txfr and unpacking look like?


I've said before I'm no computer programmer I just muddle through using copy and paste :-). We don't presently have the 2 pc's connected on a LAN so the only connection between the 2 pc's is via loconet. I could introduce a LAN if that made the process easier although I'd still have no idea how to open sockets etc.


Kev

George: I see two things here that may be the problem.


Digitrax did an update to the firmware for the PR3.Check ther site to ensure that you have the current version. See




I suggest running "Do I have Java" from then you shuld have JAVA 8.11 installed


Walt

George, I have been following this thread and am at a complete loss as to why you think that you have been insulted or called ignorant.
The members of this forum have been doing their best to help you.


Paul

On Jul 5, 2017, at 3:53 AM, kd.marsh@... [jmriusers] <jmriusers@...> wrote:

I have 2 computers with panel pro running on the same loconet. Is there any way that I could pass a string between the 2 computers?


I want to be able to pass a train identity and berth identity between the 2 computers. The train number format is number, letter, number, number i.e. 1A23 and the berth identity is just a 4 digit number.

What’s generating and receiving the information?

There are two approaches:

1) The standard computer-to-computer protocols might be the best way to do this. Just open sockets at both ends and send characters back and forth.

2) If you need to do it via the LocoNet connection, there’s a “Peer Transfer” message that can do it. A JMRI script can load one and send it, and a script at the other end can unpack it.





Bob
--
Bob Jacobsen
rgj1927@...

This is a _great_ summary.

OK if I copy it into the Help pages, e.g.



Thanks

Bob

On Jul 5, 2017, at 5:13 AM, Dave Heap dgheap@... [jmriusers] <jmriusers@...> wrote:

There are some "gotchas" with programming speed curves in various decoders:

- The NMRA S9.2.2 specifies that all decoders must provide CV2 (Vstart). The provision of CV6 (Vhigh) and CV5 (Vhigh) is optional. These three CVs are to be active only when Bit 4 of CV29 is 0. Speed tables are optional and use CVs 66 (Fwd Trim) 67-94 (the actual speed curve) and 95 (Rev Trim).These thirty CVs are to be active only when Bit 4 of CV29 is 1. The disadvantage of this speed table specification is that any tweaking of starting or maximum speeds requires reshaping of the entire speed curve.

- SoundTraxx Tsunami decoders differ from the standard. When the speed table is active (Bit 4 of CV29 is 1), the value in CV2 is not ignored but is effectively (in the decoder) added to CVs 67-94 in the speed table, pushing it upwards. The advantage of this variation from the NMRA standard is that you can tweak the starting speed without reshaping the whole curve, but the disadvantage is that you can effectively flatten the top end of the speed table it the maximum speed was already high.

- QSI decoders differ from the standard. When the speed table is active (Bit 4 of CV29 is 1), the values in CVs 2 and 5 are not ignored. If either of CVs 2 or 5 are non-zero, these become the actual Vstart and/or Vhigh and the effective values in CVs 67-94 are compressed or expanded (scaled) in the decoder so the actual curve starts and/or ends on any non-zero value in Vstart and/or Vhigh. The advantage of this variation from the NMRA standard is that you can tweak both starting and maximum speeds without reshaping the whole curve, but the disadvantage is that if your speed table already covered a restricted range, the curve will be expanded, with possible integer multiplication errors producing glitches in the speed table.

- ESU V4 and Select decoders differ from the standard (except in some early firmware versions) . When the speed table is active (Bit 4 of CV29 is 1), the values in CVs 2 and 5 are not ignored, but ALWAYS specify the actual Vstart and Vhigh of the loco. In addition the value of CV67 is fixed (read only) at 1 and the value of CV94 is fixed (read only) at 255. You therefore need to fit your speed table curve shape between these fixed end points. The effective values in CVs 67-94 are compressed (in the decoder) so the actual curve always starts and ends on the values in Vstart and Vhigh. The advantage of this variation from the NMRA standard is that you can tweak both starting and maximum speeds without reshaping the whole curve and without the possible multiplicative errors in the QSI approach. The LokProgrammer and JMRI DecoderPro software both enforce the restrictions on CVs 67 and 94 so you know what your speed table will actually look like. Also, the minimum value for CV2 is 1, so you cannot set the loco to be stationary at step 1.

The important thing to make very clear is that ALL FOUR DIFFERENT APPROACHES ALLOW FULL CONTROL OF SETTING THE ENTIRE SPEED RANGE OF THE LOCO. There is no limitation on setting of starting or maximum speed. But you MUST be aware of the different ways of setting up different decoders. The other important point is that THIS DOES NOT PREVENT SPEED MATCHING of different brands, you just have to be aware of the different ways of setting up each brand.

The best way of avoiding problems is with any brand or mix thereof is to match speed steps in this order 1,28,14,7,21,... This will avoid any problems with any brand.

Footnote: Speed tables must always increase monotonically (i.e. no speed step can have a value lower than the previous speed step). Failure to do observe this restriction can cause strange behaviour in some decoders so both LokProgrammer and JMRI DecoderPro prevent you from doing so.

Sent from my iPad
--
Dave in Australia

On 5 Jul 2017, at 7:43 PM, peter.hambidge@... [jmriusers] <jmriusers@...> wrote:

I am battling to load the speed tables.The decoder doesn't seem to accept the programming.

--
Bob Jacobsen
rgj1927@...

Hi All,


I've published a new version of EngineDriver to the Play Store, v2.14.
Most of the changes were made by a new contributor to ED, Peter Akers. Thanks, Peter!


The changes include:
request and show function labels for JMRI consists, show activeProfile on About page, hide menu options and activities when not allowed or supported, Several new Preferences added by Peter Akers: Prevent direction change while moving, Decrease Loco No. button Height, Show loco address instead of names, Increase web view size, Immersive mode, Stop on direction change while moving, Always use default labels.


As always, feedback here or on the website is most appreciated!


Regards,
SteveT

Probably something went wrong with the download. The filename should end in .dmg, not .dm. It should be 123, 693, 418 bytes long. (It might show as something different, e.g. “123.7 MB on disk” in summaries, but check the Get Info results for the exact length)

You could try downloading it again from here:



Bob

On Jul 5, 2017, at 2:28 AM, peter.hambidge@... [jmriusers] <jmriusers@...> wrote:

I am trying to install the latest jmri version on my MacOS, Sierra version 10.12.5.
Download is good but get this message when attempting to install.
" jmri.4.6-R81496dc.dn no mountable file system"
What is the computer illiterate guy missing?

--
Bob Jacobsen
rgj1927@...

Thanks for feed back.Will do some work on it.

When I get home tonight, I will delete the JMRI folder & do a clean install from the disk image.
Thanks!
Jay

Slight correction. I haven't yet added the special SUSI Function Map available in some multiprotocol decoders (but not applicable to the vast majority of users).
--
Dave in Australia

I agree their are issues sometimes, but this Engine has the WOW-121 installed 2 years ago, and yes had problems in the beginning to read Sheets, but on one of the recent updates all the CV's would read just fine, and now all I get is 308 errors on a lot of the CV's.

My Command stations are a Lenz Set 100 with 18-20 volt 10 amp Filtered DC input with the command station set to 16 volt on the track. Using a computer grade power supply with sense feedback, very stable.

The other command station is a DCC++ set to 18 volts Filtered DC and could read the CV's also now get the same errors as the Lenz.

I am using the latest test version of JMRI and always update when a new test version comes out. This is a test bed system and not running any layout.

Dennis in Tennessee

There are some "gotchas" with programming speed curves in various decoders:

- The NMRA S9.2.2 specifies that all decoders must provide CV2 (Vstart). The provision of CV6 (Vhigh) and CV5 (Vhigh) is optional. These three CVs are to be active only when Bit 4 of CV29 is 0. Speed tables are optional and use CVs 66 (Fwd Trim) 67-94 (the actual speed curve) and 95 (Rev Trim).These thirty CVs are to be active only when Bit 4 of CV29 is 1. The disadvantage of this speed table specification is that any tweaking of starting or maximum speeds requires reshaping of the entire speed curve.

- SoundTraxx Tsunami decoders differ from the standard. When the speed table is active (Bit 4 of CV29 is 1), the value in CV2 is not ignored but is effectively (in the decoder) added to CVs 67-94 in the speed table, pushing it upwards. The advantage of this variation from the NMRA standard is that you can tweak the starting speed without reshaping the whole curve, but the disadvantage is that you can effectively flatten the top end of the speed table it the maximum speed was already high.

- QSI decoders differ from the standard. When the speed table is active (Bit 4 of CV29 is 1), the values in CVs 2 and 5 are not ignored. If either of CVs 2 or 5 are non-zero, these become the actual Vstart and/or Vhigh and the effective values in CVs 67-94 are compressed or expanded (scaled) in the decoder so the actual curve starts and/or ends on any non-zero value in Vstart and/or Vhigh. The advantage of this variation from the NMRA standard is that you can tweak both starting and maximum speeds without reshaping the whole curve, but the disadvantage is that if your speed table already covered a restricted range, the curve will be expanded, with possible integer multiplication errors producing glitches in the speed table.

- ESU V4 and Select decoders differ from the standard (except in some early firmware versions) . When the speed table is active (Bit 4 of CV29 is 1), the values in CVs 2 and 5 are not ignored, but ALWAYS specify the actual Vstart and Vhigh of the loco. In addition the value of CV67 is fixed (read only) at 1 and the value of CV94 is fixed (read only) at 255. You therefore need to fit your speed table curve shape between these fixed end points. The effective values in CVs 67-94 are compressed (in the decoder) so the actual curve always starts and ends on the values in Vstart and Vhigh. The advantage of this variation from the NMRA standard is that you can tweak both starting and maximum speeds without reshaping the whole curve and without the possible multiplicative errors in the QSI approach. The LokProgrammer and JMRI DecoderPro software both enforce the restrictions on CVs 67 and 94 so you know what your speed table will actually look like. Also, the minimum value for CV2 is 1, so you cannot set the loco to be stationary at step 1.

The important thing to make very clear is that ALL FOUR DIFFERENT APPROACHES ALLOW FULL CONTROL OF SETTING THE ENTIRE SPEED RANGE OF THE LOCO. There is no limitation on setting of starting or maximum speed. But you MUST be aware of the different ways of setting up different decoders. The other important point is that THIS DOES NOT PREVENT SPEED MATCHING of different brands, you just have to be aware of the different ways of setting up each brand.

The best way of avoiding problems is with any brand or mix thereof is to match speed steps in this order 1,28,14,7,21,... This will avoid any problems with any brand.

Footnote: Speed tables must always increase monotonically (i.e. no speed step can have a value lower than the previous speed step). Failure to do observe this restriction can cause strange behaviour in some decoders so both LokProgrammer and JMRI DecoderPro prevent you from doing so.
--
Dave in Australia

Jay:

Interesting...

One off problem? Just ran through a fast check of 4.7.6/4.7.7 on both
10.11.6, 10.12.5 and 10.13.0-public beta. DCC++ remained in all JMRI
versions.

Did you reinstall from your DMG? If it remains gone that is a very
interesting... "I don't know how to do that"... problem!

Jim Albanowski

<snip>

As far as CV programming is concerned, the latest version (V4.7.7) of JMRI is just as capable as the latest LokProgrammer (V4.5.3).

LokProgrammer is very much faster at Read All Sheets and Write All Sheets than JMRI.
JMRI can Read and Write single sheets or Variables/CVs. Lokprogrammer cannot
JMRI can Program on Main. LokProgrammer cannot.
JMRI can read CV export lists from LokProgrammer. LokProgrammer cannot read any CV export lists.
LokProgrammer can write new Sound Projects and rewrite project default CV settings. JMRI cannot do either.
JMRI can correctly identify the decoder type of any fourth generation ESU decoder.
You must "Read Type from decoder" in New Loco and use the chosen definition.
You MUST Read Sheet before making any changes to ESU decoders. Every sound project has different default values.


If you are programming speed tables, ESU interprets speed tables slightly differently. You ned to use the correct ESU definition and read the instructions on the Speed table pane carefully. Program Track or Program on main work equally well for Speed Tables (or any other pane, but you must Read Sheet first for the complex panes where you are not changing everything).
I added the last ESU updates only a few days ago and they are in V4.7.7.
I have a good working relationship with Matthew Herman of ESU LLC. The latest ESU firmware incorporates a change I negotiated on behalf of NCE system users for full compatibility with NCE Advanced Consisting.
I have put a lot of development time into adding ESU-specific features to JMRI.

--
Dave in Australia

Hi everyone.


I have 2 computers with panel pro running on the same loconet. Is there any way that I could pass a string between the 2 computers?


I want to be able to pass a train identity and berth identity between the 2 computers. The train number format is number, letter, number, number i.e. 1A23 and the berth identity is just a 4 digit number.


I don't have RFID or anything fancy like.


Does anyone have an inspired way of achieving this?


Thanks


Kev

I seem to be having trouble programming my Loksound micro v4 with jmri.
I am still finding my way with Loksound.Find them very confusing at times.for e.g..can i program Loksound on the "main "as well as "program track"? I am battling to load the speed tables.The decoder doesn't seem to accept the programming.
I guess i just want to know if loksound is good with jmri?