开云体育

Brian,



I decided to do some testing. There does appear to be a problem.



I set the Jython Script Location. The following entry was changed in
ProfileConfig.xml:

OLD: <fileLocation defaultScriptLocation="program:jython/" />

NEW: <fileLocation
defaultScriptLocation="home:Documents/JMRI/Scripts/" />

I copied the python script to the new location, removed the
"preference:" from the Logix script call and the following error
occurred:



2014-06-16 17:45:29,515 util.PythonInterp ERROR -
InvocationTargetException while invoking command
execfile("shutdown.py"): Traceback (most recent call last):

File "<string>", line 1, in <module>

IOError: (2, 'File not found - /Applications/JMRI/shutdown.py (No such
file or directory)')

[AWT-EventQueue-0]



Dave Sand

I didn't know that.



However it doen't help. I made and error, it happens, to my signal head
numbering. I removed the signal head from the layout. (right click remove)
removed all the signal heads, saved the panel, restarted Panel Pro. Added
the new ones. Saved restarted. Set Signals is now refusing to add the new
signal head, saying it's getting an null pointer error removing the ones
that were already previously removed! Then it blew all my turnouts away. It
unlinked the turnout icons from the turnout names and deleted the turnouts,
it also unlinked the block sensors from the blocks.



When these exceptions come up, how do I override it?

Or why can I not override it?

how does signal logic remove track and turnout settings?



Martin Ozolins

<mailto:mdozolins@...> mdozolins@...





"Fortune favors the prepared mind" - Louis Pasteur



From: jmriusers@... [mailto:jmriusers@...]
Sent: Monday, June 16, 2014 06:09
To: jmriusers@...
Subject: [jmriusers] Re: Deletion and renaming problems.





Martin,

When you said that you went to the layout and explicitly defined the new
System name, is this the Layout Editor that you are using? If it is then
this field uses the UserName not SystemName, so if you enter a value in
there and the UserName doesn't exist it will generate a new block with a new
system name and the name that you specified will be set as the UserName.

Regards
Kevin


---In jmriusers@..., <mdozolins@...> wrote :

Ken



I tried reassigning the block variables on the track as you said, first I
changed the sensors on the old junk, then I successfully updated the blocks
in the block table, then went to the layout and explicitly definedthe new
System name and the system ignored me and used it's own system name.


Martin Ozolins

<mailto:mdozolins@... mailto:mdozolins@...
<mailto:mdozolins@...%20mailto:mdozolins@...> >
mdozolins@... mailto:mdozolins@...

(760)405 4812



"Fortune favors the prepared mind" - Louis Pasteur



From: jmriusers@... mailto:jmriusers@...
[mailto:jmriusers@... mailto:jmriusers@...
<mailto:jmriusers@...%20mailto:jmriusers@...> ]
Sent: Sunday, June 15, 2014 20:18
To: jmriusers@... mailto:jmriusers@...
Subject: RE: [jmriusers] Deletion and renaming problems.





When it comes to simply renaming things (user name assignments) those are
easy, just keep in mind if you wanted to swap something, you would need a
third 'system name' to hold one user name while doing the rest of the
switching around.

But when it comes to deleting things, you really need to either rename
anything that is in use to the new item and work down the 'tree' of parts so

when you get to deleting something, the only thing 'using' it is the table
display. So if you needed to remove a sensor, you need to 'rename' any block

using that sensor first so the block isn't 'using' anything.

This takes planning sometimes. Which brings me to the real question: Why do
you have a bunch of deleting and renaming??

Depending on that answer there may be issues with how you were doing things
that were unfortunately putting you into a difficult place right now. One
key point to keep in mind:

"Assign usernames and only use the usernames in other elements."

This greatly simplifies things when you find that wasn't the right turnout
or sensor for example later. Moving the user name to the right system name
is much simpler and cleaner for the system to do.

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

I have not done anything with the script location. My script calls
from Logix use "preference:<scriptname>.py". The script files are in
the same location as the panel XML file. It does mean that if I use
the same script for multiple layouts, I have to copy it to each layout
directory.



Dave Sand

If I may ask...

How do you have their script files locations set up? Can you change them
successfully?

All file locations setting work fine for me, except the scripts location.

Thanks,
Brian


On 16 June 2014 17:57, Dave Sand dave@... [jmriusers] <
jmriusers@...> wrote:

In addition to what Dave Heap describes, I take it a step further since
I am doing panel development for 3 different railroads. Within the
added JMRI folder is a folder for each railroad. Each railroad has two
profiles, one for simulation and the other for physical connections.
Both profiles point to the same sub-folder (Preferences >> File
Locations >> User Files Location), which contains the panel XML file,
the custom signal definitions, custom python programs and the roster
for the accessory decoders. 2 of the railroads are not Digitrax, so
they will have stand alone LocoNet. The third one will require roster
integration.

When the owner is ready to implement, I just have to copy their folder
to their PC and create the profiles on their PC and integrate the
roster for the third owner.

Dave Sand









topic
<;_ylc=X3oDMTM4ZWhicTN2BF9TAzk3MzU5NzE0BGdycElkAzY2MDI3NTgEZ3Jwc3BJZAMxNzA1MDYzNTc2BG1zZ0lkAzEwNzcwMARzZWMDZnRyBHNsawN2dHBjBHN0aW1lAzE0MDI5NTU4MjcEdHBjSWQDMTA3Njg3>
(6)
Visit Your Group
<;_ylc=X3oDMTJlOXRzczFiBF9TAzk3MzU5NzE0BGdycElkAzY2MDI3NTgEZ3Jwc3BJZAMxNzA1MDYzNTc2BHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTQwMjk1NTgyNw-->

- New Members
<;_ylc=X3oDMTJmZGRxczdtBF9TAzk3MzU5NzE0BGdycElkAzY2MDI3NTgEZ3Jwc3BJZAMxNzA1MDYzNTc2BHNlYwN2dGwEc2xrA3ZtYnJzBHN0aW1lAzE0MDI5NTU4Mjc->
18

[image: Yahoo! Groups]
<;_ylc=X3oDMTJkMnZxdHNkBF9TAzk3MzU5NzE0BGdycElkAzY2MDI3NTgEZ3Jwc3BJZAMxNzA1MDYzNTc2BHNlYwNmdHIEc2xrA2dmcARzdGltZQMxNDAyOTU1ODI3>
鈥� Privacy <> 鈥�
Unsubscribe <jmriusers-unsubscribe@...?subject=Unsubscribe> 鈥� Terms
of Use <>

.

[Non-text portions of this message have been removed]

In addition to what Dave Heap describes, I take it a step further since
I am doing panel development for 3 different railroads. Within the
added JMRI folder is a folder for each railroad. Each railroad has two
profiles, one for simulation and the other for physical connections.
Both profiles point to the same sub-folder (Preferences >> File
Locations >> User Files Location), which contains the panel XML file,
the custom signal definitions, custom python programs and the roster
for the accessory decoders. 2 of the railroads are not Digitrax, so
they will have stand alone LocoNet. The third one will require roster
integration.



When the owner is ready to implement, I just have to copy their folder
to their PC and create the profiles on their PC and integrate the
roster for the third owner.





Dave Sand

I think you have created a problem. "preference:" is an (unusual) synonym for "User Files Location".

This is how to fix things up:
- Undo all those hand edits.
- Create a folder somewhere on your computer. It would be sensible (but not mandatory) to call it JMRI. In my case the folder is "/.../Dropbox/JMRI" (on Mac or Linux) or "C:&#92;Users&#92;heap&#92;Dropbox&#92;JMRI"
- In each of your Profiles, go to Preferences->Locations->User Files Location and choose the folder you just created. Also go to Preferences->Roster->Roster->Roster Location and press "Reset Roster Location".
- Put your roster folder, roster.xml, all your Panel files, resources, throttle and other folders (except your profile related folders) into the new location.

If you have done this correctly, all should be well with both V3.7.x and V3.6. Note that I use a "JMRI" folder in my Dropbox folder because I share my JMRI files across all my computers and Dropbox keeps them all in sync.

As an alternative to moving all those folders, you could just change "User Files Location" to be the same as "Default Location" ("settings:" is a synonym for that) and leave the folders in their original locations.
--
Dave in Australia

Perhaps my file locations problems with the version 7.X "profiles" are related to what Brian is describing and perhaps I am just off base again.

Since I keep data for several layouts in my home laptop and since I often switch between Locobuffer-USB, simulated LocoNet, NCE with a USB to 232 adapter, and simulated NCE it seemed like the use of the new profiles would be a big help. What I found instead was, that unless I did a lot of extra work, it is difficult to share rosters, panels including backgrounds and icons, and scripts between the various profiles.


Searching this user group for the word "profiles" did not give me much help (more than 900 hits with many of them for the multitudinous ways the word is also used to describe other parameters) and searching the JMRI web documentation and user's manuals did not help much either.


My blunderbuss method was to tediously replace the term


"preference:resources/icons/"


with


"settings:resources/icons/"



for every line of every panel xml file.


At least for the hundred of custom icons that previous dedicated club members and others had developed, this kludge seems to have worked on my laptop.


For example, the now commented out original line:


<!-- <icon url="preference:resources/icons/USS/track/block/block-blue.GIF" degrees="0" scale="1.0"> -->


has been replaced by:




<icon url="settings:resources/icons/USS/track/block/block-blue.GIF" degrees="0" scale="1.0">


Fair warning: At this time, I have yet to try to discover what kind of mischief these changes would cause if I were to copy them back to one of the club installations where only production versions are allowed, and we still use 3.6 there.


Work had just begun to examine my collection of custom shared scripts when this thread caught my attention. Shared Rosters seem to be beyond my grasp.


Hope for a simpler method still flickers in this effort and all of my panel files have been safely backed up prior to my sledgehammer surgery.


A last minute afterthought. It now appears that version 3.6 was more forgiving in that an occasional reference to url="program:resources ...
in the xml files where the correct reference should have been url="preference:resources ... did not cause a problem, when perhaps it should have. I can no longer verify this observation from here.



Cliff Anderson

Thanks, Dave.

The original thread was Mar. 26-27.

At that time, I mistakenly thought the problem was specific to PanelPro but
now see that it happens with DP as well. Seems to be connected to the
profiles somehow.

Brian


On 16 June 2014 07:40, Dave Heap dgheap@... [jmriusers] <
jmriusers@...> wrote:

I don't recall looking at this. Must have slipped beneath the radar.

If no one else gets to it beforehand, I'll take a look at when I get a
chance.

Sent from my iPad
--
Dave in Australia

On 16/06/2014, at 12:51 PM, "Brian Gilhuly brianlgilhuly@...
[jmriusers]"<jmriusers@...> wrote:

Dave Heap was trying to fix this in March but it is still with us. I hope
3.8 will have a fix.

bump.
by moderator
Walt

Martin,

When you said that you went to the layout and explicitly defined the new System name, is this the Layout Editor that you are using? If it is then this field uses the UserName not SystemName, so if you enter a value in there and the UserName doesn't exist it will generate a new block with a new system name and the name that you specified will be set as the UserName.

Regards
Kevin


---In jmriusers@..., <mdozolins@...> wrote :

Ken



I tried reassigning the block variables on the track as you said, first I
changed the sensors on the old junk, then I successfully updated the blocks
in the block table, then went to the layout and explicitly definedthe new
System name and the system ignored me and used it's own system name.


Martin Ozolins

<mailto:mdozolins@... mailto:mdozolins@...> mdozolins@... mailto:mdozolins@...

(760)405 4812



"Fortune favors the prepared mind" - Louis Pasteur



From: jmriusers@... mailto:jmriusers@... [mailto:jmriusers@... mailto:jmriusers@...]
Sent: Sunday, June 15, 2014 20:18
To: jmriusers@... mailto:jmriusers@...
Subject: RE: [jmriusers] Deletion and renaming problems.





When it comes to simply renaming things (user name assignments) those are
easy, just keep in mind if you wanted to swap something, you would need a
third 'system name' to hold one user name while doing the rest of the
switching around.

But when it comes to deleting things, you really need to either rename
anything that is in use to the new item and work down the 'tree' of parts so
when you get to deleting something, the only thing 'using' it is the table
display. So if you needed to remove a sensor, you need to 'rename' any block
using that sensor first so the block isn't 'using' anything.

This takes planning sometimes. Which brings me to the real question: Why do
you have a bunch of deleting and renaming??

Depending on that answer there may be issues with how you were doing things
that were unfortunately putting you into a difficult place right now. One
key point to keep in mind:

"Assign usernames and only use the usernames in other elements."

This greatly simplifies things when you find that wasn't the right turnout
or sensor for example later. Moving the user name to the right system name
is much simpler and cleaner for the system to do.

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

I don't recall looking at this. Must have slipped beneath the radar.

If no one else gets to it beforehand, I'll take a look at when I get a chance.
--
Dave in Australia

Ken



I tried reassigning the block variables on the track as you said, first I
changed the sensors on the old junk, then I successfully updated the blocks
in the block table, then went to the layout and explicitly definedthe new
System name and the system ignored me and used it's own system name. These
functions are, in my opinion, broken. As you state below using usernames
should be dynamic, and there are reasons someone might want to change these
parameters, sensor change, track reconfiguration etc. Right now it seems
I'll need to rebuild all my panels from scratch. Is all the data stored in
the layout XML or should I look elsewhere to purge old data. The orphaned
search detects the newly created names as the orphans, it should be the
obsolete records.



Martin Ozolins

<mailto:mdozolins@...> mdozolins@...

(760)405 4812



"Fortune favors the prepared mind" - Louis Pasteur



From: jmriusers@... [mailto:jmriusers@...]
Sent: Sunday, June 15, 2014 20:18
To: jmriusers@...
Subject: RE: [jmriusers] Deletion and renaming problems.





When it comes to simply renaming things (user name assignments) those are
easy, just keep in mind if you wanted to swap something, you would need a
third 'system name' to hold one user name while doing the rest of the
switching around.

But when it comes to deleting things, you really need to either rename
anything that is in use to the new item and work down the 'tree' of parts so
when you get to deleting something, the only thing 'using' it is the table
display. So if you needed to remove a sensor, you need to 'rename' any block
using that sensor first so the block isn't 'using' anything.

This takes planning sometimes. Which brings me to the real question: Why do
you have a bunch of deleting and renaming??

Depending on that answer there may be issues with how you were doing things
that were unfortunately putting you into a difficult place right now. One
key point to keep in mind:

"Assign usernames and only use the usernames in other elements."

This greatly simplifies things when you find that wasn't the right turnout
or sensor for example later. Moving the user name to the right system name
is much simpler and cleaner for the system to do.

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

No hardware connected yet. NCE Simulator is all.

Martin Ozolins
mdozolins@...
(760)405 4812

"Fortune favors the prepared mind" - Louis Pasteur

Question: Which brings me to the real question: Why do
you have a bunch of deleting and renaming??



Answer: I'm learning the system and building a layout at the same time. I
don't know how the system reacts in given situations until I put it in that
situation. But that's not the only reason, I'm changing the layout and
control infrastructure on the fly and trying to keep my panels up to date.
My background is Network and Systems Engineering so I consider naming
conventions and using virtual names (user names) sometimes I'll delete a
whole section and rename it if the current naming convention is proving
problematic, I do it over.



I have been trying to make everything use the user names, some of the add or
edit scripts have made that challenging. I was also treating this like a
RDBMs which survives this type of abuse most often. I used to be a DBA in
the last century.



So far where the naming falls apart now is setting up signals. Using easy
identifiers makes some usernames quite long. J



Martin Ozolins

<mailto:mdozolins@...> mdozolins@...

(760)405 4812



"Fortune favors the prepared mind" - Louis Pasteur



From: jmriusers@... [mailto:jmriusers@...]
Sent: Sunday, June 15, 2014 20:18
To: jmriusers@...
Subject: RE: [jmriusers] Deletion and renaming problems.





When it comes to simply renaming things (user name assignments) those are
easy, just keep in mind if you wanted to swap something, you would need a
third 'system name' to hold one user name while doing the rest of the
switching around.

But when it comes to deleting things, you really need to either rename
anything that is in use to the new item and work down the 'tree' of parts so
when you get to deleting something, the only thing 'using' it is the table
display. So if you needed to remove a sensor, you need to 'rename' any block
using that sensor first so the block isn't 'using' anything.

This takes planning sometimes. Which brings me to the real question: Why do
you have a bunch of deleting and renaming??

Depending on that answer there may be issues with how you were doing things
that were unfortunately putting you into a difficult place right now. One
key point to keep in mind:

"Assign usernames and only use the usernames in other elements."

This greatly simplifies things when you find that wasn't the right turnout
or sensor for example later. Moving the user name to the right system name
is much simpler and cleaner for the system to do.

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

Thanks, Bob! All replies have been very helpful!

When it comes to simply renaming things (user name assignments) those are
easy, just keep in mind if you wanted to swap something, you would need a
third 'system name' to hold one user name while doing the rest of the
switching around.

But when it comes to deleting things, you really need to either rename
anything that is in use to the new item and work down the 'tree' of parts so
when you get to deleting something, the only thing 'using' it is the table
display. So if you needed to remove a sensor, you need to 'rename' any block
using that sensor first so the block isn't 'using' anything.

This takes planning sometimes. Which brings me to the real question: Why do
you have a bunch of deleting and renaming??

Depending on that answer there may be issues with how you were doing things
that were unfortunately putting you into a difficult place right now. One
key point to keep in mind:

"Assign usernames and only use the usernames in other elements."

This greatly simplifies things when you find that wasn't the right turnout
or sensor for example later. Moving the user name to the right system name
is much simpler and cleaner for the system to do.

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

Martin, what hardware are you using. I抦 having the same issue with some Team Digital Components but after seeing the next post in this thread, maybe it is the JMRI processing????

Thomas Cain
Indianapolis, IN
atsf93@...
Prototype Tour Chair: Highball to Indy 2016 NMRA National Convention

See my website and layout at: www.atsf93.com

On Jun 15, 2014, at 7:48 PM, Martin Ozolins mdozolins@... [jmriusers] <jmriusers@...> wrote:

Hi All



I've been working on a panel for my layout based largely on what I've
learned reading this group. I do seem to be having a software issue
deleting and renaming some table elements. I'm getting warnings on newly
created blocks that the sensor I've assigned is already being used by a
recently deleted block. It seems to get worse when renaming elements. Is
there any script that can audit the relationships or correct errors? If I
audit and correct the XML file will that help?



Thanks.



Martin Ozolins

[Non-text portions of this message have been removed]

The problem that I first reported in v 3.7.3 back in March is still present
in v 3.7.7.

Essentially, JMRI ignores anything you select for script file location and
instead insists that scripts are in a /jython sub-folder of the active
profile folder. So, a different location is shown for each profile,
regardless of the actual chosen location. To make matters worse, every time
you save preferences without editing the script file location, JMRI extends
the path by an additional reference to the profile directory.

As a result, the only way to call one script from another is is to
hard-code the full path to the file.

Dave Heap was trying to fix this in March but it is still with us. I hope
3.8 will have a fix.

Brian

Try going to the "Logix" table. When there, click on tools in the top menu. Try the "orphaned item" list and see if anything can be deleted there.

It's always best to let the program do the deletions first before trying anything yourself. If you do try to modify the file manually make sure you have an up to date back up first.

Peter

Hi All



I've been working on a panel for my layout based largely on what I've
learned reading this group. I do seem to be having a software issue
deleting and renaming some table elements. I'm getting warnings on newly
created blocks that the sensor I've assigned is already being used by a
recently deleted block. It seems to get worse when renaming elements. Is
there any script that can audit the relationships or correct errors? If I
audit and correct the XML file will that help?



Thanks.



Martin Ozolins

mdozolins@...





"Fortune favors the prepared mind" - Louis Pasteur