Templot5 and plug track - progress discussions

[Steve_Cornford]

Hi Phil
@Martin Wynne @Phil G @Phil O @James Walters

Just a question though, should the second slider bar holes not be on the center line created between the two vee webs? As is the case with the first slider bar.

For a turnout I don't think so. The drive points on timber S1 have the same arithmetic (geometric adjustment) as the S5, and indeed as the S8 timber drive points here.

I subtract the default distance apart of the drive pins/tubes (as supplied by the manufacturer) from the gauge, then divide by 2 to get a margin.

the offset between the gauge-face of the stock rail and the gauge-face of the closed switch blade, use the function aq2offset().

Call this offset aq2offset.
the y co-ordinates are calculated as a distance from the gauge face of the main stock rail (origin = 0_
ms drive point y = 0 + margin + aq2offset.
ts drive point y = 0 + gauge - margin


However I might need to adjust the arithmetic regarding the x co-ordinates for a half-diamond, for example it is currently giving me:-

for a movable K-crossing with timbering as normal
and here:-

movable k-crossing with timbering as turnout switch

Steve

 

[Martin Wynne]

Hi Martin,


Thanks, I believe that is just what I need.
For instance when I get to switch drive timber S5, the distance between the drive points connecting an actuator to the switch blades needs to decrease.
This is to keep @Phil G happy & enable him to have multiple switch drive motors/actuators/servos.

At the moment I am not applying any reduction in the drive point holes distance apart for the higher timber numbers.
Here is an example using some dimensions from @James Walters of his MakeItMiniature servo actuator.
if you enter the radius of the drive point holes as a negative number it draws a circle under the cross.
The idea being that you drill a hole in the trackbed through the pins attached to the switch blades drop, and locate into a pair of tubes fixed to the actuator. The actuator tubes do have an adjustable lattitude I believe.
This example has no reduction at the S5 timber position, but you can see that it would probably be necessary.
View attachment 12902
The default (at the moment) is 3.0mm radius (to give a 6mm diameter hole that I believe James recommends for his device).
I think all I need do is apply the adjustment to the MS drive point position so that it moves inwards.

All good fun, and at it has been a useful learning experience.
I am trying to produce the help text as I go along....

Steve

@Steve_Cornford @James Walters

Hi Steve,

I'm a bit puzzled why you have moved the first switch drive along by one timber space? It is normally between S1/S2 rather than S2/S3 on both prototype and model.

Likewise between K1/K2 on the switch-diamonds.

Those semicircular ends on the GWR P slide chairs are currently going to be done in only 12 steps (15 degrees) which might look a bit "steppy" in the larger scales. I should be looking at doing something about that.

But how can I when there isn't time to do anything if I'm going to get 556b released and make progress on the chairs?

Notice also how imperceptible is the GWR joggle in the stock rail. And it's another photo where the difference in colour between the galvanized chair screws and the cast iron chairs is very evident.

I'm also puzzled why you have 2 holes and slider ribs? An important function of the stretcher bar on both prototype and model is to hold the switch blade down on the slide chairs and prevent it kicking up under traffic. On the prototype that is done by having the stretcher bar running under the stock rail with minimal clearance (or through holes in the stock rail in some old designs using round stretcher bars).

The model systems which use pins in tubes don't provide that hold-down function. An important part of the plug track slider design is that it does hold the switch blade down:

But for that you need only one hole to drive the slider. Or preferably it is driven by rodding from the side of the switch (likewise the dropper wire connections) so that the turnout is self-contained and can have its position tweaked by adjusting the pins/screws through the brick webs, with a length adjuster on the rodding. The advantage of the deep plug track timbering bricks is that all such gubbins can be hidden below ballast level.

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,

Hi Martin,
I haven't moved it on purpose, just happened to key in K2 in the switch drive 1 position.
I will post a more prototypical example.
Steve

The current live version of Templot5 allows up to 5 drive switch slider ribs to be defined by entering timber numbers.
There is no validation.

I have introduced some validation. It is still being tested and developed.
I have just been testing all sorts of combinations that a user of Templot5 might enter.

I will add a hint that it is normal for the 1st drive timber to be S1 or K1 (dependent on template type).

As described previously there are now three main options to be associated with a switch drive timber.

They are not interdependent.

You can have slider ribs without the slot or motor.
You can have a slot without a slider rib or a motor.

The motor option has three sub-options:-
mounting points
drive point(s)
envelope

As far as the drive point(s) are concerned if you enter a dimension of zero for the distance apart only one drive point is generated.
The system is designed to suit as many users as possible.
Users can choose what drive system to use, and how to connect it to the template in question.

Experimental switch drive timbers:-

Perhaps all will become clear once I have written the documentation.

Here is the same template converted to "timber-spacing normal":-

some more development to be done here. For half-diamond with movable K-crossings and timber-spacing normal I will need to make an adjustment to the X co-ordinates for both slot and motor for timber K1. The exception to prove the rule....

I also know that I have to refine the method that I am using to generate the circles.

Steve.

 

[Martin Wynne]

@Steve_Cornford

Hi Steve,

For the switch-diamond the K1 timber needs to be 14" wide -- I need to do something about that. The spacing to K2 is only 24", so the slider ribs and slider may need revision too. Only 11" between the timbers. There was a lot of prototype stuff for K-crossings which I skipped over when doing the original timbering. For example the closed-up timbering for the joints in the wing rails (stock rail middles), and for the point-rail joints.

I assumed anyone sufficiently interested would do the necessary timber shoving. But for the chaired K-crossings I know that it is all going to have to be sorted out. One reason why I know getting the K-crossings into plug track will be a big job. The over-scale model flangeways complicate everything -- including the timber spacings (which they don't affect on the V-crossings).

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,
example of single drive slot turnout.
Users of laser cut ply bases will not be using slider ribs.

Steve

 

[Steve_Cornford]

Hi, @Martin Wynne , @James Walters , @Phil G , @Phil O

When specifying the distance apart of the switch motor drive points, if a figure of zero is entered, then only one drive point is generated, and it is generated midway between the switch blades:

converted to a half-diamond, with K1 widened to 14" and K2 forward (both using shove timbers):-

Steve

 

[Steve_Cornford]

Hi Martin,
Whilst testing & checking the switch-drive slot & motor options I have noticed a small error in the soleplate generation for half-diamond movable k-crossings. I was exporting a DXF file & checking it using Inkscape when I noticed this soleplate:

I assume it is being generated at right angles to the ms stock rail.
Also apparent on the trackpad once you start looking.

I will have a go at fixing (hoping its not my fault in the first place)
Just checked , and the fault exists in 556a , half-diamond, movable K , timber spacing as turnout-switch.

Steve

 

[Steve_Cornford]

The timber infill(203?) on S1 that has been reduced in size to only fill the soleplate is correctly registered, but the soleplate guide marks (101 in 556a, 102 in my current version) are not.
The infill (203) uses calc_fill_timber_mark which I believe performs a transform, but the guide mark (101) just uses enter_mark, so I am guessing a similar transform on p1 & p2 of each line needs to be performed...

oh well tomorrows another day, and possibly another boiled egg.

Steve

 

[Steve_Cornford]

meant to paste this screen shot in, sorry

 

[Martin Wynne]

@Steve_Cornford

Hi Steve,

Thanks. I noticed something wrong in your screenshot yesterday but couldn't put my finger on it. It seems to be only in 2D, and doesn't get into the 3D export:

But there are other issues still to be tackled. When it's an actual switch diamond the timber is 14" wide and the soleplate should be 13" wide instead of the usual 9" wide above. When it is a acting as a symmetrical switch the soleplate should revert to 9" wide on a 12"
timber.

Today in preparation for plug track being no longer temporary and experimental, I have been trying to remove the chairing code from drawtimber() and put it in the chair_unit where it belongs. Otherwise with every fresh chair drawtimber() is getting ever more unwieldy as a single function.

But it's not gone well and will take many hours to get working. I think I shall have to abandon ship and revert to the current code if I'm going to get 556b out before the end of the year.

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,

It seems to be only in 2D, and doesn't get into the 3D export:

one less problem then.

When it's an actual switch diamond the timber is 14" wide

Sorry, I forgot to do the "work around" and shove timbers for part of that issue.

the soleplate should be 13" wide instead of the usual 9" wide above

I learn something new everyday!

I see now that soleplate_width is a DXF export parameter, rather than a template parameter.

Is the general rule that S1 timbers under 14" wide have 9" soleplates, and S1 timbers 14" or wider have 13" soleplates then?

For now a user would have to produce these as a separate timber-base and modify the parameter,

I think I shall have to abandon ship and revert to the current code if I'm going to get 556b out before the end of the year.

You need more elves!

Steve

 

[Martin Wynne]

I see now that soleplate_width is a DXF export parameter, rather than a template parameter.

Is the general rule that S1 timbers under 14" wide have 9" soleplates, and S1 timbers 14" or wider have 13" soleplates then?

For now a user would have to produce these as a separate timber-base and modify the parameter,

@Steve_Cornford @James Walters

Hi Steve,

That's why I said there is still a lot of issues to tackle. The truth is that I have barely given K-crossings any thought yet. Also using a half-diamond template as an improvised symmetrical Y-turnout is purely a Templot kludge, and doesn't have any corresponding prototype.

For REA designs, normal switch soleplates are 9" wide, and switch-diamond soleplates are 13" wide. But that might not be the case for GWR and other prototypes.

The soleplate dimensions need to be template specific, set in the control template, rather than in the DXF settings. That was just a temporary fix, to avoid changing the BOX file. If you have implemented a new trailing data block, they can go in there.

I don't want to deter you from what you are doing, but there is not much point in adding the switch-drive details for switch-diamonds until we have got the K-crossings chaired up, timbering sorted out for rail joints, etc. And that will be for fixed K-crossings first, switch-diamonds will have to wait a bit longer.

Hi James, does your servo mount allow for 2 drives to be mounted closely back-to-back for adjacent timbers? For switch-diamonds the two drives always move in unison in opposite directions -- you might like to design a double mount which does both. Even possibly from a single servo?

cheers,

Martin.

 

[Martin Wynne]

@Steve_Cornford

p.s. Steve,

At present when using 2 half-diamond templates for a diamond-crossing, we omit the K1 timber from one of them. But for paper templates it doesn't much matter if we don't remember -- the two identical timbers will simply overlay in the print.

That won't wash for the chairing. At present my idea is to put a half-timber on the MS side in each template, with a single knuckle chair. That means a half-soleplate too for the switch-diamonds. It will need a small integrity-overlap at the centre to ensure no fractional gap in the STL on curved templates.

But the slider ribs will need to be full length on each side.

Just one more thing to think about.

Martin.

 

[KHC1]

Just a silly thought request. Would it be possible when chairs jaws et al are exported they are already placed on a raft. Is it possible to add an annotation to the raft to show what has been printed. So when printing the chairs for a crossing it could have B7 rh on the raft.

Keith who has just had a homemade egg mayonnaise sandwich.

 

[Steve_Cornford]

Hi Keith
You can already do that within Templot before exporting, but it us not automatic.
You add the raft by adding a background rectangle.
You can then add lettering th o the raft, by addi g another shape, but the character set is limited to 7 segment characters.
Or just add the rectangle shape for the raft export then 3d Builder can add embossed text with full character set available .
Whe I get time (I'm out & about just now) I will either find an explanation, or create a new o e.
Steve

 

[Steve_Cornford]

Hi Keith, for a crossing you also need to include LH or RH in the raft game, as they are different.
Steve

 

[Steve_Cornford]

Hi Keith,
duck duck go found this for me:-

https://85a.uk/templot/club/index.p...rack-up-to-version-244c.220/page-56#post-9440

and some more here:-
https://85a.uk/templot/club/index.p...ack-up-to-version-244c.220/page-60#post-10465

STeve

 

[KHC1]

Thanks Steve some more reading to do.

Keith

 

[Steve_Cornford]

Hi Martin,

The soleplate dimensions need to be template specific, set in the control template, rather than in the DXF settings. That was just a temporary fix, to avoid changing the BOX file. If you have implemented a new trailing data block, they can go in there.

I am in the process of adding a new trailing data block in the keep_select.pas code, but so far have just got as far as producing the code for generating the xml string for the output, so I can easily add one or more new parameters in there as well.

Something like:-
S1_soleplate_wanted:boolean;
S1_soleplate_width_in:extended; // soleplate width in inches - *inscale to give mm

Are there ever any soleplates on timbers other than S1?

Steve

 

[Steve_Cornford]

Tsoleplate_info=record
S1_soleplate_present:boolean; // true or false, false means no soleplate
S1_soleplate_width_in:extended; // soleplate width in inches, *inscale to give mm
S1_soleplate_rib_present:boolean; // true or false, True means add a soleplate joint rib?
{S1_soleplate_rib_offset_in:extended; // offset from ms gauge face in inches, *inscale to give mm
S1_soleplate_rib_height_in:extended; // heighth of rib above soleplate.....
S1_soleplate_rib_thick_in:extended; // thickness of rib....}

by soleplate rib I mean the normally insulated joint between the two parts of the soleplate....
but perhaps I am going a bit too far here? (but not too far for COT track?)

Any other paras we should consider adding even if not yet in use?

Then I assume I just add
keep_soleplate_info:Tsoleplate_info;
to the end of
Tfile_blocks=record
in bgkeeps_unit.pas?

 

[Martin Wynne]

Are there ever any soleplates on timbers other than S1?

@Steve_Cornford

Hi Steve,

Soleplates wherever there are switch blade toes. So also on K1 for a switch-diamond. In slips we want soleplates without the accompanying timber, the overlaid slip switches have timbering turned off. That's going to be interesting because the relevant half-diamond timber surface will needed to be dropped 1/2" to make space for the soleplate, for a switch which is on a different partial template. As I mentioned the whole question of plug track for diamonds and slips still has a lot to be thought out.

by soleplate rib I mean the normally insulated joint between the two parts of the soleplate....
but perhaps I am going a bit too far here? (but not too far for COT track?)

If I mentioned a rib in the existing code it refers to the rib rivetted, welded or forged on each end of the soleplate. To prevent the P chair moving outwards (gauge spread). Traffic on the diverging road of a switch imposes a significant side force on the fixings -- hence the speed restriction when taking the diverging route.

That rib is difficult to do in FDM plug track because it is above the top surface level of the brick. My thought was to add it as a resin extension option on the P chair (for the first one only) -- good for laser-cut and CNC timbers too. No problem for FDM in COT track.

Insulated joints in solebars only in track-circuited areas. So only on main running lines. And offset from the centre if there is a facing-point lock. I think these fall into the category of track furniture for resin printing -- which we haven't even looked at yet. Fishplates, switch anchors, dummy fish-washers and bolt heads, and maybe full facing-point locks. Someone did post a fishplate STL -- sorry I have forgotten who it was.

cheers,

Martin.

 

[Martin Wynne]

Tsoleplate_info=record
S1_soleplate_present:boolean; // true or false, false means no soleplate
S1_soleplate_width_in:extended;

p.s. Steve

No need to repeat everything:

Tsoleplate_info=record

wanted:boolean;
width:extended; // inches
...

I usually assume prototype inches unless specifically marked _mm:extended; // model mm

The question of whether to continue using extended instead of double for floats is moot. I tend to write extended through force of habit, but it would make sense to use doubles now that we are in Lazarus/Win64.

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin, I will ditch the S1 prefix then.

As for the rest, I was just trying to make the code as self documenting as possible.

Steve

 

[Martin Wynne]

Hi Martin, I will ditch the S1 prefix then.

As for the rest, I was just trying to make the code as self documenting as possible.

Steve

@Steve_Cornford

Hi Steve,

It's up to you if you are the one writing it.

But I don't think duplication helps clarity, it just takes longer to type:

current_soleplate_info.soleplate_width:=

Perhaps:

Tswitch_fittings_info=record

soleplate_width:extended;
soleplate_thickness:extended;
soleplate_rib_length:extended; // length along timber 3"
soleplate_rib_height:extended;
switch_anchor_stock_rail_bolt_from_toe:extended;
switch_anchor_length:extended; // along stock rail from bolt, negative for GWR
...

cheers,

Martin

 

[Martin Wynne]

p.s. Steve,

The switch anchor dimensions vary with the size of the switch. So we might need to add a:

switch_fittings_info:Tswitch_fittings_info;

to each existing switch. Which will be tricky without modifying the BOX file.

Nothing is ever as simple as it looks.

Martin.

 

[Steve_Cornford]

Hi Martin,
Just to clarify things before I go down the wrong rabbit hole......

The box file contains data for 1 or more templates.

When writing the BOX file, I need to add one type 30 XML data block for each template containing the switch_fittings_info and the switchdrives_info for that template.

I assume that I can do this within the:-

        for i:=0 to keeps_list.Count-1 do begin

When reading the BOX file, I need to attempt to read one type 30 XML data block for each template, and in doing so read each node that should be present, and if not present set the default value for that node in the template. (similar to the LOAD in the DXF custom tab)

Steve

 

[Martin Wynne]

for i:=0 to keeps_list.Count-1 do begin

@Steve_Cornford

No.

You might be saving only group templates, or only brick templates, or whatever.

But you don't need to be concerned with any of that -- just add the additional data block below the existing ones. It would be a good idea to copy what happens to the template symbols data. Except that the count will be only 1 for the new switch settings data (only one switch per template): switch_stuff_count:=1;

Compile it like this (line about 2280)

function compile_xml_symbol_str(template_index:integer; symbols:Tsymbols):string; // 242a
...
...

and line about 3670 find

symbols_count:=Length(next_ti.file_blocks.keep_symbols);

xml_symbol_str:=compile_xml_symbol_str(file_index,next_ti.file_blocks.keep_symbols);

if xml_symbol_str<>''
then begin

UniqueString(xml_symbol_str); // make sure it's in continuous memory.

len:=Length(xml_symbol_str)*SizeOf(Char);

with block_ident do begin // 4 integers, 16 bytes

segment_length:=len+SizeOf(integer);
f_index:=file_index;
block_code:=25; // = new XML version symbol data.
spare_zeroes:=0;

end;//with

BlockWrite(box_file, block_ident, SizeOf(Tblock_ident), number_written); // the data block ident. 16 bytes
if number_written<>SizeOf(Tblock_ident)
then begin file_write_error; RESULT:=False; EXIT; end;

BlockWrite(box_file, symbols_count, SizeOf(integer), number_written); // first the count of symbols. 4 bytes
if number_written<>SizeOf(integer)
then begin file_write_error; RESULT:=False; EXIT; end;

BlockWrite(box_file, xml_symbol_str[1], len, number_written); // then the XML text. len bytes
if number_written<>len
then begin file_write_error; RESULT:=False; EXIT; end;

end;

copy all the above, change symbol to your switch stuff, block_code from 25 to 30, and paste it here

//-------------

// no more DATA BLOCKS yet defined for this template, so on to the next template.

And I've noticed a bug that the symbols data is being included twice! There might be a reason for that in the case of swapping back to T2, I need to check. But it doesn't affect doing the above.

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,

Sorry I should have stated that it was the 3rd occurrence of the

for i:=0 to keeps_list.Count-1 do begin

the one that does have the block 25 symbols xml block in it before the corresponding end; to the begin

Think I need an early night tonight, ready for a new day tomorrow...

Steve

 

[Martin Wynne]

@Steve_Cornford

Hi Steve,

There was an error in the code I posted previously, sorry. Mouse fumbles.

I have edited it.

cheers,

Martin.

 

[KHC1]

Hi Keith
You can already do that within Templot before exporting, but it us not automatic.
You add the raft by adding a background rectangle.
You can then add lettering th o the raft, by addi g another shape, but the character set is limited to 7 segment characters.
Or just add the rectangle shape for the raft export then 3d Builder can add embossed text with full character set available .
Whe I get time (I'm out & about just now) I will either find an explanation, or create a new o e.
Steve

Thanks again Steve, I have just trialed the 3D builder emboss option and that works fine for me.

Keith

 

[Martin Wynne]

@Steve_Cornford

Hi Steve,

101 is the soleplate outline for 2D only:

101: begin
if (_3d=True) or (dxf_form.soleplates_combo.ItemIndex=0)
then CONTINUE
else layer:=26; // 2-D soleplate outline, switch drive mark 244a 3-D soleplate is timber infill
end;

I have fixed the problem for improvised Y-switch:

// for 2-D ... 244a

p1.x:=xns+crab+sp_side;
p1.y:=yns+yret+sp_end_near;
p2.x:=p1.x;
p2.y:=yfs+yret-sp_end_far;
//enter_mark(True,p1,p2,101,'');
calc_fill_timber_mark(p1,p2,101); // near side of 2D soleplate 101 is also switch drive mark

p1:=p2;
p2.x:=xfs+crab-sp_side;
//enter_mark(True,p1,p2,101,'');
calc_fill_timber_mark(p1,p2,101); // far end of 2D soleplate

p1:=p2;
p2.y:=yns+yret+sp_end_near;
//enter_mark(True,p1,p2,101,'');
calc_fill_timber_mark(p1,p2,101); // far side of 2D soleplate

p1:=p2;
p2.x:=xns+crab+sp_side;
//enter_mark(True,p1,p2,101,'');
calc_fill_timber_mark(p1,p2,101); // near end of 2D soleplate

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,

calc_fill_timber_mark(p1,p2,101)

I get build error message, wrong number of parameters, so used:-
calc_fill_timber_mark(101); // instead.

Steve

 

[Martin Wynne]

Hi Martin,

I get build error message, wrong number of parameters, so used:-
calc_fill_timber_mark(101); // instead.

Steve

@Steve_Cornford

Hi Steve,

Ok. I've made quite a few changes in the drawtimber() function for the 8-sided chairs. There will be quite a lot of merging to do at some stage before we can release 556b. I'm just updating print_unit etc. for the 8-sided chair outlines. Currently they have wonky corners.

p.s. what is your preferred screen layout for Lazarus? I've settled on this, with Notepad++ behind which can be quickly clicked though the gap at the top when needed.

Do you know what the marks in this column mean -- I can't find anything? Or make it wider. It is useful because a click jumps the editor a long way, faster than normal scrolling (similar to shift-click on the scrollbar). It's annoying that Lazarus has only 10 bookmarks total -- Delphi had 10 in each unit. I see several comments in the Lazarus forums about this.

cheers,

Martin.

 

[Steve_Cornford]

I believe they are linked to the icons on the right hand side:-

Here I clicked on the red mark on the right, then hovered over the warning triangle on the left to reveal the meaning of the warning.

Ok. I've made quite a few changes in the drawtimber() function for the 8-sided chairs.

in particular does that mean you have added the p1,p2 parameters to the calc_fill_timber_mark procedure?

Steve

 

[Martin Wynne]

in particular does that mean you have added the p1,p2 parameters to the calc_fill_timber_mark rocedure?

@Steve_Cornford

Hi Steve,

Thanks.

Yes. And to some of the others. I've been trying to make it easier to follow, before adding many more chairs.

I wanted to do more, but it involves too much work. It might also be better left until after we have merged your changes.

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin et al,
@Martin Wynne , @James Walters , @Phil G , @Phil O ,@Vistisen
I have now added switch drive motor envelopes to allow checking of motor positioning

The black arrows point to each of the motor envelopes.
The red highlights the mounting points
The beige highlights the drive points. (by setting the distance apart of the drive points to zero, they combine into just one drive point)

In this example I have used the dimensions of an imaginary point motor, to protect the innocent.

The drive motor on timber S1 can be reversed by setting the mounting point y offset to the drive pins negative.

In this case I could move the 2nd switch drive from S6 to S4, giving:-

The envelope rectangle just represents a box into which a drive motor will fit comfortably, it is not the actual footprint of the motor.
Different motors will have different envelopes ascertained from manufacturers specifications.

Here is an example of a motor that has a 5mm clearance between the drive pins and the closest side.

I suppose to show the overlap clearly I should allow different colours to be used for each envelope, but that might be going too far?

Steve

 

[Steve_Cornford]

Hi Martin,

I reached the stage of being able to store control templates c/w switch drive markings (slider ribs 102, drive slots 101, motor marks 103,104,105) to the background so that they are displayed in the box with those markings, and being able to select one of thos & copy to the control with all its parameters.:-

Then I tried adding the code to keep_select.pas that outputs block 30 to the .box file, and loads block 30 from the .BOX file, BUT and it is a big BUT I just keep getting ACCESS VIOLATION errors and other verrors which seem to change their nature if I switch on debugging etc.
I have been going round in circles for several days now, so It is time to throw in the towel and ask for some help!

It was outputting the new XML fields in ebk1.ebk & pb.ebk etc but with some invalid segmenst etc.
Its driving me mad,and probably is a case of not seeing the wood for the trees.
I am hoping that it is a simple error, but knowing my luck it will be a complicated error.

So I have commented out the XML stuff (possibly labelled SC 30-NOV-2024, and sbc ????) and zipped up the sources and a version that at least lets you see and play with the new screens, but won't actually save the new parameters in a .BOX file.

I think the sbc ???? comment is where there might need to be a test to cater for the .BOX file version change, but this might mean that the version needs bumping to 557.

As a diversion I started on the switch fittings parameters, and added a new button, but need the defaults for the two switch anchor fields...

so just ignore the [ switch fittings ] button for now, apart from this question...
Would it be ok to replace the field name & caption of "switch anchor stock rail bolt from toe" with "switch anchor bolt position", and then explain what that means in the help text displayed by the [? info] button.
I have populated the [? info] button help text, but it needs checking for veracity etc.

I have attached a zip of the sources in the hope that you need a diversion and might be able to advise on where I have gone wrong.

Steve

 

[Martin Wynne]

Would it be ok to replace the field name & caption of "switch anchor stock rail bolt from toe" with "switch anchor bolt position", and then explain what that means in the help text displayed by the [? info] button.

@Steve_Cornford

Hi Steve,

That was just off the top of my head. Change it to whatever you need. However the switch anchor has 2 bolts, so you need to make clear that it's the one in the stock rail. Not that we a likely to be printing switch anchors any time soon.

If the problem is simply that it won't fit the dialog width, there is an option to reduce the font size for specific lines.

I have been going round in circles for several days now,

Me too. I should have given the BC chair a separate chair code from the BB. The BC is 4-sided rectangular and the BB is 8-sided. Having them both on the same code has got me in a fix. Various ways out, but none very elegant, or future proof for non-REA prototypes.

Thanks for the zip. I will see what WinMerge makes of it against my current files.

I will have a look at the XML block. It may need a bump to 557 -- that would definitely be the case if it was in the binary section. I was hoping using XML would avoid that.

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,

I will have a look at the XML block. It may need a bump to 557 -- that would definitely be the case if it was in the binary section. I was hoping using XML would avoid that.

I think you are right, no need to bump or have any "version" testing code, as the load section performs an xml read & if not present sets a default.

Switch Anchors
Looking a the REA drawings, drawing 19 gives length of the switch anchor to be 1' 9", with the angle that it is bent too depending upon the switch size.
Also the position depends on the switch size, and it looks as though one possibility would be to relate the position to the farside edge of a particular timber (or chair type, for instance between 3P & 4P for switch sizes A to D, and between 1P & 2P for E and above).
But as you imply, this is a long way down the road for now.

Steve

 

[Martin Wynne]

@Steve_Cornford

Hi Steve,

I think we may have got into a bit of a tangle. Tswitch_fittings has mixed up two different sorts of data:

1. prototype data related to each switch size -- soleplate dimensions, number and position of stretcher bars, dimensions for the switch anchors, etc. This data needs to be associated with each switch in switch_select.pas

It also needs an option to set the dimensions when creating a custom switch.

Note that we can't modify the existing Tswitch_info directly because that is included in the the binary data for a template and its size is therefore fixed in the BOX file. It could have been kludged in Templot2 days, but I don't want to do anything now which will fail in the t2_converter function, the binary section is effectively locked forever now. I will look at other ways round.

2. model data related to the type, size, fixing holes, etc. of a point motor drive/mechanism. That will be template-specific rather than switch-specific. I think it could possibly be included in the symbols data in gaps_unit.pas That is concerned with model electricals and such matters. It is also all XML data in the BOX file, so can easily be added to.

I will have a look at sorting this stuff out.

cheers,

Martin.