Templot Club forums powered for Martin Wynne by XenForo :

TEMPLOT 3D PLUG TRACK - To get up to speed with this experimental project click here.   To watch an introductory video click here.   See the User Guide at Bexhill West.

     Templot5 - To join this open-source project on GitHub click here.  For the latest on-going developments click here.

  • 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 - progress discussions

Quick reply >
.
The file viewer images are supposed to have a blue border which turns red with the mouse over them (if the clickable option is on). It's working fine in T2, but not T5. I would like to get T5 as close to T2 as possible, but I fear it's inevitable some details are going to be lost.

Martin.
 
_______________
message ref: 12765
.
There is a feature on GitHub called Issues. But it is all rather formalized. I thought it might be useful to have a sort of communal notebook for on-going snags and issues where anyone can write whatever they want. Mainly as a reminder for me because I keep forgetting things nowadays. So I have added a file called snag_wip.txt to GitHub. Please feel free to add/edit/amend, whatever/whenever you wish.

We could do the very same thing here on Templot Club, but old posts and topics tend to get forgotten and not updated, and new members don't find them.

Martin.
 
_______________
message ref: 12766
Hi Steve and Martin,

I have just this evening seen Steve's description of his workflow for using GitHub, and I have to say I'm absolutely horrified that it is so complex/convoluted.

Sadly, I'm not in a position to provide a full description for how I use git at the moment, but I promise I will put together some notes soon (probably over the weekend).

I am currently in the unenviable position of having to set up an all-new PC, as my old PC finally died, and I went out and bought a new PC today... getting everything I need installed and running as I like it will take a little while :-(

(The old PC did live a long and useful life - bought new in 2010, it was a 1st generation i7. It still performed reasonably well, but was something of a power hog).

Alistair.
 
_______________
message ref: 12767
Hi Alastsir,
At present Martin is the Owner, but I am not yet a Collaborator, so it is a bit convoluted.
I would welcome anybody's suggestions as to how we can improve the workflow.
But for now it has enabled a degree of collaboration.

Good luck with the PC
 
_______________
message ref: 12768
_______________
message ref: 12770
Hello Everyone,

I'm still interested in contributing to T5, but things are a bit frantic at work at the moment which has limited my time.

Have setup a development environment similar Steve's above, and can pull the latest state on GitHub to my local repository, and when I can do something useful, I should be able to create pull requests like Steve's been doing.

Martin, if you could point me at where to find the sketchboard code, perhaps I could start looking at that?

Tim.
 
_______________
message ref: 12771
Martin, if you could point me at where to find the sketchboard code, perhaps I could start looking at that?
@Tim Adams @Steve_Cornford

Hi Tim,

Many thanks on your offer to help with the sketchboard function. :)

Some background. The core engine for the sketchboard is DtpDocuments, a desktop publishing component from Nils Haeck in the Netherlands. I purchased the licence and the source code about 18 years ago, for Delphi5. At that time Templot was a paid-for commercial program.

Sadly Nils suffered a brain injury in a horse-riding accident about 15 years ago and was unable to continue his software business or support his customers, although he made a brave effort to get going again. Most of his software he made open-source at that time, but not DtpDocuments which he said he intended to relaunch as a new desktop publishing/graphics component for modern Delphi. At that time he inadvertently posted the full source on his support forum in the public section instead of the customer support section. I don't know the current position, but that web site simdesign.nl has now vanished. It might be available on the Wayback Machine.

Until today that was the position in my mind, and my previous efforts to find the current status of the code got nowhere. I do remember a forum post in which he said he intended to make all his software open-source, but I didn't think that he actually did so.

Now today I find it is on GitHub here:

https://github.com/hellokino/simlib/tree/master

seemingly originally transferred from google code (whatever that is), and apparently posted 9 years ago (i.e. later than the other files listed there, and seemingly his final commit: https://github.com/hellokino/simlib/commits?author=nhaeck ).

I'm sure it wasn't there the last time I searched, so presumably it has recently been changed from private to public.

I have downloaded the code ZIP and it appears to be all there. The snag being that the files contain this:

Copyright (c) 2002-2011 By Nils Haeck M.Sc. - SimDesign
More information: www.simdesign.nl or n.haeck@simdesign.nl
This source code may NOT be used or replicated without prior permission
from the abovementioned author.

and I can find no licence file to say otherwise.

The issue is further complicated by the fact that I have heavily modified the code, so the position about sending copies of it to others is far from clear.

Clearly you can download it and look at it, otherwise there is no point in having it on GitHub, but what you can actually do with it is a mystery to me. Over to you or anyone else who can advise.

cheers,

Martin.
 
_______________
message ref: 12773
Hi Martin,
Thanks for the invite which I have now accepted so I appear in the list of contributors
Steve
@Steve_Cornford

Hi Steve,

As well as being a contributor you are showing this end as a collaborator, and you are no longer in possession of a fork. Is that correct? Collaborators don't have forks? The whole thing is as clear as mud. But thanks for being one, whatever you are. :)

cheers,

Martin.
 
_______________
message ref: 12776
hI Martin,
This is what I see on the online GitHub repositoryif I scroll down:-
1724867585536.png


but the email invite mentioned Collaborate.

Steve
 
_______________
message ref: 12778
_______________
message ref: 12779
Branch/Fork
Collaborator/Contributor

Hopefully Alistair can clear this all up when he has time?
@Steve_Cornford

Hi Steve,

I think it means you can push/merge stuff straight to GitHub from GitHub Desktop without needing to send me a PR.

How that relates to having a fork or not I don't know. I've never had one and I don't look like getting one. :)

Martin.
 
_______________
message ref: 12782
Hi Martin,
I believe I have just updated the main repository with a change to file_viewer.lfm as a test.
You probably need to fetch origin in your local GitHub Desktop to update your local repository.

I believ your local repository only gets updated under your control.
I just unticked the otFolder option in the drive_tree_view.

Steve
 
_______________
message ref: 12813
Hi Martin,
I believe I have just updated the main repository with a change to file_viewer.lfm as a test.
You probably need to fetch origin in your local GitHub Desktop to update your local repository.

I believ your local repository only gets updated under your control.
I just unticked the otFolder option in the drive_tree_view.

Steve
@Steve_Cornford

Hi Steve,

I had already made that change in my Lazarus folder. I fetched your change in GitHub Desktop and looked at it in WinMerge. All the same, so the system seems to be working. (y)

However, there is a difference of 5 in our ClientHeights. I'm on 748 v. your 743. That's of no great consequence, the OnCreate event sorts it out.

cheers,

Martin.
 
_______________
message ref: 12814
Hi Martin,
Once Templot5 (version 555a) gets released to the users, I have a suggestion that might make it easier to implement changes to chair definitions for the future.

Would you consider the use of a data dictionary to define the world of chairs?

We could produce a Utility to maintain a database for the world of chairs that would allow the creation of other family members

*I note that Lazarus or is it Free Pascal likes to prefix identifiers with a 2 character mnemonic

For instance:-

Chair_Family record (field prefix cf) // to denote a family of prototype chairs (there might be a better word than family)
cfFamily:integer // a code from 1 - 99
cfDescription:string // ie REA 1928, GWR 1929?, etc

+ other fields to store attributes that are common to all chairs in this family


Prototype_Chair record (field prefix pc) // to store the Prototype chair dimensions in inches.
pcFamily:integer // as above
pcCode:integer // 1 to 999 ?
pcName:string // S1, S1J, L1, M1, P, CC, etc
pcSides:integer // 4 or 8 sided chairs ?
plus these fields for instance:-
1725036840095.png

Excuse the fact that I have not prefixed these with pc, but incuding this screenshot avoids me having to type in these fields as examples.

plus other fields needed for 8 sided chairs etc....

Chair_Layer record (prefix cl) // to hold an array of x,y points for each layer
clFamily:integer // as above
clCode:integer // as above
clLayer:integer // 1 to 26 (from memory I think it is 26 layers)
( clArray:? // help needed here on how to define an array (in my old days it was "occurs 26"))
clPoint1x:extended (might be Float in a data dictionary)
clPoint1y:extended
clPoint2x:extended
clPoint2y:extended
..... etc etc

Usage
For a selected Family, for a selected chair, read in the Prototype Chair record, apply the inscale factor.

Read in the layer records to get the 2d points for each layer.

Please excuse if this another of my daft ideas, but it is based on my previous experience of a 4GL environment where using a data dictionary made adding new fields & structures easy & could be used to generate source code.

Steve
 
_______________
message ref: 12815
@Steve_Cornford @James Walters

Hi Steve,

That's great. Let's do it. (y)

What do you need from me?

In my mind I had a system where different prototype chair "families" might be loaded in some way from library files. If we had say an expert on Midland Railway chairs they might be able to create such a library data file in a text format which Templot could read in. James was already trying something along these lines for chair horizontal sections from CAD. Would that idea fit with this data dictionary?

cheers,

Martin.
 
_______________
message ref: 12816
Yes, I think so. (Chair horizontal sections)

That was what I was thinking of for a layers record , a layer or slice of the chair.
Am I right in thinking that for a given layer you need a set of n x,y points?

Perhaps Tim, and Alistair could point us in the right direction.

I found something called the Lazarus data desktop

Google lazarus data dictionary & you will get a link to a pdf describing it.

It is not perfect, as when you insert a field, it adds it to the end of the record rather than inserting after a highlighted field but height ho, beggars cant be chooses.

I assume that we use ftFloat to represent :extended
You have to choose size & precision with ftFloat to get it to work apparently.


Anyone on here used the data dictionary?


Steve
 
_______________
message ref: 12818
Hi Martin,
Am I right I thinking that in a unit somewhere, you have already defined the  layers for the existing REA chairs that are printable ?

In chair_unit there are some data fields prefixes with a chair mnemonic, ie L1_chair-inlong
but there are other fields defined that do not have a chair prefix, are these common to all chairs?

Steve
 
_______________
message ref: 12819
Am I right in thinking that for a given layer you need a set of n x,y points?
@Steve_Cornford

Hi Steve,

Yes, for the jaws. But not for the whole chair in one go.

A chair is comprised of two entirely separate areas.

1. the 2D stuff - the outlines you see on the trackpad. This is everything from the raft up to the "plinth" level of the chair base. This is done using the existing Templot marks list -- integer co-ordinates representing 1/100ths mm. A "mark" is a line from x1,y1 to x2,y2, with a code number describing its meaning -- the outline of a timber, for example.

2. the 3D stuff. This is inserted as DXF blocks. There are separate blocks for rail seat, inner jaw, outer jaw, key, bolt/screw boss/head, P slide bolts, etc. Some of these blocks are defined once and inserted many times in a DXF file -- an S1 inner jaw for example. Some blocks are inserted only once, such as the middle jaws in the AA chair for a 1:6.37 crossing. But use the same block insertion mechanism.

cheers,

Martin.
 
_______________
message ref: 12821
_______________
message ref: 12826
Hi Martin,
My bedtime homework reading:-
https://www.freepascal.org/~michael/articles/startlaz7/startlaz7.pdf
(has an example of storing the data in a .csv file)

https://www.freepascal.org/~michael/articles/lazdbdesktop/lazdbdesktop.pdf
(attempts to explain the lazarus data dictionary desktop)

Might have to get Sooty on the case as well :)



Steve
ps I am going to get through a lot of 🥚's
@Steve_Cornford

Hi Steve,

I know nothing about databases or database programming, so you are definitely ahead of me there. :)

cheers,

Martin.
 
_______________
message ref: 12827
_______________
message ref: 12831
You can use Database programming to do all sorts of things you wouldn't immediately think of but it may not be the best way to do it. I suspect that Templot uses vast amounts of data or at least it could so you know more than you think.
 
_______________
message ref: 12850
.
This change is cancelled -- I won't now be changing the FDM timbering socket defaults for Klipper-based printers:

fdm_klipper_cancelled.png


You can of course change the settings to whatever you want.

cheers,

Martin.
 
_______________
message ref: 12863
Hi Martin, do you have a repositry on github for your tech docs? I'd like to contribute and help where I can.
@Richardb @James Walters

Hi Richard,

Templot5 is on GitHub at:

https://github.com/Martin-Wynne/Templot5

Any help would be very welcome, thanks. (y)

Changing to open-source Templot5 has been something of a distraction from the development of 3D plug track, but hopefully it will pay off in the long run.

The main Templot docs site is:

https://85a.uk/templot/companion/

but there is nothing there yet about 3D printing, plug track, cot track, or Templot5.

James Walters is creating a user guide for plug track to accompany his Bexhill West videos, at:

https://85a.uk/bexhillwest/

but that too is in its infancy.

At present the main resource for Templot5 and plug track is this Templot Club forum. We still have a long way to go. :)

cheers,

Martin.
 
_______________
message ref: 12872
@Richardb @James Walters

Hi Richard,

Templot5 is on GitHub at:

https://github.com/Martin-Wynne/Templot5

Any help would be very welcome, thanks. (y)

Changing to open-source Templot5 has been something of a distraction from the development of 3D plug track, but hopefully it will pay off in the long run.

The main Templot docs site is:

https://85a.uk/templot/companion/

but there is nothing there yet about 3D printing, plug track, cot track, or Templot5.

James Walters is creating a user guide for plug track to accompany his Bexhill West videos, at:

https://85a.uk/bexhillwest/

but that too is in its infancy.

At present the main resource for Templot5 and plug track is this Templot Club forum. We still have a long way to go. :)

cheers,

Martin
Hi Martin,

Thank you and no problem at all, I'll take a look and come up with a plan.
 
_______________
message ref: 12874
@James Walters@Martin Wynne

Hi Martin,

Thanks for the GitHub link. I've been following as Rich Bunting (ValleysEnduro).

I hope you are well. This is a long post—about 5-10 minutes to read.

Before diving in, I wanted to check my understanding of your vision. It seems you want to open source Templot5 to reduce time spent explaining things, letting the community help maintain the project while you focus on development and enjoy your hobby. If that’s the case, I think you'll be interested in my proposal to support Templot5 documentation.

As I wrote the proposal, it became quite detailed. I’ve provided a "Too Long; Didn't Read" summary below, but I believe this project can achieve significant improvements.

TL;DR: I propose overhauling Templot5 documentation using the ASD 1000 structure, simplifying the language with STE 100 guidelines, and migrating it to an open-source platform with Sphinx and GitHub Pages. This will improve user accessibility, reduce your workload, and enable community contributions. I also recommend creating a separate GitHub repository for the documentation. A pilot programme will ensure a smooth transition, with outlined risks and mitigations. Notably, Sphinx-generated documentation can resemble the current style, ensuring familiarity. Additionally, I'm happy to host the documentation on a custom subdomain via Github pages, assuming usage remains within a free plan due to the niche nature of the project.

If this sounds good, I’d be happy to start with a pilot section to show how it works in practice. I fully recognise this is your project, so you may want to accept one, all, or a combination of these proposals. I’m eager to hear your thoughts and welcome any ideas.

Combining ASD 1000, STE 100, and Open-Sourcing​

Alignment with Your Vision: Templot was designed with a deep understanding of model railway track design, reflecting its origins and phases. My proposal to structure the documentation using ASD 1000 and simplify the language with STE 100 aligns with this by respecting Templot's complexity and flexibility. Organising the documentation into clear sections—Background Information, Procedural Tasks, Reference Material, and User Contributions—will help users navigate Templot’s dual functionality more effectively. This supports both experienced users and those seeking more prescriptive guidance.

Proposed Approach:​

  1. ASD 1000 Structure: I’ll organise the documentation using ASD 1000 methodology, breaking it into clear sections—Background Information, Procedural Tasks, Reference Material, and User Contributions. This will make it easier for users to find the information they need.
  2. STE 100 (Simplified Technical English): I’ll simplify the language using STE 100 guidelines, ensuring the content is clear, concise, and easily understandable.
  3. Open-Sourcing with Sphinx and GitHub Pages:I propose migrating the documentation to an open-source platform using Sphinx and GitHub Pages. This offers several benefits:
    • Community Contribution: Open-sourcing the documentation encourages community contributions, reducing your burden.
    • Version Control and Collaboration: GitHub offers robust version control, making it easy to track changes, revert to previous versions, and collaborate effectively.
    • Automated Content Migration: I can use tools to crawl the existing website and migrate the current documentation to Sphinx with minimal disruption.
    • Parallel Setup for Smooth Transition: I can run the Sphinx-based documentation alongside the existing system initially, allowing you to see the benefits before a full transition.
    • Consistent Look and Feel: Sphinx can closely resemble the current style of Templot5 documentation, minimising disruption during the transition.

Hosting​

To make the transition smoother, I'm happy to host the new documentation on a custom subdomain, such as docs.85a.uk, via Github pages or similar platforms. The assumption is that usage will remain within the limits of a free plan, given the niche nature of model railway track design.

Proposal for a Separate Documentation Repository​

I recommend setting up a separate GitHub repository dedicated solely to Templot5 documentation. Here’s why this approach would be beneficial:

  • Clear Separation of Concerns: Simplified management and dedicated structure for the documentation, independent of the software codebase.
  • Improved Collaboration: A dedicated repo will make it easier for the community to contribute, simplifying workflows tailored to the documentation.
  • Enhanced Version Control: Independent versioning and focused issue tracking, ensuring the documentation remains a valuable resource.
  • Better User Experience: A single, dedicated location for accessing the documentation, with clear communication about updates.

Integration with Current Domain and URL Structure​

To maintain consistency with the existing site structure, here’s how the new documentation could be integrated:

  • Subdomain Approach: Use a separate subdomain like https://docs.85a.uk/.
  • Linking and Navigation: Add links to the new documentation in the main site’s navigation or footer and include links from the forum and existing tech docs. If replacing the existing docs, consider 301 redirects for continuity.
  • URL Redirection: Set up 301 redirects from the old tech docs (https://85a.uk/templot/companion/) to the new documentation pages.

Risks and Mitigation​

  1. Community Contribution Challenges:
    • Risk: Inconsistent contributions or contributions that don’t align with the desired quality or style.
    • Mitigation: Implement clear guidelines and a review process to ensure consistency.
  2. Disruption During Transition:
    • Risk: Temporary confusion for users accustomed to the existing documentation format.
    • Mitigation: Communicate the transition plan clearly to users, including a timeline and FAQ section. Consider maintaining both old and new documentation side by side for a short period.

Pilot Programme Details​

To ensure a smooth transition and gather valuable feedback, I propose starting with a pilot programme:

  • Pilot Scope: Begin with a specific section of the documentation, such as "Creating and Managing Turnouts," to implement the ASD 1000 structure and STE 100 guidelines.
  • Timeline: The pilot programme will run for 4 weeks, during which I will collect feedback and make adjustments.
  • Feedback Loop: Set up a feedback mechanism, such as a forum thread or a feedback form linked within the pilot documentation.

Conclusion and Vision​

This proposal aims to create a more sustainable, user-friendly, and collaborative documentation environment for Templot5. By implementing the ASD 1000 structure, STE 100 language simplifications, and migrating to an open-source platform, I can ensure the documentation remains a valuable resource.

A separate repository will allow the documentation to be managed more effectively, encourage community contributions, and maintain a clear and organised structure. Hosting on a custom subdomain via Vercel will provide a reliable, cost-effective solution. Ultimately, this will free up your time to focus on innovation while the community helps maintain and grow the documentation.

Vision: My vision is for Templot5’s documentation to become a model of clarity and accessibility. With a strong foundation, I can continue to build on it, perhaps even exploring multi-language support or integrating interactive tutorials.

Moving Forward​

If this approach sounds good to you, I’d be happy to start with a pilot section of the documentation. I’m confident this strategy will make the documentation more manageable and allow you to get back to what you do best—innovating and pushing Templot5 forward.

Thanks for considering this, Martin. I’m looking forward to hearing your thoughts and working together on this exciting new phase.

About Me​

I’m an accredited Engineering Manager with extensive experience in managing and delivering technical documentation for complex platforms. My career includes work on high-profile Category A projects, where I was responsible for ensuring the successful delivery of comprehensive technical documentation. This experience has given me a deep understanding of the importance of clear, structured, and well-maintained documentation.

I’m familiar with the principles of through-life support for technical documentation and have a strong sense of what “good” looks like. My goal is to apply these best practices to the Templot5 documentation, ensuring it is accurate, user-friendly, and sustainable.

Best regards,

Richard

<sup>1</sup> ASD 1000: Guidelines for standardising technical documentation, used primarily in aerospace and defence industries, aiming to reduce ambiguity and complexity.

<sup>2</sup> STE 100: A specification for writing clear, concise, and unambiguous text, simplifying language for better accessibility.
 
_______________
message ref: 12881
Last edited:
@Richardb @James Walters @Alistair Ward @Steve_Cornford

Hi Richard,

Many thanks for taking the trouble to make such a detailed post, and especially for your offer to take on the Templot docs. It's a lot to take in, but my first two thoughts are:

1. I've been the sole suspect in the "Templot Affair" for 45 years now. As evidence for the prosecution, see:

https://85a.uk/templot/club/index.php?posts/11760 :)

It's time for me to take a back seat and let others do the driving. I still enjoy the program development and experimenting, but the endless task of supporting and explaining Templot is getting too much for me. Any offer of help with that is very welcome. Thank you.

2. Over the years, I've seen several new members arrive in Templot Club, propose all sorts of changes and improvements, and then after a few weeks never be heard from again. I'm not suggesting that you are one such -- you have already put in a significant effort to prepare and explain your proposal -- but you can perhaps understand my initial wariness.



Just to be clear -- am I reading too much into your post, or are you really offering to take on the entire task of providing the docs and user guides for Templot? And re-writing much of the existing documentation in more accessible language? Even with contributions from others that's a massive task if you mean all 3 areas of the subject:

1. the traditional use of Templot for track design and planning. The basics haven't changed much for years, but there are always new users who don't know what they are. And existing users who have never explored the full track design functions. This area also includes a lot of explaining about UK prototype railway track, which is a largely unknown subject to many modellers.

2. the recent developments of plug track, 3D printing and laser cutting. Writing the docs for that is a moving target as I keep making changes to the still experimental project. Quite a few users have jumped ahead into using it, before the experiment has actually concluded. :)

3. documenting the Templot program code for new contributors to the open-source project Templot5. No such docs exist at present, beyond the comments in the code.

I shall need to read your proposal a few times to take in all the technical details. I'm puzzled why it needs a sub-domain which would mean buying an additional https certificate. I'm happy to create a folder such as https://85a.uk/templot/docs and provide you with ftp access.

If it does need a distinct domain, you could have the use of https://85a.co.uk That already has an https certificate, and isn't currently being used for much apart from some of my email.



You are offering to prepare a pilot project to demonstrate your proposal, and my only response to that can be Yes please! I'm eager to see what you are proposing. Likewise I imagine several other members here -- the docs for Templot have always been its weak spot.

By the way, the Companion pages are prepared using https://helpandmanual.com I can export them in several other formats, such as PDF or Word docs, if that would help.

cheers,

Martin.
 
_______________
message ref: 12883
Hi Martin,

I understand your hesitancy, especially since I’ve come forward with this proposal as a new user. I’ve been exploring Templot and, from my perspective, there are several ways the documentation could be improved. Using my background and the opportunity to develop my skills, I’m committed to bringing the documentation up to speed.

I can see that there are two main areas where I can contribute: auditing, updating, and creating Templot Companion docs (which guide customers on how to use the software) and developing the Templot5 docs for onboarding contributors to the codebase. With Templot Companion, I’ll focus on auditing, updating, and creating documentation, particularly for experimental features, while also tying in contributions like James' excellent work. I’ll use the Sphinx Read the Docs theme for the styling, which will look similar to the software you mentioned, ensuring a clean and professional presentation. Concurrently, I can get brought up to speed with the Templot5 docs. While programming in Pascal isn’t currently within my expertise, I’m more than willing to learn, and I’m confident that together we can devise a way to create useful and accessible documentation for programmers.

The ASD format we discussed will be especially beneficial because it separates valuable reference data, like information on the UK prototype, from procedural guides, while still tying them together cohesively. I originally had a lot more detail in the proposal, but I had to condense it due to character limits. Ultimately, I think the best way to get the documentation up to spec is to open-source it, similar to Templot5, which will make it easier for contributors, programmers, and user feedback to be integrated effectively.

Sphinx is ideal for this project because it integrates well with GitHub, making it easy for the community to contribute and collaborate on the documentation.

For the pilot project, I can create a sample of the documentation so you can see the format and understand how the repository is managed. This will help ensure that the structure and workflow make sense and align with your vision. After that, we can explore hosting options and determine the best solution for the project. I appreciate your offer to assist with FTP access, and I’m sure we can find the most efficient way to manage everything.

Best regards,

Richard

PS I've already started on scaffolding :)

1725206560790.png
 
_______________
message ref: 12884
Last edited:
Hi Martin,
Can I suggest that Templot5 Documentation have it's own topic?

For REA chairs we are printing  screw heads rather than bolt  beads.
When we come to printing some other family of chairs, some chairs might require bolt heads.
I assume there is an appreciable visual difference between the two heads that is worth representing?

Chair Labels
can I assume that we will use the same chair labels across different chair families?

eg As far as Plugtrack is concerned we can use the chair label  S1 for both REA and GWR chair families?


Steve
 
_______________
message ref: 12885
Hi Martin,
Can I suggest that Templot5 Documentation have it's own topic?

For REA chairs we are printing  screw heads rather than bolt  beads.
When we come to printing some other family of chairs, some chairs might require bolt heads.
I assume there is an appreciable visual difference between the two heads that is worth representing?

Chair Labels
can I assume that we will use the same chair labels across different chair families?

eg As far as Plugtrack is concerned we can use the chair label  S1 for both REA and GWR chair families?


Steve
@Steve_Cornford

Hi Steve,

I don't know of any chairs which have bolt heads showing. On plain track the GWR used chair bolts, but they were inserted from below with the nuts on top. For pointwork they used square-head coach screws, like this:


index.php



As you say, there is a significant visual difference from the much more prominent REA chair screws. The reason is that REA uses a tapered ferrule in a tapered hole as-cast. GWR uses a parallel hole with a close-fitting bolt or screw.

On many pre-grouping chairs there were what modellers call 4-bolts, which were actually 2 chair screws, and 2 dome-headed spikes in tapered treenails:


treenail_spike.png



All these things we shall attempt to represent in plug track. In 4mm scale the differences will hardly notice, although they may do in 7mm scale and above.

In the code I have used the generic terms "bolt boss" and "bolt head" to describe all these fixings regardless of type. Although I rather wish I hadn't now that other folks are going to be looking at the code and potentially getting confused. What actually gets generated as a "bolt boss" or a "bolt head" will depend on the chair type code number.


On the GWR, S1 chairs are called Ordinary:


index.php



I don't yet know what names we shall be using for non-REA chairs. We may have to invent something. :)

cheers,

Martin.
 
_______________
message ref: 12889
Sorry I meant nuts

Looking at some of the available turnout plans that I have access to(Exactoscale, Scalefour etc,) they all seem to use S1 as a generic label & I think modellers accept this as a label.
So I propose for now that whether it is an REA S1, or a GWR 2-bolt ordinary, or a SR S1, or LNER S1, it would be ok to use S1 as a chair label, as opposed to a chair name (or description)

I think a GWR modeller would be only too pleased to be able to produce your 🥚cellent PlugTrack with GWR chairs, that they would not mind if the printout referred to them as S1, L1, M1, CCL, CC, CCR, P etc etc.

Steve
 
_______________
message ref: 12894
@Steve_Cornford @James Walters

Hi Steve,

That's great. Let's do it. (y)

What do you need from me?

In my mind I had a system where different prototype chair "families" might be loaded in some way from library files. If we had say an expert on Midland Railway chairs they might be able to create such a library data file in a text format which Templot could read in. James was already trying something along these lines for chair horizontal sections from CAD. Would that idea fit with this data dictionary?

cheers,

Martin.
Hi Martin & Steve,

I paused drawing the horizontally sliced chairs because:
a. Martin said to, as he was focussing on T5, and
b. I got fat and lazy on the buttons Steve kindly sent me.

But I'm keen to pick that ball up again, perhaps after Scaleforum. Last week I picked up an SE&CR chair in a junk shop. It was acutally a model shop, but it was full of junk. :) I'm keen to get it measured and sliced.

In the interim, perhaps you both might be able to give what Steve is suggesting here some thought such that I can supply exactly what you need to integrate into the process easily.

Best,

James
1725217574673.png

1725217604167.png
 
_______________
message ref: 12898
@James Walters

Hi James,

That's interesting -- a 3-screw chair but with the 1-screw and 2-screw ends swapped over, compared with REA.

I really need to leave all the chair stuff until after we have got T5 released. In any event, nothing more can be done on chairs until I have re-written a whole chunk of code to create 8-sided chair outlines.

Today I've been trying to improve the Cura profiles for the Neptune 4. The supplied profiles from Elegoo over-extrude the first layer to such an extent that it causes ripples in the layer surface. Which the nozzle then hits when doing the second layer, creating a lot of vibration and noise -- and potentially wearing down (up?) the nozzle tip. Fixing it without losing grip on the bed is proving tricky -- I now have a nice pile of failed prints on the bench. Everything is taking so much time, I don't seem able to keep up with everyone else.

cheers,

Martin.
 
_______________
message ref: 12899
Hi Guys re below
I think a GWR modeller would be only too pleased to be able to produce your 🥚cellent PlugTrack with GWR chairs, that they would not mind if the printout referred to them as S1, L1, M1, CCL, CC, CCR, P etc etc.
I agree with Steve, I think we should use the current Templot individual chairs names as a standard.IE S1 P CC, AA BB CC etc.
Not sure if this is doable but would it be possible to create a standard type label which then appears somewhere in the template?, So currently as we only have REA that would be the standard label, created for each template, with simply have each type of chair labeled as your currently working on and then some unobtrusive the type label for REA would appear somewhere in the template..

inversely when there avaible other type of chairs such as GWR would appear as the label. The trigger for which type of label could be generated by having each type of the chairs in there own sub group, so one of your first check buttons becomes which type of chairs your selecting to use. When construction a template.
Just a thought anyway.
cheers
Phil,
 
_______________
message ref: 12904
Hi Guys re below

I agree with Steve, I think we should use the current Templot individual chairs names as a standard.IE S1 P CC, AA BB CC etc.
Not sure if this is doable but would it be possible to create a standard type label which then appears somewhere in the template?, So currently as we only have REA that would be the standard label, created for each template, with simply have each type of chair labeled as your currently working on and then some unobtrusive the type label for REA would appear somewhere in the template..

inversely when there avaible other type of chairs such as GWR would appear as the label. The trigger for which type of label could be generated by having each type of the chairs in there own sub group, so one of your first check buttons becomes which type of chairs your selecting to use. When construction a template.
Just a thought anyway.
cheers
Phil,
@Phil G

Hi Phil,

Something like this? Showing on the chair heaving form. Clicking a chair label shows the form and highlights the chair clicked:


chair_family.png


(At present those labels show REA, I changed them to GWR just for this screenshot.)

It will be possible to mix chairs from different "families" on the same timber (modelling joint lines or heritage railways).

But none of this yet. Please. Let's get one thing done at a time. First Templot5, then slab & bracket, then K-crossing chairs (REA). If you want Pandrol clips by teatime it will have to be someone else doing them. :)

cheers,

Martin.
 
_______________
message ref: 12905
Back
Top