Hi Klaus I'm back looking at VSD again having been diverted by having to learn some Ubuntu command line skills as part of moving to JMRI4.14. I've got a couple of VSD questions: Q1. In the second post of this topic #155052 you wrote:
On problem 2.The VSDecoder Manager always comes up empty. What you are looking for might be "VSDecoder faceless", which skips the dialog and loads the Rosters automatically. This is doable, but I'm not sure how to quit JMRI later. For now it is not implemented.As you mentioned you can create a roster and associate the VSD file with that roster. Please see (section "Configuration Dialog"), how to achieve this. This will save some clicks and you can "Auto load" the VSD file as well, see .
Is it really the case that it's not possible to "save" the multiple decoders/profiles/VSDfiles in the VSDecoder Manager window for future sessions ?? I currently only have a small number of locos so it doesn't take that long to rebuild the Manager window for my fleet, but I imagine this is an issue for modelers with a large fleet.? The only option I can see at the moment is to keep the session running overnight if I want to go back to the layout with all sounds active the next day.? Is this on the to do list ?? If it's going to be possible in " "VSDecoder faceless", to skip the dialog and load the Rosters automatically", why isn't it possible to do that in the standard VSD UI ?Q2. i have Class64.vsd file assigned to one of my locos but when it appears in the Manager it always shows the same layout of buttons as in the GenericSteam.vsd without the combination of whistle sounds as shown in the document???which you referenced in the post above.? The problem may be caused by the fact that even if I choose Class64 as the profile and then as the VSD file, it always appears as GenericSteam profile in the Manager.? Is this a known issue?? Similarly I can't get Class94 to work as I've only ever seen the decoder for this once - it always reverts to GenericSteam. Regards Graham - @SetleDown
|
Locked
Can JMRI interconnect two DCC systems? (i.e.NCE & Digitrax).
When creating a simplified Loconet bus on a non-Digitrax layout, can both systems (in my case NCE & Digitrax Loconet bus) connect to JMRI at the same time through separate USB ports?? Can the Digitrax components be accessed from the home system.? For example can I throw turnouts with my NCE Cab through a DS64 connected to the Loconet?
|
Locked
Re: Turnouts cannot be thrown in Layout Editor when Editor Mode is off. (with MERG CBUS)
Thanks Dave. That was exactly what I needed.
Cheers / Sven
toggle quoted message
Show quoted text
On 06/01/2019 20:56, Dave Sand wrote: Sven,
Check Options >> Use Direct Turnout Control in the Layout Editor menu.
If it is checked, then the right mouse button will throw the turnout. If it is not checked, then the left mouse button toggles the turnout between closed and thrown.
Dave Sand
On Jan 6, 2019, at 2:32 PM, Sven Rosvall <sven-e@...> wrote:
Hi all,
Getting started with Layout Editor to control turnouts on my layout. The turnouts are controlled by MERG CBUS modules. I have defined them in the turnout table and can change them between "thrown" and "closed" without any problems. Good start so far. Then I drew a few of these points in the LayoutEditor and used the entries in the Turnout table. This worked fine and I could throw and close the points by clicking on the turnout icons.
But then I turned off Edit Mode (in Options menu). Now clicking on the turnouts would only close the turnouts. Clicking again would make a noise in the turnout solenoid but the turnout would not change, so something is happening.
Anyone seen this or have any hints on how to trouble shoot this?
Thanks / Sven Rosvall
|
Locked
Re: TABLE PRINT LIST TO TABLE MOVE DATA
Dave R, I have created a script which will move the user names from the ITnnn turnouts to XTnnn turnouts. There is NO capability for changing the turnout address assignments. The user name for IT123 is moved to XT123. When the hardware is implemented, the real address may end up as XT321. /g/jmriusers/files/ProblemsBeingWorkedOn/dsand/mass-move.pyAdd a "Lenz/XpressNet Simulator" connection to your profile. After you re-start JMRI, load the panel xml file, run the script, save the panel xml file to a different name. Stop and start JMRI and load the updated file and verify the results. This is a "one off" script. The scope is specific and running it twice will probably blow up the world. I agree with the comments made by Bob and Ken. It would have been faster and safer to manually move the turnout names. Dave Sand
|
Locked
Re: TABLE PRINT LIST TO TABLE MOVE DATA
Dave R,
I've done well with using the move option as is for the story you are
relating. What I found was I never had a mass of items to move from the
Internal to real system. As each board was finally added to the layout, I
was usually adding only a couple of items at a time as we would first test
them and confirm the wiring/assignments. I found this to be the better way.
Each board might show up as a handful of new sensors or turnouts. I'd play
with them via that system table to confirm they are doing what I want,
sometimes adding the invert option as needed to get the logical result I
wanted.
This concept stresses the build and test method. Don't build more than what
you can immediately test. This is important because you may find something
didn't work exactly as you planned. You don't repeat the mistake X times,
you make it once. Then on further installations you get it right the first
time. Sadly I know of many layouts that don't follow this concept. Finding
the problem when there has been six months of work of all types makes it
very hard to trouble shoot. Try finding the shorts in a yard (4 mainline
blocks and the rest 'undetected' as a power district) when 13 new, hand
built turnouts were installed without all the proper gaps cut in the
turnouts. Catching of them took a long while working. Oh, did I mention they
were also painted and scenic applied? Same goes for other parts, do one at a
time and test, then make the updates, then move to the next part.
-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org
|
Locked
Re: Setting serial port speed for CMRI connection to JMRI
you can check your error counts by using the CMRINet Metrics menu item under CMRI on the "CTC Panel"
toggle quoted message
Show quoted text
On 1/6/2019 7:16 PM, Seth Neumann wrote: on our cpNodes we usually use 28,800 but have tested them up to 56K without issues.
On 1/6/2019 4:41 PM, JerryG via Groups.Io wrote:
I am setting up several Arduinos as CMRI SMINI nodes connected via RS485 and an adapter to a single USB port on my PC.? JMRI will allow me to set the speed for the CMRI COM port connection from 9600 on up.? Any reason not to go with the fastest speed??? Any reason to just go with slow speed? Does this speed affect the rate at which JMRI polls the CMRI nodes (and if not, what does affect polling rate)?
Thanks, Jerry
_________________________________
jerryg2003@...
--
Seth Neumann Mountain View, CA
|
Locked
Re: Setting serial port speed for CMRI connection to JMRI
The cabling is electrically continuous and the driver/receiver chips don¡¯t know about the address. Which address is located where doesn¡¯t make any difference. If a node addressed as N is working or not working, changing that address to M won¡¯t make any difference. Bob On Jan 7, 2019, at 7:57 AM, Ken Cameron <kcameron@...> wrote:
What is the impact of the order of the nodes on the wire? A local layout,
that has the nodes in sequence, moved the computer/dispatcher from one end
of the line (next to node 0) to the other end of the line (past node 4).
Original location was also the lounge. Trying to dispatch TT&TO with that
behind you/over your shoulder, it just wasn't working well, too much
distraction. -- Bob Jacobsen rgj1927@...
|
Locked
Re: TABLE PRINT LIST TO TABLE MOVE DATA
You are certainly welcome to work that way, since that¡¯s how you want to enjoy your hobby. Perhaps other people do too. And perhaps, when you start to build that physical layout, it will work out as you say. I agree that people can put ¡°many hours¡± into configuring JMRI for a layout. (c.f. the ~7K file here, just part of just one layout I¡¯ve worked on: ) But _building_ the physical layout that corresponds to that is generally even more time-intensive. I¡¯ve never seen the case of spending months/years working on JMRI, then the physical layout gets built so fast that converting the JMRI configuration becomes the bottleneck. But please work on what you want to. It¡¯s your hobby, and building pieces around (and perhaps even in) JMRI can be part of it. Bob On Jan 7, 2019, at 8:06 AM, Dave Roberts <dccdaveroberts@...> wrote:
Depends on your point of view and how you approach the problem. Originally, a layout was created and then it was slowly automated using JMRI as it too, developed.
What has developed over time, especially with the introduction of simulation software packages, is the desire to plan a layout first and then once happy with it, to go ahead and build it using the JMRI program as the basis for the automation.
That way the user will have gone through the learning curve and gained valuable insights into the workings of the program upon which they will now refine as they build the actual layout to a plan that is already drawn up and proven to work.
Here is a practical example of the possible dilemma that may face us:
I have spent many hours developing a layout that I choose to build using the INTERNAL system because I did not know which system I would eventually settle on. When that choice is made it gives us two possibilities. The system has a Simulator built within it or not.
Whichever path we choose to go down we already have hours of keyboarding at our fingertips - many hours of work, making mistakes, correcting them or trying something else until we are satisfied that our masterpiece is ready to be put into service with no apparent errors being generated.
The problem is the apparent inability to be able to transfer the majority of the existing data into the new format. I can create an empty Xpressnet Simulation profile, as a halfway house, before acquiring the actual hardware but getting my program into that empty shell is the problem.
This situation arises again when we have to move to the actual version where we are using the actual hardware but in this case we can edit in the actual addresses of the hardware as it is installed on the layout which brings us nicely back to another point of view.
Dave
On 7 Jan 2019, at 15:14, Bob Jacobsen <rgj1927@...> wrote:
You miss my point. I think the tools you describe will make things more complicated for people who set out to use them, not less, and that simpler solutions are already available by using JMRI in a different way. You prefer a different approach. That difference of opinion is OK. You¡¯re certainly welcome to work on new tools to add to JMRI. If people find them useful, then they¡¯ll get used.
Bob
On Jan 7, 2019, at 2:19 AM, Dave Roberts <dccdaveroberts@...> wrote:
Bob,
Thank you for your response. I was only using the Lenz system as an example because that is what I am swapping to in the not too distant future, I hope but I am aware of the ability to create a profile with the Lenz Simulator. It is a path that I am currently following.
My thoughts were towards all those JMRI users who are currently going through a huge learning curve to get to understand the JMRI program so that they can have an error free xml file at the end of it all.
Some users will have invested a lot of time and effort going through the learning process, weeding out many errors caused/created from many different sources and after many, many months have eventually got to the point where they have created an error free xml file that is working.
It may well be split up into smaller, more manageable, chunks which is good because they can keep a Check on the smaller chunks and compare the whole layout to ensure that any amendments or changes made to any panel are also reflected in the whole layout panel.
I am not asking for bigger tools but rather more efficient tools that save the user time and effort by not having to re-create/re-key data that is already there that they may well have sweated buckets over to get right in the first place.
As their knowledge of JMRI grows they may well find themselves in a position where new, evolving technology may well dictate or create a desire to change to a new Profile/Configuration. This is what we should be looking at, too.
Dave
On 7 Jan 2019, at 01:20, Bob Jacobsen <rgj1927@...> wrote:
Can we step back for a second?
If you¡¯re expecting to have a Lenz system eventually, why not create a JMRI profile with a Lenz system simulator now? You¡¯ll be able to create layout objects like Turnouts and Sensors, fill in panels, etc as if the hardware was there.
When the hardware comes, most things will just work once you change to a real-hardware Lenz profile. You might discover that the switch motor you thought would have address 14 is easier to connect to 25, and you¡¯ll have to change that in JMRI. But it takes less time to change it in JMRI than it does to wire it in reality, so that¡¯s not a big deal. You just connect each one up, configure it, test it, and move to the next one.
If you decide to buy Digitrax or NCE hardware (i.e. a command station based on DCC communications), all you have to do is configure their system connections with the X letter, and off you go. JMRI is quite happy to have that XT14 that you earlier thought meant ¡°via Lenz¡± mean ¡°via LocoNet¡±. Again, you might have to change a few (NCE addressing isn¡¯t exactly like Lenz, in that there¡¯s no sensor 15) but that¡¯s one-by-one thing.
And if you decide to do something completely different, like C/MRI or OpenLCB, you¡¯re going to have to rethink your numbering in any case, likely in small chunks.
You might be setting out on creating bigger tools than you¡¯ll really need when it¡¯s time to work with the real layout.
Bob
Yes, I¡¯d like to have a Cat D9 too, but I only have four rows of vegetables, and a teenager to weed them.
On Jan 6, 2019, at 12:02 PM, Dave Roberts <dccdaveroberts@...> wrote:
I have been working away at the Table Records using a Non-Specific System and INTERNAL Blocks/Turnouts but with correct User Names using LE as part of getting ready to create a new configuration when my new Lenz system eventually rolls up and it occurred to me that since we can now pull out the records from every Table and store them away safely in a useful format for another use.
I investigated the problem of Moving/Importing/Exporting Data between different Configurations and landed on Nigel Cliffe's message from February last year.
Nigel's suggestion involved having to Move/edit the records, one by one, into the new configuration Tables where he had already created Blank Table Records in the new configuration. As he pointed out, that would be fine for smaller layouts but what about much larger layouts with well over 100 Turnouts and perhaps over 200 Blocks, etc?
This gave me the idea that perhaps we might be able to combine the "MOVE" function with a modified "Table Move" Script somehow? If we follow Nigel's suggestion and create, say, a Lenz Configuration and fill it with the count of actual records number as Blank Records in every Table. Can the "Table Print List" Script be modified to make it fill/Import into the Blank Records in the Tables using the data stored away, rather than dump them to the printer in .csv format. I am thinking of a more automated version of the "Move" idea suitable for any size of layout.
The fly in the ointment, as I see it, is the inability to create the correct System Name during the creation process. The Turnouts are going to be the major problem. This implies that the correct System Name is going to have to be edited in after import/Move.
Has anyone already solved the problem of moving the Table Data from one configuration to a new one?
Dave
--
Bob Jacobsen
rgj1927@...
--
Bob Jacobsen
rgj1927@...
-- Bob Jacobsen rgj1927@...
|
Locked
Re: MQTT Connection in JMRI
Andy,
JMRI will need to be able to control a Turnout with a unique name across ALL the modules, correct??If I use my NCE system to "Throw" NT100, on which module would a turnout change?
So, without solving that problem for a second, if JMRI controls a turnout with sometopic/turnout/0100 then ALL the turnouts on ALL the MQTT clients that are subscribed to THAT topic on the same Broker (the MQTT server), will get the message, regardless of their IP or MAC, and act accordingly.?They subscribed to a specific topic and will get everything published to it.?
The same happens when every stationary decoder with address #100, connected to the same DCC command station's output, will get the same message and respond. (MQTT has one great advantage here, a device will never see any messages for controlling other turnouts like? /0101, where DCC accessory #100 will see,? and need to ignore the message to #101. )
So, to have 10 modules connect to the same DCC bus, the turnouts need to have unique DCC addresses, or connect to a different command station. For 10 modules to connect to the same MQTT Broker, they need to have unique topics or connect to their own Broker. In which case JMRI need to have another MQTT Broker in Connections, so that the M1T100 turnout is uniquely different from the M2T100 turnout. So either bring your own MQTT Broker along, or choose different topics, just like you would need to use different DCC addresses, or bring your own command station.
For your cost analysis: I don't see a +/-12V wire coming from my JMRI, so I can't compare or compete! ;)
Speed
|
Locked
Re: TABLE PRINT LIST TO TABLE MOVE DATA
Depends on your point of view and how you approach the problem. Originally, a layout was created and then it was slowly automated using JMRI as it too, developed.
What has developed over time, especially with the introduction of simulation software packages, is the desire to plan a layout first and then once happy with it, to go ahead and build it using the JMRI program as the basis for the automation.?
That way the user will have gone through the learning curve and gained valuable insights into the workings of the program upon which they will now refine as they build the actual layout to a plan that is already drawn up and proven to work.
Here is a practical example of the possible dilemma that may face us:
I have spent many hours developing a layout that I choose to build using the INTERNAL system because I did not know which system I would eventually settle on. When that choice is made it gives us two possibilities. The system has a Simulator built within it or not.
Whichever path we choose to go down we already have hours of keyboarding at our fingertips - many hours of work, making mistakes, correcting them or trying something else until we are satisfied that our masterpiece is ready to be put into service with no apparent errors being generated.
The problem is the apparent inability to be able to transfer the majority of the existing data into the new format. I can create an empty Xpressnet Simulation profile, as a halfway house, before acquiring the actual hardware but getting my program into that empty shell is the problem.
This situation arises again when we have to move to the actual version where we are using the actual hardware but in this case we can edit in the actual addresses of the hardware as it is installed on the layout which brings us nicely back to another point of view.
Dave
?
toggle quoted message
Show quoted text
On 7 Jan 2019, at 15:14, Bob Jacobsen < rgj1927@...> wrote:
You miss my point. I think the tools you describe will make things more complicated for people who set out to use them, not less, and that simpler solutions are already available by using JMRI in a different way. ?You prefer a different approach. ?That difference of opinion is OK. ?You¡¯re certainly welcome to work on new tools to add to JMRI. ?If people find them useful, then they¡¯ll get used.BobOn Jan 7, 2019, at 2:19 AM, Dave Roberts <dccdaveroberts@...> wrote:
Bob,
Thank you for your response. I was only using the Lenz system as an example because that is what I am swapping to in the not too distant future, I hope but I am aware of the ability to create a profile with the Lenz Simulator. It is a path that I am currently following.
My thoughts were towards all those JMRI users who are currently going through a huge learning curve to get to understand the JMRI program so that they can have an error free xml file at the end of it all.
Some users will have invested a lot of time and effort going through the learning process, weeding out many errors caused/created from many different sources and after many, many months have eventually got to the point where they have created an error free xml file that is working.?
It may well be split up into smaller, more manageable, chunks which is good because they can keep a Check on the smaller chunks and compare the whole layout to ensure that any amendments or changes made to any panel are also reflected in the whole layout panel.
I am not asking for bigger tools but rather more efficient tools that save the user time and effort by not having to re-create/re-key data that is already there that they may well have sweated buckets over to get right in the first place.
As their knowledge of JMRI grows they may well find themselves in a position where new, evolving technology may well dictate or create a desire to change to a new Profile/Configuration. This is what we should be looking at, too.
Dave
On 7 Jan 2019, at 01:20, Bob Jacobsen <rgj1927@...> wrote:
Can we step back for a second?
If you¡¯re expecting to have a Lenz system eventually, why not create a JMRI profile with a Lenz system simulator now? You¡¯ll be able to create layout objects like Turnouts and Sensors, fill in panels, etc as if the hardware was there.
When the hardware comes, most things will just work once you change to a real-hardware Lenz profile. You might discover that the switch motor you thought would have address 14 is easier to connect to 25, and you¡¯ll have to change that in JMRI. ?But it takes less time to change it in JMRI than it does to wire it in reality, so that¡¯s not a big deal. ?You just connect each one up, configure it, test it, and move to the next one.
If you decide to buy Digitrax or NCE hardware (i.e. a command station based on DCC communications), all you have to do is configure their system connections with the X letter, and off you go. ?JMRI is quite happy to have that XT14 that you earlier thought meant ¡°via Lenz¡± mean ¡°via LocoNet¡±. ?Again, you might have to change a few (NCE addressing isn¡¯t exactly like Lenz, in that there¡¯s no sensor 15) but that¡¯s one-by-one thing.
And if you decide to do something completely different, like C/MRI or OpenLCB, you¡¯re going to have to rethink your numbering in any case, likely in small chunks.
You might be setting out on creating bigger tools than you¡¯ll really need when it¡¯s time to work with the real layout.
Bob
Yes, I¡¯d like to have a Cat D9 too, but I only have four rows of vegetables, and a teenager to weed them.
On Jan 6, 2019, at 12:02 PM, Dave Roberts <dccdaveroberts@...> wrote:
I have been working away at the Table Records using a Non-Specific System and INTERNAL Blocks/Turnouts but with correct User Names using LE as part of getting ready to create a new configuration when my new Lenz system eventually rolls up and it occurred to me that since we can now pull out the records from every Table and store them away safely in a useful format for another use.?
I investigated the problem of Moving/Importing/Exporting Data between different Configurations and landed on Nigel Cliffe's message from February last year.
Nigel's suggestion involved having to Move/edit the records, one by one, into the new configuration Tables where he had already created Blank Table Records in the new configuration. As he pointed out, that would be fine for smaller layouts but what about much larger layouts with well over 100 Turnouts and perhaps over 200 Blocks, etc?
This gave me the idea that perhaps we might be able to combine the "MOVE" function with a modified "Table Move" Script somehow? If we follow Nigel's suggestion and create, say, a Lenz Configuration and fill it with the count of actual records number as Blank Records in every Table. Can the "Table Print List" Script be modified to make it fill/Import into the Blank Records in the Tables using the data stored away, rather than dump them to the printer in .csv format. I am thinking of a more automated version of the "Move" idea suitable for any size of layout.
The fly in the ointment, as I see it, is the inability to create the correct System Name during the creation process. The Turnouts are going to be the major problem. This implies that the correct System Name is going to have to be edited in after import/Move.
Has anyone already solved the problem of moving the Table Data from one configuration to a new one?
Dave
--
Bob Jacobsen
rgj1927@...
--Bob Jacobsenrgj1927@...
|
Locked
Re: Setting serial port speed for CMRI connection to JMRI
Bob,
What is the impact of the order of the nodes on the wire? A local layout,
that has the nodes in sequence, moved the computer/dispatcher from one end
of the line (next to node 0) to the other end of the line (past node 4).
Original location was also the lounge. Trying to dispatch TT&TO with that
behind you/over your shoulder, it just wasn't working well, too much
distraction.
-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org
|
Locked
Re: MQTT (again), Sensors and ECoS<>JMRI help needed
Nathan,
If you create an Internal Sensor for every pair, you can use a very simply Logix to active that sensor if either of the real sensors are active, and Inactive when both sensors are Inactive.
Speed?
>>?Sensors groups don¡¯t seem to do it: how are other people handling this?
|
Locked
Re: Setting serial port speed for CMRI connection to JMRI
I don¡¯t think there is a check sum in C/MRI. But it works pretty well because the hardware designs have _lots_ of margin. Errors, when it¡¯s set up well, are really really rare. Interference can cause them, but that¡¯s not as often as people thing and well-constructed cabling and C/MRI ground wiring will generally take care of it. If the wiring is a bit out of spec, i.e. not all nodes in sequence, not right twisted pair cable. etc, what can happen is that cable become a capacitive load so that the signal has a gentle rise at the receiver instead of being a nice square. As the rate goes up, that rise needs to be sampled earlier and earlier; at high enough rates, it¡¯s while it¡¯s still rising and you get the wrong bits. So in practice, setting a C/MRI system up one speed-notch too high transforms it from ¡°working really well¡± to ¡°being really flakey¡±: it usually obvious that the dropping the speed is the next thing to do. In the case of 8 nodes at 9600 baud, that¡¯s a great approach. The only reason you might try to make it faster (not a recommendation!) is if people notice that they have to hold a fascia button for a bit too long before it takes. I work on one local layout with 5 SMINIs and 2 SUSICS where we went to 19.2K because it felt just a touch slow. That computer was slow, and the SUSICs slow things down because they send more data, so your experience may be different. Bob On Jan 7, 2019, at 2:24 AM, jimalbanowski <jimalbanowski@...> wrote:
Jerry:
I run on and help maintain a rather large RR with 8 SMINI nodes all rather fully loaded and 9600 baud is not a problem... I would tend to think Bob's concern about dropped messages is valid and I would stay slower... Not so much corruption... the check sum should help catch that but how JMRI handles an error thrown by a bad packet..? My friends software is DIY.
I've built several of the Arduino based nodes and since they're intended for my friend I haven't pushed them beyond his 9600 baud.
Jim Albanowski
-- Bob Jacobsen rgj1927@...
|
Locked
Re: TABLE PRINT LIST TO TABLE MOVE DATA
You miss my point. I think the tools you describe will make things more complicated for people who set out to use them, not less, and that simpler solutions are already available by using JMRI in a different way. You prefer a different approach. That difference of opinion is OK. You¡¯re certainly welcome to work on new tools to add to JMRI. If people find them useful, then they¡¯ll get used. Bob On Jan 7, 2019, at 2:19 AM, Dave Roberts <dccdaveroberts@...> wrote:
Bob,
Thank you for your response. I was only using the Lenz system as an example because that is what I am swapping to in the not too distant future, I hope but I am aware of the ability to create a profile with the Lenz Simulator. It is a path that I am currently following.
My thoughts were towards all those JMRI users who are currently going through a huge learning curve to get to understand the JMRI program so that they can have an error free xml file at the end of it all.
Some users will have invested a lot of time and effort going through the learning process, weeding out many errors caused/created from many different sources and after many, many months have eventually got to the point where they have created an error free xml file that is working.
It may well be split up into smaller, more manageable, chunks which is good because they can keep a Check on the smaller chunks and compare the whole layout to ensure that any amendments or changes made to any panel are also reflected in the whole layout panel.
I am not asking for bigger tools but rather more efficient tools that save the user time and effort by not having to re-create/re-key data that is already there that they may well have sweated buckets over to get right in the first place.
As their knowledge of JMRI grows they may well find themselves in a position where new, evolving technology may well dictate or create a desire to change to a new Profile/Configuration. This is what we should be looking at, too.
Dave
On 7 Jan 2019, at 01:20, Bob Jacobsen <rgj1927@...> wrote:
Can we step back for a second?
If you¡¯re expecting to have a Lenz system eventually, why not create a JMRI profile with a Lenz system simulator now? You¡¯ll be able to create layout objects like Turnouts and Sensors, fill in panels, etc as if the hardware was there.
When the hardware comes, most things will just work once you change to a real-hardware Lenz profile. You might discover that the switch motor you thought would have address 14 is easier to connect to 25, and you¡¯ll have to change that in JMRI. But it takes less time to change it in JMRI than it does to wire it in reality, so that¡¯s not a big deal. You just connect each one up, configure it, test it, and move to the next one.
If you decide to buy Digitrax or NCE hardware (i.e. a command station based on DCC communications), all you have to do is configure their system connections with the X letter, and off you go. JMRI is quite happy to have that XT14 that you earlier thought meant ¡°via Lenz¡± mean ¡°via LocoNet¡±. Again, you might have to change a few (NCE addressing isn¡¯t exactly like Lenz, in that there¡¯s no sensor 15) but that¡¯s one-by-one thing.
And if you decide to do something completely different, like C/MRI or OpenLCB, you¡¯re going to have to rethink your numbering in any case, likely in small chunks.
You might be setting out on creating bigger tools than you¡¯ll really need when it¡¯s time to work with the real layout.
Bob
Yes, I¡¯d like to have a Cat D9 too, but I only have four rows of vegetables, and a teenager to weed them.
On Jan 6, 2019, at 12:02 PM, Dave Roberts <dccdaveroberts@...> wrote:
I have been working away at the Table Records using a Non-Specific System and INTERNAL Blocks/Turnouts but with correct User Names using LE as part of getting ready to create a new configuration when my new Lenz system eventually rolls up and it occurred to me that since we can now pull out the records from every Table and store them away safely in a useful format for another use.
I investigated the problem of Moving/Importing/Exporting Data between different Configurations and landed on Nigel Cliffe's message from February last year.
Nigel's suggestion involved having to Move/edit the records, one by one, into the new configuration Tables where he had already created Blank Table Records in the new configuration. As he pointed out, that would be fine for smaller layouts but what about much larger layouts with well over 100 Turnouts and perhaps over 200 Blocks, etc?
This gave me the idea that perhaps we might be able to combine the "MOVE" function with a modified "Table Move" Script somehow? If we follow Nigel's suggestion and create, say, a Lenz Configuration and fill it with the count of actual records number as Blank Records in every Table. Can the "Table Print List" Script be modified to make it fill/Import into the Blank Records in the Tables using the data stored away, rather than dump them to the printer in .csv format. I am thinking of a more automated version of the "Move" idea suitable for any size of layout.
The fly in the ointment, as I see it, is the inability to create the correct System Name during the creation process. The Turnouts are going to be the major problem. This implies that the correct System Name is going to have to be edited in after import/Move.
Has anyone already solved the problem of moving the Table Data from one configuration to a new one?
Dave
--
Bob Jacobsen
rgj1927@...
-- Bob Jacobsen rgj1927@...
|
Steve,
If you could send me your OperationsTrainRoster.xml file that is causing the problem, I'll take a look at your error.
Dan
|
Steve,
You could most likely ignore the error.
Dan
|
Locked
Re: SoundPro Map Engine Start - And UK Sounds
Oh! The spj?is just a raw file, I can convert to wav?and chop bits out..?That should get me a nice whistle to start with.
|
Locked
Re: Setting serial port speed for CMRI connection to JMRI
Jerry:
I run on and help maintain a rather large RR with 8 SMINI nodes all rather fully loaded and 9600 baud is not a problem... I would tend to think Bob's concern about dropped messages is valid and I would stay slower... Not so much corruption... the check sum should help catch that but how JMRI handles an error thrown by a bad packet..? My friends software is DIY.
I've built several of the Arduino based nodes and since they're intended for my friend I haven't pushed them beyond his 9600 baud.
Jim Albanowski
|
Locked
Re: TABLE PRINT LIST TO TABLE MOVE DATA
Bob,
Thank you for your response. I was only using the Lenz system as an example because that is what I am swapping to in the not too distant future, I hope but I am aware of the ability to create a profile with the Lenz Simulator. It is a path that I am currently following.
My thoughts were towards all those JMRI users who are currently going through a huge learning curve to get to understand the JMRI program so that they can have an error free xml file at the end of it all.
Some users will have invested a lot of time and effort going through the learning process, weeding out many errors caused/created from many different sources and after many, many months have eventually got to the point where they have created an error free xml file that is working.?
It may well be split up into smaller, more manageable, chunks which is good because they can keep a Check on the smaller chunks and compare the whole layout to ensure that any amendments or changes made to any panel are also reflected in the whole layout panel.
I am not asking for bigger tools but rather more efficient tools that save the user time and effort by not having to re-create/re-key data that is already there that they may well have sweated buckets over to get right in the first place.
As their knowledge of JMRI grows they may well find themselves in a position where new, evolving technology may well dictate or create a desire to change to a new Profile/Configuration. This is what we should be looking at, too.
Dave
toggle quoted message
Show quoted text
On 7 Jan 2019, at 01:20, Bob Jacobsen < rgj1927@...> wrote:
Can we step back for a second?If you¡¯re expecting to have a Lenz system eventually, why not create a JMRI profile with a Lenz system simulator now? You¡¯ll be able to create layout objects like Turnouts and Sensors, fill in panels, etc as if the hardware was there.When the hardware comes, most things will just work once you change to a real-hardware Lenz profile. You might discover that the switch motor you thought would have address 14 is easier to connect to 25, and you¡¯ll have to change that in JMRI. ?But it takes less time to change it in JMRI than it does to wire it in reality, so that¡¯s not a big deal. ?You just connect each one up, configure it, test it, and move to the next one.If you decide to buy Digitrax or NCE hardware (i.e. a command station based on DCC communications), all you have to do is configure their system connections with the X letter, and off you go. ?JMRI is quite happy to have that XT14 that you earlier thought meant ¡°via Lenz¡± mean ¡°via LocoNet¡±. ?Again, you might have to change a few (NCE addressing isn¡¯t exactly like Lenz, in that there¡¯s no sensor 15) but that¡¯s one-by-one thing.And if you decide to do something completely different, like C/MRI or OpenLCB, you¡¯re going to have to rethink your numbering in any case, likely in small chunks.You might be setting out on creating bigger tools than you¡¯ll really need when it¡¯s time to work with the real layout.BobYes, I¡¯d like to have a Cat D9 too, but I only have four rows of vegetables, and a teenager to weed them.On Jan 6, 2019, at 12:02 PM, Dave Roberts <dccdaveroberts@...> wrote:
I have been working away at the Table Records using a Non-Specific System and INTERNAL Blocks/Turnouts but with correct User Names using LE as part of getting ready to create a new configuration when my new Lenz system eventually rolls up and it occurred to me that since we can now pull out the records from every Table and store them away safely in a useful format for another use.?
I investigated the problem of Moving/Importing/Exporting Data between different Configurations and landed on Nigel Cliffe's message from February last year.
Nigel's suggestion involved having to Move/edit the records, one by one, into the new configuration Tables where he had already created Blank Table Records in the new configuration. As he pointed out, that would be fine for smaller layouts but what about much larger layouts with well over 100 Turnouts and perhaps over 200 Blocks, etc?
This gave me the idea that perhaps we might be able to combine the "MOVE" function with a modified "Table Move" Script somehow? If we follow Nigel's suggestion and create, say, a Lenz Configuration and fill it with the count of actual records number as Blank Records in every Table. Can the "Table Print List" Script be modified to make it fill/Import into the Blank Records in the Tables using the data stored away, rather than dump them to the printer in .csv format. I am thinking of a more automated version of the "Move" idea suitable for any size of layout.
The fly in the ointment, as I see it, is the inability to create the correct System Name during the creation process. The Turnouts are going to be the major problem. This implies that the correct System Name is going to have to be edited in after import/Move.
Has anyone already solved the problem of moving the Table Data from one configuration to a new one?
Dave
--Bob Jacobsenrgj1927@...
|
Locked
Re: TABLE PRINT LIST TO TABLE MOVE DATA
Ken,
Thank you for your response. I agree that we are not going to get the perfect solution but as you say: ¡°Instead, I'd say something like a bulk move that sets a few?existing conditions¡±. At this stage I would settle for that.
Many years ago now, when I was first learning about coding, two things were hammered into our heads:
(1) Once you have written something that works you?should not have to repeat the process and keep?entering it.
(2) Any output from a program should be available for other uses to prevent wasting time and effort re-running the program.
I am thinking of all those who are going through a very steep learning curve to understand the?¡®Ins' and?¡®outs' of JMRI. They have spent a lot of time creating their masterpiece and after many, many attempts, they have managed to get a working xml file with no errors present.?
They have?diligently?ploughed through all Table?Entries using the various tools available to CHECK the file and have safely removed all records that are not used by the xml file - spelling errors or adding in extra spaces seem to be?favourite with me!
They end up with a working file that does have gaps in the System Name numbering sequence but some will have been reused by the program to fill in these gaps left by the deleted records as best it can but they now have an accurate count of just how many entries are required for each Table.
Nigel¡¯s ?suggestion to create the new configuration and fill it with the number of records required is sound. All that I am asking is to have the ability to move, by whatever means, the existing data, except the?System Name, into the blank records, one Table at a time. This would clear all gaps in the System Name sequence and make for a contiguous file within that Table.
It is here that we will need the ability to modify the System Name as necessary for the individual systems available. As you say, different systems require certain blocks ?of numbers to be allocated but this could be handled by using a different MOVE/IMPORT Script specific to the configuration.
I have even considered using the first part of the User Name as the correct System Name for the new configuration and adding in the User Name proper following that but it does?make for?large User Names and would give rise to need to be able to strip out the System Name from the start of every User Name and moving that into the System Name and this be able to be edited at a later date.
Dave
toggle quoted message
Show quoted text
On 7 Jan 2019, at 01:20, Bob Jacobsen < rgj1927@...> wrote:
Can we step back for a second?If you¡¯re expecting to have a Lenz system eventually, why not create a JMRI profile with a Lenz system simulator now? You¡¯ll be able to create layout objects like Turnouts and Sensors, fill in panels, etc as if the hardware was there.When the hardware comes, most things will just work once you change to a real-hardware Lenz profile. You might discover that the switch motor you thought would have address 14 is easier to connect to 25, and you¡¯ll have to change that in JMRI. ?But it takes less time to change it in JMRI than it does to wire it in reality, so that¡¯s not a big deal. ?You just connect each one up, configure it, test it, and move to the next one.If you decide to buy Digitrax or NCE hardware (i.e. a command station based on DCC communications), all you have to do is configure their system connections with the X letter, and off you go. ?JMRI is quite happy to have that XT14 that you earlier thought meant ¡°via Lenz¡± mean ¡°via LocoNet¡±. ?Again, you might have to change a few (NCE addressing isn¡¯t exactly like Lenz, in that there¡¯s no sensor 15) but that¡¯s one-by-one thing.And if you decide to do something completely different, like C/MRI or OpenLCB, you¡¯re going to have to rethink your numbering in any case, likely in small chunks.You might be setting out on creating bigger tools than you¡¯ll really need when it¡¯s time to work with the real layout.BobYes, I¡¯d like to have a Cat D9 too, but I only have four rows of vegetables, and a teenager to weed them.On Jan 6, 2019, at 12:02 PM, Dave Roberts <dccdaveroberts@...> wrote:
I have been working away at the Table Records using a Non-Specific System and INTERNAL Blocks/Turnouts but with correct User Names using LE as part of getting ready to create a new configuration when my new Lenz system eventually rolls up and it occurred to me that since we can now pull out the records from every Table and store them away safely in a useful format for another use.?
I investigated the problem of Moving/Importing/Exporting Data between different Configurations and landed on Nigel Cliffe's message from February last year.
Nigel's suggestion involved having to Move/edit the records, one by one, into the new configuration Tables where he had already created Blank Table Records in the new configuration. As he pointed out, that would be fine for smaller layouts but what about much larger layouts with well over 100 Turnouts and perhaps over 200 Blocks, etc?
This gave me the idea that perhaps we might be able to combine the "MOVE" function with a modified "Table Move" Script somehow? If we follow Nigel's suggestion and create, say, a Lenz Configuration and fill it with the count of actual records number as Blank Records in every Table. Can the "Table Print List" Script be modified to make it fill/Import into the Blank Records in the Tables using the data stored away, rather than dump them to the printer in .csv format. I am thinking of a more automated version of the "Move" idea suitable for any size of layout.
The fly in the ointment, as I see it, is the inability to create the correct System Name during the creation process. The Turnouts are going to be the major problem. This implies that the correct System Name is going to have to be edited in after import/Move.
Has anyone already solved the problem of moving the Table Data from one configuration to a new one?
Dave
--Bob Jacobsenrgj1927@...
|
Ken Cameron
Bob Jacobsen