Templot5 - progress discussions

[Stephen Freeman]

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
View attachment 10986
View attachment 10987

Exactoscale have for some time produced an LSWR chair in 4mm which are also the opposite of the standard REA chair, there are also some minor differences as well.

 

[Martin Wynne]

Thanks Martin,

You have answered my next question before I've even asked it!

Steve

@Steve_Cornford

Hi Steve,

As things stand at present, to set all the chairs on a template to a specific prototype:

To change an individual chair, click the prototype label. A combo appears on the right, after which you can select the required chair type in the change chair combo:

As far as the program is concerned, all chairs are treated the same. They just have a different chair type code:

REA chair codes 1..99
GWR chair codes 101..199
LSWR chair codes 201..299
etc.

with corresponding codes for each type of chair in each range.

However, none of this is working yet, and it won't be for quite a while. We need the chairs before we can decide what to do with them. And it might all change to something else. Most things do in the end -- I'm just about to change the timber thickness default.

cheers,

Martin.

 

[Phil G]

Hi Martin,
May I request at some time in the future LNWR chairs are also an option?
cheers
Phil

 

[KHC1]

Could you leave the chair names as you have them and then show a bracket after the name. So S1j(RE) or s1j(GW) etc.
Just a thought getting my hat and coat.

Keith

 

[Martin Wynne]

May I request at some time in the future LNWR chairs are also an option?

Of course -- the screenshot is just a dummy trial. You can have whatever prototype chairs someone provides the data for.

Within the limits of an 8-sided outline with 4 radiused corners. We can't do elegant S-shaped chairs with a flagpole at each end.

Martin.

 

[Martin Wynne]

Could you leave the chair names as you have them and then show a bracket after the name. So S1j(RE) or s1j(GW) etc.
Just a thought getting my hat and coat.

Hi Keith,

We can do anything when the time comes. But that's not a good idea because you wouldn't know whether clicking it changes the type of chair or the prototype.

cheers,

Martin.

 

[Steve_Cornford]

So basically REA family chair code modifier = 0
GWR family chair code modifier = +100
LSWR family chair code modifier = +200 etc

I am in process of knocking up an example of using tables(records) to define:-
a) cf_chair_family // table of chair families
b) ct_chair_type // table of chair types
c) pc_prototype_chair // table of prototype chair dimensions in inches (for a combination of cf_family & ct_code

I got stuck when I got as far as your (chair) code 10 to 13, & comparing chair labels of the Scalefour "P4 C10" diagram (supplied by C&L finescale) and the LMS REA drawings in Templot Club resources...

They refer to 1PL, 2PL, 3PL, 4PL, 5PL (& 1PR, 2PR, 3PR, 4PR, 5PR) etc
whereas in Templot5 the chair labels displayed are [1P..2P], [1P..2P], [3P..11P], [3P..11P], [3P..11P]

and in your chair code table code 10 to 13 are really components of these chairs.

So I am barking up the wrong tree with your code table :-

This is all very interesting stuff, and hopefully I will get to understand more about the inner workings
Steve
edited for typo

 

[Martin Wynne]

So I am barking up the wrong tree with your code table :-

@Steve_Cornford

Steve, that list isn't up to date. You may remember that at one stage I tried having separate half-chairs where there is more than one rail in a chair. This makes assembly easier for solid-jaw chairs but isn't needed for loose-jaw chairs. That list dates from that time and hasn't been updated, sorry.

Going to open-source was decided only a couple of months ago and was all done in a bit of a rush. Ideally I should have gone through all the files and made sure all the comments are up to date and consistent -- but that would have delayed it for weeks. The thing about an experiment is that things are constantly being changed, tried, discarded, resurrected, as I go along. Making sure every past comment is consistent with the latest code is almost impossible.

For up-to-date info about anything, refer to the actual code:

function get_chair_str(chair_code:integer):string;        // 243b

var
  chair_str:string;

begin
  chair_str:='';  // init

  case chair_code of

     -2: chair_str:=' ';    // space, was omitted chair
     -1: chair_str:='none';
      0: chair_str:='';     // invalid
      1: chair_str:='S1';
      2: chair_str:='P';
      3: chair_str:='L1CC';
      4: chair_str:='none';
      5: chair_str:='L1';
      6: chair_str:='M1';
      7: chair_str:='S1J';
      8: chair_str:='S1O';
      9: chair_str:='S1N';
      10: chair_str:='SC';
      11: chair_str:='1P..2P';
      12: chair_str:='3P..11P';
      13: chair_str:='none';
      14: chair_str:='CCL/R';
      15: chair_str:='CC';
      16: chair_str:='CCR/L';
      17: chair_str:='SS';
      18: chair_str:='MS';
      19: chair_str:='L1CCL/R';
      20: chair_str:='L1CCR/L';
      21: chair_str:='ZY';
      22: chair_str:='XN';
      23: chair_str:='XA';
      24: chair_str:='AA';
      25: chair_str:='AB';
      26: chair_str:='BB/BC';
      27: chair_str:='CD/DD';
      28: chair_str:='EF';
  29..39: chair_str:='none';
      40: chair_str:='SDP';
      41: chair_str:='SDS';
  42..49: chair_str:='none';
      50: chair_str:='PW';
      51: chair_str:='PWL';
      52: chair_str:='PWR';
  53..97: chair_str:='none';
      98: chair_str:='FG'; //dummy chair  rail foot groove
      99: chair_str:='RG'; //dummy chair  rail head groove

    else chair_str:='none';

  end;//case

  RESULT:=chair_str;
end;
//______________________________________________________________________________

It will all make sense one day, but I need time.

cheers,

Martin.

 

[Martin Wynne]

So basically REA family chair code modifier = 0
GWR family chair code modifier = +100
LSWR family chair code modifier = +200 etc

I am in process of knocking up an example of using tables(records) to define:-
a) cf_chair_family // table of chair families
b) ct_chair_type // table of chair types
c) pc_prototype_chair // table of prototype chair dimensions in inches (for a combination of cf_family & ct_code

@Steve_Cornford

Hi Steve,

To get what you want from the chair_code you could use:

chair_proto_code:=Trunc(chair_code/100);      // returns 0, 1, 2 ...   can be used to set the chair-prototype combo ItemIndex

chair_type_code:=Round(Frac(chair_code/100)*100);  // returns 0..99    can be used to set the change-chair-to combo ItemIndex

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin et al,
Chair family

Chair Types

Prototype Chair dimensions

with silly example of James SECR chair (assuming it is an S1 and the same size as an REA but with bolt holes mirrored)

obviously I have not created all the fields yet, but just to show these as an example.

Templot5+ could look this table up (perhaps a memory database for speed) then use the pc_fields to calculate the scaled fields for a chair.

Steve

 

[Martin Wynne]

Templot5+ could look this table up (perhaps a memory database for speed) then use the pc_fields to calculate the scaled fields for a chair.

@Steve_Cornford

Thanks Steve.

So presumably when setting up the chairing_dims records:

Instead of

               with L1_chairing_dims do begin  // init ..

                  chair_code:=5;

                  chair_outlong:=L1_chair_outlong*inscale;
                  chair_inlong:=L1_chair_inlong*inscale;
                  chair_halfwide:=L1_chair_halfwide*inscale;

                  chair_mid_halfwide_near:=0;
                  chair_mid_halfwide_far:=0;

                  inbolt_1x:=L1_inbolt_1x*inscale;
                  inbolt_2x:=L1_inbolt_2x*inscale;

                  outbolt_1x:=L1_outbolt_1x*inscale;
                  outbolt_2x:=L1_outbolt_2x*inscale;

                  bolts_from_end:=L1_bolts_from_end*inscale;

                  crad_inner:=L1_chair_crad_inner*inscale;
                  crad_outer:=L1_chair_crad_outer*inscale;

               end;//with

we would now have something like

             function get_steves_table:Tsteves_table;

             begin
                RESULT.valid:=False;   // init

                 ...  read table for chair code and fill RESULT;

               RESULT.valid:=True;
             end;
             //=================================




     with L1_chairing_dims do begin  // init ..

       chair_code:=5;

       steves_table:=get_steves_table;

       if steves_table.valid=True
          then begin
                    chair_outlong:=steves_table.chair_outlong*inscale;
                    chair_inlong:=steves_table.chair_inlong*inscale;

                      ... ...
                      ... ...
                end;

     end;//with

Where would the table be? An XML file perhaps? Or possibly a text file on GitHub which anyone could edit and post pull requests for?

I think I might be missing something -- what is an .ods file?

cheers,

Martin.

 

[Martin Wynne]

p.s.

or

chair_code:=(chair_proto*100)+5;

or

function get_steves_table(chair_proto:integer):Tsteves_table;

Martin.

 

[Steve_Cornford]

Hi Martin,
Answers in reverse order

what is an .ods file?

.ods is a LibreOffice file (equivalent to Microsoft .xls or .xlsx)
I just used LibreOffice to knock up a spreadsheet containing 3 sheets, 1 for each table.
I am not proposing that we use this in the Templot5+ world.

Where would the table be? An XML file perhaps? Or possibly a text file on GitHub which anyone could edit and post pull requests for?

The tables could be held in a proper relational database, but I am still researching these, and the phrase "relational database" might scare some people.

Each table could be held in a separate file. Possible file formats are .XML or a CSV type of .txt file.

Indeed in https://www.freepascal.org/~michael/articles/startlaz7/startlaz7.pdf there is an example of a CSV type of text file in:-

10 Adding some structure: CSV data

There is also a description of the TMemDataset in :-

9 The simplest dataset: an In-Memory dataset

I envisage that we could provide a set of CSV files with Templot5+.
At the startup of Templot5+ (or do I mean Trackpad5+) we could read in the CSV files and for each one create a TMemDataset (for speed of access).
Templot5+ would have a new sub-menu entry on Trackpad utils menu, perhaps called Chair Themes
This would invoke the chair_themes unit, which would provide a process of maintaining any tables (files) related to chair themes.
The chair_themes form could perhaps contain a TpageControl with separate tabs for ;-
Chair Family, Chair Type, Prototype Chair
On exit from Chair Themes (or in lazarus speak OnClose?) confirmation would be sought to save changes.
If affirmative, then the CSV files would be updated, and the relevant TMemDataset table would be refreshed.

Think of the CSV files as the stored environment, whereas the TMemdataset tables are the encoded environment.

At present you have a lot of what are in essence repeated copies of the same set of field names but with different prefixes.
eg S1_, L1_, etc

The idea is that these are replaced with just one set prefixed pc_

Then for a particular family and code (chair code) the relevant record could be retrieved speedily from the pc_prototype_chair TMemdataset and read into the fields prefixed pc_

Then instead of having code that is repeated for each type of chair, you can have a common bit of code such as in math_unit:-

inbolt_1x:=pc_inbolt_1x*inscale;
inbolt_2x:=pc_inbolt_2x*inscale;

This means that when you add yet more chair parameters (for instance for 8 sided chairs), you only have to add the parameter to the file definition, and only once in math_unit, rather than once for every chair type that needs it.

Steve

 

[Martin Wynne]

At present you have a lot of what are in essence repeated copies of the same set of field names but with different prefixes.
eg S1_, L1_, etc

The idea is that these are replaced with just one set prefixed pc_

@Steve_Cornford

Hi Steve,

That might not work without more work, there are several places where some of the dimensions are referenced directly, for example:

// see if L1 bridge chairs needed instead...

if ( (timb_str='T') and (tbn>(csi.num_block_slide_chairs_in_T+csi.num_block_heel_chairs_in_T)) )
or ( (timb_str='S') and (csi.num_slide_chairs>0)
and ((csi.num_block_slide_chairs_in_T+csi.num_block_heel_chairs_in_T)=0)
and (tbn>(csi.num_slide_chairs+csi.num_block_slide_chairs+csi.num_block_heel_chairs)) )

then begin
// 1. calc space available on the turnout rail at switch heel (main rail has priority for ordinary chairs)

chair_space_y:=aq3offset(xtimbcl-S1_chair_halfwide*inscale,dummy_k)-g; // calc for turnout side

if chair_space_y<(L1_chair_outlong*inscale+L1_chair_inlong*inscale+inscale/4) // less than 1/4" between them
then begin //EXIT; // temp even bridge chairs conflict - needs M1 or bolted half-chairs.

heel_lengthx:=xtimbcl+9*inscale; // temp 9" beyond last heel block chair 243a

... ...

and more similar elsewhere. The above will need to reference the current chair family. There might even be cases where an REA chair won't fit but a MR chair, say, would do. The above code could maybe try all of them. There's a lot to think about.

The code does need a lot of tidying up because it developed piecemeal over several years, but it's not always obvious.

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,

I envisage the set of CSV files would exist in \TEMPLOT5-OUTPUT\CSV-FILES folder perhaps, also in GitHub.

Also I forgot to mention the possibility of:-

cl_chair_layers table to hold as many chair layer information ( eg as provided by James?)

cj_chair-jaws table if it was possible to define a nunber of jaw types, then add one or more jaw_type fields to pc_prototype_chair table.

ALSO

rt_rail_type table etc.

The possibilities are endless....

Steve

 

[Steve_Cornford]

Hi Martin,

There are always exception to the rule, but using the pc_prototype_chair table doesn't preclude also having the odd S1_ or L1_ prefixed variables, it will just be necessary to populate them by reading in the relevant pc_ field first (or even directly referencing pc_chair_outlong

 )

A lot to think about, but looking on the bright side, you do enjoy coding!

By the way, when researching this I came across this field that you have defined but not actually used yet:-
[ATTACH type="full" width="1133.5px"]11007[/ATTACH]

So I concluded that I do not yet need to have a pc_chair_jaw_halfwide column yet.

Steve

 

[Steve_Cornford]

dont know what happened there !
STeve

 

[Steve_Cornford]

Hi Martin,
You have recently posted a provisional sketch of your 8 sided chair thoughts.
Do you by any chance have an equivalent one for the existing 4 sided chair design that annotates the various chair parameters such as chair_inlong, chair_outlong, etc?
Steve

 

[Martin Wynne]

Hi Martin,
You have recently posted a provisional sketch of your 8 sided chair thoughts.
Do you by any chance have an equivalent one for the existing 4 sided chair design that annotates the various chair parameters such as chair_inlong, chair_outlong, etc?
Steve

@Steve_Cornford

Hi Steve,

I'd like to say that I have beautiful drawings of all the Templot designs. But sadly I don't. I have only rough sketches, some of them very rough and coffee stained over the years. Here's the original sketch for the S1 chair base outline -- now 7 years old I see. Corner rads are at 15deg steps -- I wish now that I had made them finer, and I will do when I re-write this for 8 sides.

All the chair data is dimensioned from the rail gauge-face and the chair centre-line. The sketch is nowhere near to being to scale:

cheers,

Martin.

 

[Steve_Cornford]

Thank you Martin, wonderful to see the sketch that started you on this path.

PlugTrack has evolved quickly over the last 5 years, just think how long nature takes!

Steve

 

[Martin Wynne]

@Phil O

Looking again at this GWR drawing:

I mentioned previously that it is showing the GWR 00 chair with unequal corner radii -- 1/2" radius on the inner end and 1" radius on the outer end. I can't think of any explanation for that, and I believe now that it is a drawing error -- I think these GWR 00 chairs have a 1/2" corner radius all round. Comparing the two chairs above and roughly scaling the drawings, the GWR 00 outer corners are clearly drawn as 1/2" radius all round.

Can anyone confirm that?

The snag with assuming an error is that all the other 00 chair drawings on the same sheet are showing the same error, if it is an error. And looking at Phil's photos of GWR crossing chairs, see:

https://85a.uk/templot/club/index.php?resources/gwr-switch-and-crossing-chairs-photos.13/

shows most of them with much larger corner radii.

Assuming a prototype drawing error in model-making can lead to so much grief on the forums that I dare not think about it.

Martin.

 

[Steve_Cornford]

Hi Martin,
Also looking at the drawing:-
BS95R ord'y chair length 14.5", inbolt/outbolt separation 11", gives inbolt & outbolt y value of 3.5"/2 = 1.75" from end of chair
OO ord'y chair length 15.5", inbolt/outbolt separation 12", gives inbolt & outbolt y value of 3.5"/2 = 1.75" from end of chair

In your chair_unit, all the _bolts_from_end variables are set to 1.75", which I thought was interesting.
I was thinking the "bolts_from_end" should be a family attribute rather that a prototype chair attribute?

We need a source of some SECR, LSWR, MR, LNWR chair drawings.

I have found some SECR & LSWR & SR darwings in Southern Times, but facsimile is rather poor.
Steve

 

[Martin Wynne]

In your chair_unit, all the _bolts_from_end variables are set to 1.75", which I thought was interesting.
I was thinking the "bolts_from_end" should be a family attribute rather that a prototype chair attribute?

@Steve_Cornford

Hi Steve,

Yes. Every single variable in the present program will need to be prefixed REA_ before we can start creating the same all over again for other prototypes. I really haven't made any preparations whatsoever for other prototypes, which is why I keep telling GWR and FB modellers not to hold their breath, and that there is still a long way to go.

I do want to get the full range of REA chairs finished before looking at other prototypes. Otherwise I fear a great muddle coming on the horizon. Folks are still waiting for tandem turnouts, slips, double junctions and all the rest. Just getting all that done in REA, and all the chair heaving and SC customizing needed will be a massive task. And then there will be all the explanations and videos about it needed. At least after 2 days on the Neptune I now have a profile which I'm happy with, but it all seems never-ending.

To keep the GWR modellers quiet in the short-term, we might be able to produce the Paddington 2-bolt version of the BS-95R REA S1 chairs:

It needs a 1-bolt version of the S1 inner jaw (i.e. 2 ribs) and the screw-boss and head swapped to a smaller nut-on-top pattern. The chair base and loose outer jaw can be the same as REA. That might be doable in the short-term, although strictly it is only for wartime and BR(W) prototypes. I do have a full-size one here, which should help.

cheers,

Martin.

 

[Stephen Freeman]

Hi Martin,
Also looking at the drawing:-
BS95R ord'y chair length 14.5", inbolt/outbolt separation 11", gives inbolt & outbolt y value of 3.5"/2 = 1.75" from end of chair
OO ord'y chair length 15.5", inbolt/outbolt separation 12", gives inbolt & outbolt y value of 3.5"/2 = 1.75" from end of chair

In your chair_unit, all the _bolts_from_end variables are set to 1.75", which I thought was interesting.
I was thinking the "bolts_from_end" should be a family attribute rather that a prototype chair attribute?

We need a source of some SECR, LSWR, MR, LNWR chair drawings.

I have found some SECR & LSWR & SR darwings in Southern Times, but facsimile is rather poor.
Steve

Midland Railway Society produce a mighty tome on everything you need to know about the chairs and track in general (I do not own acopy nor am I a member, I did have the loan of a copy from a customer some years ago, so I made best use of it). If I remember correctly the book is in A3 format. I may have something on LSWR etc not sure.

 

[Steve_Cornford]

Hi Martin,

Progress report.
I have been experimenting with a lazarus package called ZMSQL.

It provides facility of importing from a .CSV file, and creating a memory dataset , also saving to a .CSV (and being able to select the field seperator)

So far just edited one of the demo projects supplied with ZMSQL, so it is compiled with different windows settings from Templot5.

I have not added this into Templot5 yet, as I am still getting my head around the principles.

Upon initial load i get:-

If I click the [load from CSV] button it assumes the ZMSQL database is held in \..\Themes folder, and is looking for tablename pc (meaning a table called pc held in pc.csv), and gives me:-

When I click ok, I get:-

You can navigate the records with the green buttons.
You can insert a record using the + button.
[Save changes] button saves back to the existing pc.csv file
[Save to New.CSV] saves to new.csv using the selected field delimiter

This is just a test form based on the demo example provided, but with field names more relevant.

I need to develop this and provide for the loading saving of tables :-
cf.csv (table of chair family records, tablename:=cf)
ct.csv (table of chair type records, tablename:=ct)

ZMSQL provides a means of defining a master/servant relationship

table pc is a servant of both cf (linked by field family) and ct (linked by field code).


Steve

 

[Steve_Cornford]

Hi Martin,

Every single variable in the present program will need to be prefixed REA_

If I can make progress on the idea of storing families, chair types & prototype chair information in easily maintainable tables you probaly wont need to prefix variables with REA let alone S1_, L1_ etc

Steve

 

[Martin Wynne]

Hi Martin,


If I can make progress on the idea of storing families, chair types & prototype chair information in easily maintainable tables you probaly wont need to prefix variables with REA let alone S1_, L1_ etc

Steve

@Steve_Cornford

Hi Steve,

That could all be done directly in Lazarus using classes and record types, and loading/saving to/from XML. Which I'm familiar with and just need the time to do. But this database stuff is all new to me. I'm a bit concerned about the hit to response times if every screen re-calc requires data to be read from a file?

cheers,

Martin.

 

[Steve_Cornford]

Form editor view

I am not necessarily proposing using the TBDNavigator or TBDGrid controls in the end product, its just that is what the example project used.

Steve

 

[Phil O]

@Phil O

Looking again at this GWR drawing:

I mentioned previously that it is showing the GWR 00 chair with unequal corner radii -- 1/2" radius on the inner end and 1" radius on the outer end. I can't think of any explanation for that, and I believe now that it is a drawing error -- I think these GWR 00 chairs have a 1/2" corner radius all round. Comparing the two chairs above and roughly scaling the drawings, the GWR 00 outer corners are clearly drawn as 1/2" radius all round.

Can anyone confirm that?

The snag with assuming an error is that all the other 00 chair drawings on the same sheet are showing the same error, if it is an error. And looking at Phil's photos of GWR crossing chairs, see:

https://85a.uk/templot/club/index.php?resources/gwr-switch-and-crossing-chairs-photos.13/

shows most of them with much larger corner radii.

Assuming a prototype drawing error in model-making can lead to so much grief on the forums that I dare not think about it.

Martin.

Hi Martin,

I no longer visit Cranmore and all of the permanent way gang that I have worked with have retired from chucking lumps of cast iron and steel about. I didn't think about photographing the bog standard chairs as they were plentiful.

If I remember and think about it I will have a look at what's still in the loop at Keyham station. Or you have a visit to the SVR on one of your out and about trips, there may still be a few 00 panels of track about, there is/was on the ESR, but you wouldn't know it, if it wasn't on the chairs.

I would just stick with the 95R.

 

[Steve_Cornford]

Hi Martin,
XML is verbose & not human friendly (IMHO), but we could use that format if you wish.

To be honest the actual format of the stored data is not that important, as we would read these tables into a memory dataset (array) and access them from there.


You will not have to read from file, the files hold the tables, but these are read into a memory data set, which i believe will not impinge on response times.

Start of session
for each table, copy from file into a memory data set.

during session
for a given chair eg L1 in family REA
select all fields from pc where family = rea, code = 1

the memory data set is just another type of array, held in memory.

I know there will be exceptions where you need to refer to a parameter of another chair type, but I believe there is a solution to these exceptions.

Once I have developed the idea further I hope to be able to explain it all better!

I believe it has the possibility of saving you a lot of repetative typing (in the future)


Steve

 

[Martin Wynne]

@Steve_Cornford

Hi Steve,

It's not too difficult to write a utility to read a text file and create an XML file. We have the XML engine already.

Your tables are showing only 2D data. For the 3D chair jaws and sections, how does your system cope with large arrays of floats?

In my mind I can imagine doing everything within Lazarus arrays, I don't know why we need a database engine in the mix. For example

inbolt_x:=chair_data[proto_code][chair_code].inbolt_x;

with the arrays filled on startup by reading an XML file.

However, at present I don't have the time or the energy to think about it, there is too much else to do. I will leave it to you to do whatever you think best. I must get Templot5 released and incorporated into a Templot2 update before Scaleforum, which is going to need all my time for the present.

It would be good however if GWR modellers could be offered at least a 2-bolt BS-95R S1 in the near future, I know for certain from past Scaleforum experience that James and John will be fielding the same question "what about GWR?" over and over again. It used to drive me nuts when I was selling the turnout kits and components. They won't rest without a joggle in the stock rail.

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,
I agree, we dont need a database engine in the mix, I was just using ZMSQL to quick build an example of something that we could add into :-
Trackpad > Utils > Maintain Themes >
> Chair Family
> Chair Type
> Prototype Chair Dimensions

However I do think that .CSV files are better for storing that sort of table where we have to store records, and are easily viewed outside of Templot5.

Your tables are showing only 2D data. For the 3D chair jaws and sections, how does your system cope with large arrays of floats?

I had to start somewhere with just a few fields. I think previously I proposed a layers table.
Some of the 3D data belong to chairs, I might propose a separate jaws table.
Also some of both the 2D and 3D data are attributes of family rather than the proto_chair table.

Lets pause discussionfor now to allow you to concentrate on Templot2 to Templot5 progression.

Just shout if there is anything any of us can do to help with this.

Steve

 

[Martin Wynne]

Just shout if there is anything any of us can do to help with this.

@Steve_Cornford

Hi Steve,

Thanks. The main help would be to take over all support and help replies here. I haven't managed any coding today, but I seem to have been on here all day. My eyes are watering from looking at the screen and I need a break for a bit.

A code change needed after my recent trials is to make the side tangs on the clip-fit plugs a bit narrower with more side space, so that they can be washed out behind more thoroughly. My mother was always telling me to wash behind my ears.

The water-washable resin is tougher and less resilient than IPA-washable, so it's important that they are washed out behind the tangs, otherwise they are a much tighter fit to install in the sockets. I think in addition to plunge washing in a bucket they need a few minutes swirl in the Mercury washer too, perhaps with a bit of IPA or meths added to the water. And that's as much as I can type for now.

Martin.

 

[Steve_Cornford]

The main help would be to take over all support and help replies here

I will attempt to respond, and hopefully others will as well.
Presumably you get alerted to any new posts on here, but I think I only get notified when it is a topic I have participated in.

A code change needed after my recent trials is to make the side tangs on the clip-fit plugs a bit narrower with more side space, so that they can be washed out behind more thoroughly. My mother was always telling me to wash behind my ears.

I assume that means adding some new parameters

Existing parameters

Steve

 

[Steve_Cornford]

or making some existing tang_ parameters user amendable....

Having now performed a find in files for tang_

Steve

 

[Martin Wynne]

I will attempt to respond, and hopefully others will as well.
Presumably you get alerted to any new posts on here, but I think I only get notified when it is a topic I have participated in.

@Steve_Cornford

Thanks Steve.

You can receive a notification for every post on here if you wish. You need to set up each forum section separately, which is a bit tedious. Click the Watch button at the upper right of each form section (not topic). More info about this at:

https://85a.uk/templot/archive/topics/topic_3839.php#p31676

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,
I have set watch by alert on some forums.

Steve

 

[Martin Wynne]

or making some existing tang_ parameters user amendable....

Having now performed a find in files for tang_

Steve

@Steve_Cornford

dxf_unit

line 680-ish

clip_tang_end_space:extended=5/16;  // 5/16" 244d  end space between tang base and tang housing

Needs more space, maybe 5/8" ? Or more? How does it look? Tangs on L1 already quite narrow.

Already in the XML. Not much point being there without an option somewhere to change it, so add it to one of the dialogs. This one?

procedure Tdxf_form.extend_plug_buttonClick(Sender: TObject);    // 241b

Not the logical place for it, but others are full. So change button to "modify tang" ?

Needs a max limit, wrong value entered would wreck the tang.

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,
For water washable resin chairs would a cheap ultrasonic cleaner help, with a water based cleaning fluid?

I definitely would not advocate using one with IPA for IPA washable resin chairs due to fire hazard.

Steve

 

[Martin Wynne]

For water washable resin chairs would a cheap ultrasonic cleaner help, with a water based cleaning fluid?

@Steve_Cornford

Hi Steve,

I don't have one, so I can't say. I do have a Mercury wash/cure unit. I had been using it for UV curing only with the water-washable resin, plunge-washing the chairs in a bucket of water. I'm now putting them in the Mercury swirl wash for 5 minutes after the plunge washing, with 50ml of IPA added to 2 litres of water (using your bracket again!). There is some slight clouding of the water, so it's worth doing. The IPA addition (or meths) also helps with faster drying. The Mercury tub could be used for the plunge washing too (as I used to do with IPA) without needing the bucket. But that means changing the tub water more often.

With the water-washable resin chairs, the clip-fit into the FDM sockets is much easier after swirl washing. Looking at some rafts which had plunge washing only, I can see that the chairs on the end of a raft are clear behind the tangs, but those in the middle of the raft are still clogged.

cheers,

Martin.