H-Bridge with L298N motor driver

Given symptoms seen, I do not know whether to call it a restriction or a bug.

I am not sure what is the exact problem with the buses. Is there an open bug in Github?

The advantage of combining all the GND and power pins in the schematic view is that we can reuse the symbol for other physical packages. However, in the current implementation, the svg of the schematic still needs individual connectors. For example, the GND has three connectors (6, 8, and 18). Thus, the symbols are not reusable.

I would prefer to show all of them in the schematic symbol. I think it would be less confusing to newbies. Additionally, there could be cases where the designer wants to not connect all together. For example, sometimes you want to generate different grounds for the analog and digital circuits or add filters to some power supply pins. And finally, depending on where you are with the mouse when hovering over the GND connector, you see different info, see below:

image
image

Finally, I would remove the different numbers of the GND or other connections in the name (I am not sure if this is possible). It feels strange to have names as GND6 or GND8. I would call all of them GND. In any case, I am not sure if we should start counting the connectors in 1 and not in 0. It seems weird that the name does not match the pin number, see below:
image

It is a problem with inhibit not working correctly (I don’t think it works at all in fact) in schematic. If inhibit let you suppress pins then the buses would connect to the correct place of a single pin (from multiple pins in other views). I don’t know if there is an issue open on github or not.

I think this is a much more complex change and perhaps not possible. Even if inhibit worked, the pins would need to be in the fzp and in the bus (just inhibited in schematic) for this to work. The pin numbers of the part you want to share the schematic with would need to match the current part in the fzp, breadboard and pcb views (and in the pins showing in schematic as well) which I don’t think will usually be practical.

That can be done, but as noted has the disadvantage that if you have a connection to another pin on the same net it won’t connect (although right now I can’t reproduce the issue, as I don’t think this should work!)

The second connection to ground should refuse to connect (I have seen it do so before but don’t remember what part it was!) as there is already a connection to that net and it won’t create a second one. Not sure what I’m missing here perhaps @microMerlin will know.

The reason for the pin numbers (which can be fixed by using the pin number rather than the connector number) is that the name field in the fzp file should be unique (so a name of GND should not be repeated in the name field in the same fzp file.) The reason was said to be that the code will use the name field to try and differentiate a part or perhaps it is this (from the parts file format file)

"But sometimes the replacement connector does not have the same id. In this case you can use the replacedby attribute on the obsolete connector, with the value being either the id or name of the replacement connector. Here is an example using the name:

<connector id='connector15' name='D0RX' type='female' replacedby='RX/D0'>"

the parts file format document used to say something to the effect “the name should be unique” but it looks like that has been removed in an update. I expect the code will screw up on the above replacedby if the name is not unique in the fzp file and that may have been the reason for the original warning. FritzingCheckPart.py will (if you enable the option which I do) issue a warning for duplicate name values and I usually try and avoid them. As noted the easy way out in this case is use the real world pin number starting at pin1 which is what I usually do. I can change this one to use that convention too.

Peter

The symptom (at least one case) is that with some (all but one) connectors of a bus suppressed (inhibited) in schematic, a wire on breadboard view to one of the inhibited connector pins would not show up as a ratsnest in schematic. The final connector on the bus should be ‘equivalent’ in schematic, and the ratsnest should go there. I don’t know if that is in a bug report either, but it is probably not tagged as a bus problem. It is inhibit that is broken.

I’ve only seen the ‘refuse’ case. Not the apparently working case you show.

For some of the rest, it looks like there might be some overlap in the wording used which mixes together the connector id, name, and description. I think all of the common (bussed) ground connectors can have “GND” as the description. As noted in some versions of the documentation, duplicate name values might be a problem, especially if the name is used for replacedby references. I think I posted a question about that awhile ago. I did not get a definitive answer about how it actually works, and did not do the research needed to either test several cases, or find the references in the code base that needed unique values for reliable operation.

My bad for not including the sketch. The grounds are all bused and I don’t think the second ground connection to the header should work.

schematic-test.fzz (27.6 KB)

Peter

That part and sketch seem to work as they should with my various test sequences. I may need to try some of my previous cases as well for hybrid connectors. Here is my bug report (though it was never tagged as a bug) from a couple years ago around most of this. With multiple follow up scenarios and test cases. Maybe a version update has fixed this.

Here are my own notes about a possible solution:

WIth that, the functionality seems to be the same as not using hybrid, making all of the bussed connectors except one invisible, and stacking them all on top of each other in schematic view. There is still some oddities about what information hover will display for the visible pin.

I do not think an issue with this sketch.

Maybe this has been fixed? Have you tried to reproduce it in an old version?

I guess that this is not the feature that only allows one connection between two connectors. You cannot duplicate traces between connectors already connected by a direct trace. I do not think this should be an issue for multiple connectors bussed together.

It seems that this is mostly a documentation issue.

If there is only a non-hybrid connector and the rest are hybrid connectors, I made a fix not to show the information of the hybrid connectors. In any case, this still has some weakness as it will show the info of just one connector instead of listing all the pin numbers in that bus. For example, it the example of the VNH2SP30 before, it will show just “GND6:Ground (7)” when it is actually representing all the GND connections in pins 7, 9 and 19.

Of course, if there are several “non-hybrid” connectors, the program will show one for them which could change depending on the position of the mouse, which is not good either.

I would definitely use the pin number, which is what the user sees. I think it makes it less confusing.

The rule that forces names to be unique is still in the Wiki:
“The <description> element and name attributes seem self-explanatory. But it is important to note that within a part, a connector’s name and id attributes must be unique—that is, no two connectors in a given part should have the same id or the same name .”

For me seems very strange that the name needs to be unique (from a philosophical point of view). If there is an id, the id needs to be unique but the name can be reused. It seems weird to have different names for pins that are in the same net. I would restrict the replacementBy to only use ids. But of course, we should explore that this does not cause issues other than when obsoleting. @KjellM , any input on this?

Yes, I missed that part of the wiki.

I believe (but haven’t checked the code) that if a part has identical family variant and properties the code will eventually use the pin names to differentiate between two parts. In practice it is normally fine to duplicate names, nothing bad appears to happen in most cases, but that doesn’t mean there isn’t an edge case where it matters. I didn’t know before that obsoleting could obsolete by pin name and that is likely another (or perhaps the only?) reason for no duplicate names. The original text used to say something to the effect of " names should be unique" leaving the impression it wasn’t a hard rule, but if there are cases where the code depends on the name being unique then it should be enforced as unique.

Peter

It acts the same on 9.3b so it doesn’t look like a fix, rather that I am doing something different. Unfortunately I don’t remember which part I made where I saw this problem to try and reproduce it. I know I have a part somewhere where you can not make a connection to a pin that already has a connection in schematic I just don’t remember which part that is. In any case here is a new version of the part with the name field replaced with pin numbers. The grounds are still common because they are bused. If the grounds don’t all connect together internally (which I am assuming they do) then they should not be bused and indeed all the grounds should be on separate pins (which is a requirement for filters on the grounds or separate traces to avoid ground voltage drops to work anyway!) The problem is I don’t have a board to see if the pins connect together internally or not. If you can verify if the various grounds are all or only some connected together internally I’ll change the part to match the board.

Dual_VNH2SP30_Motor_Driver.fzpz (8.8 KB)

edit: I found another issue while making a test sketch to try obsoleting. Here is the test sketch and images showing the issue.

Dual_VNH2SP30_Motor_Driver.fzz (11.5 KB)

breadboard (correct)

schematic (wires reversed, mis labeled)

pcb (correct)

I think it would be useful to have a real sketch that uses this part to test with as well as this contrived test case, does anyone have such a sketch that they could upload?

Peter

I found the open pr on this and the example in there is still broken. It is more complex than just two buses (which is what I didn’t remember!), the fault looks to be between male and female connectors (which my example above doesn’t have.) The details are here along with a .fzz file that breaks. It presumably won’t apply to this part as it doesn’t have female connectors.

edit:

The obsoleting appears to be a bust. It doesn’t seem to work at all and I don’t know why. I used the obsolete.py script and set replacedby items to change the pin numbers but it doesn’t appear to work. The part in the parts bin appears to point to the obsoleted part not the new part, confirmed by starting a new sketch (which gets the obsoleted part rather than the new part.) Letting it update the obsolete part in the test sketch turns out badly (although it does seem to upgrade to the new part, just not correctly.)

and not much of the upgrade of the part appears to work. The bottom 5 connectors had rats nest lines and clicking on those is why the connections are green all the others are unconnected. The other two views are similar (breadboard being the worst.)

I’ll poke at it for a while longer, but I don’t think there is much hope of getting it to work properly. This is a simplified version where the only change is the pin numbering (where pins start at 0 instead of 129) in the hope this would work, but it is as bad as the original attempt and I don’t know why.

Peter

Thanks! I have analyzed the issue regarding the rejected connections and I was able to reproduce it with parts in the core too. I made another issue more focused on that: Part-to-part connections in BB causes connectivity issues in other views · Issue #3974 · fritzing/fritzing-app · GitHub
However, it seems fixable in the code and only happens in part-to-part connections (which are only allowed in the BB).

Unfortunately, I do not have any of them either (I have several versions of the L298 boards, but not of the VNH2SP30).

I do not have any :frowning:

I never used the replaceBy for pins. For parts works well.
The parts in the core bin need to be updated to use the new one. You need to change the file /fritzing-parts/bins/core.fzb

Right now, I do not have much time now to test/debug the obsoleting mechanism when replacing connectors.
edit:
Maybe we wait on improving all these parts and focus on developing the tools to do this work easily. E.g., improving the hybrid connectors, fixing the bug with part-to-part connections, and improving the code to obsolete the parts. Or at least, start with parts that do not need to replace connectors.

I eventually discovered this by grepping for the moduleId in the parts repo. So far I used the same modelIndex and that seems to work but I’m not sure it is correct. Its on my list of things to document (along with a number of changes to the obsolete.py script.) At the moment I’m trying to figure out what breaks the obsolete, I have a part that basically the original part with the pin numbers changed that works and am about to try changing the svg’s scales to see if that is what causes the failure (if not I’ll keep making changes til it dies :slight_smile: ) If anyone has the Pololu boards (which is no longer made by the way) it would be great to know if the grounds and battery connections are all connected together in the board, from the schematic on the Pololu site it certainly looks like it which means the current part is incorrect. There is a new board available (although it is listed as rationed) so perhaps a new version is in order. In any case I’ll keep poking at obsoleting to see what work needs to be done and documenting the process.

Peter

OK I have identified (and will report) the bug. It is changing a connector from female to male in the fzp file. Doing that causes this on upgrade:

in the obsoleted part all the pins are female, changing them to male causes the above on upgrade. A temporary workaround is to leave the pins as female (as it is relatively unimportant although desirable to fix inmy view!) I’m thinking I may make a new part for the upgraded board that replaced this one as well since I’m making changes anyway and maybe move a bunch more of the h bridge motor driver parts in to the same family (ignoring for now the question of whether a family should have the same number of pins to be swappable without problems which is still open!) At least I now know enough to create some documentation on obsoleting parts I think.

Peter