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
Benefits of running a Rpi
Robert Schworm
Friends, I have watched this blog for some time now and there are a lot of issues surrounding Microsoft! Versions, firewalls, anti virus, etc. I find it rather stress free to be using jmri on a Rpi 3B+. It is solid, can not be hacked, no firewalls,etc. There is only jmri with an easy file structure. Further,I use a monitor and keyboard to get away from virtual operation...just another level o f complexity to deal with. I use ftp to my PC to store files as needed. I use scrot to take pictures and ftp back to the PC for printing. For archiving, every so often, I take the SD card to the PC and use win32 install to create a archive file in case I trash the Rpi.? This has saved me several times. I also have a clean archive of Steve,s distro.? Enjoy your trains and keep the help and tips coming. Thanks.? Bob. S |
|
Locked
Re: Dcc4pc simulator or lack thereof
oh cool if there is anything i can do to help, I don't know when I'm going to buy hardware as that depends on when I get money in my hobby fund.? I'd love to help beta test and maybe it's about time i learn how to code in Java so I can help with that too. Matthew Chambers, CBT, NR0Q Owner/Engineer M Chambers Communications Engineering LLC PO BOX 311, Atlanta, MO 63530 Office (660)239-4911 Mobile (660)415-5620 On Tue, Aug 6, 2019 at 3:25 AM ardmay via Groups.Io <ardmay=[email protected]> wrote: Hi Matthew, |
|
Locked
Re: Dcc4pc simulator or lack thereof
Hi Matthew,
I thought you might like to no that JMRI does not support dcc4pc railcom reader hardware at present and has not done so for the last three years, in fact I've loaded and run back releases and it seems to work in a fashion up to release 4.12 but there after it can't read the output of the hardware. I have the hardware and have been in communication with the dcc4pc people, Bob Jacobsen and Kevin Dickerson (original developer for dcc4pc/JMRI interface). The hardware is very good but no good without the interface with JMRI. I've been told that some progress might be made in the near future! I'll let you know if I hear any news! Regards Michael Smith? |
|
Locked
Re: How to save a control panel which has been zoomed.
toggle quoted message
Show quoted text
On 6 Aug 2019, at 07:55, whmvd <vandoornw@...> wrote:
|
|
Locked
Re: How to save a control panel which has been zoomed.
Terry, Please add how. Imagimne someone with the same problem, trying search term after search term, finally stumbling on this thread, looking in eager anticipation at the responses and only finding 'Sorted!'... Wouter On Mon, 5 Aug 2019 at 22:54, Terry Metcalfe via Groups.Io <terrymetcalfe=[email protected]> wrote: Sorted! |
|
Locked
Re: I fell at the first fence
Dave,
thank you for this. ?Of course, i will need two turnouts. ?Silly me for not realising the obvious! Terry |
|
Locked
Re: Java heap error. Solved?
¿ªÔÆÌåÓýMarc, To me they are one and the same. They are one and the same for you. They are not one and the same for many users, particularly those using Dropbox/OneDrive or those sharing User Files Location between Simulator and Layout profiles: Here (slightly obfuscated) is the Locations from one of my ~10 machines/VMs for one of my ~30 profiles: User Files Location: /zzzz/my folders/yyyy/Dropbox/JMRI/ Roster Location: /zzzz/my folders/yyyy/Dropbox/JMRI/ Profile Location: /zzzz/my folders/yyyy/Dropbox/JMRI Config Profiles/NCE_Simulator.jmri/ Settings Location: /Users/xxxx/Library/Preferences/JMRI/ Current Config file:/zzzz/my folders/yyyy/Dropbox/JMRI Config Profiles/NCE_Simulator.jmri/ProfileConfig.xml Scripts Location: /Applications/JMRI/jython/ Program Location: /Applications/JMRI Temp Files Location:/var/folders/vx/hphnjzl97c32m3gdb_9mbhmc0000gn/T/ Log Files Location: /Users/xxxx/Library/Preferences/JMRI/log/ Dave in Australia |
|
Locked
Re: Probem with feedback from MGP sensor.
Oh Billybob, sorry.
Don't mind my last mail - the mails was late to me so I didn't see that the case has evolved further. Nice to see that you seem to understand what might be happening. Thanks, mvh/anders |
|
Locked
Re: DP consist pane
¿ªÔÆÌåÓý
That section is new, and refers to as yet unreleased ( at least officially ) things the consist manager can do. ?Is there something else you thought was missing? Paul |
|
Locked
Re: Probem with feedback from MGP sensor.
¿ªÔÆÌåÓýHej That log seems to have interesting info !?! To make the log clearer I took both logs and put them together
sorted in time order. I have also marked the lines from the track occupancy sensor in bold. The Sensor messages can be seen in both logs, but they come with
no explanation in the JMRI Z21 log. 23:39:40.763: [08 00 A4 00 01 91 01
01]? ?08 00 A4 00 01 91 01 01
23:39:40.839:
[B2 48 51 54]? Sensor L2S401 (2-West) is High.? (BDL16 # 26,
DS1; DS54/DS64 # 51, AuxA/A1).
JMRI doesn't understand what Z21 tries to say? mvh/anders
|
|
Locked
Re: Probem with feedback from MGP sensor.
Billibob,
On 08/05/2019 11:58 PM, billybob experimenter wrote: Paul, the example message you present would be valid (so long as the required "checksum" byte is added.OK, I went back and re-read the Z21 Documentation on this, and now I understand the problem. The A4 messages are supposed to be sent by the Z21 in response to LocoNet messages sent by devices that can identify equipment (using Railcom, or Transponding, or...).? There is actually a translation from the LocoNet messages to this format, so the hardware isn't misbehaving, this particular message just isn't the one we are expecting.? (The expectation, based on what Roco's CAN based hardware does when it emulates LocoNet, is that we just get the transponding messages directly). Thanks for making me go back to the source. Bosse, In the Z21 menu, you will find a Z21 Configuration Tool. In the tool, please uncheck the box next to "LocoNet Occupancy Messages" and then press the "Write Values" button. According to the Z21 protocol documentation, The flag that corresponds to is what triggers the message translation that we are not handling.? After you have reset the flag, without restarting JMRI, check and see if your detection works as expected and report the results back to us. If that works, I'll just make the default so that flag is not checked.? If that doesn't work, it's going to be a little while before I can get to adding support for those particular messages. Paul |
|
Locked
Re: Probem with feedback from MGP sensor.
Paul, the example message you present would be valid (so long as the required "checksum" byte is added.
toggle quoted message
Show quoted text
Unfortunately, the log provided by Bosse includes some Z21 "A4" messages where the remainder of the Z21 messages _do not_ conform to valid LocoNet messages. Perhaps this implies that the Z21 hardware is misbehaving, or that the Z21 protocol isn't quite as simple as is implied by the documentation. Regards, Billybob -----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Paul Bender Sent: Monday, August 05, 2019 11:49 PM To: [email protected] Subject: Re: [jmriusers] Probem with feedback from MGP sensor. On 08/05/2019 11:36 PM, Paul Bender wrote: Billlybob,For what it's worth, the example message in the Z21's documentation is: 0x07 0x00 0xA4 0x00 0x81 0xF8 0x03 that makes the loconet message 0x81 0xF8 0x03. Paul |
|
Locked
Re: Probem with feedback from MGP sensor.
Paul,
toggle quoted message
Show quoted text
All I am saying is that the passing logic will need to do something more than simply pass a bunch of bytes as a LocoNet message, because the bytes you seem to be planing to pass as a LocoNet message are not a sensible LocoNet message. LocoNet code will be confused by the message. Just because the JMRI LocoNet message to Z21 message mechanism simply adds some Z21-specific header bytes _does not necessarily_ make the reverse transaction a simple matter of stripping off a few Z21-specific bytes to get a LocoNet message. And Just because the Z21 protocol says that the A4 opcode indicates that the remainder of the message includes a LocoNet message _does not necessarily_ make the remainder of the Z21 message a valid LocoNet message! If JMRI's Z21code will _interpret_ the Z21 message, and work with LnSensor objects, then I've mis-interpreted your previous messages on the subject. Enough said. Regards, Billybob -----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Paul Bender Sent: Monday, August 05, 2019 11:37 PM To: [email protected] Subject: Re: [jmriusers] Probem with feedback from MGP sensor. Billlybob, On 08/05/2019 11:13 PM, billybob experimenter wrote: Simply removing the first 4 bytes will NOT result in a valid LocoNet message! The first byte of a LocoNet message (the "OpCode" byte) _must_ have its most-significant bit set. Using your process, the first byte of the LocoNet message would be 0x01, which is not a valid LocoNet "OpCode".Regardless of whether or not the LocoNet payload in the message is valid, the Z21's A4 opcode indicates the payload is a LocoNet Detection message and we aren't currently passing that to the LocoNet stack. If I am not mistaken, the Z21 just passes the information it receives from the LocoNet to us. Paul |
|
Locked
Re: Probem with feedback from MGP sensor.
On 08/05/2019 11:36 PM, Paul Bender wrote:
Billlybob,For what it's worth, the example message in the Z21's documentation is: 0x07 0x00 0xA4 0x00 0x81 0xF8 0x03 that makes the loconet message 0x81 0xF8 0x03. Paul |
|
Locked
Re: Help getting JMRI working on a new WIN10 computer
Be careful when interpreting the "track status" messages shown in the LocoNet slot data (and visualized in the LocoNet monitor).
toggle quoted message
Show quoted text
Some command stations provide erroneous information about track status, especially following command station power-up, before any LocoNet message tries to control the DCC track power. This is a known problem with certain DCS100 command stations with early firmware. It may also affect other DCS100 firmware versions and possibly other command station types. So far as I can tell, this problem only affects a small number of DCS100s, and the vast majority of users do not use any hardware or software which makes any use of the erroneous data, so the effect of the problem is nearly non-existent, at worst. There is _nothing_ that JMRI can do when the command station provides this erroneous track power status - JMRI cannot predict whether the data is correct or wrong, so it can _only_ report the data that the command station provides. The best way to avoid the problem (if you have a command station which exhibits this problem) is to send a LocoNet message to turn track power off then turn track power on using your favorite method (i.e. Throttle, properly-configured DS54 input pushbuttons, DCS50/51/52 front-panel pushbutton, or via computer software). JMRI sees the LocoNet messages to turn track power off and on, and follows that status appropriately. So far as I know, the JMRI "Power Control" tool (under "Tools"->"Power Control") will send the proper messages to LocoNet, so long as the JMRI configuration profile has properly indicated the correct connection for the "Power Control" setting in the "defaults" preferences. I believe that the same holds true for the "track power" button on the DecoderPro window - if the "defaults" have the correct "connection" specified for "Power Control", then the pushbutton will send the correct messages. The only track-power "oddness" I am aware of is how certain command stations behave with respect to the LocoNet request to "IDLE" the DCC track signal. Older command stations support the concept, while some newer Digitrax command stations appear to treat the LocoNet "Track IDLE" request as a request to turn track power "ON". I do not see this as a shortcoming of JMRI. If there are additional issues with JMRI and track power control of Digitrax command stations, I would love to hear the details (in a separate thread!) Regards, Billybob -----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of forfoum@... Sent: Monday, August 05, 2019 11:12 PM To: [email protected] Subject: Re: [jmriusers] Help getting JMRI working on a new WIN10 computer <snip> When you invoke Monitor Slots each message has the track status in it. Report of slot 27 information: Loco 0 (short) is Not Consisted, Free, operating in 28 SS mode, and is moving Forward at speed 0, F0=Off, F1=Off, F2=Off, F3=Off, F4=Off, F5=Off, F6=Off, F7=Off, F8=Off Master supports LocoNet 1.1; Track Status: Off/Running; Programming Track Status: Available; STAT2=0x00, ThrottleID=0x00 0x00 (0). In example above it is OFF * <snip> Marc |
|
Locked
Re: Probem with feedback from MGP sensor.
Billlybob,
On 08/05/2019 11:13 PM, billybob experimenter wrote: Simply removing the first 4 bytes will NOT result in a valid LocoNet message! The first byte of a LocoNet message (the "OpCode" byte) _must_ have its most-significant bit set. Using your process, the first byte of the LocoNet message would be 0x01, which is not a valid LocoNet "OpCode".Regardless of whether or not the LocoNet payload in the message is valid, the Z21's A4 opcode indicates the payload is a LocoNet Detection message and we aren't currently passing that to the LocoNet stack. If I am not mistaken, the Z21 just passes the information it receives from the LocoNet to us. Paul |
|
Locked
Re: Help getting JMRI working on a new WIN10 computer
Steve G,
Strange, I've not heard of problems with using JMRI for control of the layout power. Yes, issues with the built in USB on the newer command stations. Do you have a GitHub issue id I should read about? I know a number of layouts that use the JMRI control of track power on Digitrax systems. Granted none of them are using the latest command stations. -Ken Cameron, Member JMRI Dev Team www.jmri.org www.fingerlakeslivesteamers.org www.cnymod.com www.syracusemodelrr.org |
|
Locked
Re: Probem with feedback from MGP sensor.
Paul,
toggle quoted message
Show quoted text
Simply removing the first 4 bytes will NOT result in a valid LocoNet message! The first byte of a LocoNet message (the "OpCode" byte) _must_ have its most-significant bit set. Using your process, the first byte of the LocoNet message would be 0x01, which is not a valid LocoNet "OpCode". Regards, Billybob -----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Paul Bender Sent: Monday, August 05, 2019 11:05 PM To: [email protected] Subject: Re: [jmriusers] Probem with feedback from MGP sensor. On Aug 5, 2019, at 6:32 PM, bossevest@... wrote:<snip> 23:39:40.763: [08 00 A4 00 01 91 01 01] 08 00 A4 00 01 91 01 01I believe the problem is that messages like the ones above should be translated by the Z21 code into LocoNet messages, but that isn¡¯t happening. The good news is that should be quick to fix if that is the case. The first 4 bytes of those messages ( 08 00 A4 00 ) are the Z21 header. The rest of it should be a LocoNet message. Paul |
|
Locked
Re: Probem with feedback from MGP sensor.
On Aug 5, 2019, at 6:32 PM, bossevest@... wrote:<snip> 23:39:40.763: [08 00 A4 00 01 91 01 01] 08 00 A4 00 01 91 01 01I believe the problem is that messages like the ones above should be translated by the Z21 code into LocoNet messages, but that isn¡¯t happening. The good news is that should be quick to fix if that is the case. The first 4 bytes of those messages ( 08 00 A4 00 ) are the Z21 header. The rest of it should be a LocoNet message. Paul |
Ken Cameron
to navigate to use esc to dismiss