H-Bridge with L298N motor driver

[vanepp]

@microMerlin

Done ‘correctly’, I see this as expanding on, instead of conflicting with. I believe that Inspector will allow switching between core and custom parts that have the same family name. As long as there are matching property names with unique values.

AFAIK this is correct with the limitation (which I think is a bug) that unless you save the part in the bin Inspector doesn’t recognize it. Just loading the part, Inspector doesn’t allow you to change (the parameters are greyed out.) Closing Fritzing and saving the bin fixes that and then it works as expected I think.

@microMerlin

I strongly suspect that (a large part of) the real problem is in the code. Documenting what the current limitations are is a start, but it should be possible to handle a lot more cases than currently work as expected.

I think this is true, but seems to have a low (perhaps justifiably) priority with the developers. I expect parts editor improvements and urgent bug fixes are taking all available time. Since there aren’t many new parts submissions it is hard to argue against the low priority.

Peter

[vanepp]

OK here is an updated copy of the part. Label changed to “A”, family “H-bridge motor driver” variant “variant L298-Module” and the description replaced with a shorter text version (which avoided me figuring out the html .) I don’t know where the other motor driver is to change that.

L298N-DC-motor-driver-further-improved.fzpz (27.9 KB)

Peter

[fai]

Great @vanepp !
The other motor controller is the core bin:

It is the MD03A.

There are also other H-bridges in Fritzing:
h-bridge.fzp which is in the IC family!

The Motor controller family:
MonsterMoto-Shield-v12.fzp:Motor Controller
quadstep-v12.fzp:Motor Controller

And the motor driver family:
grep -ri “>motor driver</p”
A4950_37.fzp: motor driver
Dual_VNH2SP30_Motor_Driver.fzp: Motor Driver
EasyDriver_v44.fzp:Motor Driver
FRM050.fzp: Motor Driver
L293D.fzp: Motor Driver
Rotoshield-1.0a.fzp:Motor Driver

I would only make minor adjustments in these fpz files unless these parts have critical issues. Basically, changing the family, label and variant. If we need to change the svg files, we need to obsolete them, which takes much more time.

[vanepp]

I must be getting blind! Now when I enter MD03A in the search box it comes up, when before it didn’t (or I mistyped the part number .) A quick looks says it needs svg changes, the pin numbering starts at 130 (perhaps created from eagle2fritzing?) and should be converted to start at 0. The svgs may not meet the graphics standards either but I haven’t yet looked closely. I’ll have a closer look at what needs doing to clean it up.

Peter

[vanepp]

OK here is a trial part for the MD03A part. It is a trial part because it currently requires obsoleting because the pin numbering has changed. I’m willing to try and figure out obsoleting and see what happens (i.e. how successful the upgrade is.) as well there are options for schematic other than the one I have chosen, a different one may suit your purpose better. The original bb is not that bad, the major problem is the pins start at 129 and go up. They should start at 0 but that will require obsoleting the part to change the pin numbers (which I am in favor of!) For comparison purposes I rescaled the svg to the correct scale so 1 drawing unit is 1/1000in this is the original svg

Of note here is the first pin is connector129pin (and is out of sequence!) and the coordinates in xml editor have digits after the decimal sign (less that 1/1000 of an inch!) which are not useful and should be rounded for better clarity (at least in my opinion!) Then I rescaled the svg to be correct (1 drawing unit = 1/1000inch) and cleaned up the alignment of the pads and text. While doing that I rounded the numbers in the xml to 1/1000 of an inch (we don’t need more than that and it can be automated by a script with some work for exceptions that need more precision.) I also renumbered the pins to start at 0 and increase sequentially (unlike the original!)

This has the effect of aligning the pins on exactly (within 1/1000 of an inch) to the 0.1inch grid.I also converted the strings that were individual characters in to strings which makes them easier to modify (as well as the svg slightly smaller.) The major change is the pin numbers starting from 0 instead of 129. This will require the part to be obsoleted to adjust the pin number mapping (which I am in favor of doing so we don’t have to visit this part again later!)

On to schematic

This is the original schematic, again the major change is pin numbering, but there are a few more issues. The pins are 0.2in long rather than the preferred 0.1in and the colors don’t conform to the graphics standards.

I chose to use Randy’s schematic Inkscape extension to make a new schematic in my favored format:

The pins are renumbered to start at connector0 and the xml numbers are rounded to 1/1000 of an inch. The overall layout mirrors breadboard (which I find more useful when debugging, but others may not like!) That means there are no pins such as ground overlaid to create one connection. The downside to this is that Fritzing will not let you make a connection to a ground pin if there is already a connection to the ground net somewhere else in the same net. That can be confusing to a new user and I believe is the main reason for using overlaid pins. I like this because if I am debugging on the actual board the schematic pin is in the same position it physically is on the board which makes it easy to find in schematic. We could chose to move all the ground pins to the bottom and all the power pins (overlaid to give a single connection point) on the top if that would suit better. If we leave the pin numbers as is (starting at 129) we can avoid doing the obsoleting, but as noted I would prefer to renumber the pins. I can have a look at figuring out how to do that if you like.

on to pcb

Mostly more of the same, rescaled, renumbered to start at connector0pin with the numbers rounded to 1/1000 inch. In a number of cases I changed the pins from paths to circles as circles are easier to change (and get a consistant hole size from!) than paths.

on to the fzp

add version tag set the version to 2 (assuming the original was version 1!)

update the Fritzing version to 0.9.10

add my name to author

change label from MD03A to A (for assembly)

change family from “motor driver” to “H-bridge motor driver”

change varant from “variant 2” to “variant MD03A”

moved the url from the decription to the field

added missing silkscreen layerId to the pcb layers.

renumbered the pins with standard boiler plate connectors, copy the descriptions from the original as the original has incorrect svgIds!

add buses which are missing in the original part! That results in this test part which has all of these changes. See if you would prefer a different schemematic layout.

Dual_VNH2SP30_Motor_Driver.fzpz (11.9 KB)

Peter

[fai]

Hi @vanepp ,
we can obsolete the part if it is necessary. In this case, we do not have to reuse the svgs in other files, and maybe we can use Fritzing´s script: fritzing-parts/obsolete.py at develop · fritzing/fritzing-parts · GitHub It has some limitations (obsoletes all svgs and other issues), see discussion here, but it may not be an issue for this part.

Regarding the schematic symbol, I prefer the original one. Schematic symbols should be grouped by functionality rather than their position in the physical package. This makes them easier to understand and to route. See for example KiCad guidelines section S4.2.

Regarding stacking ground and power connections, I think we may not need to do it. If they are all visible, it is easier to understand that several of them exist and we avoid issues with Fritzing. It definitely should be easy to use for new users.

[vanepp]

OK here is a new version of the part with a schematic modified back to the original. The power pins are set on top and bottom as recommended by Kicad but are overlaid on one another because if we are going with schematic as an abstract view that is more correct. The pins that are over laid have their stroke (except for the 1st occurrence) set to none so they are invisible (leaving the stroke set makes the pin bolder when rendered.) I think this is one of the things that should be standardized, what exactly a schematic in core parts should look like (obviously with external parts schematic can be whatever the poster wants, the only place we really have control is core parts. I expect @KjellM and @microMerlin will want to comment, but any one else that has an opinion is also welcome to chip in. I know in the past (when the forums had many more participants!) this was a contentious issue with a number of folks not wanting any standard applied. I suspect (as I did then) having standards for core parts is desirable for a variety of reasons, mostly consistency so when people clone a part they start from a part that is properly configured. This currently is not the case in core parts, but eventually I hope to clean that up but first we have to agree on a standard which may not be easy.

Dual_VNH2SP30_Motor_Driver.fzpz (8.8 KB)

Peter

[microMerlin]

Given the current code constraints, your description matches my preferences. If the code worked better with buses, combined with excluded pins in the schematic view, that would seem the way to go. Visually (and electronically) it would give the same result.

[vanepp]

@microMerlin

If the code worked better with buses, combined with excluded pins in the schematic view, that would seem the way to go. Visually (and electronically) it would give the same result.

Then maybe that is what to hope/ lobby for. Cleaning up core parts is going to take a long time, so code changes have time to come to the rescue. If work is being done on buses, I would like to see the restriction of only schematic subparts or buses not both removed. I don’t see why the restriction is there now, I assume a shared data structure of some kind.

Peter

[microMerlin]

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

[fai]

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:

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:

[vanepp]

@fai

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

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.

@fai

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 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.

@fai

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.

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.

@fai

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.

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

[microMerlin]

@vanepp

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.

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.

@vanepp

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.

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.

[vanepp]

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

[microMerlin]

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.

connections are not being followed through bus definitions across views

Here are my own notes about a possible solution:

The documentation for Hybrid connectors needs to be expanded. Latest symptoms say that to have a connector in the part definition, it needs to exist in the svg for every view. To make it invisible, where it can not be selected, will not have wires or rats nest lines attached by Fritzing, the connector definition (for that view) needs to have the hybrid=“YES” tag, and the connector «pin¦terminal¦pad» svg graphics element(s) need to be invisible (stroke=“none” fill=“none”). With that combination connectivity based on bus connections seems to be maintained, with ratsnest wires connecting to the nearest other connector for the bus.

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.

[fai]

@vanepp

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.

I do not think an issue with this sketch.

@vanepp

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!)

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

@vanepp

The second connection to ground should refuse to connect (I have seen it do so before but don’t remember what part it was!)

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.

@microMerlin

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.

It seems that this is mostly a documentation issue.

@microMerlin

There is still some oddities about what information hover will display for the visible pin.

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.

@vanepp

The reason for the pin numbers (which can be fixed by using the pin number rather than the connector number)

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

@vanepp

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.

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?

[vanepp]

@fai

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 .”

Yes, I missed that part of the wiki.

@fai

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.

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

[vanepp]

@fai

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

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

[vanepp]

@fai

@vanepp

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.

I do not think an issue with this sketch.

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.

parts with grouped pins don't connect correctly in schematic

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

[fai]

@vanepp

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.

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).

@vanepp

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.

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

@vanepp

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?

I do not have any

@vanepp

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.)

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.