parts with grouped pins don't connect correctly in schematic

[vanepp]

Current Behaviour

Four parts each with 2 pins one pair male and one pair female, two not grouped and two grouped will connect in breadboard (as they should) but in schematic the two grouped parts will only make one connection unless connected via wires (in which case they connect correctly.

Breadboard:

Schematic:

Here the connection circled in red has no rats nest line, and even if you try and manually connect the two unrouted pins will not make a connection. If the connection is via a wire (the bottom connection) it works correctly, so only the male/female connection that is part of a group doesn't work correctly note there are two parts layered on top of each other in breadboard).

Here is the test sketch (remove the trailing .zip to keep github happy to recover the .fzz file for the sketch which has the parts in the temp parts bin.)

test-Sketch.fzz.zip

Build: 0.9.4

Operating System: Windows 7

Steps to reproduce:

see the test-Sketch.fzz file above and try and make a connection in schematic.

Expected Behaviour

The female to male connection with a group should connect in schematic. The reason for wanting this to work (besides the fact it should work) is to allow shields to reflect in to schematic as indicated in the forum post:

https://forum.fritzing.org/t/request-dragino-lora-shield-for-arduino/9137/6

with an Arduino shield attached in breadboard to a modified Arduino Uno part.

[ghost]

is it a graphic issue? Does the schematic still work? if the schematic doesn't work it most likely is an interaction error.

[vanepp]

No, it is an internal routing type code problem. A female part should autoconnect to a male part and propagate the link to the other 2 views. That isn't happening here. There is a similar problem with breadboards which may be the same bug.

[ghost]

Oh, I am new can you give me an example?

[ghost]

Also, I opened the .fz and it did not load properly.

[vanepp]

"Oh, I am new can you give me an example?"

Welcome aboard! The example is in the .fzz file. The custom parts in it exhibit the error in as small an example as possible, as the screen shots above show.

"Also, I opened the .fz and it did not load properly."

That is probably because you unzipped the .fzz file (which will create a .fz file.) What you need to do is simply rename test-Sketch.fzz.zip to test-Sketch.fzz (which is a zip file) and load that in to Fritzing. Github doesn't know .fzz files and will not allow them to be uploaded, thus the .zip on the end to keep github happy. In addition you can see the problem in the Fritzing forum post referenced above (this is a minimal test case to allow easy debugging when we get to it, the forum post has the complete part where this is used.) If you are new you probably want to join the forums (https://forum.fritzing.org/) because our documentation is mostly non existent and asking in the forums is the usual problem solving mechanism.

Peter

[mMerlin]

@vanepp Peter, the terms you used in the problem description are a bit fuzzy/misleading. We regularly talk about grouping and ungrouping elements in svg files for Fritzing parts. What you are working with is bus connections within a part, which is in the part definition file, not the svg. So your grouped parts are really bused (or maybe ganged?).

You probably know most of this, but including it to get the logic chain.

All connectors on a single bus are wired together internally in the part. As far as Frtizing is concerned, attaching a wire to one connector on the bus is electrically equivalent to attaching a wire to any other connector on the bus. Or looked at another way, a wire attached to any connector on a bus is really attached to all of them.

Once a route is available between 2 connections, through any path (including those internal bus connections), Fritzing is not going to show a ratsnest line to create a duplicate route. In your schematic view, part M2 and M4 are both parts with a bus between connector 1 and connector 2. So internally M2.1 is wired to M2.2, and M4.1 is wired to M4.2. Once the wire is placed between M2.2 and M4.2, M2.1 and M4.1 are also connected. There is no need to have or show another wire or ratsnest.

When you connect a male grouped and female grouped test part in the breadboard view a route is established between the paths, but only a single ratsnest line will be shown in schematic view. Which pins that is shown between will follow the rules of shortest distance / nearest pins. By moving and rotating the schematic parts, the ratsnest line will move around: pin 1 to pin1, pin2 to pin1, pin1 to pin2, pin2 to pin2. But that single ratsnest (or wire) is really connecting all 4 of the pins together. Remember this is schematic view, which is logical connections. You can create double/parallel physical connections/loops on breadboard and pcb views, but schematic shows only the logical connections. One wire is all that is needed. If you want to make those bus connections more obvious on schematic view, add it as an internal wire in the schematic symbol. Your grouped pins are really just wires (jumper blocks), so show the pins as being connected. Internally.

I realized that this is a simplified test case. I looked at the linked post and the missing wires would create duplicate connections between buses. The blue circled ratsnests wires look like pins that are bused on the arduino part, but not on the shield, and the shortest path created a connection from a pin on the shield that was bused (and connected to Arduino) to a pin that was not on the bus. For example, after deleting all of the wires, to get back to pure ratsnest on the schematic for the incorrect by overlay sketch, Arduino pin D13/SCK connects to pin 13 on the shield. From symptoms, Arduino pin "D13/SCK" is bused to pin "SCK", shield pin "13" is bused to pin "D13", and shield pin "SCK" is bused to "ICSP1 SCK". The connections created on the breadboard by mounting the shield are from Arduino "D13/SCK" to shield "D13" and Arduino "SCK" to shield "SCK". This distance on the schematic from shield "D13" to shield "ICSPI SCK" is less than from Arduino "SCK" to shield "SCK", so the ratsnest wire goes there. Moving the 2 modules close together (0.1in separation between the matching pins) moves the ratsnets to where you would expect them. There are sill "missing" ratsnests for the extra/duplicate GND pins. These must be bused on both parts. Starting with the parts close together like that, creating the actual wires from the (now correct/expected) ratsnest, then moving the parts further apart should get what you want. Except for having only a single GND. You only need to create wires for A4/SDA - A4, AS/SCL to A5, SCL/A5 to SCL, SDA/A4 to SDA, D13/SCK to 13, D12/MISO to 12, D11 PWM/MOSI to 11, SCK to SCK, MOSI to MOSI, MISO to MISO before moving further apart. Those are the pins on buses that have easy alternate (short) paths.

Most of the perceived issue is from trying to keep the schematic block looking similar to the physical module. Really (only my opinion), the schematic should be more of logical view. There should only be one GND on a part, and only one pin shown for each bus. But that is not the current convention.

Most of that is working as designed. The only thing I found a problem with, was that I could not create a schematic wire from/to an alternate connection on the bus, when the ratsnest wire was on a different pin on the bus. For example, Arduino SCK to shield SCK when the ratsnest was from shield D13 to shield SCSP1 SCK. That seems like a bug.

But the bused pins are connecting (electrically) correctly on the schematic.

correct-connections-by-overlay-shield-on-arduino-Sketch.fzz.zip shield-schemtic.svg.zip

[vanepp]

So perhaps this is more of an enhancement request than a bug, because as noted in the reply to the forum post. I'd like to see more flexability in Fritzing if the code cost isn't too high.

[failiz]

I agree with @mMerlin , that this is as intended. The issue with ground pins not being connected is a different issue and it is reproducible with core parts. I opened issue #3974 with its possible cause. @vanepp , if you still think that there are improvements for Fritzing, could you create a new bug report and close this one? The discussion here is quite out of the scope of the original issue and it would be nice to clarify the actual issue without the extra noise. :-) In any case, I can see that there are occasions where you want a rastnets for all the connections. For example, in a microcontroller all GND pins need to be connected. If the part has a bus in the GND connectors, a user connecting just one ground in the PCB will not get more rastnets. In contrast, in an Arduino PCB, this is the correct behavior as the ground plane of the Arduino makes the connection. But I have not thought too much about this, maybe you have different thoughts.