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
Search
Locked INFERNALS
|
Like Jon Miller, I at first thought INFERNALS was a joke, or JMRI's tongue in cheek substitute for internal. But, I still don't know what it means, or its proper use. I just checked the JMRI Help Glossary and didn't find INFERNALS.
Can someone define INFERNALS for us "ignoratti"? Can someone add a definition to the HELP GLOSSARY? I appreciate that the programming of JMRI, and those giving aid to the group, know far more about programming and software than I. You perform a great service for the rest of us. But, we sometimes find your writings incomprehensible. Adding more terminology to the GLOSSARY would be very helpful! Don Weigt |
|
Jon Miller
开云体育On 1/4/2019 10:30 AM, Don Weigt
wrote:
Glossary and didn't find INFERNALS. ??? When you go to Preferences, Default you will
find (in my case LocoNet) and Internal
(which is a Simulation mode).? I think because on one of the
releases it set this to "Simulation" which created many emails
"why doesn't it work".?? I think Dave refers to it as
"infernal". -- Jon Miller For me time stopped in 1941 Digitrax Chief/Zephyr systems, SPROG, JMRI User NMRA Life member #2623 Member SFRH&MS |
开云体育Like
Jon Miller, I at first thought INFERNALS was a joke, or JMRI's tongue in cheek
substitute for internal. But, I still don't know what it means, or its proper
use. I just checked the JMRI Help Glossary and didn't find INFERNALS. Can someone define INFERNALS for us "ignoratti"? ?
?
?
I think INFERNALS means the state of the JMRI software
when your layout control system does not connect to JMRI and the program goes to
internal settings in order to run without telling you that it has done so thus
causing you to post a question as to why your JMRI software is not working with
your layout control system anymore.
?
Donald:-)
? |
|
It seems my antipodean sense of humour/satire/frustration gets lost other side of the pond.
toggle quoted message
Show quoted text
Infernals is a play on words, describing the consequences and support nightmare created by the unfortunate code decision that caused connection preferences to be set to Internal if hardware was temporarily absent. Here is the text snippet I usually posted in response to this problem: "If you get "Found mfg 123 (Masoth Electronic, GMBH) version 123; no such decoder defined.", and/or all CVs return a value of 123 and long address 15,227 it is 100% certain that you cannot communicate with the decoder and that one of two possibilities have happened: 1) Preferences->Defaults has Service Programmer (and possibly other items) set to Infernal. 2) Preferences->Connections has System Connection set to Simulator. Possibility (1) is the most likely. It would most likely have occurred due to a previous failure to open a connection. If there is no alternative to Infernal, you currently have a problem with the connection to your DCC system and you need to resolve the connection problem before proceeding. If an alternative is available select that, restart JMRI and try again. Warning, the Infernal problem can happen again in the future if you have any connection problems. See comments at: /g/jmriusers/message/153294 This has hopefully been fixed in JMRI V4.14" -- Dave in Australia On 5 Jan 2019, at 5:47 AM, Donald <kinney@...> wrote: |
开云体育1) From my Concise Oxford Dictionary 8th Edition, 1990: infernal adj. 1?a of hell or the underworld b hellish, fiendish 2 detestable, tiresome I can think of no better description of the situation we found ourselves in! 2) Who hasn't heard a diehard steam enthusiast refer derisively to the "Infernal Combustion Engine" (diesel) as it supplanted the "External Combustion Engine" (steam)? --? Dave in Australia On 5 Jan 2019, at 7:15 AM, Dave Heap <dgheap@...> wrote:
It seems my antipodean sense of humour/satire/frustration gets lost other side of the pond. |
开云体育Dave The miss understanding is probably because we are upside down and see things differently! Gerry On 5/01/2019 7:15 am, Dave Heap wrote:
It seems my antipodean sense of humour/satire/frustration gets lost other side of the pond. Infernals is a play on words, describing the consequences and support nightmare created by the unfortunate code decision that caused connection preferences to be set to Internal if hardware was temporarily absent. Here is the text snippet I usually posted in response to this problem: "If you get "Found mfg 123 (Masoth Electronic, GMBH) version 123; no such decoder defined.", and/or all CVs return a value of 123 and long address 15,227 it is 100% certain that you cannot communicate with the decoder and that one of two possibilities have happened: 1) Preferences->Defaults has Service Programmer (and possibly other items) set to Infernal. 2) Preferences->Connections has System Connection set to Simulator. Possibility (1) is the most likely. It would most likely have occurred due to a previous failure to open a connection. If there is no alternative to Infernal, you currently have a problem with the connection to your DCC system and you need to resolve the connection problem before proceeding. If an alternative is available select that, restart JMRI and try again. Warning, the Infernal problem can happen again in the future if you have any connection problems. See comments at: /g/jmriusers/message/153294 This has hopefully been fixed in JMRI V4.14" -- Gerry Hopkins MMR #177 FNMRA Great Northern Downunder NMRA Australasian Region Contest & AP Chairman Web Administrator |
|
Marc, Sorry to "flog a dead horse", as the old saying here goes. Hope that's clear to everyone... I'm sorry if I took this all to seriously, but please understand what it's like for some of us just getting started with JMRI. I wondered if INFERNALS was a joke, or real. I had seen other posts using INTERNALS, so thought there might be both in JMRI speak. We're already dealing with JYTHON, which I understand is real, as is PYTHON in other places. So, when the gurus toss out terms, my first inclination is to think they are real. What's good fun for those who understand better, is just more uncertainty to those of us trying to wrap out heads around this big new thing. I'm still wondering why Layout Editor is adding capital "i"s to the detector labels I have on my panel. For example, I enter PD03, it appears in the list as IPD03. Probably stands for INTERNAL PD03, but I've still not learned why some items get those added to their designators, while others, such as turnouts, don't. And I still don't grasp JMRI's distinction between internal and not internal. Might some be virtual in panels and others related to physical items on the layout? Not sure that's right, since detectors are on layouts. JMRI is complicated enough without making it more confusing, however innocent the intent. Stepping off the soapbox! (rant ends) Don Weigt |
开云体育Don, As a support person I completely agree that the 'Internal' setting bug was an 'infernal' bother. As for your 'I' question the answer is pretty simple. Detectors, turnouts, etc. always require a 'System' name. The system name tells JMRI what connection is used to read and send any messages from/to that device. This shows up as a prefix like 'L' for LocoNet, 'N' for NCE, M for LCC etc. These examples are for actual hardware connections. However it is also possible to create an entry in JMRI that has no actual hardware connected. That JMRI only entry will have an 'I' for 'Internal' attached to it. If you want to give random names to hardware be sure to use the
'User' name, not the 'System' name for your own definition. You
are not allowed to simply make up 'System' names because they are
the pointers to the actual hardware on your layout. 'PD03' sounds
like it is your user name for some detector, so some 'helpful'
programmer added an 'I' in front of it rather than warning you
that you can't do that because there is no such thing as a 'PD'
system device. Dick :) On 1/5/2019 9:55 AM, Don Weigt wrote:
|
|
Dick, Thanks for the explanation of the capital "i"s. I hope they don't have to be changed when I choose which interface I use for the control panels and railroad hardware: possibly C/MRI. I want to have turnout control from the panels, but also from my EasyDCC tethered and any JMRI wireless throttles. If the prefix is for the type of control system, I wonder which would be right for that?! Ideally, a wireless tablet could be used as both a control panel and as a throttle. Is there an existing way to do that? I can imagine a "button" in a corner of the screen that is pressed to toggle between control panel and throttle displays, or using most of a larger tablet's display for the control panel, with a narrow band along an edge for the throttle. That could be very workable on my ASUS' seven inch display. If any discussion follows, that paragraph about combined wireless control panels and throttles probably should be made a new topic... Don Weigt |
|
Don W,
To clarify something about adding devices, what the system name means. Generally the field you enter is information for how JMRI will find the device. Now for Internal devices, it is just a name field with no specific meaning. But for everything else, here is how the system name breaks down: 1st character (and sometimes digit) tells JMRI which connection to use to talk to this device. Next character is about the 'type' of the device. Example is T for turnouts, S for sensors, R for routes, X for Logix, and so on. This tells JMRI which 'manager' deals with the device. Rest of the characters, this will vary greatly as for real hardware it has specific meaning to picking the remote device. It may be a simple number or something more complicated, but it will depend on the system (as picked by the 1st character). Note: when you are entering the name, you don't type in the first two parts, those are provided by the pull down that selected the system name, the screen you are in picked that it is a turnout, sensor, etc... -Ken Cameron, Member JMRI Dev Team www.jmri.org www.fingerlakeslivesteamers.org www.cnymod.com www.syracusemodelrr.org |
|
Marc,
toggle quoted message
Show quoted text
That is not correct. “I” is for internal and uses the Internal managers. A simulated Digitrax connection is still “L” and uses the Digitrax managers. Instead of a PR3/4 or LocoBuffer-USB, the connection hardware is emulated by the LocoNet Simulator software. The “Defaults” problem was an arbitrary switch to the Internal managers when a real hardware device was not present. If the connection was defined using a simulated mode, then the arbitrary switch never happened. Dave Sand On Jan 5, 2019, at 1:33 PM, Marc <forfoum@...> wrote: |
|
Don W,
If you are building panels using Internal devices because you don't know which real system you will use, then assigning 'usernames' to each item will save you a lot of effort later. If all the panels use the usernames from the tables (for turnouts and sensors) then later when you start getting real hardware, there is a step to 'move' the username from one systemName to another. All the places using the username won't notice the change. Keep in mind that many panels do have logical things that use Internal for their system. These are virtual items sometimes used in control panels or maintaining logic states. Now the normal default for a CMRI connection is 'C', EasyDCC seems to user 'E'. -Ken Cameron, Member JMRI Dev Team www.jmri.org www.fingerlakeslivesteamers.org www.cnymod.com www.syracusemodelrr.org |
|
Ken, Marc, and Dave, Thank you for the follow up. Now I understand the system names for devices a lot better! I just hope they change automatically, if needed, when I move from simulation to running with my EasyDCC train control and whatever model railroad interface I choose. If that proves too difficult, I may keep the EasyDCC as it is, and just use JMRI for the layout control and monitoring functions. Of course, that would mean not having automatic running or automatic emergency stopping, since JMRI wouldn't have access to the trains. Looking again, I see both turnouts and sensors do have the capital "i" first letter, and T or D for the second, as you described. I used the PD for photodetectors, to differentiate them from current sensing block occupancy detectors. I hope that isn't going to cause problems. I also gave them more descriptive user names. Detectors may even get comments added, as the user names are BLK00DET05, and so on. Fifth photodetector monitoring train positions in block zero is that one's meaning. All blocks will have current sensing block occupancy detectors, although they are quite useless in yards where I have multiple tracks in one block. I would like to use JMRI to control operating signals along the mainline, as well as turnouts. A few crossing signals are also possible. It would be great if all that proves practical for me, with tablets serving as the control panels, whether carried or mounted to the facia. The 64 photodetectors will be used only to monitor the trains' locations, progress, and clearances in hidden staging tracks. Previously, the photodetectors only operated LEDs on a control panel. With JMRI, I may do more. ORing them together with Logix could give another block occupancy detection signal, and Logix might be able to allow automatic storage of multiple trains on each staging track, as I did manually. Clearance is assured as long as one or more detectors are clear between trains. I typically stored three trains on each of two long tracks. Staging was configured as a double track reversing loop with trains running through in only one direction. So trains on each track returned in the same order as they exited the visible railroad. My apologies if that was too much detail. Don Weigt |
|
Thank you again, Ken. I have EasyDCC and a home brew computer interface that worked previously. I'm reassembling my railroad after a move, with some main line changes. I plan to reuse the EasyDCC which I have reinstalled and working now, plus as much of the computer software I wrote as I can, along with the hardware it used previously. I'm in the process of reinstalling it now. It inputs turnout positions, and from control panel switches, block occupancy detectors and photodetectors. It controls block power, LED indicators, and turnout positions. I'd like to add main line signalling, using JMRI for the logic, and sending the control data to my interface to drive LED signals. My challenges will be translating and transferring data between JMRI and my home brew interface, along with my EasyDCC. I'm pretty confident the EasyDCC part will work, but as pointed out, it lacks any way to input railroad data. My other railroad input and output data are mapped in computer RAM, but directing the data to and getting it from the right spots will be the challenge: which bits in which bytes correspond to the JMRI labels, and in what format is it sent and received between JMRI and my hardware. As suggested, C/MRI may be a good choice, as the JMRI end is done, I just need to translate it to work with my home brew. At the moment, I don't know why it should be easier to make my control computer "speak" C/MRI than native JMRI, but someone in this group probably will tell me which will be easier. I started learning JMRI by entering part of my track plan in Layout Editor. That will give me some experience with JMRI and something to use for developing the communication to my system. Thanks again for all your help, some of your recent information has cleared up a lot of mystery for me! Don Weigt |
|
Don,
The main reason you would consider making your custom hardware appear as something like CMRI is that making the system connection in JMRI is a fair bit of Java work. There is no such thing as a 'native' JMRI connection. Each system connection is written for a specific type of system. CMRI is just one of the simpler protocols out there. -Ken Cameron, Member JMRI Dev Team www.jmri.org www.fingerlakeslivesteamers.org www.cnymod.com www.syracusemodelrr.org |
Ken Cameron
to navigate to use esc to dismiss