Skip to content
This repository has been archived by the owner on Jan 14, 2018. It is now read-only.

Potentiometer_Alps_* fixed pin numbers #23

Closed
wants to merge 1 commit into from

Conversation

feichtinger
Copy link

Hi there

I found that several Potentiometer footprints have reversed pin numbers (especially the horizontal ones). (See also: PR: Potentiometers

So I started to fix this for the Alps footprints. (But there are many more to do...)
bildschirmfoto vom 2017-09-11 22-12-13

@jkriege2
Copy link
Collaborator

Hi!

I agree that pin1 should be at the top ... a hort hint on this PR: You can of course do all the changes by hand ... but note: Most Pot-footpritns are script generated: https://github.com/pointhi/kicad-footprint-generator/tree/master/scripts/Potentiometers ... maybe it's easier to alter the scripts and regenerate them?

JAN

@pointhi
Copy link
Collaborator

pointhi commented Sep 12, 2017

@jkriege2 it looks like you have the most experience with the scripts. Probably you have time for it.

I also noticed lot's of data was defined in the python scripts. Using KicadModTree.ModArgparser in the future would help us to have a more consistent part definition which should also help contributors to understand how the code works. It also helps us to seperate between code and data, which is always a good idea.

We should also look to integrate some parts of https://github.com/pointhi/kicad-footprint-generator/blob/master/scripts/tools/drawing_tools.py and other helper scripts into the framework itself.

@jkriege2
Copy link
Collaborator

Yes, I can see whether I find some time this evening ... I'll let you know ;-)

About the tools: yes definiertely ... maybe we can more or less merge your complete repo into the KiCAD-utils? This way we have one repo, which contains all the generator scripts ...

Best,
JAN

@jkriege2
Copy link
Collaborator

Hhmmm ... I don't think I currently have enough time to work on this ... I had a look into the scripts and changing that stuff is a bit more complex than I thought (also if we rotate the footprints, which this will cook down to in some cases, we also will need to rotate/modify the 3D models ... and then the 3D models should be brought up to speed with STEP, scaling and all ... so that I won't be able to manage at the moment). ... is this problem very severe to you? Basically what it cooks down to: We have footprints that violate KLC in that pin1 is not at top-left (+ old/wrong 3D model scaling) ... but the footprints are in fact fully functional and the pins are not "wrong" (the two pot end-pins should be exchangeable if I'm not mistaken) ...

JAN

@feichtinger
Copy link
Author

but the footprints are in fact fully functional and the pins are not "wrong" (the two pot end-pins should be exchangeable if I'm not mistaken) ...

Well, normally when you turn a potentiometer to the right you want 'something to increase'. (Think of the volume knob at your stereo.) So in this aspect pin 1 and 3 are not interchangeable.

Another issue is the "horizontal and vertical" thing: #18

I will take a look at the script when I find some time. But probably I wont care about the 3D parts.

@evanshultz
Copy link
Collaborator

@feichtinger
Turning the knob one way will move the wiper towards one pin, while turning it the other way will move it away from that same pin. To make this clear it would be prudent, IMO, to add something on the schematic symbol to make this clear. Perhaps putting CW and CCW by pins 1 and 3, respectively.

Be sure to mentally separate logical connections of the part from the application (your example). The symbol and footprint could be built many different ways, but regardless when making the schematic I could still connect the symbol such that turning the shaft clockwise means "volume up".

The horizontal vs vertical is a good reminder. I assume you are just bringing this up so that it's not forgotten, as that issue seems to be understood.

@feichtinger
Copy link
Author

Turning the knob one way will move the wiper towards one pin, while turning it the other way will move it away from that same pin. To make this clear it would be prudent, IMO, to add something on the schematic symbol to make this clear. Perhaps putting CW and CCW by pins 1 and 3, respectively.

I already made this changes to the poti symbols to mach the 1,2,3 convention.

But I agree with you, it would be nice to have some additional hint in the symbols. Remember: they also have to fit for linear potis, so CW and CCW does not work. But maybe we could use MIN and MAX or START and END or something like that. Or maybe just an arrow that points out the "turn right" or "move to the right" direction.

Be sure to mentally separate logical connections of the part from the application (your example). The symbol and footprint could be built many different ways, but regardless when making the schematic I could still connect the symbol such that turning the shaft clockwise means "volume up".

Of course you can always overcome the shortcomings of the library by closely locking at the pin numbers of symbol and footprint and then connecting it so that it works the way you want it. But it would be nice to be able to just place a poti symbol in the schematic, connect it, and be sure it works!

@evanshultz
Copy link
Collaborator

@feichtinger Did you do these changes by hand? When the footprints are already scripted, as these are, we will make changes by updating the scripts and re-running them. Your comments above indicate to me that you did not use the scripts. Unfortunately, I believe this means your work will be lost.

I'm making some other changes to the pot scripts now and will look into the issues noted above:

  1. Reversed pins
  2. Pin 1 not at the top left (maybe I can adjust the rotation of the 3D model to make the match)
  3. No argument interface to the script

Regarding the rotation of the shaft, I'm not getting it. In a potentiometer, the wiper position is based on the shaft position. There is a fixed relationship between wiper position and shaft position, meaning CW and CCW as pin names are relevant. I don't know what "linear potis" means, but perhaps it's a typo or another language? Rotary encoders are free-spinning, but I don't see any mention of them above.

@feichtinger
Copy link
Author

feichtinger commented Nov 10, 2017

@evanshultz Yes, I did make the changes by hand. Unfortunately I did not realize that the parts were script generated. Of course it would be the best to edit the script and rerun it.

Unfortunately, I believe this means your work will be lost.

No big deal. I would be very pleased if you could fix the pot script : -)

I don't know what "linear potis" means, but perhaps it's a typo or another language?

Well, in a "linear potentiometer" the slider moves on a straight (linear) axis. I think they are also called "fader"

Obviously there is no CW and CCW direction for a fader.

Potentiometers also can have several different relationships between the slider position and the resistance, for example "linear" and "logarithmic". Not to be confused with the geometry of the potentiometer. So the word "linear" might be confusing here, sorry for that.

This has nothing to do with rotary (or linear) encoders. I guess that's a completely different chapter.

@evanshultz
Copy link
Collaborator

@feichtinger
OK. Yes, we used confusing terms. It's all clear and I'll finish the script and then close this PR soon.

Now I know what kind of pot you mean. Thanks for clarifying. The most common term I've heard used is "slide potentiomter" (see https://www.digikey.com/products/en/potentiometers-variable-resistors/slide-potentiometers/78), and the control that this type of potentiometer allows is commonly called a fader.

Thanks again for taking the time to document improvements to the library parts!

@SchrodingersGat
Copy link
Contributor

@evanshultz @feichtinger @jkriege2 what is the status of this PR? Can we get it merged before transfer to the new repository?

@evanshultz
Copy link
Collaborator

Yes, I'm working on it now. Almost finished with the script updates to generate new pot footprints and then I'll add them to the new repo.

But on this specific issue, I re-read the discussion above and I don't think it solves any problems. There is an issue, but I think the fix is different than flipping pins 1 and 3 as written above. Using terms like "start" and "end" don't help because those are implementation terms and do not relate to the intrinsic function of a potentiometer. Let me try again to explain the problem and proper resolution as I see it.

This may take a lot of words and feel overblown for what appears simple. But I've been through this before in a professional life and found a solution that works. When new hires come on board this issue may flare up again, but with little to no explanation it becomes clear and I've not seen further problems.

A pot (not a rotary encoder) has a two fixed endpoints. Between them the wiper moves across the element. The relationship between the direction the shaft is turned and the movement of the wiper is what needs to be captured.

I could change the connection of the pot and make turning left or turning right have the same effect. That is implementation, and the schematic symbols and footprints do not (and cannot!) capture this. It's up to the designer to understand and use the part as they desire. Only when the pot and surrounding circuitry are considered together can terms like "start" or "end" or "left" or "right" be used. Those words are meaningless when just looking at a symbol and footprint without the surrounding circuitry. You cannot know what will happen to a product when turning a pot without knowing the circuitry around the pot.

Looking at https://github.com/KiCad/kicad-library/blob/master/library/device.lib, we currently have arbitrary pin numbers on all generic pot symbols. And we're trying to connect that symbol to a variety of specific footprints. There is nothing intuitive about the pin numbers and it's so easy to get things wrong. Right now, the CW position could be pin 1 for one manufacturer and pin 3 for another.

We could have specific symbols for each footprint (atomic parts), but that's somewhat annoying for such a generic component as a potentiometer (at least to me). We could define pin 1 to the CCW position, but it's not salient and requires some supporting information to make this arbitrary decision clear. I believe a better option is to use specific pin numbers, such as CW (the end of the element where the wiper is when the shaft is turned fully clockwise), W (the wiper), and CCW. Then we would be able to confidently match a single symbol with any footprint. Dual gang pin numbers would be CW1, W1, CCW1, CW2, W2, etc. And the user would intuitively know the operation of the pot from the symbol, allowing the pot to connected to achieve a desired effect. By using "smart" pin numbers on the symbol, as long as the pin numbers of the footprints have the same numbers and capture the parts' behavior (as the datasheet should explain), the user can know their design will work. It would be much less easy to end up with a board where turning the pot left made the volume go down when the intent was to make turning right increase volume, for example

Now is the time to make a change, for v5 and while I'm updating the pot script anway.

I don't see any way except changing symbol and footprint pin numbers. Am I missing something? Other ideas?
@SchrodingersGat @jkriege2

@jkriege2
Copy link
Collaborator

I'm not so sure whether we should provide this fancy naming-scheme as it seems really error-prone to me ... is that even mentioned in the datasheets? How should we check contributions for that?

I think it's the rresponsibility of the user to make such things work for him. Also think about the mounted from below pts with axis through a hole ... what's CCW/CW there? seen from top or bottom?

2017-11-21 20_07_15-3d viewer

@evanshultz
Copy link
Collaborator

evanshultz commented Nov 21, 2017

@jkriege2
Can you explain what is error prone about it? With an example? I've thought it through and it seems very logical to me. However, I may be blinded to other problems because I've used the system for years.

I'll give an example to start things off. I know ALPS RK09 is in the library, so I just picked the first one in the ALPS RK09 lineup. When you look directly at the shaft end with the shaft turned fully CW, the wiper is closest to the right terminal. So pin 1 is CCW, pin 2 is W, and pin 3 is CW. That's all there is to it.

Now how about another one? I randomly chose Bourns 3339S from the library. Nicely, this datasheet gives all of this information and they label the pins exactly like I'm saying we should do. It's totally unambiguous here.

Since that worked out so well, let's find another vendor and take a look at Piher PC-16. Here the pins are given as A, S, and E, which correspond to CCW, W, and CW.

I fail to see how this is (or could be) any less confusing as pin numbers of 1, 2, or 3 are meaningless. Pin numbers of CW, W, and CCW have meaning to them and can be helpful, but the user can easily ignore the pin numbers if they choose. And while measuring the actual pot can confirm the pinout, there's absolutely nothing lost over the current scheme which has no intelligence and would also require guessing.

This PR is about fixing the potentiometer pin numbering because it's broken and doesn't work. Here is a way to fix it and provide standards.

Regarding the shaft being upside down, I say we go from a top view. If the pot is on the bottom, then everything becomes reversed. It seems obvious to me that if the pot is intentionally flipped that things will be different than the normal orientation. The normal position should be the reference.

EDIT: Clarified the wording on the ALPS RK09 example.

@feichtinger
Copy link
Author

I am skeptical about using non-numeric pin numbers. Also, as I already mentioned above, CW and CCW does not work for non-rotational / slide potentiometers.

I suggest to keep the pin numbers at
1: left/lower/CCW end
2: slider
3: right/upper/CW end

4, 5, 6 and so on for dual/triple pots. This is what the current pot symbols look like. Maybe this convention should also be added to the KLC.

But there are still the pin names. If you think it is help-full (I think it is) to add "CW" and "CCW" (or something else) labels here, go ahead.

@evanshultz
Copy link
Collaborator

@feichtinger
Why are you skeptical? Back up your skepticism.

You are correct about slide pots not fitting CW and CCW, and thanks for reminding me. (I've not used slide pots professionally and so didn't run into this.) They do not generally have a start and end (or left and right) that has any meaning, since the ends are interchangeable. If one end is called start, that could be up or down depending on the circuit and mechanical orientation of the pot.

However, is there a better nomenclature that works for rotary and slide pots? That's a great question but I don't have a great answer. Having multiple symbols (for slide, for rotary, etc.) seems silly rather than a single symbol that works with all footprints. Just adding text notes or pin names also makes them specific for rotary or slide or whatever.

In your pin list above, only CW and CCW relate to the wiper's position. Left, right, lower, and upper are all related to the shaft's position, not the wiper's position. Thus it doesn't guide the KiCad user into how the symbol should be connected. If the pins are left as numbers, there would need to be images to indicate the connection chosen in KiCad (or else the user has to find out when then select a footprint).

@feichtinger
Copy link
Author

feichtinger commented Nov 22, 2017

Why are you skeptical? Back up your skepticism.

First of all it is very unusual. As far as I know there is no other component in the KiCad Library that has non-numeric pin numbers...? The second thing is that, as @jkriege2 mentioned, it could be error prone, think of upper and lower case: is it "CCW", "ccw" oder "Ccw"? Also you can not guarantee that every program you may export/import KiCad files to can handle non-numeric pin numbers. (Not even KiCad itself in the future...)

How about that: We just put an arrow in the pot symbols pointing from the CCW (pin 1) terminal to the CW (pin 3) terminal. This way, when the users inserts a pot symbol in the schematic he already gets a hint how to connect it so that it works the way he wants. For 90% of the cases this might already be sufficient. For the special cases the user has to look into the footprint anyway.

A marking of pin 1 in the footprints (as it is usual for connectors and ICs) might also be helpful.

@evanshultz
Copy link
Collaborator

Non-numeric pin numbers isn't a problem. We (the librarians) have at least talked about it for switches, and I've tested it and it works.

I don't see the naming as an issue. We go with all uppercase to reduce ambiguity and that's that.

However, the arrow does seem to work for me. Maybe there are cases that don't work that I can't think of right now. It allows a correlation between the motion of the shaft and the wiper's position. That is the key thing that was missing. As you said, somewhere (KLC?) this will need to be specified so that it's codified. And with some convention then the footprints can be untangled and updated to match. I'll leave this open for a few days to gather feedback. If there aren't any better ideas or any major issues, I'll finish off the pot script updates using this philosophy and post a PR for the pot symbols. Thanks for the great suggestion!

@poeschlr
Copy link
Collaborator

Can we slowly bring this to an end such that we can transfer this lib to the new repo?
Otherwise we need to take the current footprints over and you can fix everything later on.

@evanshultz
Copy link
Collaborator

@poeschlr
Yes, I would like this to end too. However, I still don't think any solution above helps. Even an arrow doesn't tell the user which way the shaft turns will move the wiper.

For now, I propose to leave the pin numbering as it is and I will transfer over the pot footprints with the other fixes (ref des on F.Fab, horiztonal/vertical confusion, etc.). More thought can be done on this post-v5. Anybody object?

@poeschlr
Copy link
Collaborator

poeschlr commented Dec 5, 2017

Good for me. (To be honest the whole cw/ccw discussion is above me.)

@evanshultz
Copy link
Collaborator

Superseded in the new repo by KiCad/kicad-symbols#165.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants