This is not a topic I have paid much attention to. I have a lokprogrammer and maybe I am misunderstanding some of the things Randy has posted, about JMRI being slow to read and write DV's but for loksound, I am set.
JMRI does more than program decoders. I looked at a video to generate switching lists, but in my stage of construction, it's not something I need now.
Wireless operation: I see people rave about operating their layout with a cell phone. My Iphone 6 doesn't alway acknowledge that even I have a finger. (please hold your obscene comments so this thread doesn't get locked) Plus it is a battery hog, so that didn't peak my interest.
I saw an introductory video by TSG Multimedia on youtube. That is John Abatacoloa's channel. He initially wasn't a model railroader, just a videographer, but had a friend, Dan Cortipassi, who was. He filmed Dan, reviewing trains or detailing trains. They had a falling out and John became an N scale modeler.
Back to the topic, he did and introductory video. It may not be the best, but it shows some of the things that JMRI can do besides program decoders. I wasn't planning on DCC turnout control, but setting routes by a tablet, is far more interesting to me than using a power cab to control turnouts.
Anyway, for those of you that want a visual of what JMRI is all about, I suggest this youtube.
Henry
COB Potomac & Northern
Shenandoah Valley
Henry,
Was hoping this could help me out with Turnout Tables, but all I heard was how great JMRI is. That's true, once you can figure what to do with the big box of mixed Legos that you get. Help is promised in most windows you pull up, but the turnout situation is a good example of where there's a whole olot of JMRI that's not ready for prime time.
There is Turnout Tables. Fill it out and it works. Then you make another change somewhere and it asks if you want to restart to have it take effect? Sure. But then your Turnout Table disappears, without even asking you if you want to save it. Why would you NOT want tom save it? And why not a warning that you should save it? Apparently, you're just supposed to know that. And I did, except I'm getting to the age when I forget as much as I learn every day. So I concede I should've know while at the same time it SHOULD have given me some sort of warning it was going to File 13 my hour or so of work entering all that data.
So tonight, I reenter everything and very much focus on hitting Save next. And it gives two choices, just saving the data or saving data and configuration. So I pick the second, resting assured that this time it'll all be OK.
JMRI restarts this time and the Turnout Table that I have set to start when it starts up? It's blank. So if it's saved, sure need a map to get there. Help isn't much help, as it refers only to the window that's active. This is a feature, not a bug, but doesn't help much for those who haven't already learned their way through the multiple windows it takes to set-up something as simple as turnout control.
Now, I've done this before, so I know it's possible. It's just that how it's done is scattered like breadcrumbs here and there throughout Help with no clear guide from start to finish. You just have to keep randomly plugging away and losing stuff (even after it was "saved") until yoiu stumble into it working.
JMRI is indeed feature-rich. It's also still very much a kludge, with various moving parts scattered about without a roadmap as to what comes first. I've come to the conclusion that what's needed is an entire other project, JMRI for Dummies, that walks the user throuugh the various stepping stones to actually achieve something like How do I operate my turnouts? Because making little tables and panels is neat, but not very useful if they don't proivide actual functionality, let alone being able to be found once you've entered the data they call for.
What's kind of depressing is that part of the intent behind JMRI seems intended to help people learn how to program. Unfortunately, the lack of good Help and the absence of clear step by step instructions to achiveing basic functionality tends to discourage, becaused the preference seems to be to break things up into multiple panels for no good reason, rather than encourage the learning process. By the time I get this figured out, I'll be so discouraged that I won't touch the thing again until something breaks, circling the drain to empty out my brain tub, rather than filling it up.
Good luck to tghose who take the plunge, because in the absence of good Help, you're goiung to need a lot of good luck.
Mike Lehman
Urbana, IL
I gave up on JMRI months ago. It is not user friendly, and the documentation is atrocious. I am not a computr geek, and I have no desire to become one. All I wanted out of the software was the ability to maintain a car roster and generate switchlists. sometimes it worked, and sometimes it was click through window after window after window. I have since gone back to maintaing my car roster on Excel and hand generating switchlists.
Bear "It's all about having fun."
The UI, at least in the layout editor portion, has to me ALWAYS been atrocious, and when someone brings it up it usually gets a response along the lines of "you have no clue". Yes - EVERY other application I use, SAVE is save, there is no "store". Yes, some things automatically save if you exit without explicitly hitting the save button, but MOST applications just ask if you want to exit without saving. You save things, you don't just hide them and bring a differnet window to the front to work on the next part.
The DecoderPro part at least is not like this, it even prompts to save a roster entry if you try to close without doing so.
JMRI is a prime example of why Java has to die, sooner rather than later. Great, the same program works on 3 platforms. But it has none of the good features of any of them, in order to do this, every aspect of the UI has to be least commoon demoninator.
There's a down side to volunteer open source coding - and it's the same trap I fall into for personal stuff as well. Once you have your gee-whiz new feature included and working, you lose interest in tweaking the mundane stuff to make it better, particualrly the UI. That's fine when it's something I'm using for myself, but when you are trying to make something for general consumption, it's not. Even the big commercial software companies fall victim to this, either with little attention paid to the UI, or not even following their own guidelines. For the love of everything, a panel, a table, they are FILES. Allow SAVE and OPEN like EVERY OTHER PROGRAM. If the tables and the panel and the diagram are all supposed to be part of one 'file' then do it that way, make the elements like the tabs of a common spreadsheet, individual pages that are part of the whole which is the element that is saved and loaded.
Biggest problem I had with it was, you can't mess up when drawing a track diagram and assigning block detectors (sensors). It seems to keep them in the order you entered them, not in the order they appear on the diagram, so when I made an oops and skipped block 12 out of 16, then deleted 13-16, then added 12-16, block 12 lit up when the train was on the part connected to the 16th output of the detector. Yes, there are 'programmer' ways to fix this, but not something your average model railroader is going to know how to do.
Yes, I am a Windows snob, but really, how many model railroaders are using Linux? I actually did, the train room computer I had to go with my last layout was a low power system running Linux. It worked, mostly, but there were the typical problems which, while now documented, still are things the average modeler isn't going to want to deal with, considering on Windows or a Mac it just works.
The complications with the Layout Editor and Panel Editor are why I am going with my own DIY application, written in VB. The overly complicated scripting language adopted is another (the exact use of spaces matters? really?). And that bad experience with a simple loop of track still haunts me. After I redid it and got it all in order, I was still getting random incorrect block detections - train in block 5 would light up block 12 or something. Everyone blamed the hardware - oh, those old Digitrax boards don't work with supersonic (high frequency PWM) decoders. Then my non-computer friend, whose layout this was, built the same thing with Traincontroller and it just worked. While you can;t expect a 100% free program to be as fully polished as a rather expensive one, there's a lot more that could be done, if only someone was actually interested in doing it. But, it's a boring task and also UI design is the surest way to stir up controversy between developers. I'll just do my VB thing, which is also why my control nodes don;t need to be 100% CMRI compliant, since I am controlling both ends of the action. I don't need JMRI for Ops, as I have a very nice application that I can also easily modify if needed that stores all my loco and rolling stock rosters for inventory purposes as well as generates car cards and switch lists. It too was free.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
Randy,
You said "... I have a very nice application that I can also easily modify if needed that stores all my loco and rolling stock rosters for inventory purposes as well as generates car cards and switch lists. It too was free."
What is it?
macOS is a very well known "UNIX". I use DecoderPro on my iMac and love it!
I have it also installed under Win 7 and Win 10 running in a virtual machines (VMWare) under macOS but I prefer the native mode under macOS.
Windows is nice but it does not fit/integrate very well into an "Apple Family" using iPhone, iPad, iMac, AppleTV etc :-)
ps. I need Win exclusive to run the windows only application of Zimo and ESU for decoder firmware update.
Reinhard
I had a friend once tell me it was like eating chicken - eat the meat and spit out the bones. I tried JMRI and found the wonderful assortment of capabilities which were poorly documented and lousy UI. However, I found that some of the features were great for my needs so I plowed thru and figured them out. My biggest use of JMRI today is to program decoders and to maintain routes. Much easier than using my Digitrax throttles. For me, these features are the meat I can eat. The rest are bones I have spit out for now.
Paul D
N scale Washita and Santa Fe RailroadSouthern Oklahoma circa late 70's
There are several comments and observations here that pretty much match my own. Mike called JMRI a kludge. I'm not sure whether kludge is a verb or a noun, but it seems to fit. JMRI is a three-humped camel designed by committee.
That reminded me of an old joke from the early days of PCs called The I Ching of Programming. It goes something like this:
A Manager brings the requirements document to the Master Programmer and asks how long the program would take to develop if he assigned one engineer to the task.
"It would take one year" the Master replied, without looking up.
"What if I assigned two engineers to the task?" the Manager asked.
The Master replied, "Then it would take two years."
"And what if I assigned ten engineers?" the Manager continued.
The Master paused and said, "Then, the job would never be completed."
LINK to SNSR Blog
A problem with LOTS of software, and I include JMRI, is that it is designed to be easily used by the people who built it. And that little consideration is put into how a somewhat normal non-computer-literate human can EASILY and HAPPILY use it.
Ed
bearman Randy, You said "... I have a very nice application that I can also easily modify if needed that stores all my loco and rolling stock rosters for inventory purposes as well as generates car cards and switch lists. It too was free." What is it?
It's Dave Husman's CardCards Access database. You need Microsoft Access to be able to use it, but his app is free to download, in the CarCards Yahoo group.
OP here. While I said I wasn't paying much attention, I did not realize people thought it was so user unfriendly as expressed here. It seemed like I was missing out on something a lot of people liked.
I guess I'll continue missing it.
faraway macOS is a very well known "UNIX". I use DecoderPro on my iMac and love it! I have it also installed under Win 7 and Win 10 running in a virtual machines (VMWare) under macOS but I prefer the native mode under macOS. Windows is nice but it does not fit/integrate very well into an "Apple Family" using iPhone, iPad, iMac, AppleTV etc :-) ps. I need Win exclusive to run the windows only application of Zimo and ESU for decoder firmware update.
Eh, I've had an iPhone since the 3G, and it works fine on Windows. I just don't use iTunes, it's an absolute disgrace of a program (at least the Windows version) and even if I had a mac I don't think I'd ever let it organize my music - it nearly made a messof my carefully organized collection back then, and STILL insists songs I have in specific folders belong to a different album. Hard to see how that is possible since I ripped them from my own CDs. I have an iPad, too. Backup of both is iCloud, so I don't need to hook them to my PC for anything. If I need to transfer something, I have a utility that allows access to music, photos, movies, and books without iTunes.
Linux is a whole different animal than BSD-bases OSX. Apple isolates you from some of the underlying stuff - on a Mac do you have to go in and give yourself permission to use the USB port?
It's not just JMRI - the Arduino IDE is also written in Java to be as cross platform as possible. Most anyone who's moved beyond basic blink the LED stuff will tell you how poor the IDE is - does little more than a language-aware text editor like NotePad++. Several other more capable IDEs now have Arduino support so you can just upload your sketches in the same fairly easy manner as with the real Arduino IDE, but still have access to better programming tools. I use them all, depending on what I need at the moment.
It all comes down to the whole cross platform thing. There are things most Linux GUIs do better than Macs or Windows. There are things OSX does better than Linux or Windows. There are things Windows does better than Linux or OSX - but you can immediately eliminate any of those if you want to make a program run on all platforms (easily - there ARE ways around this to keep the UI independent of the 'meat' of the program, but of course that's more development effort).
It IS possible for JMRI to be better at some of this. It's a design philosophy choice in PanelPro - DecoderPro works differently and is quite useful and usable. The Loconet utilities are exceedingly useful for any Digitrax user. I haven't even looked at the operations part - I really think that was the last thing they needed to add, but I guess enough people are interested in a one stop shop and want everything plus the kitchen sink. It seems that came sortof out of left field though - sure, you have your LOCOS stored in JMRI from programming all the decoders, but rolling stock? Actually, one of my (long time) back burner projects was to link the CarCards program to JMRI so I wouldn't have to put my locos in twice. Trying to code a programmer seemed silly, when I could just have it drive an already completely functional programmer in DecoderPro. I may revisit that some day, although perhaps just write the API of an existing programmer like the SPROG, but it's not really high priority as I have standardized my decoders and I don;t really need any fancy programming - it takes me longer to fire up JMRI and get to the programmer than it does to do what I need with a throttle.
PEDI had a friend once tell me it was like eating chicken - eat the meat and spit out the bones.
Hadn't heard it summarized like that but I think that does sum it up.
Decoder Pro is pretty essential and fortunately it's moving parts are integrated together well enough that it mostly works if that's all you need.
I tend to use Panel Pro for other things like turnout control and spit out the bones on the rest. I did get the Turnout Table working finally. Yes, Randy was right, it's a Store vs Save thing. I was storing, which sounded good, but why you'd want to enter data and then do nothing with it, as Store does, is over my head. I can see it as an option but only if Save was the very clear default option.
I wish it did work easily for Ops, but that was just too steep a climb given the loss of faith in my ability to stay on the steep learning curve.
The Linux thing isn't an issue here, as I have a Unix expert in the household. Was even learning a little of that (it's not easy to learn command line anything once one's youthful memory starts to fade) but when the most recent Raspberry Pi build melted down, I threw in the towel and went forward with JMRI on the iMac. At least it seems to grant me a GUI for everything.
So I did finally figure out both the turnout table and the Macros, which are "Routes" in JMRI-speak. Thought I had it all done right, so went with the invite to restart after organizing the webserver, then a typical chunk of JMRI-irony pops up, a warning to save the Routes in the configuations. That would have been a very good warning to have BEFORE i'd hit the restart button...
But all too typical, even when they finally tried, it was too little, too late. Yep, that horse had already left the barn, it was gone before the warnjing came up. Guess they're just using the heel of their boot to rub it in or something, as getting the warning then is more of an in your face slap than it was helpful. Guess we'll keep putting up with the abuse until morale improves.
cannot get JMRI to run on my mac! GRRR!
Joe Staten Island West
The primary purpose I use JMRI/Decoder Pro is to read and store my locomotive CVs - in the event that I need to reset the decoder at some future date and I want to restore it to the adjusted CV values it had before the reset. Yea, it can be a bit slow on reading and writing the newer sound decoders but I can live with that.
Tom
https://tstage9.wixsite.com/nyc-modeling
Time...It marches on...without ever turning around to see if anyone is even keeping in step.
I'm 64 and computer illiterate. I do well navigating JMRI except for the one page for programming lights, especially ditch lights. I change this and that and get weird results. I get ditch lights on in reverse, or only one light working or one brighter than the other or one blinks and the other on stays on when the horn is used. I'll figure it someday.
BigDaddy I did not realize people thought it was so user unfriendly as expressed here.
I did not realize people thought it was so user unfriendly as expressed here.
They should ask for their money back.
Gary
Gary,
Since JMRI/Decoder Pro is open-source and FREE, they're getting what they paid for it.
tstage Gary, Since JMRI/Decoder Pro is open-source and FREE, they're getting what they paid for it. Tom
Ah, yes. But is it WORTH just what you paid for it?
Exactly, just because it's free and open source doesn't mean the UI has to stink. There are other free open source programs with nice UIs. There are expensive paid programs with horrible UIs.
The fact that the DecoderPro component is fairly straightforward but the PanelPro component is not says there is no real excuse. The DecoderPro UI isn't bad at all, and seems well suited to even expanding the number of tabs for newer sound decoders to keep the various groupings of settings without rewriting the whole thing, it's all controlled by the decoder definition file.
I first down loaded it for the operations sections. I was very dispppointed. Seems to me that are cross platform do not seem to operate very well. The UI is one of the worst I have ever seen. An example of freeware with a great UI is Open Office. I find it easier to do program the decoders by hand. As to switchlists same thing write them by hand.