Ken, Randy:
Thanks a lot for reporting back such good news!
Let's see how reliable that option is working.
Klaus
|
Hello everyone,?
I have never had any issues finding the download files to run the JMRI WiThrottle until recently. Originally the person who setup the ability to do so was running Linux and is now no longer a member of the model railroad club I belong to. Everyone runs Windows of some kind so I am trying to make it as club friendly as possible. If anyone knows where to find the files or has them and would like to send them to me it would be greatly appreciated.
Benjamin Le BlancComputer Tech & Locomotive Programmer of the?Mid South Model Railroad Club
[Non-text portions of this message have been removed]
|
Locked
Re: Update to JMRI 4.8 - CMRI Connection
Is your C/MRI set up a SUSIC with 24- or 32-bit cards? JMRI might not poll (run the lights fast) unless it thinks there are _input_ cards. I don¡¯t remember exactly how that part works, and am away from hardware to try it. So, as a diagnostic, please try configuring at least one input card and a JMRI sensor targeted at it. (If you have a SMINI, the ¡°card¡± is predefined, but please set up the JMRI sensor) The baud rate should match what¡¯s set on your boards (and the value you used to have in JMRI when it was working) JMRI now can handle multiple C/MRI connections, so make sure that you haven¡¯t accidentally created more than one in the preferences. Bob On Jul 24, 2017, at 10:57 PM, scott.rose@... [jmriusers] <jmriusers@...> wrote:
Hi,
I have been running JMRI 4.6 with my CMRI system for some time without issue. I'm using a USB - Serial converter with a Windows 7 machine.
I recently tried updating to one of the 4.7 test releases and found I had lost comms with the CMRI. Restoring 4.6 resolved the problem and I was back up and running. I left things until the next production release.
Updating to 4.8 unfortunately gives me the same issue. The SUSIC indicates a fast flash indicating a problem with the send/rec. I have:-
1. Deleted and recreated the serial connection for the CMRI.
2. Reduced the configuration to the only first output card
3. Tried different baud rates.
4. Created a new panel file with only one output card
None of the above will give me the slow flash on the SUSIC indicating successfull send/rec to the CMRI - EXCEPT reinstalling version 4.6.
Have I missed something obvious? Any help appreciated.
Regards
Scott
-- Bob Jacobsen rgj1927@...
|
Locked
Re: PR3 not communicating after 4.8 upgrade
Tim,
Did you perhaps connect your PR3 to a different USB port on your computer? That will cause Windows to change the COM Port "number". Usually, plugging the PR3 into the original USB port will return to the "old" COM Port "number".
When the COM Port number changes, it is usually possible to find the new COM Port number using JMRI's "Preferences" tool, in the "Connection" tab. Typically, JMRI will show the current selection, in red (because JMRI cannot communicate with that port number), and a list of other possible numbers, in black. Usually, one of the other COM Port numbers is the correct one...
If that fails, there is always using the Windows "Device Manager" to figure out exactly which COM Port "number" is assigned to the PR3.
Regards,
Billybob
|
Locked
Re: PR3 not communicating after 4.8 upgrade
Do I understand correctly that JMRI isn¡¯t presenting COM3 as a choice when you check the preferences for the PR3 connection? That's unexpected on Windows 7. We probably need to have some help from a JMRI on Windows user, but the place to start is to check that Windows itself still sees the PR3. Perhaps some part of it¡¯s drivers got uninstalled accidentally? Bob On Jul 24, 2017, at 2:56 PM, Tim Lux timlux33@... [jmriusers] <jmriusers@...> wrote:
Hi, I am new to the group, and unfortunately have a problem I am hoping others may have solved or at least get advice from those more computer literate than myself. I did not see a similar issue in recent posts.
I have used Decoder Pro solely for programming locomotives on a standalone track since I converted to DCC in 2013. I have a Digitrax system and hence use the PR3 as a standalone programmer, and successfully used it as recently as this past weekend. Today I downloaded version 4.8 release after reading the release notes, and now serial port COM3 which is where my PR3 connects is not recognized, and Decoder Pro says no programmer is connected. I use a windows 7 operating system so thought none of the warnings noted for Linux or Mac should apply.
Did I miss something? Any advice would be appreciated. Thank you -- Bob Jacobsen rgj1927@...
|
Locked
Re: TracTronics SECSI user?
One user (!) reported success using the boards with JMRI. But that was a long time ago, and the details are fuzzy. Perhaps he¡¯s still here and can comment? If you¡¯ve got the boards, it might be worth trying them. The code¡¯s still in JMRI. Just select it in preferences, set the port, save, restart and see. Bob On Jul 24, 2017, at 7:10 PM, mskibbe@... [jmriusers] <jmriusers@...> wrote:
I know I'm dragging this up from waaaaay back, but I've been hanging on to a bunch of TracTronics SECSI boards and am looking for a more modern way to run them. It looks like there was once some progress on a JMRI interface, based on this conversation and some notes in the JMRI SourceForge documentation.
Is there a connection available? Does anyone have the protocol document for SECSI available? The document doesn't seem to be in the files section anymore, and I'm having trouble locating it now that TracTronics is gone. -- Bob Jacobsen rgj1927@...
|
Locked
Re: Locobuffer locking up from data overload?
Steve,
I will have to let other CATS and JMRI experts take on the question of using the SE8c in "fourth aspect is flashing red" mode instead of "fourth aspect is dark" mode. I have almost no experience with CATS, and have little insight into its workings.
I assume that CATS simply uses existing JMRI's SE8c support. JMRI's SE8c support specifically assumes "dark" for the fourth aspect, and uses that fourth aspect, plus a timer, to send a sequence of "Color" -> "Dark" -> "Color" when a flashing aspect is selected for a given head. This is a basic assumption of the SE8c model within JMRI, and CATS doesn't have any control over this unless CATS overrides the SE8c functionality in JMRI. That seems unlikely.
From a purely JMRI perspective, it would be necessary to change the SE8c code to support "SE8c in flashing red" (or any other color) mode. It would require an appropriate "signal system definition" that only made use of flashing aspects of that color, and it would not allow a SE8c "dark" signal head or "dark" SE8c signal mast - i.e. no approach lighting for any signal head or mast controlled by an SE8c which is configured for "fourth aspect is flashing red" mode.
Regards,
Billybob
|
Locked
Re: Locobuffer locking up from data overload?
Steve,
Be aware that some LocoNet-connected devices get their Switch commands from the DCC track signal even if they have Loconet connected. This can cause difficulty if you go the "Bushby bit" route.
The DS64 prefers to get its switch commands from the DCC track signals; I believe that it may pull the switch commands from the RailSync wires on the LocoNet cable when DCC track power is not connected directly.
The DS54 ONLY gets its switch commands from the DCC track signal, even if LocoNet is connected.
Some 3rd-party LocoNet devices also take switch commands from the DCC track signal or the RailSync wires on the LocoNet cable, in preference to LocoNet messages. This can be true when a 3rd-party LocoNet device is designed to be usable on non-LocoNet systems.
Your mileage may vary...
What is the "Bushby bit" and what does it do? Doug Stuard, sage of much Digitrax lore, gives a description in JMRIuses post 63537, at .
__begin technobabble__
In essence, most all LocoNet devices which issue "switch control" messages use opcode 0xB0. Opcode 0xB0 may be "blocked" by the command station when the "Bushby bit" is set.
Alternately, the opcode 0xBD may be used to do pretty much the same thing as the 0xB0 opcode, but the "Bushby bit" has no effect on the LocoNet messages with opcode 0xBD. The 0xBD messages will be sent to the DCC track signal regardless of the "Bushby bit" setting.
It is believed that the basic premise was that one could use software mechanisms to decide which switches were "locked". That mechanism would decide if a given LocoNet message with opcode 0xB0 was to a switch that was "locked". If the switch was not locked, then the software could generate an equivalend 0xBD message on LocoNet, thus propagating the switch control request to the DCC track signal and therefore to the switch "motor". If the switch was locked, the software would ignore the request, or send a message to the dispatcher, or some other operation.
This interpretation of "Bushby bit" usage may not work for that class of LocoNet devices which actively monitor LocoNet messages to get their control information. It depends on whether the given LocoNet device can be programmed to pay attention only to opcode 0xBD messages, or whether it only responds to 0xB0 opcodes.
__end technobabble__
Regards,
Billybob
|
Locked
Re: Locobuffer locking up from data overload?
Billybob,
Thank you for your response. Here are the answers to your questions:
1. I'm running JMRI 4.6 (Production version). I've not yet updated to 4.8.
2. I'm currently using the DCS210 command station, but I used to use a DCS 100 and still had this problem.
3. I AM using flashing aspects and you are correct: I suspected this could be the problem or at least one part of it. I only use Flashing Red though, and I know that the SE8c can provide that in hardware. As I understand CATS (and this may be an area where I might need help from a CATS expert or Rodney Black himself) the recommended default usage is to set the 4th aspect of the SE8c to "Dark" so CATS can generate any flashing aspects by sending the color, then dark, then the color, etc. I believe granting "Track and Time" also causes some signals to flash and it does seem that this failure occurs when a lot of locals are out working and a lot of Track and Time has been granted. So I believe if I set the SE8c to hardware flash the red, and can figure out how to get CATS to send that instead of "red-dark-red" I might be able to lick this problem (I don't use flashing yellow or flashing green as the KCS 3rd sub in 1982 didn't use those aspects).
Any CATS gurus out there who can help me convert to sending just one "flashing red" command to generate that aspect? Maybe invent a "make-believe" aspect in the CATS grid and have it send the flashing red code?
4. I don't need to pass any DCC switch commands to the track bus, but I didn't realize the "Bushby Bit" would stop that. I thought the "Bushby Bit" just kept throttles from sending switch commands to the system. If it truly prevents commands from being sent down the track bus, then I agree that could be the fix! And those NAKs are hitting the LocoBuffer also contributing to the overload. I'll try setting the Bushby Bit and experiment and confirm that the system can still throw the turnouts and clear the signals etc.
All of my accessory decoders are connected directly to LocoNet with auxiliary power - they neither get commands nor power from the track bus.
I have several loconet USB's (and subbing them doesn't cure the problem so it isn't a problem with that specific hardware item). Also I ordered the SSB-Gateway to power/terminate that standalone loconet, so may go that route as well.
Thank you again for taking the time to offer up suggestions. It's people like you who make this site so great! I'll report back on the results of my efforts once I get some time to experiment.
Thanks again,
Steve Davis
KCS 3rd Sub
|
Thanks Dick,
Tried again and it let me in but did warn me that it was new programme, less than a week old.
Thanks for the assurance
John
|
John,
This happens at every new release. Some 'Antivirus' software simply checks to see if other people have already downloaded the program before. If it is something new then it blocks it. Obviously a new JMRI release is 'New' so it gets blocked. Maybe it should be called 'Luddite detection software'. Ignore it and install anyway.
Dick :)
toggle quoted message
Show quoted text
On 07/25/2017 09:18 AM, johnbart@... [jmriusers] wrote:
Hi, I attempted to update my 4.6 version of DecoderPro for Windows to the current production version of 4.8. However, on clicking on download to update my 4.6 version I was blocked with a message that stated that the download site was a Deceptive Site. Anybody know why? What do I do now?
Regards
John
|
Hi, I attempted to update my 4.6 version of DecoderPro for Windows to the current production version of 4.8. However, on clicking on download to update my 4.6 version I was blocked with a message that stated that the download site was a Deceptive Site. Anybody know why? What do I do now?
Regards
John
|
Locked
Re: Test version 4.9.1 of JMRI/DecoderPro is available for download
Yes. the 2 Radio buttons for the programmer were set to internal.
It confused me. It saw my command station fine.
Thanks!!
Jay
|
Ah, the sweet taste of success.=I moved the jmri.conf file to my directory "C:\Users\ModelTrainNut\JMRI" and added JUST ?default_options="-J-Djogamp.gluegen.UseTempJarCache=false".=And now the Audio Tables open with ZERO delay.=Cross your fingers that this fix holds...
=Randy
toggle quoted message
Show quoted text
On Tuesday, July 25, 2017 2:40 AM, "Klaus Killinger klaus.killinger@... [jmriusers]" <jmriusers@...> wrote: Bruce: One question, if I may.? Have you tested JMRI with jmri.conf line default_options="-J-Djogamp.gluegen.UseTempJarCache=false" too? This bypasses the jogamp_exe_tst* process, which I think causes the hanging! If not yet: Firstly, I recommend to check whether JMRI has accepted your jmri.conf file. This could be done by running the JMRI InstallTest from Windows Start button:? All Programs > JMRI > Tools and Demos > InstallTest. JMRI starts up and creates a protocol. Click on the Quit button. When the protocol shows "Completed" copy the protocol into a text editor and search for a line beginning with "Execute:".? That line should also contain the default_option value (note: without the prepended "-J") from your jmri.conf file. Now run SoundPro and and click on one of the sound options. Many thanks for doing all these tests. And sorry for being so persistent. Regards Klaus Am 24.07.2017 um 05:26 schrieb Bruce Alcock nytrr@... [jmriusers]: Well, I could not find a JMRI.conf so I asked Randall and he pointed me to the template file.
Since all it contains is comments, I was doubtful this was going to work.? What I had done was take the default statement, put it into an empty file, call it JMRI.conf and then clicked on one of the program icons on my desktop.? Nothing.? So I tried it again, expecting to tell Randall that it didn't work.
So I left it and when I came back to my PC, the program had opened up.
This was on the PC that works.
I took the config file, put it on the PC that didn't work, opened up SoundPRO.? SoundPro opened up right away, but when I clicked on one of the sound options, nothing - program hung again.....
Well, not exactly. I left it for a while and when I came back, it had opened? the audio table.? But I am going to delete the .conf file on my PC that works, because it really slows down the startup.
UPDATE:? it took almost an hour for SoundPro to come up this evening....
-bruce
Bruce G Alcock | OK N-Rail | 405-381-4314<tel:405-381-4314> | nytrr@...<mailto:nytrr@...>
[Non-text portions of this message have been removed]
------------------------------------ ------------------------------------ ------------------------------------ Yahoo Groups Links
|
Klaus,
That is now working for me. I got it into the jmri.conf but for my Eclipse
sessions, I found I had to add it as a 'VM Options' in the configuration for
my run/debug configurations. However, I had to remove the '-J' at the front
and just have:
-Djogamp.gluegen.UseTempJarCache=false
As the option.
-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org
|
Bruce:
One question, if I may. Have you tested JMRI with jmri.conf line default_options="-J-Djogamp.gluegen.UseTempJarCache=false" too?
This bypasses the jogamp_exe_tst* process, which I think causes the hanging!
If not yet:
Firstly, I recommend to check whether JMRI has accepted your jmri.conf file.
This could be done by running the JMRI InstallTest from Windows Start button: All Programs > JMRI > Tools and Demos > InstallTest.
JMRI starts up and creates a protocol. Click on the Quit button.
When the protocol shows "Completed" copy the protocol into a text editor and search for a line beginning with "Execute:". That line should also contain the default_option value (note: without the prepended "-J") from your jmri.conf file.
Now run SoundPro and and click on one of the sound options.
Many thanks for doing all these tests. And sorry for being so persistent.
Regards
Klaus
Am 24.07.2017 um 05:26 schrieb Bruce Alcock nytrr@... [jmriusers]:
toggle quoted message
Show quoted text
Well, I could not find a JMRI.conf so I asked Randall and he pointed me to the template file.
Since all it contains is comments, I was doubtful this was going to work. What I had done was take the default statement, put it into an empty file, call it JMRI.conf and then clicked on one of the program icons on my desktop. Nothing. So I tried it again, expecting to tell Randall that it didn't work.
So I left it and when I came back to my PC, the program had opened up.
This was on the PC that works.
I took the config file, put it on the PC that didn't work, opened up SoundPRO. SoundPro opened up right away, but when I clicked on one of the sound options, nothing - program hung again.....
Well, not exactly. I left it for a while and when I came back, it had opened the audio table. But I am going to delete the .conf file on my PC that works, because it really slows down the startup.
UPDATE: it took almost an hour for SoundPro to come up this evening....
-bruce
Bruce G Alcock | OK N-Rail | 405-381-4314<tel:405-381-4314> | nytrr@...<mailto:nytrr@...>
|
Locked
Update to JMRI 4.8 - CMRI Connection
Hi,
I have been running JMRI 4.6 with my CMRI system for some time without issue. I'm using a USB - Serial converter with a Windows 7 machine.
I recently tried updating to one of the 4.7 test releases and found I had lost comms with the CMRI. Restoring 4.6 resolved the problem and I was back up and running. I left things until the next production release.
Updating to 4.8 unfortunately gives me the same issue. The SUSIC indicates a fast flash indicating a problem with the send/rec. I have:-
1. Deleted and recreated the serial connection for the CMRI.
2. Reduced the configuration to the only first output card
3. Tried different baud rates.
4. Created a new panel file with only one output card
None of the above will give me the slow flash on the SUSIC indicating successfull send/rec to the CMRI - EXCEPT reinstalling version 4.6.
Have I missed something obvious? Any help appreciated.
Regards
Scott
|
Locked
Re: Test version 4.9.1 of JMRI/DecoderPro is available for download
As Bob said, it sounds like you have selected Simulator as the connection type.
Most Simulator connections deliberately return a value of 123 for every CV read, as a result the DCC address will show as 15227.
It is possible that one of the Simulator types does return a value of 132 instead, with a different apparent DCC address.
--
Dave in Australia
toggle quoted message
Show quoted text
On 25 Jul 2017, at 1:10 PM, [email protected] [jmriusers] <jmriusers@...> wrote:
This new release seems to have populated every field with 132 in the programming screen.
I opened up an existing engine when this happened.
The DCC Address was messed up too.
|
Locked
Re: Test version 4.9.1 of JMRI/DecoderPro is available for download
Bob, Loaded v4.9.1 this morning on two machines - my train room desk top (Win10, 1.3gh, 4gb ram) programmed and read a bunch of locos with the Sprog 3 - no problems. The second machine - Acer laptop (Win 10, 2.13gh, 4gb ram) with Sprog II - same as above no problems. Decoders used when testing TCS T4, TCS WOW 101 and WOW 501 , Tsunami 1, Tsunami 2 and Eco 2000 ALL perfect reads. Many thanks to the guys who do all the work. Gerry -- Gerry Hopkins MMR #177 FNMRA Great Northern Downunder NMRA Australasian Region Contest & AP Chairman Web Administrator
|
Locked
Re: JMRI running, loading and saving extremely slow
Any program running on a PC can be slowed down by memory constraints, too much activity, or disk space issues. Also, connections to other devices can make it seem extremely slow. I would advise to not be too quick to blame the program.
If your computer has enough memory, has the disk space, is not bogged down with too much overhead (other programs running in the background, for example), then the connection may be the issue. To verify the install without the connection question mark, change the preferences to Simulator and try again.
Personally, I feel bad when a new program cannot run on my older computer, or some program runs extremely slow due to memory constraints and disk page swapping. For me, this has not been the case with JMRI, except when my Linux connection became invalid after updating.
Since reading this, I became really curious so I just broke out my old XP IBM ThinkPad (normally not Internet connected) and updated my JMRI to 4.9.1, and my Java to 141 (1.8.0_141, after ignoring the Java warning about not being supported on old operating sytem). After downloading the file, the update to JMRI (4.9.1) took five and a half minutes from double-clicking the zip file to clicking "Finish". Then, running PanelPro took about 10 seconds to bring up my profile options, at 20 seconds the LocoNet Simulator started, and at 26 seconds PanelPro was fully loaded. Loading a plain panel (my old layout) took about 6 seconds. My newest draft panel will not load yet due to parsing errors.
As a contrast, on my newest Win 10 PC, PanelPro loads quickly (at 2 seconds, shows profiles, and 5 shows LocoNet Simulator, and at 7 seconds is fully loaded).
My $9 Linux computer (CHIP) is connected by a Digitrax PR3 to my Digitrax Zepyr DCS50. Running JMRI 4.7.7ish and Java 1.8.0_91, it boots into JMRI and WiThrottle automatically in about two minutes. If I then quit PanelPro then restart it, my profile options show up at about 19 seconds, the WiThrottle window at about 39 seconds, and it is fully loaded at 48 seconds.
So, share some additional information about your hardware, and people can help get to the bottom of any concerns you might have about JMRI.
Phil in gorgeous Young Harris, Georgia, USA (in the path of the total solar eclipse Aug 21)
|
Bob Jacobsen
Ken Cameron