fritzing / fritzing-app

Fritzing desktop application
http://fritzing.org
Other
4.03k stars 832 forks source link

pin numbering of pin headers is wrong #2199

Open davidperrenoud opened 10 years ago

davidperrenoud commented 10 years ago

From th.gauwe...@googlemail.com on September 06, 2012 15:02:58

The pin numbering of the pin headers do not follow the convention.

Actually its anti-counterclockwise. The convention is one row to the next row.

E.g. pin 1 is in the corner upper left. Then pin 2 is below pin 1. But the convention is that pin 2 is in the same row in the right from pin 1.

see http://www.kreatives-chaos.com/artikel/avr-programmieradapter for example.

Original issue: http://code.google.com/p/fritzing/issues/detail?id=2199

davidperrenoud commented 10 years ago

From stefanhermann79@googlemail.com on September 06, 2012 23:49:19

Yes, that is true and we should change it. I guess, I suggested to do it like on IC parts but that was obviously wrong.

davidperrenoud commented 10 years ago

From irasc...@gmail.com on October 20, 2012 15:20:19

Status: Accepted
Owner: andre.knoerig@gmail.com
Cc: stefanhermann79@googlemail.com

davidperrenoud commented 10 years ago

From VillageH...@gmail.com on November 24, 2012 10:04:28

I like to confirm that changing this is very important and add that a fix is urgent. Practical example. Say you want to redo the design of an Arduino in Fritzing including the 6 pin ISP pin-header. If one uses the 6 pin pin-header from the Fritzing library the connection is shuffled and thus the ISP will not work, even the schematic is drawn correctly and the Layout is passes the design rule check. Since pin-headers can carry power rails the non conventional numbering of fritzings pin-header can destroy circuits during Bring to Life. That is why I suggest a fix is urgent.

That being said the last list of features added have been most useful. Fritzing is becoming a very useful tool! Thanks very much!

davidperrenoud commented 10 years ago

From irasc...@gmail.com on November 24, 2012 23:13:38

Labels: -Priority-Medium Priority-High

davidperrenoud commented 10 years ago

From irasc...@gmail.com on December 28, 2012 00:50:41

also the case with shrouded pin headers http://fritzing.org/forum/thread/1274

Summary: pin numbering of pin headers is wrong (was: pinning of pin headers is wrong)

davidperrenoud commented 10 years ago

From th.gauwe...@googlemail.com on February 26, 2013 13:54:42

is there a timeline for fixing? Or may I help you fixing it?

davidperrenoud commented 10 years ago

From irasc...@gmail.com on February 26, 2013 22:52:44

@th.gauweiler

thanks for the offer of help. This fix turns out to be difficult for a couple of reasons (which is why we haven't gotten to it yet):

  1. most of the parts affected are generated from code which is a bit tricky to modify, particularly since the numbering order is in shared code
  2. we have to figure out a way to introduce the new versions of the parts without breaking people's existing sketches (which use the old versions of the parts)

Cc: -stefanhermann79@googlemail.com bluearc....@gmail.com

davidperrenoud commented 10 years ago

From th.gauwe...@googlemail.com on February 27, 2013 04:04:02

On one kind you have to break the old sketches. I suggest to keep the pcb view but break the circuit diagram, when the pcb is already layouted.

Any other suggestions?

davidperrenoud commented 10 years ago

From irasc...@gmail.com on July 03, 2013 05:34:12

The problem is not quite as large as originally thought: it only affects dual row pinheaders (including shrouded pin headers), plus a certain number of the newly generated connector parts.

davidperrenoud commented 10 years ago

From irasc...@gmail.com on July 03, 2013 05:45:19

Owner: irasc...@gmail.com
Cc: andre.knoerig@gmail.com

davidperrenoud commented 10 years ago

From gc...@loowis.durge.org on July 06, 2014 16:55:56

Last update to this bug was just over a year ago - any progress on it yet?

davidperrenoud commented 10 years ago

From gc...@loowis.durge.org on July 06, 2014 17:43:43

Just been playing around with this some more (using a dual row pin connector). Using the "Select graphic" button in the Parts Editor, it's possible to fix the pin assignment in the Breadboard view :) But I couldn't get the same feature to work for the PCB view :( (it always wants to select a big rectangle, rather than the small circles representing the pins, even if I turn off every layer except the 'copper')

But then I found if I delve in and hand-edit the XML file to adjust the cx and cy values for the circles in the SVG, I can then 'fix' the PCB layout of the pins too! :-D But I have to be careful not to change the number of pins for the part, because that then resets the pin positioning to be incorrect. Therefore I need a separate custom-fixed dual-row header part for each of the differently-sized dual-row headers I need to use.

So at least I have a (slightly cumbersome) workaround for now.

davidperrenoud commented 10 years ago

From gc...@loowis.durge.org on July 06, 2014 18:09:48

Spoke too soon! "But I couldn't get the same feature to work for the PCB view" - seems that's only true for a shrouded dual-row header. If I choose a non-shrouded header, then I can use the Parts Editor GUI to remap the pins in the PCB view (still a bit clunky though, but easier than hand-editing XML).

Zalewa commented 9 years ago

Hi. I've just stumbled upon this problem. Are there any plans on fixing this? If you don't want to break compatibility with existing schematics then perhaps it should be provided as an option that would be enabled by default for new schematics? I was actually looking for such option before I found out it's actually a bug.

CCommander commented 8 years ago

Another year has passed and it occurs that I have stumbled upon this problem. Are you still aware of the issue? Is there a perspective that this could be improved?

Kahldar commented 8 years ago

Hi ! Is there a plan to fix this bug ? Pins numbers on shrouded headers are still wrong (0.9.3). Thanks.

davidgiven commented 7 years ago

Hello --- any news on this one?

th-gauweiler commented 5 years ago

Hopefully the new team can solve the issue.

EsGeh commented 5 years ago

Yeah, this is an annoying problem! Maybe the backwards compatibility issue could be solved by just by providing a fixed version as a separate part so existing sketches don't break...? We are all looking forward to this being fixed soon!

KjellMorgenstern commented 5 years ago

Hi there, thanks for pinging this issue and bringing it to my attention. Adding a new version of a part is not that complicated, so the fact this is still unresolved is a hint that there is a bit more to this issue.

If someone could add screenshots or even an .svg of how the part / feature should look like this would already be of big help to me.

th-gauweiler commented 5 years ago

The look does not have to change.

The point is: the concrete part will be generated on the fly. Just the algorithm how the pins are numbered is wrong. I guess it is the same as for IC.

Kjell notifications@github.com schrieb am Sa., 11. Mai 2019, 19:39:

Hi there, thanks for pinging this issue and bringing it to my attention. Adding a new version of a part is not that complicated, so the fact this is still unresolved is a hint that there is a bit more to this issue.

If someone could add screenshots or even an .svg of how the part / feature should look like this would already be of big help to me.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/fritzing/fritzing-app/issues/2199#issuecomment-491530590, or mute the thread https://github.com/notifications/unsubscribe-auth/AAU7SCSYSO2GRFUCQDGHCDDPU4AEHANCNFSM4ATMBPLQ .

th-gauweiler commented 5 years ago

Assume you have a 2x3 connector and three parts. The pinning of the connector should be in this form: one two three four five six Now connect two with the resistor. four with the capacitor and six with the diode. schematic.fzz shows the right schematic. And this should lead to the connection in file pcb.fzz.

The example was made with a now fresh installed frizzing version. Version 0.9.3b http://fritzing.org/download/0.9.3b/ was released on Juni 2, 2016.

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail Virenfrei. www.avast.com https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Am Sa., 11. Mai 2019 um 23:42 Uhr schrieb Thomas Gauweiler < th.gauweiler@googlemail.com>:

The look does not have to change.

The point is: the concrete part will be generated on the fly. Just the algorithm how the pins are numbered is wrong. I guess it is the same as for IC.

Kjell notifications@github.com schrieb am Sa., 11. Mai 2019, 19:39:

Hi there, thanks for pinging this issue and bringing it to my attention. Adding a new version of a part is not that complicated, so the fact this is still unresolved is a hint that there is a bit more to this issue.

If someone could add screenshots or even an .svg of how the part / feature should look like this would already be of big help to me.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/fritzing/fritzing-app/issues/2199#issuecomment-491530590, or mute the thread https://github.com/notifications/unsubscribe-auth/AAU7SCSYSO2GRFUCQDGHCDDPU4AEHANCNFSM4ATMBPLQ .

th-gauweiler commented 5 years ago

If someone could add screenshots

I just see, that my example files, which are appended to my email are filtered out by GitHub.

How may I append screenshot or even files to an issue?

KjellMorgenstern commented 5 years ago

Drag and drop usually works on GitHub

th-gauweiler notifications@github.com schrieb am Mi. 15. Mai 2019 um 12:55:

If someone could add screenshots

I just see, that my example files, which are appended to my email are filtered out by GitHub.

How may I append screenshot or even files to an issue?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/fritzing/fritzing-app/issues/2199?email_source=notifications&email_token=ABRROSMHU6FQ7KDBQYNYZ5LPVPT2NA5CNFSM4ATMBPL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVOJJDA#issuecomment-492606604, or mute the thread https://github.com/notifications/unsubscribe-auth/ABRROSPR67DCNL5PRLKNHODPVPT2NANCNFSM4ATMBPLQ .

th-gauweiler commented 5 years ago

wrong pinning.zip

An example, that illustrate the example:

Assume you have a 2x3 connector and three parts. The pinning of the connector should be in this form: one two three four five six Now connect two with the resistor. four with the capacitor and six with the diode. schematic.fzz shows the right schematic. And this should lead to the connection in file pcb.fzz.

Its an error in generating a concrete item of a generic part. The parameter double row must be set.

KjellMorgenstern commented 5 years ago

From schematic.fzz image image

From pcb.fzz image image

KjellMorgenstern commented 5 years ago

So, currently you get

1 6
2 5
3 4

Looking at an Arduino Mega (they have the odd numbers on the right), one would expect:

 ...
 22 21
 24 23
 26 25
 ...

or following the numbering on the raspberry pi connector

1 2
3 4
5 6
...

I understand, that the Rasperry PI connector naming scheme is closest to what is suggested in this thread.

Besides (another issue, which I might have closed a bit to early), it can be a bit confusing that you have a single line in the Breadboard view and a double line in the PCB.

failiz commented 3 years ago

Remove imported label

failiz commented 3 years ago

I do not think that changing the algorithm is very difficult. The problem is how to keep backward compatibility (do not modify previous sketches which were done with the current algorithm). @KjellMorgenstern , are the generated parts stored in the sketch file or are they generated again when you open the sketch? If the latter, is there a way to check if the connectors were done with some specific version? If the connectors are not generated again, we could replace the code without problem. If not, we should check the version of the connector and use one algorithm or the other. Are there any other approaches?

KjellMorgenstern commented 3 years ago

There could be a new property 'pin order' -> 'left-right', 'right-left', 'counter clockwise', 'clockwise', 'down', 'up'

For simplicity, I think I have only seen lr, rl, and ccw , so those three might be sufficient. Default could then be ccw, so old parts have the same behavior, no matter if they are stored or generated. If generated, the parts would not be backward compatible. But currently files like 'generic_female_alternating_pin_header_6_100mil.fzp' are created, so it should be possible to add this as generic_shrouded_pin_header_10_100mil.fzp -> generic_shrouded_pin_header_10_100mil_ccw.fzp

and then generic_shrouded_pin_header_10_100mil_rl.fzp generic_shrouded_pin_header_10_100mil_lr.fzp ...

KjellMorgenstern commented 3 years ago

Since that is quite a number of options (pins, form, hole size, pin spacing, row, position, package, pin order) , and not all combinations are possible, I'd consider adding a button in the inspector that shows a dialog, possibly with a preview.

failiz commented 3 years ago

It looks that there is no standard: https://electronics.stackexchange.com/questions/106426/standard-nomenclature-for-2-row-connector-numbering-schemes https://www.cirris.com/learning-center/general-testing/special-topics/27-connector-pin-counting-sequence

However, I agree that the zig-zag pattern is more common (specially for ribbon cables). I am ok with making it an option, but the default one should be the 'left-right' (zig-zag). We could use the suffix of the file as you suggested to determine the option used. And if there is no suffix, use the ccw one. I would also limit the options to just ccw and 'left-right'. I not sure if it makes sense to have more (the benefit compared to the time to implement them).

th-gauweiler commented 2 years ago

10 years

louigi600 commented 1 year ago

2023 and still not fix and you get charged money for he latest version of Fritzing while they cant even get right a generic 16pin 2x8 for ribbon cable pin header numbering. This is so disappointing. but there are correct ones for 2x5 and 2x10... but unlike the gereric one for these you can't set an arbitrary pin count.

I really need 2x8 with sholder male with classical ribbon cable numbering: anyone made one ?