¿ªÔÆÌåÓý

Date

Locked Re: Problems with Timetable #timetable-tool

 

Iain,

The method that I used to sort the station distances breaks down with large numbers.

Due to the release schedule for 4.14, I am not going to be able to get the fix into the next production release. It should be included in the 4.15.1 test release.

In the meantime, if you divide the distance for each station by 10 and set the custom scale to 10, the station sequence and graph look ok.

Dave Sand

On Dec 13, 2018, at 10:34 AM, Iain <iain@...> wrote:

How send???


Locked Re: 4.13.6, Digitrax DCS240 and indexed CVS

 

Thanks for all the effort on this.

One problem with indexed writes did show up, and that will be fixed shortly.

I think you could be seeing issues in the DCS240, either that one in particular or more generally. You mentioned testing with a DCS100 and JMRI 4.13.5 which went OK. That might point to the problem being the DCS240 command station, which would be good to know. But it might also be something new in JMRI 4.13.6 There were some changes in this area, though they weren¡¯t expected to make trouble like this.

Is there any chance you could try the DCS100 with JMRI 4.13.6?

Thanks again.

Bob

On Dec 13, 2018, at 6:43 AM, Mick Moignard <mick@...> wrote:

Bob

Done that: tests with Allow caching when writing index CVs for read or write operations unchecked. I've added two files about it to the folder in ProblemsBeingWorkedon. One is a Loconet log file and the other is some text and screenshots. It notes specifically two things:
- JMRI working in Page mode when the setup request Direct Byte mode
- the fact that the command station is a DCS240, which I know from experience is flaky in Page mode, and that I've used DP 4.13.6 - same computer, too - with a genuine DCS100 to program an ESU L4 in Ops mode with no issues.

Mick
______________________________________________________________________
Mick Moignard
Specialising in DCC Sound
p: +44 7774 652504
e: mick@...
skype: mickmoignard
IBM Notes and Domino: still has what it takes as an App Dev and Collaboration platform.
--
Bob Jacobsen
rgj1927@...


Locked Re: MQTT Connection in JMRI

 

Sounds quite reasonable.

What should the syntax be? As near as I can tell, everything but the wildcard characters (# and +) are valid in MQTT topic names. That means that we can¡¯t count on colons and semicolons (or quotes or periods or ¡­) as separators.

For signal heads and masts, I¡¯m not sure of the "This will also allow the Masts to simply publish ¡°Clear¡±¡± comment¡¯s meaning. Wouldn¡¯t that be separate from including the output in the name? Or is the goal to be able to replace JMRI¡¯s Clear with something else?

Bob

On Dec 13, 2018, at 8:57 AM, Speed <gertmul@...> wrote:

Bob,

It might be a bit more work up front, but a little easier down the road if we allow the user (installer) to pick the "message" or "payload" for each state change. For example, as a MERG turnout can be defined with a system name with MT123;-345,
we could (without adding a separate column for the "topic") use TxNamib/servo.0001/01:Trown;Closed or if my MQTT subscriber needs 0 and 1, then TxNamib/servo.0001/01:0;1

This will also allow the Masts to simply publish "Clear", "Stop", "Approach", "Stop and Proceed", etc., versus sending a number for the state, 0-7. Of course, some Masts are built with Heads, and they would like to publish "Red", "Flashing Yellow", etc. In the case of the Masts, we could either add more semicolons to define the messages, or create a table in a window to set it up in. But I don't think TxNamib/mast.0005/12:Clear;Approach;Stop is too hard to accomplish? As long as we know the states are in that order.

[ Someone asked why we would use a node name/number in the topic: it makes it a lot simpler for the node itself to only subscribe to the topic "TxNamib/servo.0001/#" versus subscribing to multiple topics (various post about this on Google) and managing 16 strings that needs to be stored in non-volatile memory (if you want it to be configurable). Currently, I only have to save the "0001" in EEPROM, as well as the TxNamib/, the MQTT ip address, the WiFi SSID and WPA. ]

Speed
--
Bob Jacobsen
rgj1927@...


Locked New file uploaded to [email protected]

[email protected] Notification
 

Hello,

This email message is a notification to let you know that a file has been uploaded to the Files area of the [email protected] group.

File: TimeTableData.xml

Uploaded By: Iain

Description:
Data for Dave Sand

You can access this file at the URL:
/g/jmriusers/files/ProblemsBeingWorkedOn/TimeTableData.xml

Cheers,
The Groups.io Team


Locked New file uploaded to [email protected]

[email protected] Notification
 

Hello,

This email message is a notification to let you know that a file has been uploaded to the Files area of the [email protected] group.

File: TimeTableData.xml

Uploaded By: Iain

Description:
Data for Dave Sand debugging

You can access this file at the URL:
/g/jmriusers/files/Timetable%20Files/TimeTableData.xml

Cheers,
The Groups.io Team


Locked Re: MQTT Connection in JMRI

 

Bob,?

It might be a bit more work up front, but a little easier down the road if we allow the user (installer) to pick the "message" or "payload" for each state change. For example, as a MERG turnout can be defined with a system name with MT123;-345,
we could (without adding a separate column for the "topic") use TxNamib/servo.0001/01:Trown;Closed or if my MQTT subscriber needs 0 and 1, then? TxNamib/servo.0001/01:0;1

This will also allow the Masts to simply publish "Clear", "Stop", "Approach", "Stop and Proceed", etc., versus sending a number for the state, 0-7. Of course, some Masts are built with Heads, and they would like to publish "Red", "Flashing Yellow", etc. In the case of the Masts, we could either add more semicolons to define the messages, or create a table in a window to set it up in. But I don't think TxNamib/mast.0005/12:Clear;Approach;Stop is too hard to accomplish? As long as we know the states are in that order.

[ Someone asked why we would use a node name/number?in the topic:?it makes it a lot simpler for the node itself to only subscribe to the topic "TxNamib/servo.0001/#"? versus subscribing to multiple topics (various post about this on Google) and managing 16 strings that needs to be stored in non-volatile memory (if you want it to be configurable). Currently, I only have to save the "0001" in EEPROM, as well as the TxNamib/,? the MQTT ip address, the WiFi SSID and WPA. ]

Speed


Locked Re: Test version problem in Operations with Locomotive Type

 

Hi Dan. From Panel Pro, go into Operations, then Locomotives. I imported these mostly from Decoder Pro, but have been adding others for some time. If I select an existing? loco with type 'steam' and change it to diesel, other locos are having their type changed at the same time! It's randomly changing other locos, fairly consistently. I'm running simulator so no loconet connection, and this happens if I load my panel or work purely in ops.

Ta.?

John

On 13 Dec 2018 13:46, "Dan Boudreau" <daboudreau@...> wrote:
John,

Can you give me step by step detailed instructions on what you're doing so I can reproduce?

Dan



Locked Re: Problems with Timetable #timetable-tool

 

How send???


Locked Re: Problems with Timetable #timetable-tool

 

Iain,

If you could send me the TimeTableData.xml file (user files location / timetable) or upload it to ProblemsBeingWorkedOn, it would help me figure out what is actually happening.

Dave Sand

On Dec 13, 2018, at 9:26 AM, Iain <iain@...> wrote:

Sorry I meant to add it looks like 2^16 to me??


Locked Re: setting up version 4.12

Perry Squier
 

Dave,

Thank you again for your help. I have successfully connected my Mac to NCE Power Pro. At the bottom of the ¡°All Entries¡± pane service mode programmer and Ops mode programmer are both in green and on line.
However I cannot do any programming. In programming track if I try to write it does not shut the RR off and activate the programming track, and in Program on the main the loco will not take any changes. Any more thoughts?
Thanks,

Perry

On Dec 12, 2018, at 6:53 PM, Dave Heap <dgheap@...> wrote:

Since you have a Power Pro, the instructions differ:

Irrespective of DCC system, there are some basic rules for troubleshooting any USB-attached device to a Mac.

Plug your device into your Mac.

Go to "System Information" from Apple Menu->About This Mac->More Info->System Report.

Look in the USB section, expand all sections under controllers and hubs and see what devices are present.

Unplug your device, select Refresh from the System Information menus and see what device has disappeared. Plug your device back in, refresh again and see what reappears. Repeat until you see what is changing. If there is no change, there must be a hardware problem external to your Mac, such as a faulty USB cable, connector or device and there is no point going any further until your Mac can see the physical device.

Once you have seen the device in System Information, you will quite likely have to install Mac drivers for it (although some do not need extra drivers, see your documentation). If unsure, try the next step anyway. The System Information should give you the Manufacturer.

In High Sierra, you must open System Preferences->Privacy and Security and allow the kernel extensions (drivers) you installed to be loaded, or they will not be used.

Unplug your device. Open a window of the Terminal utility (from /Applications/Utilities), copy and paste the following command in EXACTLY (including spaces and punctuation) then press Enter.

while : ;do clear;ls -lt /dev|head;i=$((i+1));echo $i;sleep 1;done

This command should show about 10 lines of output and then sit looping, with a counter incrementing every second.

Plug your device back in and wait a few seconds. Two new items with names like cu.xxx and tty.xxx should appear in the list. They should disappear if you unplug your device. If this does not happen, you do not have the correct drivers installed for your device and you will need to solve that before proceeding further. Once you have found your device, write down the name you see.You want the cu.xxx version not the tty.xxx version.

If you have got this far you know your device is be being seen by the Mac, that it has a matching driver installed and the name of the connection port "cu.xxx" you need to select in JMRI. If you cannot get this far, there's no way JMRI can find your device until the driver issue is resolved.

1) JMRI Settings.
============
The correct JMRI settings for a recent Power Pro are:
System Manufacturer: NCE
System Connection: Serial
Serial Port: <the name you determined above>
Connection Prefix: N (default and recommended)
Connection Name: NCE Power Pro (recommended name).
Additional Connection Settings: ticked
Baud Rate: 9600
Command Station EPROM: 2006 or later (unless you have an old system)

2) Connection to the Power Pro serial port.
===============================
The Power Pro front panel is quite a heavy gauge. Because the socket is behind the panel and the retaining binder posts are in front of the panel, a normal serial connector cannot seat correctly in the socket (the pins barely engage). The result is an unreliable connection.

This link explains the problem and fixes, with actual photographs.
<>

To see if this is the problem, you need to remove the top cover of the Power Pro box and carefully unscrew the hex binding posts from the front, ensuring you do not push hard against the socket and that nothing comes loose inside. You then need to carefully push the connector in WHILE holding the socket against the front panel from the rear (to prevent stress damage to the connector solder joints or the circuit boards.

If this fixes the problem, file or grind down the tops of the hex binding posts so they no longer push the connector away.

Please report back exactly how far you get.
--
Dave in Australia


On 13 Dec 2018, at 5:23 AM, Perry Squier via Groups.Io <wpsquier@...> wrote:

I have the proper USB cable to go from the Power Pro command station to my Mac since I was using it on another older Mac and an older version of Decoder Pro. I downloaded the version 4.12 to my newer Mac. Do I follow the instructions Dave sent for the Power Cab?
Thanks,


Locked Re: Problems with Timetable #timetable-tool

 

Sorry I meant to add it looks like 2^16 to me??


Locked PanelPro - Opening problem and CPE window placement seems strange

 

Does PanelPro determine where to place new windows that I open in Panel Pro or any of its applications? I am using Win10 and Java 8 (update 19).
Ever since I changed from 4.13.5 to 4.13.6, I am having problems with window placement when I open PanelPro. For starters, when I first open PanelPro, I get TWO windows titled "Loconet Simulator". Then when I am working on a panel in CPE and I try to take an action such as Zoom, the window it opens to select a percentage change is likely to show up anywhere on the screen. If I change the zoom to 200% then try to open the zoom window again later, the pop up window is off the bottom of the screen with a small edge showing but I cannot grab it and drag it back into view so I can use it. My only option is to zoom to fit then start over.
Paul D


Locked Re: Problems with Timetable #timetable-tool

 

A bit more information.? After entering the 7 stations in ascending order using feet, it is noticeable that on saving and reloading the order changes.? The numbers shown are still correct(???) but the order is now off.? The graph is "correctly wrong" i.e. the left hand column has the stations in the correct order BUT only 4 of the 7 at equidistances.? HOWEVER the calculated times for the journey ARE CORRECT on the face of the graph.? So the first station shows the correct departure time, as does the next and so on.? The graph Y axis is wrong but the right times for the trains are there.

So there are three lurking problems 1) in the list of stations which incorrectly sorts, but the distance in feet values are correct in the interface and on the TimeTable.py output.
2) the correct timings are being calculated at and between stations in feet and mph, and displayed on the graph 3) the graph Y axis is failing to calculate the distribution of stations properly, and losing 3 of the 7 -? value in feet for the final station displayed is 97152.0 - the stations beyond that point are 170016 and greater.


Locked Re: possible bug, LocoNet slot monitor

 

I totally agree we need a full filter, if I run my WIP Expanded Slot with the
"new" current filter I get to see all 400 slots which it makes the monitor more
than a pain to use. One of the first things we did when testing expanded slots
was to add the checkbox filters, ugly but effective,

In addition to Marc's filters, I would add jump direct to loco, jump direct to
slot.

Steve G.

---------- Original Message ----------
From: Marc <forfoum@...>
Date: December 12, 2018 at 6:59 PM


LoconetChecker had the options to filter Digitrax slots for :

Active ( InUse, Common)
Active + Idle
All slots
All slots including System slots
System slots only
Free slots only
Idle slots only
Inactive slots only (this one never seemed to work)
Common slots only
InUse slots only

To me the one that mattere is the "COMMON".

Where 12 or 20 slots are involved it is not an issue. Where 120? (or 240)
slots are involved it can become a pain without filtering.

- - - -
While playing around with this, I discovered that JMRI throttles (virtual)
will throw a " Failed to get response from Command Station " instead of the "
Slot FULL ' message.
That it does 10 retries to try and get a slot assigned.
'SLOT? FULL'? message is only displayed in 'Monitor Loconet'.
System Console reports the 10 retries.?

These occupied slots never get purged out by the system, no matter the Command
Station OSW settings.

So people can think it is a Communication? fault more than a? simple " slot
full " problem.

Marc



Locked Re: Release functional testing

 

That would be great!

The release script (in the theatrical sense, not in the computer-program sense) is here:
It¡¯s a bit messy, but we really do follow the steps.

There¡¯s a lot of automated testing (i.e. see and )

The testing with hardware comes in toward that end of the process, and it¡¯s a bit ad-hoc. After the (proposed) files are created and available at e.g. the release builder sends an email to the developers list and asks for feedback on the files. Historically, this was mostly to make sure that the installers would install OK on different kinds of machines (none of the people who usually do the releases are Windows native, for example). In that process, some people generously spend time testing on their hardware, but it¡¯s not really systematic.

It would be _great_ to get some additional hardware-based testing at that step.

It would also be good, and perhaps more practical, to get the test releases themselves used and reported back more systematically. They¡¯re part of a sequence, and it¡¯s really helpful to find problems that occur in that sequence as early as possible. Some people do send a note to i.e. jmriusers or by private email after they use it. That valuable and much appreciated. But it¡¯s not systematic, particularly in the less-popular systems and less popular connection methods (If we break LocoBuffer support, we hear it immediately; if we break an EasyDCC connection, it might be longer¡­). If people who use those less popular equipment would test at least a test release or two in each sequence, and we had a systematic way to get that feedback, it would help us keep problems from cascading.

Thanks for thinking about this!

Bob


On Dec 13, 2018, at 4:19 AM, Bob Morningstar <bobmorning@...> wrote:

Bob J and the JMRI team:

Do documented release test scripts exist for testing pre-production releases? In a past life I did this sort of work and would like to contribute with release testing.

I was thinking along the lines of repeatable testing scenarios/scripts which have defined test parameters, steps, and desired outputs?
--
Bob Jacobsen
rgj1927@...


Locked Re: 4.13.6, Digitrax DCS240 and indexed CVS

 

Bob

Done that: tests with Allow caching when writing index CVs for read or write operations unchecked. ?I've added two files about it to the folder in ProblemsBeingWorkedon. One is a Loconet log file and the other is some text and screenshots. ?It notes specifically two things:
- JMRI working in Page mode when the setup request Direct Byte mode
- the fact that the command station is a DCS240, which I know from experience is flaky in Page mode, and that I've used DP 4.13.6 - same computer, too - with a genuine DCS100 to program an ESU L4 ?in Ops mode with no issues.

Mick
______________________________________________________________________
Mick Moignard
Specialising in DCC Sound
p: +44 7774 652504
e:
mick@...
skype: mickmoignard
IBM Notes and Domino: still has what it takes as an App Dev and Collaboration platform.


Locked Re: Test version problem in Operations with Locomotive Type

 

John,

Can you give me step by step detailed instructions on what you're doing so I can reproduce?

Dan


Locked Re: Release functional testing

 

Steve's message about 'real hardware' is important. We as developers only
have some of the hardware in our hands. Identifying others with hardware
that the developers don't have is important. Getting some of those
individuals able to do specific testing for us, capturing logs, etc... is
important for use when getting new systems and hardware on line.

If somebody has 'some of the less known hardware' it is very helpful if they
are willing and able to check out the development releases to see if we
missed something and broke them or to try new features for those lesser
known systems.

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


Locked Re: Release functional testing

 

Hi Bob,

Aside from the CI testing,
I'd say the main priority in user testing is does it actually connect to the hardware?

As JMRI connects to so many different command stations and hardware types, that's one thing which is difficult to reproduce.
Can you actually drive a train / program a decoder?
While simulated connections are great, there's nothing like getting a proper bit of hardware connected.

I've been doing quick pre-release tests on Win7 + a Raspberry Pi for MERG CAN USB + MERG CAN Network connections,
using a current panel + profile, along with a virgin install, however only testing the bits I'm familiar with, eg. I don't even open up SoundPro or OperationsPro.

I've seen that some people test a profile ( + panels? ) created from the previous 2 major releases to check the upgrade process.

If you had any recommendations for this, I'm sure there'd be some interested folks,

Steve.


Locked Problems with Timetable #timetable-tool

 

I have just loaded 4.13.6 in order to get at Timetable - I just couldn't resist it!

I'm sorry, but I have broken the new toy.? I am an oddball in that I want to use it for a real timetable with real distances and speeds - not a model.? If I use feet the numbers are very large and the graph function produces a maximum window size graph with only 4 of the 7 stations on it all equidistantly spaced.? If I use metres it reduces the size of the numbers and the graph comes out with all the stations showing in the right order, in a small window, at reasonable spacing etc. BUT of course it expects my speeds in KPH so the timetable doesn't match with the real thing.? If I change the values to equivalent KPH I need decimal places for accuracy, but I am only allowed integers. UGH!

I doubt that this is of any importance to anybody else, but I'd like miles (or chains or yards) and MPH please?