Templot5 and plug track - progress discussions

[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.

 

[Steve_Cornford]

Hi Martin,
Some further thoughts having slept on it.

In theory there is nothing wrong in the principle of adding some more blocks of XML data, it was when I came to put theory into practice that I stumbled.....

Do XML blocks have to be Template Specific, or could we also have an XML block as Switch Specific?
Perhaps by adding an extra parameter to the block header?
If so we could have block 30 TIMBER_FITTINGS and block 35 SWITCH_FITTINGS, but as E&E say not necessarily in that order.

It would be quite useful to have the switch anchor bolts as marks on both the stock rail and the switch rail, with the possibility of a line drawn between them, at least when printing a template.

Talking of template specific, I added two buttons to the timbering dialogue that are not template specific but at least I did make them a different colour! (slot data & slider data)
I found it very useful to have the slot data on that dialog screen as it was then very easy to adjust the dimensions of the slot & immediately see the result. This led me to change the slot mark generation to using the calc_fill_timber procedure thus ensuring a true rectangle was generated that was parallel to the associated timber.

I also took the liberty of including the option to change the K-crossing between fixed, movable or automatic although this was not an item in the Timbering menu. It does make life easier to also have it here, as well as on any future Crossings dialog.

Steve

 

[Martin Wynne]

@Steve_Cornford

Hi Steve,

Not yet taken in what you just posted, but I have been making some suggested changes (red dots):

(bgkeeps_unit)

I have split your data into prototype and model, Tswitch_fittings_info, and Tsd_data.

Tswitch_fittings_info is added to the data for each switch in the list. (soleplates, stretcher bar positions, switch anchors)

(p.s. GWR soleplates are 3/8" thick with forged ends, REA soleplates are 1/2" thick with ribbed ends.)


Tsd_data is separate, a max of 5 drives per template should be enough (F switches have 4 stretcher bars), so can be a static array instead of dynamic.

Then current_model_switch_drives for the control template, and keep_model_switch_drives for each background template, saved in an XML block (or could be added to the symbols XML block -- the sd dialog button could be on the gaps_form).

cheers,

Martin.

 

[Martin Wynne]

@Steve_Cornford

Hi Steve,

Here is the declaration for Tswitch_fittings_info. You can see in Tswitch_info above it, that there is 240 bytes of spare space there. In Templot2 days I would have used that for the fittings info, with a bump to 557 to update earlier loaded files. But I don't want to make any further changes to the binary section in the files. So this will need its own XML block for any custom settings.

bgkeeps_unit.pas

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,
WIll that sort out the access violation errors that I get when it tries to generate the xml? Before I have even asked it to create a box file, just during startup.
Steve

 

[Martin Wynne]

Hi Martin,
WIll that sort out the access violation errors that I get when it tries to generate the xml? Before I have even asked it to create a box file, just during startup.
Steve

@Steve_Cornford

Hi Steve,

It will do when I have sorted it out. I'm adding stuff in switch_select.pas which I haven't looked at for 20 years, and it's not easy to follow.

If you delete every .ebk file from the Templot folder, it should start up at least once. There is probably 5 of them. It is likely to create more .ebk files as soon as you add anything to the storage box, so you will need to delete them again.

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,
Sorry if I have caused you extra work.

Still 20 years ago you probably were not thinking that you would be looking at it again in 20 years time

Did you even know realise the power of a boiled

Steve

 

[Steve_Cornford]

Had a screen break to make a start on my layout.
I am attempting to make lighter baseboards, so here is a foamboard beam.

Very easy to cut to size & glue together with Gorilla wood glue.
Using glass headed pins whilst glue cures.
Steve

 

[Martin Wynne]

@Steve_Cornford

Hi Steve,

I have changed this to switch_anchor_length

Looking at the drawings (I should have done that first) it seems all REA anchors are 1ft-9in long, and it's left to the fitters to crank and twist them, and drill for the holes to fit each switch size. So the actual switch rail hole centres will have to be calculated by Templot. Anchor bar section is 2.1/4" x 3/4".

Also the stock rail bolt positions are not dimensioned on the drawings, so will have to be estimated.

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,
It might have been wishful thinking, but when I looked at the REA drawings this morning and discovered there were not any measurements given for the bolt holes, I came to the conclusion that they were positioned so that
the bolts of the switch anchors were just about aligned with the edges of the timbers.
If we had a parameter called switch_anchor_timber_bolt_offset and a parameter called switch_anchor_timber_str, we could use that to determine the position.
I suspect that in model terms that would be a good compromise.

The switch anchor is 1' 9" long, with bolt holes 2" from each end.
So that for a given switch size if we used a stock rail timber number as a parameter, determined the far side of the timber x co-ordinate then added the bolt_offset , then that would be a good compromise for the stock rail bolt position.
Then possibly draw an imaginary circle with radius (21" - (2 * 2") ) and where it crossed the switch rail would be the position of the bolt the other end.
Switches A to D seem to have the swicth anchors between 3P and 4P.

The E switch has the switch anchor between 1P and 2P

The switch anchors obviously have to miss the chairs.

Steve

 

[Martin Wynne]

@Steve_Cornford

Hi Steve,

I've just been looking at the same drawings.

Thanks -- you are right to suggest dimensioning the bolt from the timber. That ensures that if the timber is shoved along, the anchor will move with it and still fit.

Rather than finding a geometrical intersection, it is easier to walk to and fro along the switch rail until we are exactly 13" from 2" beyond the stock rail bolt. Then another 2" to the switch rail bolt. Not forgetting that the 13" is from the rail web, not the rail edge.

cheers,

Martin.

 

[Steve_Cornford]

it is easier to walk to and fro along the switch rail

And there was me thinking you would have a formula up your sleeve
Still a bit of exercise is good for you

 

[Martin Wynne]

.
So we now have:

                            // switch anchor details...
                  switch_anchor_timb_str:string[4];                      // timber number
                  switch_anchor_stock_rail_bolt_from_timber_x:double;    // stock rail bolt from timber centre
                  switch_anchor_length:double;                           // full anchor bar length (negative for GWR)

Martin.

 

[Terry Downes]

I'm not sure whether this is a T5 bug or an error on my part but, I can not seem to evoke the 'fill below key' option when trying to export stl files for resin chairs?

 

[Martin Wynne]

I'm not sure whether this is a T5 bug or an error on my part but, I can not seem to evoke the 'fill below key' option when trying to export stl files for resin chairs? View attachment 13002

@Terry Downes

Hi Terry,

You can enable that option by clicking here:

After which you will be able to click the fill below key tick-box option.

It's done like that because it's not compatible with loose jaws -- the filler chunk is part of the rail seat and prevents the rail being dropped vertically onto the seat. Use only with slide-on chairs with solid jaws.

I found it gave no advantage and I was minded to remove it entirely. Also it's not prototypical of course.

cheers,

Martin.

 

[Martin Wynne]

@Steve_Cornford

Hi Steve,

I've got as far as getting the switch-fittings settings into the switches list:

But I have added the data only for this one yet. I might leave adding the rest to you, while I get on with the motor mounting stuff.

It has meant a lot of changes in switch_select.pas and other units to do this without modifying the binary part of the BOX file. But it would now be easy to add further switches, such as modern FB etc. Still needs some work on the dialog for custom switches. I will post some files tomorrow.

We also need to add a range of switches for switch-diamonds, so that we can get the correct timber spacings and rail joints. At present that all relies on timbers being shoved as required. Not much point in trying to do the chairing if the timbers are in the wrong place.

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,
Post the necessary files when you are ready, and I will add the data for the ones I have info for.
GWR and REA ones for a start.
Steve

 

[Martin Wynne]

Hi Martin,
Post the necessary files when you are ready, and I will add the data for the ones I have info for.
GWR and REA ones for a start.
Steve

@Steve_Cornford

Hi Steve,

I'm just trying to put together something I can post without getting tangled up with the unfinished chairing stuff.

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,
No hurry, just wanted to confirm that I was ready and willing to do some elving....
Steve