Templot Club forums powered for Martin Wynne by XenForo :
  • The Plug Track functions are experimental and still being developed. Some of the earlier pages of this topic are now out-of-date.

    For an updated overview of this project see this topic.   For some practical modelling aspects of using Plug Track see Building 3D Track.

    The assumption is that you have your own machines on which to experiment, or helpful friends with machines. Please do not send Templot files to commercial laser cutting or 3D printing firms while this project is still experimental, because the results are unpredictable and possibly wasteful.

    Some pages of this and other topics include contributions from members who are creating and posting their own CAD designs for 3D printing and laser-cutting. Do not confuse them with Templot's own exported CAD files. All files derived from Templot are © Martin Wynne.
  • The Plug Track functions are experimental and still being developed.

    For an updated overview of this project see this topic.   For some practical modelling aspects of using Plug Track see Building 3D Track.

    The assumption is that you have your own machines on which to experiment, or helpful friends with machines. Please do not send Templot files to commercial laser cutting or 3D printing firms while this project is still experimental, because the results are unpredictable and possibly wasteful.

    Some pages of this and other topics include contributions from members who are creating and posting their own CAD designs for 3D printing and laser-cutting. Do not confuse them with Templot's own exported CAD files. All files derived from Templot are © Martin Wynne.

Templot5 and plug track - progress discussions

Quick reply >
Hi Martin,
I had a go at producing a 32-bit version of Templot5
Running it under debug, when restoring previous work, i get this error:-
1731347754109.png

Then when click ok, and hovering on statement responsible it shows:-
1731347809932.png

Does xnl_3=Nan indicate that at this stage xnl_3 has not been assigned a value, and under 32-bit regime the null value represents infinity?
Dont get this error when compiled & run as 64-bit.

Steve
 
_______________
message ref: 14864
Does xnl_3=Nan indicate that at this stage xnl_3 has not been assigned a value, and under 32-bit regime the null value represents infinity?
Dont get this error when compiled & run as 64-bit.
@Steve_Cornford

Hi Steve,

That's strange, because no such error in Win32 using Delphi5.

I will do some digging. Thanks for reporting it.

cheers,

Martin.
 
_______________
message ref: 14866
Hi Martin,
Before you spend too much time on it I will try installing 32-bit lazarus on my 32-bit windows 8 machine & try compiling & running it there.

I had installed the 32-bit lazarus rde on my 64-bit as a 2dn lazarus install, and that might be the problem.

Steve
 
_______________
message ref: 14867
Does xnl_3=Nan indicate that at this stage xnl_3 has not been assigned a value, and under 32-bit regime the null value represents infinity?
Dont get this error when compiled & run as 64-bit.
@Steve_Cornford

Hi Steve,

Thanks for reporting this. These three local variables were not being initialised -- they are now - math_unit line 29505:

xnl:=0;
xnl_2:=0;
xnl_3:=0;


xnl_3 could indeed be a NaN (not a number) in some cases, but the error result from that calculation was not being subsequently used.

Clearly the Win32 compiler on Lazarus is more fussy about reporting such things than the Win64 compiler, or Delphi5.

What are our thoughts about T5 being for Win64 only? I don't recall any reports from users with older Win32 computers wanting to do the 3D stuff and not being able to. But it would mean keeping Templot2 available for track planning on such Win32 systems. And updating T2 with any track planning function updates to match T5, and with updated help notes and docs. It is all getting more and more tangled. :unsure:

cheers,

Martin.
 
_______________
message ref: 14898
Hi Martin,
What are our thoughts about T5 being for Win64 only?
Hopefully I will get time tomorrow to get Lazarus rde 32-bit up & running on my Windows 8 32-bit.

I was wondering about bundling copies of say Templot_5_32.exe and Templot_5_64.exe with Templot_2.exe, and putting a test in Templot_2.exe that when the BIG TEMPLOT5 button is pressed the ability to discern which OS you are running under?

For the 3D & 2D exports do you require a 64-bit machine to run the mesh-fixers and slicers?

I believe most CAD s/w is 64-bit nowadays

Steve
 
_______________
message ref: 14900
Hi Martin,
Here is my outline design for a Switch Drive dialogue (based on your sliders_unit)
1731443873692.png

The principle being that the switch drive slots are now associated with a timber rather than a preset distance form the toe.
Just like the switch drive slider ribs, and the actuator mounting points (if checked)
The drive data will allow access to the positional & dimensional parameters for each switch drive position.

By actuator I mean some form of point motor or actuator mounting plate. eg Dingo Servo mount, MakeItMiniature actuator, Tortoise, Exactoscale TOU.. etc

Nothing like a bit of programming to clear the mind (or do I mean muddy the waters?)

Steve
 
_______________
message ref: 14901
any corrections, suggestions gratefully received.
@Steve_Cornford

Hi Steve,

Looks good, but turnout control template -- also applies to movable K-crossings (switch-diamond). Or will do.

Suggest increased spacing - a blank line above the red headings?

cheers,

Martin.
 
_______________
message ref: 14905
Hi Martin,
but turnout control template -- also applies to movable K-crossings (switch-diamond). Or will do.

Code:
begin
    // populate template_str
    template_str:='turnout';

    drive_help_str:='    `0Switch  Drive Options`9'
     +'||You may define between one and five switch drive positions for this '+template_str+' control template,'
     +' by inputting the lowest timber number of a pair of timbers to establish the location.'

Just havent got round to adding the code to discern between half-diamond and turnout yet.

Suggest increased spacing - a blank line above the red headings?
ok will do.

Perhaps we need a "g" for Green Headings? :unsure:

Steve
 
_______________
message ref: 14906
Hi Martin,
Now that I have taken a closer look at the program help screen, I noticed that you output a small program version number and the copyright symbol at the bottom of the scrolled text.
1731484735785.png

This means that it is not always visible. Should we move it to a non-scrolled position, just below the "...use the scroll..." text?
Also the copyright symbol is lonely. Should it have your name after it, and possibly the year?

Steve
 
_______________
message ref: 14910
Hi Martin,
Sorry I had already added the `g option into help_unit.pas, as I found it easier to just edit the `x to `g.

Also as I am a word man rather than a numbers man I used the X11,svg,css "green" name for the colour rather than #008000.

Code:
 'g': add_str:=add_str+'<SPAN STYLE="font-weight:bold; color:green; font-size:'+IntToStr(help_font_size+2)+'px; font-style:italic;">'+part_string+'</SPAN>';  // green header    556b

Steve
 
_______________
message ref: 14912
Hi Martin,
So using lazarus rde 32-bit on my 64-bit laptop I was still getting floating point errors after adding in your intialisation code to math_unit.

I tried using the IsNan function to identify & correct but that did not work so I resorted to

nantest:string;

nantest:=FloatToStr(extended_variable);
If nantest="Nan" then extended_variable:=0;

extended_variable name changed to protect the innocent!

Here is the actual code I used:-
Code:
                                            // for BB/BC wing flares      241a

                                          // sbc debugging
                                          nantest:=FloatTostr(wing_end_flares.ts_wing_k);
                                          if nantest='Nan' then wing_end_flares.ts_wing_k:=0;

                                          nantest:=FloatTostr(wing_end_flares.ts_wing_add);
                                          if nantest='Nan' then wing_end_flares.ts_wing_add:=0;

                                          nantest:=FloatTostr(wing_end_flares.ms_wing_k);
                                          if nantest='Nan' then wing_end_flares.ms_wing_k:=0;

                                          nantest:=FloatTostr(wing_end_flares.ms_wing_add);
                                          if nantest='Nan' then wing_end_flares.ms_wing_add:=0;

                                          if IsNan(wing_end_flares.ts_wing_k)    // this test does not work, so added the above
                                             then begin
                                                    showmessage('sbc1 ts_wing_k Nan');
                                                    wing_end_flares.ts_wing_k:=0;
                                                    showmessage('sbc2 ts_wing_k = '+FloatToStr(wing_end_flares.ts_wing_k));
                                                   end
                                              else begin
                                                    showmessage('sbc3 ts_wing_k = '+FloatToStr(wing_end_flares.ts_wing_k));
                                                   end;//if

                                          if IsNan(wing_end_flares.ts_wing_add) then wing_end_flares.ts_wing_add:=0;   // does not work
                                          // isnan not reliable test


and screen print:-
1731673205824.png


it appears to go through this code for every chair on the control template, not just for BB/BC chairs, or am I misunderstanding this section. Is it performing the vraious different calculations just in case they are needed later on?

Funny that it all seems to work ok when compiled & run as a 64-bit program.
One of the mysteries of my life.

Steve
 
_______________
message ref: 14980
Hi Martin,

At the start of the drawtimber procedure there is a comment about the variables xtb,xns,xfs,yns,yfs and tbl. See:-

Code:
procedure drawtimber(full_length,retcurve:boolean; joint_timber,key_towards:integer);     // mark timber outline and chairing

   // enter with xtb, xns, xfs, yns, yfs, tbl (all unshoved)
   // if full_length=False, this is for crossover exit road - so no far end.

Rather than me go jumping to a conclusion about the defnitions of these variables and what parts of a timber outline they represent, is there any chance you have a diagram or explanation of them?

Otherwise I fear I will get in a muddle as usual.

Steve?
 
_______________
message ref: 14993
// enter with xtb, xns, xfs, yns, yfs, tbl (all unshoved)
@Steve_Cornford

Hi Steve,

From memory (I'm too tired tonight to check):

xtb = x to centre of timber, from Ctrl-0

(xns,yns) = co-ords of the near corner of the timber (main-side), x from Ctrl-0, y from MS stock rail gauge-face

(yns usually negative)

(xfs,yfs) = co-ords of the far corner of the timber (turnout-side)

tbl = length of timber

All calc dims are square-on for left-hand straight turnout.

Sorry I'm too tired to answer your question about the page list tonight. I've got 3 half-finished replies on the go, I've been on the computer all day. Still have to make a meal.

Martin.
 
_______________
message ref: 14994
Sorry I'm too tired to answer your question about the page list tonight. I've got 3 half-finished replies on the go, I've been on the computer all day. Still have to make a meal.
Hi Martin,
If one of the half finished reply's is mine, please don't bother until you have some free time its not that important at all.
cheers
Phil,
 
_______________
message ref: 14996
Hi Martin,
Switch Drive Slider Ribs
Currently you can enter up to 5 timber numbers to generate pairs of switch drive slider ribs.
This even works for Tn and Xn timbers, but there is a problem if you enter the last timber number of a set/class of timbers, for instance on a this B6, timber S11 is the last timber of set/class S.
1731861957543.png

You only get 1 of the pair of slider ribs (because the next timber after S11 is not numbered S12 but T1). This example also shows that it actually works for timber T1.

Proposal
As these components are called switch-drive slider ribs, for now I suggest we limit there use to timbers that actually have P slide chairs, unless you think otherwise.

Steve
 
_______________
message ref: 15060
Hi Martin,
Switch Drive Slider Ribs
Currently you can enter up to 5 timber numbers to generate pairs of switch drive slider ribs.
This even works for Tn and Xn timbers, but there is a problem if you enter the last timber number of a set/class of timbers, for instance on a this B6, timber S11 is the last timber of set/class S.
View attachment 12773
You only get 1 of the pair of slider ribs (because the next timber after S11 is not numbered S12 but T1). This example also shows that it actually works for timber T1.

Proposal
As these components are called switch-drive slider ribs, for now I suggest we limit there use to timbers that actually have P slide chairs, unless you think otherwise.

Steve
@Steve_Cornford

Hi Steve,

I knew it would work for all the timbers, but I forgot to allow for crossing the boundary between S and T etc.

I had in mind that a slider in the X area might be handy -- for spring/moving wing rails, and possibly even swing-nose crossings.

Suggest you disable it for T timbers, but leave it on for S and X (and also D for switch-diamonds). Disabled for the highest numbered S or D perhaps, or for only slide chairs. Slide chairs for switch-diamond is types SDN and SDP.

cheers,

Martin.
 
_______________
message ref: 15069
.
Currently we have got the wrong hats on.

T2 has a green splash screen with a yellow hard hat.

T5 has a yellow splash screen with a green hard hat.

They should surely match? Need to swap them over before the next update.

Martin.
 
_______________
message ref: 15085
Hi Martin,

Suggest you disable it for T timbers, but leave it on for S and X (and also D for switch-diamonds). Disabled for the highest numbered S or D perhaps, or for only slide chairs.
So for turnouts I allow S and X timber number prefixes.
And to start with for half-diamonds I only allowed D and X prefixes, but then revised that so that switched half-diamonds allow S and X (as that is what the timber numbers are displayed as, see:-
1732055525962.png

but then I realised 💡

if you have the half-diamond movable timbering set = as turnout switch, you get S switch timbers. (so allow S & X)
If you have half-diamond movable timbering set = as normal, you get K switch timbers. (so allow K and X)

fixed half-diamond timbering set = as prototype you get T prefixed timbers (so allow T and X)
fixed half-diamond timbering set = as model, you get D1 followed by T2, T3 etc (so allow D1, then T2 onwards, and X)

The last combo means that if you enter D1 you only get one of the pair of ribs as there is no D2, so for now I am going to treat fixed half-diamond as allowing T and X prefixes & cope with the D1 -T2 scenario inside math_unit slider ribs processing by temporarily ghosting D1 as T1.

I will worry about what happens when having defined the switch drive timbers, you amend the switch-setting or the v-setting or convert a turnout to a half-diamond or vice versa later, on the basis that hopefully the user will follow your recomendations & first get the "layout" finalised before adding any extra switch drives etc....
For now I might just add a bit of verification when I am creating this panel in the timbering dialogue and highight it in red or something:-
1732058943575.png

as simulated here...

After all this is still very much an ongoing experiment....

At least I now have a small inkling about half-diamonds, fixed or switched, and the options thereof. :unsure:

Steve
 
_______________
message ref: 15102
Steve,

You don't need much of a machined flair on swing nose crossings, not that a 1 in 10 would be a swing nosed crossing in the first place.
 
_______________
message ref: 15120
_______________
message ref: 15169
in 556b with 8-sided chairs the plugs and sockets will be narrower than the 4-sided chairs were in 556a.

The good news is this means they can be skewed a bit more, and it may not be necessary to force the equalizing.

The bad news is that chairs and bases made in 556b will not be compatible with those made in 556a. I posted a warning about this previously. I'm not going to apologise for this because I keep saying that it's all experimental and things may change.

But this change won't be confirmed until I have actually made some chairs to prove that they print ok. Which I can't do yet because I'm still working on the code. One thing at a time.

I'm cancelling that change. The plug width for the 8-sided crossing chairs will be the same as before. i.e. 7.5" wide (2.5mm in 4mm scale).

It's not possible to use narrower plugs because they won't print reliably, there is too much overhang from the plug to the edge of the chair.

This means chairs and bases from the next update (556b) will be fully compatible with previous versions, despite the change in chair outline for the crossing chairs.

Martin.
 
_______________
message ref: 15179
However personally speaking I would no longer bother with that. As when update 556b is released you will be able to do it correctly with the right chairs. Given the 556b will be released soon (I understand there is just one elusive bug holding it up at the moment)
@Phil G @Steve_Cornford

Hi Phil,

Sorry, I'm afraid that's wishful thinking. :(

556b will have the 8-sided V-crossing chairs (for a better match to the REA designs than the previous rectangular ones).

But not yet the K-crossing chairs, sorry.

I have fixed the elusive bugs, but there is still work to do before I can release 556b. The chair heaving is not yet working properly. And Steve has been doing a lot of work on the settings dialogs, which has not yet been merged into the release code. Plus several other loose ends to finish. Such as changing links from the Companion to the Wiki.

cheers,

Martin.
 
_______________
message ref: 15182

@Phil G @Steve_Cornford

Hi Phil,

Sorry, I'm afraid that's wishful thinking. :(

556b will have the 8-sided V-crossing chairs (for a better match to the REA designs than the previous rectangular ones).

But not yet the K-crossing chairs, sorry.

I have fixed the elusive bugs, but there is still work to do before I can release 556b. The chair heaving is not yet working properly. And Steve has been doing a lot of work on the settings dialogs, which has not yet been merged into the release code. Plus several other loose ends to finish. Such as changing links from the Companion to the Wiki.

cheers,

Martin.
Hi Martin,
Sorry I was jumping the gun, I has assumed wrongly you would be doing the K chairs at the same time given they look so similar. Never mind there is no urgency. :)
I am glad you have found and fixed the bugs. did you also sort out the strange missing rad on one of the chairs?
Am I right in thinking 556b will allows Phil from Oz, map changes to be fully usable? Without having to dive into lazarus
cheers
Phil,
 
_______________
message ref: 15185
did you also sort out the strange missing rad on one of the chairs?
Am I right in thinking 556b will allows Phil from Oz, map changes to be fully usable?
@Phil G

Yes and yes.

Further to Martin's message I was wrong to suggest K chairs and thus diamonds are imminent.(we are going to have wait some time longer for K chairs) Having said that I believe they would be the logical next chairs to get made (I am honestly not putting any pressure on you here Martin)

The next logical step will be 6-sided slab & bracket AA chairs. It's not yet decided how to do the loose jaws for them. They may need to be glued on like the COT chairs, rather than clip down (which is tricky). They are needed for the K-crossing chairs too, so need to be sorted out first. Also the half-bolted chairs.

cheers,

Martin.
 
_______________
message ref: 15189
Hi Martin,
Just to keep you informed on my progress with switch drive timber options.

As at 556a, both switch drive slots and soleplates used mark code 101.

Mark codes 101 to at least 109 were spare.

I have therefore used some of these un-allocated mark codes as follows:-

I have amended the soleplates so that they use mark code 102.

I have revised the use of slider1_str..slider5_str to designate a switch drive timber.

Switch drive timbers may have the following components:-

switch drive slider ribs (mark code 487 - as before)
switch drive slots (mark code 101)
switch drive motor(assembly, see motor data)
1732364668809.png


the motor data assembly to consist of the following components:-
motor mounting points (mark code 103)
motor drive points (mark code 104)*
motor envelope (mark code 105)*
1732364956135.png


switch drive slider ribs, switch drive slots and switch drive mounting points are all working, but I now have to add the code store them in the background and the box file by adding a new XML block (code 30)

motor mounting points are the holes required to attach the chosen actuator to the baseboard.
motor drive points are the holes (on the drive slot centre-line) required for the actuator drive pins to connect to the switch blades/tie-bar or whatever.
motor envelope is a rectangle into which the chosen actuator will fit to aid planning.

Steve
 
_______________
message ref: 15207
Just to keep you informed on my progress with switch drive timber options.
@Steve_Cornford

Hi Steve,

That's great. (y)

When I released the code open-source I was doubtful anyone would get that far into it. I was always hopeful others would add useful new functions. Rather than fretting about conforming with someone else's software standards or rewriting stuff that was already working.

It's great to see what you are doing. I did mention that the secret is in a boiled egg. :)

cheers,

Martin.
 
_______________
message ref: 15209
Hi Phil,
@Phil O
Short answer:=Yes
Here is a half-diamond V-8 with movable k-crossing, half-diamond timbering: movable K-crossing: timber-spacing normal.
1732378046806.png


switch drive slider ribs allowed on K, X timbers
switch drive slot marks allowed on K timbers
switch drive motor marks allowed on K timbers (the white + marks)

Then Real > Test Timbering Dialog, half-diamond timbering:- movable K-crossing: timber-spacing as turnout-switch
1732378714288.png

1732379037459.png

any K switch-drive timbers are converted to S switch-drive timbers.

ps. switched chairing off for the last screen-shot as they are not yet practical.

Switch Drive Timbering options now available (556b?) without Experimental chairing, as someone might want them without COT track or COT track.


Steve
 
_______________
message ref: 15211
Last edited:
Hi Martin,
It might be a case of back to the classroom for me...
Having added switch drive motor drive points (where the drive pins come up through the baseboard) I have a problem housten...
WHen adding a switch drive to a higher timber, I will need to adjust the ms side drive point to so that it derivces from the gauge face of the switch rail not the stock rail...
see here:-
1732386286816.png

Just got to figure out how to do that?

Steve
 
_______________
message ref: 15218
Hi Martin,
It might be a case of back to the classroom for me...
Having added switch drive motor drive points (where the drive pins come up through the baseboard) I have a problem housten...
WHen adding a switch drive to a higher timber, I will need to adjust the ms side drive point to so that it derivces from the gauge face of the switch rail not the stock rail...
see here:-
View attachment 12896
Just got to figure out how to do that?

Steve
@Steve_Cornford

Hi Steve,

Not too sure what you are asking for. If you are looking for a function to return the open position of a switch blade, there isn't one. All the design work in Templot is done with the switch blades closed against the stock rail. Measuring the open position will have to be done by trial and error on an actual switch.

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

y_offset:=aq2offset(x,k);

Where x as usual is the distance from Ctrl-0. You need to supply a float parameter k which on return will contain the angle (in radians) between the switch rail and the stock rail. Quite often you don't need it and can ignore the result.

This function works for any value of x through the entire template, returning the offset to the turnout-road crossing rail (gauge face). If you do a search you will find many examples of this function in use. For example it is used to set the length of the switch heel block chairs.

cheers,

Martin.
 
_______________
message ref: 15221
Hi Martin,

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

y_offset:=aq2offset(x,k);

Where x as usual is the distance from Ctrl-0. You need to supply a float parameter k which on return will contain the angle (in radians) between the switch rail and the stock rail. Quite often you don't need it and can ignore the result.

This function works for any value of x through the entire template, returning the offset to the turnout-road crossing rail (gauge face). If you do a search you will find many examples of this function in use. For example it is used to set the length of the switch heel block chairs.
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.
1732407411300.png

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
 
_______________
message ref: 15234
Hi Steve,
This is to keep @Phil G happy & enable him to have multiple switch drive motors/actuators/servos.
Thanks Steve much appreciated :)
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.
Thank you for your help Martin, you are a 🗜️enius 📐
I agree with that :)
cheers
Phil,
 
_______________
message ref: 15236
Back
Top