¿ªÔÆÌåÓý

Date

Locked Re: SoundPro Map Engine Start - And UK Sounds

 

Graham,

Al Babinsky provided yet another link, which I'd like to forward:


It occurs to me that the site is offline, but archive.org could assist.

Klaus


Am 06.01.2019 um 15:26 schrieb SettleDown:

Thanks Klaus - I'll check it out.
Graham


Locked Re: Jython as a teaching tool

 

Jim,

On 7 Jan 2019, at 10:22 AM, Bob Jacobsen <rgj1927@...> wrote:

It would help to make sure that the NCE USB has a 7.something version of the firmware so you can connect your AIU to get information back from the DB20s.
You need Power Cab firmware version V1.65B and V7 NCE USB to use AIUs successfully.

The Power Cab version is on the second screen at startup. The NCE USB version will show in the JMRI system console when you get communication functioning at the correct baud rate. It will be either "V6.3.x" or "V7.3.x" where "x" (range 0-7) is the status of jumpers 2,3,4.

Dave in Australia


Locked Re: Setting serial port speed for CMRI connection to JMRI

 

on our cpNodes we usually use 28,800 but have tested them up to 56K without issues.

On 1/6/2019 4:41 PM, JerryG via Groups.Io wrote:
I am setting up several Arduinos as CMRI SMINI nodes connected via RS485 and an adapter to a single USB port on my PC. JMRI will allow me to set the speed for the CMRI COM port connection from 9600 on up. Any reason not to go with the fastest speed? Any reason to just go with slow speed? Does this speed affect the rate at which JMRI polls the CMRI nodes (and if not, what does affect polling rate)?

Thanks, Jerry

_________________________________
jerryg2003@...




--
Seth Neumann Mountain View, CA


Locked Re: Setting serial port speed for CMRI connection to JMRI

 

Jerry,

As you increase speed, you increase the load on the computer and each of the
nodes to service the traffic. You also increase your sensitivity to noise on
the wires as well as reduce the maximum length of the wires you are allowed.
Instead I go for finding the slowest speed that doesn't miss events at the
layout end. If I have something that is very short cycle times, I would bump
up the baud rate. Remember for each node you have to allow for the traffic
to poll it and listen for the reply. You sum that to come up with the whole
layout cycle time. Is 200mS ok or do you need 50mS? I suggest start slow and
then bump up if needed.

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


Locked Re: Setting serial port speed for CMRI connection to JMRI

 

It polls as fast as it can communicate so higher speeds are faster response. Higher speeds also become more critical of the type of communication cables, how well it is shielded, and how much electrical noise is around. I would advise to use good quality 2 pair with each pair shielded, foil shields with a drain wire and keep the data cable away from any noise producing devices. Mount the semiSMINI,s and arduinos on something with a grounded metal plate or foil shield . Use good quality well filtered power supplies. Then run the baud rate as fast as you want that produces reliable communications.

Jim

On Jan 6, 2019, at 18:41, JerryG via Groups.Io <jerryg2003@...> wrote:

I am setting up several Arduinos as CMRI SMINI nodes connected via RS485 and an adapter to a single USB port on my PC. JMRI will allow me to set the speed for the CMRI COM port connection from 9600 on up. Any reason not to go with the fastest speed? Any reason to just go with slow speed? Does this speed affect the rate at which JMRI polls the CMRI nodes (and if not, what does affect polling rate)?

Thanks, Jerry

_________________________________
jerryg2003@...





Locked Re: Setting serial port speed for CMRI connection to JMRI

 

Faster baud rate makes for a faster loop, but it¡¯s not entirely proportional. There are also (small) processing delays in various places.

Too fast can result in lost messages. Occasionally, rarely, it can result in corrupt data because C/MRI doesn¡¯t have very much error checking (it usually doesn¡¯t need it)

You could start out at something intermediate and watch the lights. If they¡¯re consistent, no big gaps due to missing messages (which cause a big-fraction-of-a-second timeout), you¡¯re good.

Bob

On Jan 6, 2019, at 4:41 PM, JerryG via Groups.Io <jerryg2003@...> wrote:

I am setting up several Arduinos as CMRI SMINI nodes connected via RS485 and an adapter to a single USB port on my PC. JMRI will allow me to set the speed for the CMRI COM port connection from 9600 on up. Any reason not to go with the fastest speed? Any reason to just go with slow speed? Does this speed affect the rate at which JMRI polls the CMRI nodes (and if not, what does affect polling rate)?
--
Bob Jacobsen
rgj1927@...


Locked Re: TABLE PRINT LIST TO TABLE MOVE DATA

 

Can we step back for a second?

If you¡¯re expecting to have a Lenz system eventually, why not create a JMRI profile with a Lenz system simulator now? You¡¯ll be able to create layout objects like Turnouts and Sensors, fill in panels, etc as if the hardware was there.

When the hardware comes, most things will just work once you change to a real-hardware Lenz profile. You might discover that the switch motor you thought would have address 14 is easier to connect to 25, and you¡¯ll have to change that in JMRI. But it takes less time to change it in JMRI than it does to wire it in reality, so that¡¯s not a big deal. You just connect each one up, configure it, test it, and move to the next one.

If you decide to buy Digitrax or NCE hardware (i.e. a command station based on DCC communications), all you have to do is configure their system connections with the X letter, and off you go. JMRI is quite happy to have that XT14 that you earlier thought meant ¡°via Lenz¡± mean ¡°via LocoNet¡±. Again, you might have to change a few (NCE addressing isn¡¯t exactly like Lenz, in that there¡¯s no sensor 15) but that¡¯s one-by-one thing.

And if you decide to do something completely different, like C/MRI or OpenLCB, you¡¯re going to have to rethink your numbering in any case, likely in small chunks.

You might be setting out on creating bigger tools than you¡¯ll really need when it¡¯s time to work with the real layout.

Bob

Yes, I¡¯d like to have a Cat D9 too, but I only have four rows of vegetables, and a teenager to weed them.


On Jan 6, 2019, at 12:02 PM, Dave Roberts <dccdaveroberts@...> wrote:

I have been working away at the Table Records using a Non-Specific System and INTERNAL Blocks/Turnouts but with correct User Names using LE as part of getting ready to create a new configuration when my new Lenz system eventually rolls up and it occurred to me that since we can now pull out the records from every Table and store them away safely in a useful format for another use.

I investigated the problem of Moving/Importing/Exporting Data between different Configurations and landed on Nigel Cliffe's message from February last year.
Nigel's suggestion involved having to Move/edit the records, one by one, into the new configuration Tables where he had already created Blank Table Records in the new configuration. As he pointed out, that would be fine for smaller layouts but what about much larger layouts with well over 100 Turnouts and perhaps over 200 Blocks, etc?

This gave me the idea that perhaps we might be able to combine the "MOVE" function with a modified "Table Move" Script somehow? If we follow Nigel's suggestion and create, say, a Lenz Configuration and fill it with the count of actual records number as Blank Records in every Table. Can the "Table Print List" Script be modified to make it fill/Import into the Blank Records in the Tables using the data stored away, rather than dump them to the printer in .csv format. I am thinking of a more automated version of the "Move" idea suitable for any size of layout.

The fly in the ointment, as I see it, is the inability to create the correct System Name during the creation process. The Turnouts are going to be the major problem. This implies that the correct System Name is going to have to be edited in after import/Move.

Has anyone already solved the problem of moving the Table Data from one configuration to a new one?

Dave
--
Bob Jacobsen
rgj1927@...


Locked Re: TABLE PRINT LIST TO TABLE MOVE DATA

 

Dave R,

So what you are after is a bulk move operation. Typical case is replacing
one system connection with another. I doubt a perfect match between tables
for many systems. Instead I'd say something like a bulk move that sets a few
existing conditions:
1. Both views of the individual connection filtered table must be displayed
in the order that matches the entries. I mean if you start with the origin
as CT1001, and the destination as DT205, the next entry below CT1001 (that
is a CT*) will be moved to the next entry below DT205 (that is a DT*).
2. You have to supply a range number, similar to the way you can create a
number of entries with a starting entry and a range.

I'm thinking beyond the simple sequence systems, or where due to the
hardware, there are gaps in the number range. I'm trying to think of tools
that use some sort of matching or cut/paste of ranges etc... to help this
but right now, I'm not thinking of any good examples.

What I think happens today is people like myself who can attack the file
using text editing tools to do find and replace method, use those tools
(anyone keep up on sed, M4, and awk?) to resort to the changes. Others
either find somebody who can do that trick or use lots of single moves.

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


Locked Setting serial port speed for CMRI connection to JMRI

 

I am setting up several Arduinos as CMRI SMINI nodes connected via RS485 and an adapter to a single USB port on my PC. JMRI will allow me to set the speed for the CMRI COM port connection from 9600 on up. Any reason not to go with the fastest speed? Any reason to just go with slow speed? Does this speed affect the rate at which JMRI polls the CMRI nodes (and if not, what does affect polling rate)?

Thanks, Jerry

_________________________________
jerryg2003@...


Locked Re: Digitrax PR4 Stand Alone Programming Track Issues

 

On Sun, Jan 6, 2019 at 04:26 PM, Roger Merritt wrote:


Scott,

? ?You said ... *?The leads from the PR4 to the programing track are about
8 inches long.??

* The leads from the PR4 is for the sound loader program.? If you using JMRI
you should be using the two outputs from the command station designated
"Programming Track".? Separate track from the main track.

Roger
That's not true Roger. The PR4 replaces the PR3 and can be used as an interface or as a standalone programmer using JMRI.


--
Peter Ulvestad

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


Locked Re: Jython as a teaching tool

 

James,

I teach Computer Science ( well, mostly software Engineering these days ) at a university and occasionally bring JMRI or JMRI related topics up in classes.

I can certainly provide a few resources that might be useful.

Send me a note off list, and I can forward a few things to you.

Paul

On Jan 6, 2019, at 6:22 PM, Bob Jacobsen <rgj1927@...> wrote:

That should be enough for some interesting examples!

It would help to make sure that the NCE USB has a 7.something version of the firmware so you can connect your AIU to get information back from the DB20s.

There¡¯s a lot you can do with that hardware to (likely) raise student interest. From just simple sequences of operations to more complicated things that interact with the train(s) and surroundings.

The extra AIU contacts could also let you can some manual input to the scripts, which can allow a bit more creativity in what they do.

Bob


On Jan 6, 2019, at 2:27 PM, James Muthig <jmuthig3@...> wrote:

Hi all, I originally mistakenly posted this as a reply to message #155575, sorry Mike S. and thank you for responding anyway Ken C. :)

I am a high school computer science teacher and novice jmri user. I am starting a intro Python class in a few weeks and would like to 'spice' things up a bit using Jython. My setup, NCE Power Cab, NCE cab/bus interface, NCE AUI, 6 NCE DB20's and NCE 2 NCE 'Snap-its' . 25' of track (S-Scale) with a siding. I'd like to write a few simple scripts to demonstrate some basic programming concepts, loops, if/then, etc. Can anyone take a look at my gear and tell me if this is doable?

Thanks,
Jim M>
--
Bob Jacobsen
rgj1927@...






Locked Re: MQTT (again), Sensors and ECoS<>JMRI help needed

 

The two sensor triggered occupancy is not a reliable system. Power on's and reversings will give false outputs.

Andy

On 1/6/2019 12:43 PM, Nathan Tableman wrote:
As part of getting my technicals right before I go deeper or more complex; I have come across a few technical issues/questions I need some help with:

1 - Sensors

I have Ir detection devices near the start and stop of each block, so with 3 blocks I have 6 of them. I have released this was not needed and really I only needed 4 as the end of one block is the start of another (duh!).
SNIP

---
This email has been checked for viruses by AVG.


Locked Re: Digitrax PR4 Stand Alone Programming Track Issues

 

Scott,

? ?You said ...?The leads from the PR4 to the programing track are about 8 inches long.??

The leads from the PR4 is for the sound loader program.? If you using JMRI you should be using the two outputs from the command station designated "Programming Track".? Separate track from the main track.

Roger


Locked Re: Jython as a teaching tool

 

That should be enough for some interesting examples!

It would help to make sure that the NCE USB has a 7.something version of the firmware so you can connect your AIU to get information back from the DB20s.

There¡¯s a lot you can do with that hardware to (likely) raise student interest. From just simple sequences of operations to more complicated things that interact with the train(s) and surroundings.

The extra AIU contacts could also let you can some manual input to the scripts, which can allow a bit more creativity in what they do.

Bob


On Jan 6, 2019, at 2:27 PM, James Muthig <jmuthig3@...> wrote:

Hi all, I originally mistakenly posted this as a reply to message #155575, sorry Mike S. and thank you for responding anyway Ken C. :)

I am a high school computer science teacher and novice jmri user. I am starting a intro Python class in a few weeks and would like to 'spice' things up a bit using Jython. My setup, NCE Power Cab, NCE cab/bus interface, NCE AUI, 6 NCE DB20's and NCE 2 NCE 'Snap-its' . 25' of track (S-Scale) with a siding. I'd like to write a few simple scripts to demonstrate some basic programming concepts, loops, if/then, etc. Can anyone take a look at my gear and tell me if this is doable?

Thanks,
Jim M>
--
Bob Jacobsen
rgj1927@...


Locked Re: MQTT Connection in JMRI

 

Speed,

The generic NodeMcu is very impressive, and I will definitely be trying some out. Thanks for the tip. However, the typical Ebay price I saw was in the high $3+.? Plus of course the cost of the other end adds up to a $4 -$8 additional overhead for a dedicated per turnout connection. That's not particularly? competitive to a twisted pair carrying +/- 12V.

Unless I've missed something, a wireless TCP/IP net is not IP address selective. So the adjacent layouts could be connected by default at the packet level. Given that the larger? train shows in Europe can have 40 or so layouts, and that many small local shows happening most weekends have half a dozen from a selection of possibly thousands nationally. That implies to me that somewhere, there is going to have to be some kind of authoritative "national registry" of unique "Layout XXXXXX" names. Much like Enet Mac addresses are issued to manufacturers.

I'm still not convinced that a 2-way only turnout is the "fundamental particle" That all other track route changing configurations are made of. ;)?? I have to think some more about traversers and the additional time and length limitations they impose. Gantletts and Multi-track grade crossings are also somewhat challenging in that they are affected by another block's occupancy.

Andy





On 1/4/2019 12:37 PM, Speed wrote:
Andy,

There are no dumb questions!

When you look at the 3-way turnout's hardware itself, there are 2 sets of switch points and they need to move, Thrown or Closed. 2 Tortoises, 2 servos, 2 manual gadgets or 2 something elses. So, yes, in JMRI it is currently done with 2 turnouts. Fairly easy to use Routes in JMRI to control the thrown and close of the needed turnouts to get you to the 1st, 2nd or 3rd path by activating a sensor. So, if we put Routes in MQTT, then the relevant subscribers could be told to do something when topic DFW/clublayout/module001/yardladder/route gets a message like "3".

MQTT is not a wireless protocol, TCP/IP is all you need. It became very popular with IOT devices, and that gave it the wireless flavor. The fear about the adjacent layouts being controlled by the same MQTT subscription will need to be just as you would if they were DCC controlled accessories on the same command station. If two modules both use the same DCC address (example #145) for a turnout, both will move. For an MQTT implementation, DFW/clublayout/module001/turnout002 would not interfere with DFW/clublayout/module006/turnout002 or myownlayout/module001/turnout002, if they where to connect to the same MQTT broker. And then of course, JMRI would also need to have all the turnouts in the same table, and thus unique as well. (One of the smart things in LCC/OpenLCB is the 64-bit addressing that would help keep all LCC devices on the planet unique.)

Back to the wired versus wireless question, with a NodeMcu now costing $1.25 <>, I do not know how a "wired" Ethernet implementation would beat that! Noise is a good topic, but not for this thread, this is MQTT in JMRI, and not a "wireless" thread.

Speed




---
This email has been checked for viruses by AVG.


Locked Re: Decoder pro version

 

On Sun, Jan 6, 2019 at 03:59 PM, John Heaps wrote:


can find no mention of version 4.10 on?Jmri.sourceforge.net (
).

4.14 is given as the most recent stable version as follows.

" JMRI 4.14 Production Release (
) Released on December 23, 2018.

JMRI 4.14 is recommended for new users. It's the most recent stable production
release. "

John Heaps,
Vic. Oz.
Bob has corrected the issue. The offending page now redirects to jmri.org
--
Peter Ulvestad

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


Locked Re: Decoder pro version

 

¿ªÔÆÌåÓý

I can find no mention of version 4.10 on? .

4.14 is given as the most recent stable version as follows.

Released on December 23, 2018.

JMRI 4.14 is recommended for new users. It's the most recent stable production release."


John Heaps,
Vic. Oz.


On 6/01/2019 12:41 pm, Tom Wilson wrote:

Bob,

is still up and alive and showing 4.10 as current production version.
I saw that posted a few days ago on another forum.


Tom Wilson
Colorado Springs, CO

On Sat, Jan 5, 2019, 6:03 PM Bob Jacobsen <rgj1927@... wrote:
As Peter mentions, 4.14 is current and available at

If you¡¯re seeing an earlier version at some URL, could you let me know where?? I¡¯d like to get that fixed.

Bob

> On Jan 5, 2019, at 1:22 PM, Michael Shockley via Groups.Io <docshock31=[email protected]> wrote:
>
> I am using decoder pro 4.10xxxx. The website says that is the current production version.? Some people tell me they are using 4.14xxx as a production release.
> My concern is the my new locomotive isn¡¯t listed as a choice¡ªTsunami2 OEM Athearn Genesis. I think the list is GP7 and GP38-2. I have an SD60E.
> Just trying to understand.

--
Bob Jacobsen
rgj1927@...







Locked Re: Running JMRI From A MacBook Pro

 

Thanks Steve,

From what I have gathered this driver is for a CANUSB and CANUSB2 ( NOT CANUSB4 ).
Mojave should auto recognise a CANUSB4.
Will be adding this to the MERG hardware connections page,

Steve


Locked Jython as a teaching tool

 

?Hi all,? I originally mistakenly posted this as a reply to message #155575, sorry Mike S.? and thank you for responding anyway Ken C. :)? ?

I am a high school computer science teacher and novice jmri user.? I am starting a intro Python class in a few weeks and would like to 'spice' things up a bit using Jython.? My setup, NCE Power Cab, NCE cab/bus interface, NCE AUI, 6 NCE DB20's and NCE 2 NCE 'Snap-its' .? ?25' of? track? (S-Scale) with a siding.? I'd like to write a few simple scripts to demonstrate some basic programming concepts, loops, if/then, etc.? ?Can anyone take a look at my gear and tell me if this is doable?? ? ?

Thanks,
Jim M>


Locked Parse Error

 

Just loaded 4.14 on back up laptop to look at and try and got the following errior?? "Parse Error"
"The content of element type "options" must match { train options {row color options { traineditoptions {scripts{manifest creator{ switchlist creator"
Gives me the option to skip message this time.
What should I do?? For some reason I have not got a respose from JMRI group why??? Am I not clear in what is happening? I just copied error notice.
Thanks WP Steve