From: David D. <djd...@ma...> - 2008-05-28 11:36:09
|
Ken, Add the turnout between the anchor points, then use new track segments to connect the anchor points to the turnout. Turnout connection points are moveable to allow for cases where the standard turnout representation needs to be distorted. Dragging turnout connection points will not make a connection. Only track segments will make connections. (This is heavily entwined with the way Layout Editor keeps track of connectivity.) Dave On May 27, 2008, at 2:49 PM, Ken Cameron wrote: > Quick one about trying (or failing) to make points connect: > > I have two blocks with anchor points at their ends (red box). I’m > trying to fit a turnout (main route) between them. It seems that if > I try to move the endpoint of the turnout, it ‘extends’ the other > endpoint and the track endpoint doesn’t ever connect. I end up with > two very close red boxes on top of each other. > > What am I doing wrong?? > > -ken c > > From: "David Duchamp" <djd...@ma...> > Date: May 27, 2008 2:31:22 PM EDT > To: "Discussions about changes to the code; design, intent, etc" <jmr...@li... > > > Subject: Re: [Jmri-developers] Ideas for layout editor > Reply-To: "Discussions about changes to the code" <jmr...@li... > > > > > Thanks again for the good ideas and discussion. You're also pointing > out areas where the Layout Editor documentation needs to be beefed up. > > See below. > > Dave > > On May 27, 2008, at 9:56 AM, Ken Cameron wrote: > >> Dave, >> >> About the connecting of points. So if I read you right, if it doesn't >> change the shape (little red box to green or something) then it >> either >> thinks the two points aren't close enough or one of the things >> attached >> to one of the points isn't defined enough so it would know how to >> connect them. Like missing block data or something, that sort of >> thing. > > If a connection point is red, it needs more connections. > > If a connection point is green, it has its required number of > connections. > > Block data is not necessary for making a connection. As a > convenience while building a layout diagram, block data may be > specified. Block data may also be added later via a popup menu. > > Block data must be defined before signal logic can be initialized by > Layout Editor tools. Each layout turnout, level crossing, and track > segment can be assigned to a block (multiple blocks for a crossover > turnout or level crossing). >> >> >> A 'view scale' would be nice for this, basically a zoom window while >> working out the more complicated sections of track. Then zoom it back >> out for normal use of the panel. The one scale/move tool doesn't >> scale >> where the signals are. So all the lines may move, but the signal >> heads >> stay wherever they were. > > That's correct. There isn't a Java way that I've found to scale > a .gif picture. Thats why I recommend working out all the layout > track connections, as much as possible, before adding signals. It's > easy to scale up and back down using the Tools menu, and migrate to > the area in question. >> >> >> Can you place a turnout in the middle of a block or does a turnout >> require a separate block?? > > Yes you can place a turnout in the middle of a block, but you > wouldn't want to if the turnout is signaled. But an unsignalled > turnout, for example, for an industry siding, should work fine. > > The "best" way I've found to block around RH, LH, and WYE turnouts > is to assign the turnout to the same block as the throat track, and > assign the continuing track and the diverging track to different > blocks. This results in signals working fine with Simple Signal > Logic, in block occupancy being displayed clearly as a train > traverses the area, and in the fewest number of blocks. > > Some people, however, like to have each turnout in its separate > block to afford a handle to prevent a turnout from being thrown if a > train is occupying the turnout, but I haven't found the need--maybe > I just haven't thought enough about the problem. If I did > physically put a turnout in its own block, I'd still assign the > turnout as noted above, and link the two occupancy sensors with a > Logix. (Sort of a block within a block). > > For double crossover turnouts, I recommend using four different > blocks--one for each "throat" connection, with the A, B, C, and D > blocks in the turnout set to the same blocks as the blocks assigned > to their respective connected track. (If this doesn't make sense, I > can explain in more detail.) > > For single crossover turnouts, the crossover should have at least > two blocks, with a block boundary on the crossover. The A, B > connections may have different blocks or the same block, and the C, > D connections may have different blocks or the same block. A single > crossover should end up with three block boundaries. One on the > crossover track, and one on each continuing track, either one at the > throat of the switch or internal to the turnout. > > Note: A, B, C, and D are defined in the documentation of Layout > Editor Tools. > > From a Layout Editor point of view, the least flexible situation > occurs with "throat-to-throat" signals where the throats are so > close together you would not want to place signals at the throat. > This situation occurs when diagramming a double slip, for example. > Or when two turnouts are actually connected throat-to-throat. The > only way I've been able to make signals work well, and track > occupancy look meaningful as a train traverses the area, is if both > of the throat-to-throat turnouts and their connecting track segment > are in a separate block from the four blocks of the four connecting > tracks (continuing and diverging for each turnout). > > For a triple turnout, in Layout Editor you use an LH turnout with > its throat connected to the continuing connection point of an RH > turnout using a very short track segment. (or vice-versa). Here > I'm not sure what the "best" blocking scheme is. I have one of > these on my layout, but I haven't gotten around to placing signals > there yet. My current blocking is for the two turnouts and their > connecting track segment to be in the same block as theconnecting > track at the throat of the triple turnout connecting track, and for > each of the three diverging/connecting tracks to have its own > block. (Layout Editor has no tool for setting up a signal with > three signal heads (the throat of a three-way turnout), and I'm not > planning to develop one.) >> >> I do think that some sort of 'priority' for a finished panel that >> would >> override or lock the defined parts like blocks and paths would be >> handy >> I think. Granted the more I think of this, the more I'm suspect >> that it >> would be easy to implement. > > I agree that this would be a good idea. It will be easy to > implement, if the priority designation is only in effect if the > "priority" panel is not in edit mode. > >> Please clarify something: Is the idea that >> you have one panel file, but it contains multiple panes/windows > > Yes. Multiple panels, of either type (Panel Editor or Layout > Editor) in the same file, all using the same configuration > information contained in that file. > >> or that >> each should really be its own file?? > > No. Definitely a complication if one tries to do this with the > present system. > > And I'm sold on the one file (with multiple panels possible) setup > because 1) it is so much easier for users to use and implement, and > 2) because the same configuration items (turnouts, sensors, signal > heads, signal logic, blocks, etc.) apply to all panels that are open > at the same time. > >> I'm cloudy on the multiple panels >> part, I know what I'd like, but not sure about how I should do it. My >> typical idea is the one pane that generated most of the logic and >> signals, a 'timetable' like drawing in layout editor using as much of >> the auto logic as possible. The next would be a pane that looks >> like the >> layout and is viewed by the passing crowd to show what is where and >> why >> it is doing things (stopped for signal etc...). Then another pane >> that >> would be the CTC window for controlling the railroad and other hidden >> automation screens (like my script) that run the trains in response >> to >> the signals 'in front' of them. > > That should work fine. > > After creating and saving the first panel, just select New Panel... > and start creating the second, saving appropriately. Use the same > configuration names to reference the same items (blocks, turnouts, > sensors, signal heads, etc.). > > Another possible way is to set up a Layout Editor panel to > facilitate automatic initialization of things, and a Panel Editor > panel to look more like a real CTC panel. The Panel Editor panel > would use the same logic set up by the Layout Editor panel. > > Some may wish to divide their layout into multiple auxiliary panels > (either Layout Editor or Panel Editor types) to facilitate using > multiple screens. If Layout Editor is being used for automated set > up of signal logic and blocking, however, there should be one master > "priority" panel that describes the entire layout. This master > panel must exist in the panel file, and show up in the Show Panels > submenu, but it doesn't need to be displayed. >> >> That last part, figuring out what the 'in front' signal is for a >> given >> train, is where I was trying to use the direction data in the >> paths. But >> the more I give it thought, I'm thinking that from a given block a >> train >> would only have one valid (turnout position) going one way, and the >> other way would be a block the train was either still in, or had just >> left. And this is what I should use and skip the whole part about >> what >> direction those paths think they are pointing. If I had the >> 'timetable' >> layout, then direction is constant and seems to work ok. > > If you're running a layout specific script, you probably know what > blocks are where, which will follow which as a train makes the > desired transit of the layout, and how to set turnouts to move along > from point A to point B. > > Currently, there is no general purpose way in JMRI to set up a > transit (path, route) for a train through the layout. I've been > thinking of several possibilities for such a feature (a first step > in automatically running trains), building on Blocks and Layout > Editor's connectivity information. We could discuss the best way to > implement such a thing, but I'm probably not going to be able to do > much implementation before the fall. Such a feature would have a > static component (a part that could be stored in a configuration > file), but it would have to be implemented dynamically for it to be > useful in automatically running trains around the layout. >> >> >> Oh, one thing about 'defaults' that came to mind was when the layout >> editor was creating signals. The option on a signal for the 'flashing >> yellow' was the one I had to go around and set all the time. But >> here I >> think we may be back to treading on the issue of signal logic doing >> 'aspects' instead of 'outputs' if you know what I mean. > > Would putting a check box in each of the SetSignals... tools do what > you want? >> >> >> Thanks greatly for the work done. I'm trying to figure out how to >> leverage the best of it so people can end up 'auto running' trains >> without having to write scripts that know everything. The goal in my >> mind would be a option on the throttle tool as the interface. You >> tell >> it a few things about where you are starting and the speed limits and >> punch go. After that, it is automatic and just follows the signals >> and >> turnouts controlled by a CTC or other logic. > > Sounds like we're aiming in the same direction (see above). I > hadn't thought of the need to set speed limits, however. > > I have a hidden blocked staging area on my small layout that > accommodates up to 8 trains. My vision (goal) is to have one or two > trains start automatically from the staging area at predetermined > fast times, transit the layout automatically (while I run a local or > work in the switching yard), and/or stop at a passenger station or a > side track to drop off or pick up cars. I haven't figured out a > good way to implement this vision, especially how to send the train > along on its way after I manually add/remove cars from it. > >> From:"David Duchamp" <djd...@ma...> >> >> Ken, >> >> Thanks for the feedback and the ideas. >> >> (See below). >> >> Dave >> >> On May 27, 2008, at 7:03 AM, Ken Cameron wrote: >>> >>> 1. A snap to grid option. I'm always having trouble getting anchor >>> point >>> to bind, particularly to turnouts, and worse if my original panel >>> had a >>> track segment and later I want to go and replace it with a >>> turnout. Or >>> something to help make anchors match each other. >> >> The cursor should change shape as you drag a track segment within >> range of a connection point. If you release when it is within range, >> it will snap to connect. I could increase the radius of the range if >> that might help--it's set small to avoid having more than one >> connection point in range. If the cursor is not changing shape for >> you, please let me know. >>> >>> >>> 2. Ability to set defaults for a panel with respect to things edited >>> in >>> the popup menus. I'm trying to remember what I was doing that I kept >>> having to go to the popup and setting the same thing time after >>> time, >>> but now it's morning here and I can't remember. >> >> If you can remember what item on what popup menu, I'm sure that would >> be an easy thing to implement. >>> >>> >>> 3. Editing ability to get at the path data like direction. Here I'm >>> thinking of how to add things like the CW, CCW tags where I know >>> where >>> the layout is really going that sort of thing. But this is where I'm >>> also thinking we might need a special flag to mark the ends of a >>> reverse >>> loop so logic trying to track things would know that we are >>> crossing a >>> boundary and that our direction sense has indeed reversed. >> >> "Direction" is a very complicated issue unless you lay out your panel >> with all tracks horizontal and don't have any block boundaries at the >> end connection point of any horizontal track. The way they would be >> laid out on a real CTC panel. >> >> I've found that I usually avoid using "Direction" all together, for >> reasons similar to what you describe above. What exactly are you >> using direction for? There may be an easier way around the question >> than tackling the complex direction question. The way Direction is >> set up, it really only makes sense to use directions if they are >> manually set up, except in the case I mentioned above. >>> >>> 4. Ability to 'rank' a set of panels so things like paths and >>> directions >>> would come from one panel and ignore the others. Here I'd have the >>> 'logical' panel so I have maximum control and consistency of the >>> directions. But then have other panels that might look more like the >>> real layout, but they take all that extra info from the first panel >>> instead. >> >> The reason multiple panels are used to define paths and directions is >> to allow them to dynamically change as panels are edited. I could set >> up a flag for a panel to be given "Priority" in defining paths and >> directions, provided that panel is not in Edit Mode. Would that work? >>> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/<ATT265458.txt> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________ > Jmri-developers mailing list > Jmr...@li... > https://lists.sourceforge.net/lists/listinfo/jmri-developers |