Locked
Re: java Exception when try to add a second internal sensor
Hi Dave,
Fix works for me, has also resolved?
Again thanks for your time on this,
Steve.
|
Duncan,
For each track that has a schedule, select none or blank in the edit track window.? That will remove that schedule from the track.? You can later re-select the schedule if you want to.? In the Locations window, under tools, there's print or preview, there you can get a list of your schedules that have been assigned to a spur.
Dan
|
Guys,
I am trying to setup some panels using Firefox Tablets. The first two seem to work fine. I was reading somewhere that I could add virtual signals to them. Can somebody point me to a tutorial? I'm looking to use this on my hidden staging area If I can.
I'm currently using a Digitrax system, will I need to buy a SE8C to do this?
Wayne
|
Is there a simple way to turn all schedules on and Off? Just doing some experimenting with the program.
|
Locked
Re: SE8C NTXXX Commands instead of LTXXX
That makes good sense to me.? I will experiment and see if it proves out.
Thanks Billybob!
Chris
toggle quoted message
Show quoted text
On Tue, Dec 3, 2019 at 02:45 PM, billybob experimenter wrote:
Chris,
By default (according to the SE8C manual I have), the SE8C has its OpSw 14 set to "thrown". This means that the SE8C gets its control messages from the DCC track signal. And, if you have the NCE DCC track signal driving your Standalone LocoNet "RailSync" wires, this would explain why you saw the NTxx messages controlling the SE8C.
But if you have SE8C OpSw 14 set to its non-default value of "closed", the SE8C will pay attention to the LocoNet "Data" wires. Your Standalone LocoNet gets its signal on the LocoNet "Data" wires via the LocoBuffer-USB, and the SE8C would therefore be controlled via JMRI "LTxx" control messages.
I suspect you had OpSw at its "default" value when the JMRI NTxx turnouts controlled the SE8C signals, and had changed SE8C OpSw 14 to "Closed" before finding that the JMRI "LTxx" turnouts were controling the SE8C signals.
Regards,
Billybob
|
Locked
Re: java Exception when try to add a second internal sensor
Steve, Andy,
The fixes for this problem, along with issue #7458, have been merged. ?They will be included in test release 4.17.7. ?
When the test release is available, please confirm that the fixes work. ?Thanks.
Dave Sand
----- Original message -----
From: Dave Sand <ds@...>
Subject: Re: [jmriusers] java Exception when try to add a second internal sensor
Date: Saturday, November 30, 2019 4:02 PM
Steve, Andy,
I am still working on this issue. ?The scope has expanded. ?
Start JMRI with CBUS Simulator, open the Sensor table, select Add, select MERG, type the letter a. ?The same java exception that occurs when adding a second internal sensor.
Current issues:
- CBUS system name validation is not handling illegal system names properly. ?This is the actual problem.
- A residual listener is causing the default connection (first listed) to be invoked before trying the the selected connection.
- When the connection is changed, such as from Internal to MERG, the previous value should be reset to empty.
Dave Sand
----- Original message -----
From: Dave Sand <ds@...>
Subject: Re: [jmriusers] java Exception when try to add a second internal sensor
Date: Tuesday, November 26, 2019 2:54 PM
Steve,
I have identified a possible cause for the unexpected CBUS validation. ?There is a listener left when the first Add window is closed which is triggered when Add is selected again. ?When CBUS is the FIRST connection, it gets called to validate the saved input from the first add. ?The previous value is reused to facilitate entering multiple similar names.
If LocoNet, NCE, etc. are the FIRST connection, they get called instead of CBUS, but their validation is not as comprehensive as CBUS so the error does not occur. ?Creating a virtual LocoNet connection as the first connection is a temporary work around. ?A review of Preferences >> Defaults would be required.
I still need to identify if this is the true problem and figure out a solution. ?Another issue is that there is a change to validation in progress which may or may not affect this particular issue.
Dave Sand
----- Original message -----
From: "steve young via Groups.Io" <icklesteve@...>
Subject: Re: [jmriusers] java Exception when try to add a second internal sensor
Date: Tuesday, November 26, 2019 10:39 AM
Hi Andy,
Thanks for reporting, have been able to reproduce the same exception.
Will need to do a bit of digging around why any sort of Internal Sensor validation is going via CBUS Sensor validation,
Steve.
|
You can not change the baud rate as it is a fixed value. Changing it in Device Manager will not help either,
This bug was fixed in JMRI 4.17.3 but once the damage is done ( JMRI 4.16, 19200 baud)? the only way to fix it is re-view the Locobuffer-USB connection in Preferences under JMRI 4.17.3 or higher and save it.? No need to change anything? This will correct the NUL value that is in both profile.xml files and issue will be resolved.
Marc
|
Locked
Re: SE8C NTXXX Commands instead of LTXXX
Chris,
By default (according to the SE8C manual I have), the SE8C has its OpSw 14 set to "thrown". This means that the SE8C gets its control messages from the DCC track signal. And, if you have the NCE DCC track signal driving your Standalone LocoNet "RailSync" wires, this would explain why you saw the NTxx messages controlling the SE8C.
But if you have SE8C OpSw 14 set to its non-default value of "closed", the SE8C will pay attention to the LocoNet "Data" wires. Your Standalone LocoNet gets its signal on the LocoNet "Data" wires via the LocoBuffer-USB, and the SE8C would therefore be controlled via JMRI "LTxx" control messages.
I suspect you had OpSw at its "default" value when the JMRI NTxx turnouts controlled the SE8C signals, and had changed SE8C OpSw 14 to "Closed" before finding that the JMRI "LTxx" turnouts were controling the SE8C signals.
Regards,
Billybob
|
Locked
Re: SE8C NTXXX Commands instead of LTXXX
Bob,? that confirms one of my thoughts that it was likely picking up the NCE commands via the Rail Sync connection. But I don't know why it chose NT over LT and then changed it's mind.?
Thanks for the input.
Chris
toggle quoted message
Show quoted text
On Tue, Dec 3, 2019 at 02:00 PM, Bob Jacobsen wrote:
The SE8c can take inputs from the LocoNet cable _or_ from the track DCC signal. It could be that it decided to use the track signal with LT wasn¡¯t working. But I¡¯m not sure why it would do that.
Bob
On Dec 3, 2019, at 11:27 AM, heilichr via Groups.Io <heilichr@...> wrote:
Strange behavior.... I just installed my first SE8C and during initial testing it would only respond to NT commands, not LT. It has since resolved itself. Wondering what would have caused this?
--
Bob Jacobsen
rgj1927@...
|
Locked
Re: SE8C NTXXX Commands instead of LTXXX
The SE8c can take inputs from the LocoNet cable _or_ from the track DCC signal. It could be that it decided to use the track signal with LT wasn¡¯t working. But I¡¯m not sure why it would do that. Bob On Dec 3, 2019, at 11:27 AM, heilichr via Groups.Io <heilichr@...> wrote:
Strange behavior.... I just installed my first SE8C and during initial testing it would only respond to NT commands, not LT. It has since resolved itself. Wondering what would have caused this?
Summary of my of setup (it's a frankenstein lol).
NCE PowerPro command station
JMRI 4.17.3
Stand-alone Loconet with Locobuffer USB rev N.
2 BDL168s for detection
C/MRI connection running an Arduino that runs a servo and signal lights at one turnout
Tam Valley Octopus and Octocoder running 8 servos.
All this worked fine when I connected to SE8C to the loconet (and still does). When I first connected the SE8C it appeared to be working, except that the Digitrax test signal light would not change aspect when the correct LT turnout addresses were sent from JMRI. It just stayed Red over Red. I know the SE8C was properly connected to the loconet because I was able to read and write OP-Switch settings. The signal was setup in JMRI as LT turnouts and those turnouts were used to create an SE8C signal head. When I could not get the signal to work, I decided to connect a tortoise (SW address 01) and try it. By accident, I found it would respond to to switch address NT01 but not LT01.
This prompted me to send NT addresses to the signal heads and sure enough, they worked! But the story doesn't end here. I took the SE8C to my friends Digitrax layout to set the Board ID to 8. Back at home, I reinstall it and the now signals and tortoise no longer respond to the NT addresses. Instead, they correctly respond to LT addresses and not the NT.
Yes, it works fine now. But I'm the kind of guy who needs to understand why things happen to prevent future problems. Do any of you guys have any idea what could have caused this?
Any help, explanation or theories would be greatly appreciated!
Best Regards,
Chris Heili
-- Bob Jacobsen rgj1927@...
|
Locked
SE8C NTXXX Commands instead of LTXXX
Strange behavior.... I just installed my first SE8C and during initial testing it would only respond to NT commands, not LT.? ?It has since resolved itself.? Wondering what would have caused this?
Summary of my of setup? (it's a frankenstein lol).??
NCE PowerPro command station
JMRI? 4.17.3
Stand-alone Loconet with Locobuffer USB rev N.
2? BDL168s for detection
C/MRI connection running an Arduino that runs a servo and signal lights at one turnout
Tam Valley? Octopus and Octocoder running 8 servos.
All this worked fine when I connected to SE8C to the loconet (and still does).? ?When I first connected the SE8C it appeared to be working, except that the Digitrax test signal light would not change aspect when the correct LT turnout addresses were sent from JMRI.? It just stayed Red over Red.? I know the SE8C was properly connected to the loconet because I was able to read and write OP-Switch settings.? The signal was setup in JMRI? as LT turnouts and those turnouts were used to create an SE8C signal head. When I could not get the signal to work, I decided to connect a tortoise (SW address 01) and try it. By accident, I found it would respond to to switch address NT01 but not LT01.?
This prompted me to send NT addresses to the signal heads and sure enough, they worked!? ?But the story doesn't end here.? ?I took the SE8C to my friends Digitrax layout to set the Board ID to 8.? Back at home, I reinstall it and the now signals and tortoise no longer respond to the NT addresses.? Instead, they correctly respond to LT addresses and not the NT.? ?
Yes, it works fine now.? But I'm the kind of guy who needs to understand why things happen to prevent future problems.? ?Do any of you guys have any idea what could have caused this??
Any help, explanation or theories would be greatly appreciated!
Best Regards,
Chris Heili
|
Locked
Re: Test version 4.17.5 of JMRI/DecoderPro is available for download
Hi Bob:? Thanks for publishing.?
I can confirm a FIX in JMRI 4.17.5 for problem encountered in JMRI 4.16.
With JMRI 4.16 Panel Pro, clicking "Tools > Tables > Turnouts" would return the error "'libgluegen-rt.jnilib' cannot be opened because the developer cannot be verified."? I assume this is a driver signing issue.?? With JMRI 4.17.5, this problem does not appear.
Looking forward to the next official release.? Hopefully this is still on schedule for December 2019.
--John
=======================
Background on my environment:
Macbook Pro 15" 2019 version
Mac OS X Catalina 10.15.1
No separate Java installed; Panel Pro reports Java 1.8.0_181(en_US)
NO hardware installed, using simulator for C/MRI and ocoBufferUSB (with no config files nor scripts, just enabled in preferences)
|
Ray,
I recommend that you read through the tutorial while referencing one of the demo panels. ?"CTC Tutorial.xml" is the base ABS panel while "CTC Tutorial Panel.xml" is the completed panel.?
For SSL using signal heads, you will need to look at the following areas:
- CTC Editor: ?Configure >> Defaults menu item. ?Set the signal type.
- Signal direction indicators: ?Use the signal head names for the left and right traffic signal lists.
- Call-on: ?The "Aspect" and "Called on sensor" fields will be used instead of the "Block" field.
- Indication locking: ? Use the signal head names.
I don't know what you mean by blank screen. ?When you have an issue, always look at the system console for clues. ?If you don't start it during panel loading, you can get it using Help >> System Console. ?The "Copy to clipboard" button makes it very easy to copy and paste the content of the system console to a message.?
Dave Sand
----- Original message -----
From: "coolerman10002003 via Groups.Io" <coolerman10002003@...>
Subject: Re: [jmriusers] PanelPro CTC tools
Date: Tuesday, December 03, 2019 12:56 AM
Sorry Dave,
I screwed up and unzipped on the wrong system on the correct system zip opened fine.
Now the fun part making it work with my SSL based ABS signal panel.
I also have gotten the blank screen, so maybe an explanation of whats going wrong?
Thanks,
Ray
|
Thanks for the quick response! I will try to digest the info. probably not as easy as I hoped! Regards, Marcus Staehling
On Tue, Dec 3, 2019 at 11:09 AM John Russell < john@...> wrote: ZIMO offer the support for connection via USB or LAN (Ethernet) using the CAN 2.0 Protocol, as described in this pdf :-
This is described as the instructions for developers of computer control programs for model railways for the MX10. So, if you can interpret this protocol, then it can be used for either USB or Ethernet connection, if I understand this correctly. Page 9 has the PC/USB interface defined and the next page (p. 10) has the LAN/Ethernet info. If I translate these 2 pages, would that help? Is there anyone who can do write the code that JMRI needs to start talking to the MX10? looking at the details on this 58 page document, it seems a big project to develop this from scratch.
Regards
John Russell
|
ZIMO offer the support for connection via USB or LAN (Ethernet) using the CAN 2.0 Protocol, as described in this pdf :-
This is described as the instructions for developers of computer control programs for model railways for the MX10. So, if you can interpret this protocol, then it can be used for either USB or Ethernet connection, if I understand this correctly. Page 9 has the PC/USB interface defined and the next page (p. 10) has the LAN/Ethernet info. If I translate these 2 pages, would that help? Is there anyone who can do write the code that JMRI needs to start talking to the MX10? looking at the details on this 58 page document, it seems a big project to develop this from scratch.
Regards
John Russell
|
Thanks to all who replied. I have successfully installed and run version 2.21.65 of Engine Driver.
Craig
toggle quoted message
Show quoted text
On 12/3/19 7:51 AM, Steve Todd wrote: On Tue, Dec 3, 2019 at 05:24 AM, Craig Goodyear wrote:
What is the latest stable version of Engine Driver for Android 2.3.5?
Hi Craig,
I'd suggest 2.21.65 The changelog shows that was when EngineDriver's API version was bumped from 7 to 14. Android 2.3.5 is API 9 or 10.
--SteveT
|
Craig,
The last version of EngineDriver that supports Android 2.3.5 (API level 10) is EngineDriver 2.21 - after that version, the minimum Android version was lifted to 4.0 (API 14) and is now at 4.03 (API 15).
You can grab that version from?
Hope this helps.
Best regards,
Matt H
|
Craig,
Why not navigate to here and ask your question directly to them?
John
toggle quoted message
Show quoted text
---------- Original Message ----------
From: Craig Goodyear <cjhs22a@...>
Date: December 3, 2019 at 7:24 AM
I have an Android device running version 2.3.5. I have been running
engine driver on this device. Because a factory reset was required, I am
not able to install from Google Play due to the version of Android.
What is the latest stable version of Engine Driver for Android 2.3.5?
Craig
|
I have an Android device running version 2.3.5. I have been running engine driver on this device. Because a factory reset was required, I am not able to install from Google Play due to the version of Android.
What is the latest stable version of Engine Driver for Android 2.3.5?
Craig
|
Hi Heiko,
Thank you for pointing me in the right direction.
For completeness and those encountering the same issue, I will modify your instruction with what I did as in JMRI in the Advanced connections the 57600 baud rate is grayed out and I cannot be changed. However, changing the Locobuffer-USB driver settings to 19200, rebooting, and running JMRI installtest at this rate will error out as expected. (Driver=19200 and JMRI=57600).
Next, I closed out of the JMRI installtest and changed the Locobuffer-USD driver settings back to 57600, rebooted, and re-ran JMRI installtest.
Now it works! I have successfully connected to my Digitrax DCS 200 Super Chief.
Thanks again, Arnie
|
Bob Jacobsen
Craig Goodyear
Matthew Harris