Plug34.dat and related parts discussion

[Javier Orquera]

Per Magnus suggestion, I open this thread and hope to clarify what I do:

This is the real life part 4110(?)/4707 and Flash Ligth Unit:

   
   
   

Essentially, the plugs have the same shape; and here is my proposal to the plugs:

"New" shape of plug34
   

m_plug
   

4707s02
   

990b
   

As you can see, I think it's "better" with this "new" shape of plug34.

For the remaining parts (u9018, u9019, u9134 and u9146), I reworked them all (based on BL images) and the result is:"

u9018
   
u9018s01
   
u9018s02
   
u9019
   
u9134
   
u9146
   
u9146s01
   

u9018s01 is used on all the parts; u9018s02 is used in u9018, u9019 and u9134 and u9146s01 in u9146.

Part 4353.dat: according to images from internet, I think it needed to be adapted to some of the above parts.

Finaly: if these goes as I planed, there is no problem on submiting the parts.

[Rene Rechthaler]

Why is the new plug version unrotated again? most plugs are wildly slanted (the slots)...
Also the rotated version was able to keep most parts of the outer shell as prims.
I would suggest to delete the bottom edges and faces of the latest version and make two adapters, one with these bottom edges and faces and one with the outer steps (like u9018s02) but made of prims.

Edit: made suggested versions (plug without bottom, plug bottom and wide bottom)
feel free to use, edit and comment...

[Rene Rechthaler]

Checked my parts: only the pin slots of plugs are aligned, pin slots of the bigger parts (switches and the light unit) are slanted...

So I made a new adapter with aligned slots:
   

at the top of the file are the connections (here coloured blue):
   

normally that ring face from pin to socket is chamfered, but there are no availiable prims for that.

[Magnus Forsberg]

a.)
If you remove the full cylinder, and have the bottom surface at the xy-plane, it will better as a scalable prim.

b.)
   

The edge prim you removed can't be in the edited file. It needs to be included in the metallic pin.
The edge prim will inherrit the colour of the part, and will not look correct for a user using the alternative colour file with coloured edges.
In my image there are red edges on the metallic pin.

[Javier Orquera]

a.)
If you remove the full cylinder, and have the bottom surface at the xy-plane, it will better as a scalable prim.

What about if I inline the cyli with edge (in the respective parts) and left the "plug", so it can achieve what you want?

[Rene Rechthaler]

made two more bottom adapters (based on ada):

with inner edgelines (for long pins) and outer edgelines (for short pins with flange).

made with 1-16 and 3-16 prims to be substitutable...

[Javier Orquera]

Hello: this is my latest "try" to do the files correct; don't know if my files can be submited but I hope it can, specialy plug34.dat

[Steffen]

thanks for posting a link to this thread at
https://library.ldraw.org/tracker/32619

I hope we can resolve the plug issues in a discussion here.

For me it is a no-go to have a plug primitive with slanted slots.
Imagine, we would have a rectangle primitive which would be slightly rotated and not positioned aligned with the grid axes.
That's a no-go.
The same goes for me for the plug primitive.
It needs to have its slots vertically and horizontally aligned with the coordinate grid.
As primitives can use higher precision than normal parts, there should not really be rounding errors,
because the plug just gets positioned in its parent parts 1:1 and is not scaled up or down.
Also, it would be used there again with vertical slots, so there should not be a rounding problem.

For this reason I like the solution posted now by Javier, where the slots are vertical again in plug34.

[Rene Rechthaler]

what about this? only the electric plugs have aligned slots.
   
ring adapter from rotated r3.5 (plug34) to unrotated r4
or just check my other adapters some posts above...

[Steffen]

no, I don't think we need an adapter.

just have plug34 with proper vertical slots and use it in parts.
that's it.

[Javier Orquera]

Per the question made by Steffen here https://library.ldraw.org/tracker/32703, I show a comparison between the real life plugs and my versions:


  electric pin 1_3.png (Size: 104.69 KB / Downloads: 438)       


  electric pin 2.png (Size: 55.14 KB / Downloads: 437)      

In blue is my s/u9018s01.dat, for u9019, u9134 and u9146. The subfile can be converted into a primitive: if converted, it needed to be changed both file name and description (this apply to my plug34.dat).
Also, the s/u9018s01.dat is used in my u9018.dat.

Any comment?

[Steffen]

thank you for this detailed info.
to me, this looks all good, and I think we should update plug34.dat so that it represents these plugs.
I suggest to create 2 variants:
- the existing plug34.dat used for the SHORTER plug
- create a NEW plug34b.dat for the LONGER plug

Note here that the slots are either rotated 0° or 45° but not 11.25°.

[Rene Rechthaler]

but what about the slanted one for the fixed non-plug parts?

[Willy Tschager]

I just read a good part of the discussion at the PT and here. I'm floored by the fact that so much energy and emotion is put into such a banal thing as a pin.

Could you please agree on this as fast as possible and fix Plug34 for all as it is holding up a lot of parts.

w.

[Javier Orquera]

Hello: attached is a pic of my version of 4707.dat (I also made changes to my 4110s01.dat to be used with this part).
May I submit my 4707.dat using my name as author or needed to kep the original author?
Also, needed to submit 4110.dat with changes.
Don't waste the time reworking the part 4707; I did it.

[Magnus Forsberg]

Hello: attached is a pic of my version of 4707.dat (I also made changes to my 4110s01.dat to be used with this part).
May I submit my 4707.dat using my name as author or needed to kep the original author?
Also, needed to submit 4110.dat with changes.
Don't waste the time reworking the part 4707; I did it.

No you may not.
Improvments are welcome but sinse this is an official part you must keep the original header and author.

Do you have a plan for the keys? As now, they are an unwanted duplication of official files.
https://library.ldraw.org/search/part?s=4112p

[Rene Rechthaler]

But the part itself looks very good...
Do the keys and the caps fit both versions?
maybe these can get inlined then.

[Javier Orquera]

No you may not.
Improvments are welcome but sinse this is an official part you must keep the original header and author.

Do you have a plan for the keys? As now, they are an unwanted duplication of official files.
https://library.ldraw.org/search/part?s=4112p

OK, I keep the header and autor.
As for the keys: they are diferent from each switch. So:

1. Part u9001.dat and u9002.dat need to be renumbered and, as my 4707 versión keeping header and author, send it with details; or delete both parts and submit with my name, since it correspond to part 4707.
   
2. Keep keys's authoring for part 4110 since it have not been created at the time.
   

[Rene Rechthaler]

for the keys, if it is confirmed that they are the same:
why dont we obsolete the old ones and use the new ones for both versions?
the cap was integrated in the old version, but should be a separate part in both versions.

[Javier Orquera]

The keys are not the same. First is for 4110, second is for 4707.

[Rene Rechthaler]

hm, similar enough to use a common subfile?
do the different switches (for points/levers/coupling/signals/arrows) have different keys (within the same generation)?
i guess the base is always the same...

[Javier Orquera]

hm, similar enough to use a common subfile?
do the different switches (for points/levers/coupling/signals/arrows) have different keys (within the same generation)?
i guess the base is always the same...

Main difference is in the bottom. Other than that, is just aestetical (to me).
My guess is the keys are the same within the generations.

[Javier Orquera]

Attached is an image of my 4707s01.dat. Since there is an official 4707s01, wath's the proccedure to follow?

[Magnus Forsberg]

Attached is an image of my 4707s01.dat. Since there is an official 4707s01, wath's the proccedure to follow?

As already stated above, you must keep the header and you are free to improve the geometry code.

[Javier Orquera]

Hello: I search in the internet the switches and find the following:

1. Remote Control with Switch Pattern, Signal Pattern and Level Crossing Pattern exist in both versions, old (part number 4110?) and new (part number 4707)
   
2. Remote Control with Decoupler Pattern exist only in old version
   
3. Remote Control with 2 Circled Arrows Pattern exist only in new version
   

Can someone confirm this?

Also, may I request the change to the switch's keys official numbers to the "true" numbers (according to the pics I find) or I am allowed to submit my versions with the correct numbers?

[Magnus Forsberg]

Ok, here is my attempt to understand this.

   

There are two sets of switches.  One older 4110, with a recessed socket for the pin on the left side, 
and one newer 4707 with a more flat design.

First question:  Is it correct that the two families contain only four switches each?
Quote:
Remote Control with Decoupler Pattern exist only in old version
Remote Control with 2 Circled Arrows Pattern exist only in new version
Or do we make 2 sets of 5 switches?

Second question:
We also have new information about the correct part numbers on the switches.
u9001 is 4709
u9002 is 4708
These files are official and need to have Move to-files made.
Is it possiblle to use the Move to routine here? 9001 and 9002 have a different (incorrect?) rotation point.
(I'm assuming Javier wants to have new versions made, or already have them ready?)

The real question is: Can we use the Move to-routine here, or do we need to make them obsolete?

Lets start with these questions. I think they will be decisive of how we should move on.
I have many more.

[Javier Orquera]

First question:  Is it correct that the two families contain only four switches each?
Quote:
Remote Control with Decoupler Pattern exist only in old version
Remote Control with 2 Circled Arrows Pattern exist only in new version
Or do we make 2 sets of 5 switches?

Second question:
We also have new information about the correct part numbers on the switches.
u9001 is 4709
u9002 is 4708
These files are official and need to have Move to-files made.
Is it possiblle to use the Move to routine here? 9001 and 9002 have a different (incorrect?) rotation point.
(I'm assuming Javier wants to have new versions made, or already have them ready?)

The real question is: Can we use the Move to-routine here, or do we need to make them obsolete?

Lets start with these questions. I think they will be decisive of how we should move on.
I have many more.

First question: I'm stick to real (existing) parts.
Second queston: yes, I did all of them, with the respective details, and are ready to be submited. Also, did the assemblies.

To your real question: I choose to obsolete the entire official 4707.dat and asocieted parent parts.

[Javier Orquera]

Here it is a sample of my 4707.dat version:

[Magnus Forsberg]

Here is what I want us to do:

• We must obsolete the old keys, 9001 and 9002. It is not possible to use a Move to, due to the difference in rotation points.
  
• Steffen remains as Author of 4707 and its subfiles, but Javier is free to update 4707, and reuse any of the subfiles to 4707.
  
• 70028-f1 and -f2 are allready made, moving u9004c01. However, IMO we don't need the two version with pressed down buttons. 70028 should be made with no pressed down buttons.
  
• 4707c01 is 70027. Need a Move to-file.
  
• 4707c02 should be obsoleted.
  
• u9005c01 could be renumbered to 4707c04, since it uses the same bottom as the 3 other assys.
  
• Steffen remains as Author of the four assys; 70027, 4707c03, 70028, and 4707c04(u9005c01).
  
• Javier will be the author of the new keys.
  

Any comments?

   

[Rene Rechthaler]

one thing i realized on my track point switches:
the "old" mechanical switches with the springs and stuff dont have the milky white thing at the bottom which prevents both buttons to be pressed...
does that mean they can shortcut then?

[Magnus Forsberg]

one thing i realized on my track point switches:
the "old" mechanical switches with the springs and stuff dont have the milky white thing at the bottom which prevents both buttons to be pressed...
does that mean they can shortcut then?

??
Do you mean electrical shortcut? How is that relevant in these files?

[Javier Orquera]

I have looked videos abaout the pressed keys and note that they don't go to the "end" due to the springs (in real life terms), so the 4.3 deegres in the help info is wrong: anyone knows which is the correct angle?

[Rene Rechthaler]

Hm, when pressed, the "gap" is parallel...
(about the same distance as the small gap at the cover, all around the part)
what is the angle of the "slope" at the underside?

[Orion Pobursky]

Plug34 is holding up a whole raft of files. We need to have a relevant conversion about how to release the parts currently on the tracker. This means: filename, origin, and user visible geometry. Everything else (like HELP, non-visible geometry, etc...) can happen after we've solved the first 3 issues for all parts.

[Orion Pobursky]

https://library.ldraw.org/tracker/32704

It's been almost a month since the last comment on this part. What's the way forward here?

[Javier Orquera]

Am I allowed to submit my version as stated by Magnus?
If so, it is requiered to do with the new numbers (assembled ones)?

[Javier Orquera]

Also, since the switch with signal keys and without pressing them has not been created, may I claim authoring of it?

[Orion Pobursky]

Magnus the most knowledgeable so I empower him to make the admin decisions regarding this.

[Magnus Forsberg]

Am I allowed to submit my version as stated by Magnus?
If so, it is requiered to do with the new numbers (assembled ones)?

We have some new information from Joshua:

the 1981 control desks/decks are:
70027 CONTROL DESK F. POINTS [rectangle and circle-"no" symbols]
70028 CONTROL DESK F. SIGNAL [red and green circles]
70067 CONTROL DECK F. DECOUPLING UNIT [yellow arrow up, yellow arrow down]
the 1983–1986 entries:
70160 SWITCH BOARD F.CROSSING [crossing gate up/crossing gate level]
70286 SWITCH BOARD F.TRACK [counter-clockwise arrow, clockwise arrow]

I will continue to investigate.

But I think you can go ahead and upload the updated version of 4707 and new keys you have ready.
I will take care of the old files that need to become obsolete, and making Move to-files if needed.

[Javier Orquera]

I show you my plugs for 4707, opinions?

   
   

[Magnus Forsberg]

I think we need to have a different layout in these switches.

Top is the whole switch.
Next is a full body + the 2 keys
The full body should contain all the bottom + cover + plugs, and any more parts you want to create.

This way the user can simply inline the whole switch and manipulate the keys, without having the model filled with all the loose sub-parts.

Some of the switches will be renumbered, but I suggest that the bodies simply are made as 4707c06, 4707c07 and so on.
This will also make it possible to have a different amount of plugs in the body, 3, 6 or 8 holes.

[Rene Rechthaler]

as I began to explain on the part itself, here is my suggestion:
4707: base part (just plastic, no metal)
4707c01-c03: body (base+metal+cover)
4707c0Xp0X: assemblies with (printed) keys ->p00 is unpatterned
example: 4707c01p01: 3 hole cover with the keys for the switches
c01p02: decoupler
c01p03: circle arrows
c02p01: barrier
c03p01: signal
c01p00: 3 holes and unpatterned keys

[Magnus Forsberg]

I am in the process of renumbering the complete assemblies to the 5-digit numbers.
But yesterday I realised I had them on the wrong set of files, already in my second table above.
I hope I have now reverted back to good situation, but I think I need help from Orion to remove some bad files.

In the meantime I have put together a Summary page with both sets of switches.
Any opinions?
Maybe we should renumber the keys so that the c01 contain p01, c02 contain p02, and so on?

[Javier Orquera]

It is good to me.
What about the assemblies with unprinted keys? It's needed the 3, 6 and 8 front holes for each version? If so, how to manage the part numbers?

[Magnus Forsberg]

It is good to me.
What about the assemblies with unprinted keys? It's needed the 3, 6 and 8 front holes for each version? If so, how to manage the part numbers?

I don't see a need for a uncoloured assembly shortcut. We have a uncoloured base for the Keys and IMHO that is enough.
I don't think we have any uncoloured base for the big assemblies.

[Rene Rechthaler]

should the key subfiles 4112s01 and 4709s01 get a common subfile? they are very similar...
and u9653s01.dat could be used in u9655.dat

[Magnus Forsberg]

I am in the process of renumbering the complete assemblies to the 5-digit numbers.
But yesterday I realised I had them on the wrong set of files, already in my second table above.
I hope I have now reverted back to good situation, but I think I need help from Orion to remove some bad files.

In the meantime I have put together a Summary page with both sets of switches.
Any opinions?
Maybe we should renumber the keys so that the c01 contain p01, c02 contain p02, and so on?

The renumbering is now done.
You're all welcome to review them.

One thing remains.
We now know the correct number on 5 of the assemblies, but does any of the other 5 exist?

[Rene Rechthaler]

One thing remains.
We now know the correct number on 5 of the assemblies, but does any of the other 5 exist?

what exists? 4707c01.dat and 4707c05.dat definitely exist as physical part, but where are the assembly numbers from?