|
Locked
Re: JMRI 4.6?
Gary D,
A lot would depend on how many of the features of JMRI you are using? If you are only using it for decoder programming, then the only real tripping point is the layout connection details. It would likely be easier to set them fresh, but you wouldn't have to make intermediary steps. But if you are using panels and lots of scripts, then there are more issues to consider. Biggest is a number of changes that effect homemade scripts. If you give some details of what features you use, we can give better clues for you. -Ken Cameron, Member JMRI Dev Team www.jmri.org www.fingerlakeslivesteamers.org www.cnymod.org www.syracusemodelrr.org |
|
ADMIN: Copied from a post by Bob Jacobson
This looks like a good moment to describe the thinking behind JMRI¡¯s releases more generally. Twice a year, we create something called a ¡°production¡± release. These have names like 4.16, 4.18, etc. These are the ones that we encourage people to use, particularly new users, because they¡¯re a good balance of new features and annoying bugs (new and unfixed) Any development process can create bugs; sometime even properly-working new features are considered bugs by some users! So how do we get from ¡°new code¡± to ¡°production release¡±? *) About once a month we create a ¡°test¡± release. These have names like 4.17.1, 4.17.2, etc leading up to 4.18; after that, a new series starts with 4.19.1, 4.19.2, leading to the next production release. These have new features, like ¡°rotation of Layout Editor¡±. We encourage as many people as possible to download these and _test_ them, so that new problems can be found ASAP. The test release process doesn¡¯t work unless people do that. Generally, all the small numbered test releases are made with all the contributed changes up to that point; they¡¯re meant to be inclusive. Toward the end of the sequence, though, the risk-reward ratio changes: We don¡¯t want to introduce a new bug in the last test release before a production release. Partly that¡¯s because the test process isn¡¯t perfect; partly that¡¯s because such big changes can often wait a little bit anyway. People working on new features and fixes really do try to not break things. We¡¯ve got lots of automated and manual testing in place. But JMRI is large, complicated, and has lots of interacting features: We need users to check things to make sure that JMRI still works for _them_. So it¡¯s very helpful for people to install and check a test release or two between production releases. At a minimum, we request that people download and use a new production release once a year or so: The further behind a layout is, the bigger the step forward when it has to be updated, and the more likely that unexpected issues will arise. If that happens at the same time as a new computer, or a change to the layout, or multiple issues are present, then it can be really complicated and time-consuming to resolve. *) Between test releases, during that month of accumulation, there are ¡°development¡± release available. These are called names like 4.17.1-ish, 4.17.2-ish, and they¡¯re built several times a day if changes have been made. They are truly the latest and greatest. A few hours after a change is made, it can be gotten from one of those (the change mentioned here has already been built into these: ) People can download and install these to check new features of interest to them. If problems are found and reported, the whole process moves along even better. Bob -- Peter Ulvestad JMRI Users Group Moderator - ( ) Tam Valley Group Moderator - ( ) Sprog-DCC Group Moderator - ( ) Edmonton Model Railroad Association - |
|
Locked
Re: Verify Initial Setup
Mike G,
I don't know if anyone else mentioned it yet, but the cab firmware of 1.28C is kind of out of date. There are a number updates and feature in there. Now for just doing simple things like being a throttle and programming decoders, it isn't going to make a big difference. It does add a tool or two if you ever want to do anything else like signals or turnout controls etc... So consider getting the update from NCE. But at least you are getting to the decoders. Now what the latest version of JMRI will always provide is the latest new decoders that have been discovered. The reason a given decoder may show as one of many is the decoder 'brain' only gives us a few hints on which decoder it is. And that matches more than one decoder we know. Some vendors have huge numbers of different decoder that give the exact same id code because the differences are external, like size and shape or number of function wires connected. On cases like that, you might know which is the best fit, or you may just have to guess. -Ken Cameron, Member JMRI Dev Team www.jmri.org www.fingerlakeslivesteamers.org www.cnymod.org www.syracusemodelrr.org |
|
Locked
Re: Rotation of layout
#layouteditor
This looks like a good moment to describe the thinking behind JMRI¡¯s releases more generally.
Twice a year, we create something called a ¡°production¡± release. These have names like 4.16, 4.18, etc. There¡¯s the ones that we encourage people to use, particularly new users, because ithey¡¯re a good balance of new features and annoying bugs (new and unfixed) Any development process can create bugs; sometime even properly-working new features are considered bugs by some users! So how do we get from ¡°new code¡± to ¡°production release¡±? *) About once a month we create a ¡°test¡± release. These have names like 4.17.1, 4.17.2, etc leading up to 4.18; after that, a new series starts with 4.19.1, 4.19.2, leading to the next production release. These have new features, like ¡°rotation of Layout Editor¡±. We encourage as many people as possible to download these and _test_ them, so that new problems can be found ASAP. The test release process doesn¡¯t work unless people do that. Generally, all the small numbered test releases are made with all the contributed changes up to that point; they¡¯re meant to be inclusive. Toward the end of the sequence, though, the risk-reward ratio changes: We don¡¯t want to introduce a new bug in the last test release before a production release. Partly that¡¯s because the test process isn¡¯t perfect; partly that¡¯s because such big changes can often wait a little bit anyway. People working on new features and fixes really do try to not break things. We¡¯ve got lots of automated and manual testing in place. But JMRI is large, complicated, and has lots of interacting features: We need users to check things to make sure that JMRI still works for _them_. So it¡¯s very helpful for people to install and check a test release or two between production releases. At a minimum, we request that people download and use a new production release once a year or so: The further behind a layout is, the bigger the step forward when it has to be updated, and the more likely that unexpected issues will arise. If that happens at the same time as a new computer, or a change to the layout, or multiple issues are present, then it can be really complicated and time-consuming to resolve. *) Between test releases, during that month of accumulation, there are ¡°development¡± release available. These are called names like 4.17.1-ish, 4.17.2-ish, and they¡¯re built several times a day if changes have been made. They are truly the latest and greatest. A few hours after a change is made, it can be gotten from one of those (the change mentioned here has already been built into these: ) People can download and install these to check new features of interest to them. If problems are found and reported, the whole process moves along even better. Coming back to this specific feature request, it¡¯s complicated enough and there are enough _other_ changes pending in LayoutEditor that it¡¯s being held for after the next production release. Pending what we find, the next production release will be this weekend, and JMRI 4.19.1 with this feature will come right after (perhaps even a half-day before). You can get an early look at that via the development installers (see ) - if you test that and find issues, perhaps they can even be fixed by the 4.19.1 release! Bob On Dec 17, 2019, at 8:02 PM, Spuds McCat <spudsmccat@...> wrote:-- Bob Jacobsen rgj1927@... |
|
Locked
Re: Issue copying profiles with long name
i think we are talking about a windows problem. you mean jmri runs in the background and overrides windows in a negative way? are you suggesting that copying jmri files somehow is different than copying any other files? are you further saying since the specific discussion was whether the term "file name" includes the path or not, that in jmri one can copy a file when the character limit of the command is greater than 256? If that is true it is worth using jmri as a file manager. to utilize jmri to override windows must it be running, be it in the background or actively open or will this "trick" of exceeding the 256 character limit of windows work if it just resides on the computer I truly thought my comments on windows file name limitations would be helpful. But if this is only a jmri problem why do I experience the same problem when copying files and I dont have jmri installed? Bobby Abrams On Wed, Dec 18, 2019 at 3:21 AM Randall Wood via Groups.Io <rhwood=[email protected]> wrote:
|
|
Locked
Re: Issue copying profiles with long name
no my friend the path is part of the file name and that is why what you want to do is not working in the manner you wish it to Bobby Abrams  On Tue, Dec 17, 2019 at 9:58 PM <forfoum@...> wrote: That is not a file name , it is a path + file name? |
|
Locked
Re: Issue copying profiles with long name
it may be that using copy the name is now 280+ (counting copy from and copy to) Bobby Abrams On Tue, Dec 17, 2019 at 8:52 PM JerryG via Groups.Io <jerryg2003=[email protected]> wrote: I can recreate the problem at will.? More info:? |
|
When trying, it takes four tries:
All off, 9600 All off, 19200 All on, 9600 All on, 19200 That covers the many combinations of versions, firmware, prior options, and past history. If the console never shows the firmware code 6.3.x or 7.3.x, you've covered the jumper/baud rate combinations. Still leaves cables and connections. Also if during this either of the status lights in the USB stick on solidly, that's another clue of what is going on. This last log posting at: 2019-12-17 10:17:44,336 util.Log4JUtil INFO - * JMRI log ** [main] It never got the right response. It did get garbled data, that usually means an issue with baud rate wrong. As long as the console is showing the AA messages errors, we are not talking to the USB successfully. -Ken Cameron, Member JMRI Dev Team www.jmri.org www.fingerlakeslivesteamers.org www.cnymod.org www.syracusemodelrr.org |
Ken Cameron
Peter Ulvestad
Bob Jacobsen
Bobby Abrams