Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
- Jmriusers
- Messages
Search
|
Locked
Re: Fast Clock - Phone
we (model railroad control systems )offer a design by Andrew Deak that displays on a browser or a device's browsers or hard digital and analog displays
toggle quoted message
Show quoted text
On 11/19/2018 1:54 PM, Tim Anderson wrote:
May not be the right group - --
Seth Neumann Mountain View, CA |
|
Locked
Lenz Compact/XpressNet
¿ªÔÆÌåÓýHello, Having had many difficulties using DCC++, inasmuch I cannot operate servo turnout controls regrdless of settings etc., I have the possibility of aquiring a very cheap Lenz Compact. Having borrowed the unit over the weekend, along with an XpressNet interface (USB) from someone else, to test, I have found a problem I cannot understand. Basically, things work as I expect. Points (turnouts) operate correctly (using various Arduino based servo controllers. Not a problem there as I wasn't able to get that far with DCC++).; Problem I have is with Throttle:
Any thoughts would be welcomed ASAP.
Also same issue with JMRI/RaspPi (per Steve Todd's RPi-JMRI.20180927) i.e. stop/idle issue Thoughts and comments would be greatly appreciated. Many thanks in advance Tom |
|
Locked
Re: Identifying Active Addresses
Darren,
If "all mobile decoder addresses on a layout" was really intended to mean "all mobile decoder addresses currently in use on the command station", then for Digitrax, you can use Loconet>Monitor Slots to see addresses in use by any loconet based throttle, not just JMRI throttles, though, if someone has lifted a train off the track without releasing it from the command station, the command station still sees it as in use. Other brand systems may have something similar. But if you really mean what you said, i.e. on the track which includes parked trains not in use, then as the other guys have said. -Dave Mc. |
|
Locked
Re: Identifying Active Addresses
RailCom was eventually added to the NMRA standards (S9.3.2) as an optional feature, but few manufacturers outside Europe support it.
toggle quoted message
Show quoted text
-- Dave in Australia On 20 Nov 2018, at 9:51 am, billybob experimenter <jawhugrps@...> wrote: |
|
Locked
Re: Dispatcher, Signal Mast definitions (BR-2003) and speeds
The max speed is just that, max if all signals are at there max, it gets adjusted by the signals, but never higher than the max. It's the minimum speed taking into account speed limits for curves, turnouts, blocks etc, between 2 points regardless of signals. The final speed used takes into account signal aspect, speed factors, max for loco etc.
toggle quoted message
Show quoted text
Setting all the speeds in Warrents to 100 totally defeats the purpose. You set you curve speed to medium, a diverging turnout to slow etc. If you are not using speed profiles, the final throttle setting will be not quite right, as all speeds will be 100% throttle as the throttle will be set to aspect speed (now always 100) divided by max speed for signal system (now always 100). Steve G. On November 19, 2018 11:34:50 AM EST, Torben Cox <torben.cox@...> wrote: Steve --
Sent from my Android device with K-9 Mail. Please excuse my brevity. |
|
Locked
Re: Identifying Active Addresses
Darren,
In general it is not possible to get a list of _all_ mobile decoders on the layout. There can be some exceptions, though. Here are some details. a) There is _no_ way to identify a mobile decoder "on the layout" when the decoder does not support either Digitrax "Transponding" or "Railcom". By "on the layout" I mean "not on the programming track". This is a basic limitation of the NMRA standard-based DCC implementation, because the original NMRA standard does not allow "two-way" communication on the "main track". b) Without any "extra" hardware, it is possible to get the Digitrax command station to report information on which locos are currently "known to it". This is may or may not be "all locos on the railroad". If a loco is currently "dialed-up" on a throttle, then the command station "knows it". If a non-existent decoder address is dialed-up on a throttle, the command station "knows it". In some cases, locos which were previously "dialed up" are known to the Digitrax command station, but one cannot rely on this to be true in all situations. c) If a mobile decoder supports Digitrax "Transponding" and has functional "Transponding" and is on a chunk of track which supports transponding via the appropriate hardware, then the decoder might be "findable" and "identifiable" d) If a mobile decoder supports "RailCom" communication and has functional "RailCom" reporting and is on a chunk of track which supports "Railcom" communiation and the apropriate "RailCom" hardware exists between a Digitrax command station/booster and the track, then the decoder might be "findable" and "identifiable". Regards, Billybob |
|
Locked
JMRI 4.13.4 - Difficulties with Tables
David Parks
¿ªÔÆÌåÓýTable input new item ? The Sensor and Turnout tables no longer allow the system name to be copied to the clip board.? When creating an LCC Internal sensor or turnout this now requires the hand typing of 46 characters including punctuation.? It used to be possible to copy an existing entry and modify one or two characters to get the desired new entry.? Adding a series of new LCC Internal entities now takes a lot of very careful typing not previously necessary. ? Table delete item ? Rapid delete of existing items crashes JAVA.? This has been an issue for several JMRI test releases.? The JAVA error is generally a Stack Overflow or a null pointer in a table hash pointer.? It appears that a delete is not complete when another deletion begins.? This should be an inherently single-threaded process. ? Table loading time growth ? Sensor, Turnout and other table load time has grown by 300% - 400% over several JMRI releases. This is true on all files and all Windows computers.? The excess time for table loading is not compensated by lower any savings in startup time later in the load cycle.? Panel load times is also much longer, but is partially offset by faster times for Logix and other initialization to activate. ? File contains only 2k Sensors and Turnouts (no panels):? Load Times with fast computer.? Times increase by a factor of 4 to 6 with slower computers. 4.12.0? 47 seconds 4.13.3? 58 seconds 4.13.4? 102 seconds ? Similar results will all files reduced to Sensors and Turnouts for comparison.? This causes load times to have grown from 2-3 minutes to 8 minutes for a large file with a modest computer. ? David Parks Los Altos, CA |
|
Locked
Re: Operate more than one WiFi throttle simultaneously?
Some DCC systems (e.g. NCE) support an unlimited number of virtual throttles as virtual throttles all share one "cab" address/slot. The only limit is on the number of simultaneously-moving (requested speed>0) locos/consists (consists count as one), due to the need to store all these in a track queue. This number always exceeds the number of "cab" addresses/slots.
toggle quoted message
Show quoted text
Other DCC systems and JMRI implementations differ in concept and limitations. -- Dave in Australia On 20 Nov 2018, at 8:44 AM, leo pesce <lpescester@...> wrote: |
|
Locked
Re: Fast Clock - Phone
Tim,
EngineDriver has the ability to show the fast clock in either 12 hour or 24 hour format.? This is enabled via a Preference setting.
Robin Becker
San Diego CA
Robin
|
|
Locked
Re: "Macros", scripting or programming logic for mobile decoders possible?
#scripting
You can¡¯t default the brakes to on. |
|
Locked
Fast Clock - Phone
May not be the right group -
I have a need where the fast clock would be displayed on a phone or tablet? Is this possible? Is there already an app? Reason: Its a large railroad. Thanks, Tim |
|
Locked
Re: Operate more than one WiFi throttle simultaneously?
Just to be on the same page, we are talking about virtual throttles number in JMRI, right? not total engines number. Because there could be consisted sets of engines. Also, do not forget that if you run warrants or automatic running, those do count as more virtual throttles. Cheers LeoP On Mon, Nov 19, 2018 at 12:59 PM crusader27529 <crusader2752939@...> wrote: I built a DCC++ based system for my club, and it certainly can operate |
|
Locked
Re: Operate more than one WiFi throttle simultaneously?
¿ªÔÆÌåÓýResponse time only suffers if many changes are happening at once. Every DCC system must send packets continuously so the DCC power is maintained. If no locos are moving an IDLE packet is sent continuously. If only one loco is moving, speed packets to that loco are sent continuously.?If two or more locos are moving, speed packets are?sent continuously, but to each loco in turn. Speed packets must be sent occasionally to every moving loco or the loco will time out and stop. Most DCC systems have a priority system in the track queue so that changed packets "jump the queue". So if you have 250 locos moving simultaneously and you change speed of one loco, the response is immediate. If 100 users try to change speed at once, you will see a response time degradation. Accessory and Function commands are only sent a limited number of times and also jump the queue. Many changes at once are needed for degradation to occur. Your understanding of NCE advanced consists is not quite correct. NCE always uses the consist address for speed and direction packets. It sends Function packets to the Lead and Consist addresses. It doesn't send individual commands directly to any non-lead loco address. --? Dave in Australia On 20 Nov 2018, at 8:01 AM, crusader27529 <crusader2752939@...> wrote:
Be aware that the basic architecture of the DCC signal limits the number of packets to about 110 per second.?If every loco had a packet sent to it, after 110 locos, the response time would suffer, but that would be regardless of the system used. |
|
Locked
Re: Dispatcher - SML - auto-allocation problem
Hi Mitchel
toggle quoted message
Show quoted text
You add can add the directiion sensors to the SML manually under sensors. They are mainly used for single track running, but they will keep the signal red if you test for it ACTIVE, inactive means that section is allocated in the specified direction. Other things that can be added are checks conflicting signal masts, and any sensors you set up for other reasons. By fail safe I mean that the train doesn't enter the section ahead if its not allocated even if the signal is green. Steve G. ---------- Original Message ---------- |
|
Locked
Re: "Macros", scripting or programming logic for mobile decoders possible?
#scripting
I like the brake idea.? Will check the Soundtraxx group to see if I can default to set brakes when powering on.? Would still like to automate the throttle steps, just for convenience...
-- Nick |
|
Locked
Re: Identifying Active Addresses
¿ªÔÆÌåÓýThat would not be technically possible unless: a) Every mobile decoder on your layout supports RailCom protocol and has it enabled. b) Your DCC command station and every booster?supports the?RailCom cutout and detector system. OR c) Every?mobile decoder on your layout supports?Digitrax Transponding d) Every track section has the appropriate Digtrax detection hardware attached and you have the other requisite hardware. --? Dave in Australia On 20 Nov 2018, at 4:41 AM, Darren Voorhees <devoorhe@...> wrote:
If there a way in JMRI to identify all mobile decoder addresses on a layout? |
|
Locked
Re: Operate more than one WiFi throttle simultaneously?
I built a DCC++ based system for my club, and it certainly can operate multiple locos from a WIFI input to the JMRI computer.
The base DCC++ is memory limited on an Arduino UNO, but stripping out what's not need specifically for operating the trains themselves, 35 or so locos can be run concurrently. I'm in process building a system base on an Arduino MEGA, and that should be able to run many more trains. That exact number will be determined, but I expect it to be 200 or more. Be aware that the basic architecture of the DCC signal limits the number of packets to about 110 per second. DCC doesn't send every packet to every loco continuously, so the number of packets needed to actually operate a loco is dependent on what the loco is doing. If every loco had a packet sent to it, after 110 locos, the response time would suffer, but that would be regardless of the system used. I had an friend whose club uses an NCE system, and since NCE treats each loco, even in a consist as a separate loco, every loco gets commands sent to it as required, where most other system only send commands to the consist address. Having said that, the friend has never had any issue operating, even on a large modular layout in a convention center. The layout was so large that one 'loop' around it took 45 minutes without stopping. |
to navigate to use esc to dismiss