H-Bridge with L298N motor driver

microMerlin · August 17, 2022, 5:51am

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

fai · August 19, 2022, 10:07am

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 · August 19, 2022, 7:07pm

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

microMerlin · August 19, 2022, 9:46pm

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.

vanepp · August 19, 2022, 10:56pm

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 · August 19, 2022, 11:16pm

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.

github.com/fritzing/fritzing-app

connections are not being followed through bus definitions across views

opened 08:36AM - 17 May 20 UTC

mMerlin

## Current Behaviour The setup: The (custom) `arduino_uno_for_shields` par…t has multiple bus definitions. Among them are entries to connect the digital IO pins D11, D12, D13 to the ICSP1 header pins for MOSI, MISO, and SCK. The part contains connector definitions for all of those pins, but the ICSP pins deliberately do not include `schematicView` entries. Since they are bused together, and schematic view is a logical view, any connection (on any view) to D11, D12, D13 should also be a connection to the matching ICSP1 header pins. More on *should* in a moment. The `dragino_lora_shield` part also includes multiple bus definitions. Here, the ICSP pins are **NOT** linked with the digital IO pins. However, both the ICSP header and associated digital IO pins ARE bused to pins on a configuration header. Another bus definition in the uno part, is for the 5 ground pins. 4 of those pins exist on the shield (there is no ICSP2 header here), but they are left as individual pins, not grouped together by a bus definition. Holding mouse down on the bused pins of the individual parts in breadboard view shows the pin, and each of the bused pins, as yellow. In the current implementation, the pcb view for the uno is blank, but the shield exists, and the bused pins light up with mouse down on one of them. The schematic view has definitions for both parts, but currently none of the bused pins have more than a single representation, so individual part buses are not readily visible here. When the shield board is dragged over the uno part in breadboard view, the matching pins turn blue, showing a valid connection. When (aligned correctly and) released, those shield pins turn green, plus the extra header pins that are (both) bused within the shield part and are (now) connected to one of the uno pins. That is the configuration header pins that are bused to the digital IO or ICSP(1) header pins. In addition, the Arduino digital IO side of the enable jumper headers light up. The shield side of those jumpers stay red, but mouse down on them turns the bused shield digital IO pins yellow. With the shield `mounted` on the uno, mouse down on any of the bused connections turns the whole group yellow. Of note here are the ICSP(1), configuration header, and Arduino digital IO pins. Mouse down on (for example) D13 turns D13, ICSP1 SCK, SV2 pin 1, and SV2 pin 3 yellow. The uno part has D13 bused to ICSP1 SCK, the shield part has D13 bused to SV2 pin 3, and ICSP SCK bused to SV2 pin 1. With the shield part aligned/connected with the uno part, the 2 D13 pins are connected, and the 2 ICSP SCK pins are connected. So all 6 of the pins are connected. In breadboard view, they actually show as connected using mouse down on one of them. ![bb_sck_bus](https://user-images.githubusercontent.com/918823/82139494-5d7d0200-97e5-11ea-8176-8df3df5cd82e.png) ![bb_gnd_bus](https://user-images.githubusercontent.com/918823/82139488-5524c700-97e5-11ea-9ac9-585b388566c9.png) All of that looks correct, but PCB view does not show quite the same information. There are no uno connection pins to click on, but the pins for the shield are available. Mouse down on D13 here turns only it and SV2 pin 3 yellow. The connection to ICSP SCK, via the shield to uno D13 connection, uno bus from D13 to ICSP1 SCK, uno ICSP1 SCK to shield ICSP SCK is not seen, nor the extension of that to SV2 pin 1 through the bus on the shield. A simpler failure is the ground connections. Each of the 4 GND pins on the shield is connected to the matching GND pin on the uno, and all of the uno GND pins are grouped in a single bus. However, mouse down on the pcb view shield GND pins does not show any of the others as connected. ![pcb_d13_bus](https://user-images.githubusercontent.com/918823/82139508-7be2fd80-97e5-11ea-8d5d-22816baf89c0.png) ![pcb_sck_bus](https://user-images.githubusercontent.com/918823/82139511-800f1b00-97e5-11ea-8195-1c5e0cac5c0c.png) ![pcb_gnd_bus](https://user-images.githubusercontent.com/918823/82139514-83a2a200-97e5-11ea-8749-6e62e71661a1.png) The schematic view has issues as well. The GND pins of the uno and shield are not shown as connected. The 3V3 and 5V pins are connected, as shown by the ratsnest lines. The 3V3 is easy. There is only a single 3V3 pin on each of the uno and shield parts, and they are connected by the placement of the shield part on the uno in the breadboard view. The 5V is a bit more complex. There are 3 5V pins on the uno part grouped into a bus. Each of the 2 5V pins on the shield is connected to a matching 5V pin on the uno by the shield placement in breadboard view, plus the single schematic view 5V pin for each part is matched to the main 5V pin. The 2 5V schematic pins are hooked to connections that are directly connected in breadboard view. Like the 3V3 connection, no bus needs to be referenced to show the linkage. As described above, the 5 uno part GND pins are grouped into a bus, but the 4 shield part GND pins are left separate. For the schematic view shield part, the single GND pin is associated with the GND pin that is beside (in breadboard view) VIN. The single uno part schematic view GND pin is associated with the second power header gnd pin, which is beside (in breadboard view) 5V. In schematic view they are not connected. No ratsnest line, and nothing else turns yellow with mouse down on the pins. ![sch_no_gnd_connection](https://user-images.githubusercontent.com/918823/82139532-a0d77080-97e5-11ea-81a0-253456f56a7b.png) As shown on breadboard view, the 4 ICSP SCK pins are connected and grouped together. On schematic view, that is not visible. Mouse down on one of the D13 pins only turns it and the other D13 pin yellow. Mouse down on the shield ICSP SCK pin only turns it yellow. ![sch_d13_connection](https://user-images.githubusercontent.com/918823/82139536-a6cd5180-97e5-11ea-84d3-8de8d5d3d64e.png) ![sch_no_clock_bus](https://user-images.githubusercontent.com/918823/82139540-b0ef5000-97e5-11ea-821a-4c03dcab5944.png) The fact that the 2 physical pins are tied together, as defined by the bus definition, is not being seen as creating a connection between the GND pins in schematic view. Same for PCB view. The connections are not being followed from PCB view pin, to connected part pin, through connected part bus, back to another pin on PCB view. The schematic view case is simpler, since there is at least a GND pin from the bused group in the view, even it is not the one that is directly connected in the breadboard view. The pcb view does not have a GND (or any) pin for the uno. But in both cases, the internal connectivity information should be providing a path through the physically connected pins, and the bused pins that are grouped with them. Here is the sketch with custom parts that were used to generate the screenshot images. Remove the trailing .zip to open it. [bus_connection_ignored.fzz.zip](https://github.com/fritzing/fritzing-app/files/4639906/bus_connection_ignored.fzz.zip) **Build:** Version 0.9.5 (dCD-548-17-g694c4a08 2020-04-27) 64 [Qt 5.12.7] Same symptoms with Fritzing 0.9.4.2019-12-01.CD-498 **Operating System:** Fedora 31 Workstation 5.6.11-200.fc31.x86_64 **Steps to reproduce:** - Open the example fzz sketch - Mouse down on various pins in each view to see what is connected, and examine the ratsnest lines (only) in schematic view ## Expected Behaviour Every view should use the part bus definition information, and connections to the associated pins (in any view) when checking what should be connected by ratsnest or shown as connected on mouse down. The schematic should show a ratsnets wire between the part GND pins Mouse down on either GND in schematic view show show the other GND as connected Mouse down on Either D13 or SCK in schematic view should show all 3 pins as connected Mouse down on any of the shield GND pins in PCB view should show all 4 as connected Mouse down on any of D13, SV2.1, SV2.3, ICSP SCK of shield part in PCB view should show all of them as connected The GND pins in schematic

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.

fai · August 22, 2022, 9:14am

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.

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 · August 22, 2022, 2:53pm

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

vanepp · August 23, 2022, 8:35pm

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 · August 25, 2022, 1:58am

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.

github.com/fritzing/fritzing-app

parts with grouped pins don't connect correctly in schematic

opened 04:09AM - 15 Apr 20 UTC

vanepp

## Current Behaviour Four parts each with 2 pins one pair male and one pair f…emale, 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: ![Capture](https://user-images.githubusercontent.com/16514277/79297088-f1c81200-7e91-11ea-955f-15d208d45c88.PNG) Schematic: ![Capture1](https://user-images.githubusercontent.com/16514277/79297172-3e135200-7e92-11ea-8cd9-0dedc60cc7e0.PNG) 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](https://github.com/fritzing/fritzing-app/files/4479057/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.

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 · September 1, 2022, 10:08pm

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

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.

vanepp · September 1, 2022, 11:00pm

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

vanepp · September 2, 2022, 9:51pm

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

fai · February 25, 2023, 10:36pm

Hi @vanepp !
Finally, I pushed the L298N module to the fritzing parts repository, pull request: added L298N module (motor driver) from the forum by failiz · Pull Request #361 · fritzing/fritzing-parts · GitHub

Regarding the other one, I guess we will have to wait until there are clear guidelines (and scripts) for obsoleting parts. I saw your PR, but I guess that developers are busy trying to publish the next release. Hopefully, we will be able to fix and organize the parts soon.

vanepp · February 26, 2023, 5:56am

It is easy enough to submit a pull request to change the female pins to male and once that is committed do the obsolete from the now male pins (which doesn’t break) as I’m not sure the male to female pin fix is going to be all that easy.

Peter

microMerlin · February 26, 2023, 12:07pm

That 2 step sequence might make it through the process, but I suspect could break existing sketches. Any sketch with the problem part that does not get opened after the first commit will probably have the same problem currently identified when the ‘real’ fix is done with step 2.

vanepp · February 26, 2023, 3:35pm

Good point! I hadn’t thought of that one. I probably need to try it and see what happens first. Thanks!

edit: Yes as far as I can see that is a problem. So on to plan B. Make the changes except for the female pins (leave them female which won’t hurt anything) and make a pull request for the Dual VNH2SP30 Motor Driver. As that board is now obsolete I may make a new one for the current board (which won’t have obsoleting problems) as well.

Edit2:

Here is the promised new part for the replacement for the Dual_VNH2SP30_Motor_Driver (fighting bugs in obsoleting got old so I decided to make a part which i am usually successful at )

Dual_VNH5019_motor_driver.fzpz (22.4 KB)

and here is a new version (with some more bug fixes!) of the Dual_VNH2SP30_Motor_Driver which is having obsoleting problems.

Dual_VNH2SP30_Motor_Driver.fzpz (13.8 KB)

and its test sketch for obsolete testing (which I just realized won’t be useful without its obsoleteing fzp file
so here it is (from

obsolete/Dual_VNH2SP30_Motor_Driver.fzp

Dual_VNH2SP30_Motor_Driver.fzp (16.0 KB)

in the parts repo with the files from the fzpz installed in the core and svg/core directories. As well you will need this copy of bins/core.fzb as it needs a change too

core.fzb (49.8 KB)

So far the problems I have seen are that obsoleting doesn’t update the version field correctly (it leaves the version as the original (details in this issue on github)

github.com/fritzing/fritzing-app

obsoleteing doesn't correctly update the label field

opened 10:13PM - 28 Feb 23 UTC

vanepp

## Current Behaviour Load a sketch with an obsoleted part (Dual_VNH2SP30_Moto…r_Driver in this case) ![capture](https://user-images.githubusercontent.com/16514277/221991414-cc683d8d-b366-4528-bd32-2f5941ad11ed.jpg) say yes to the update ![capture1](https://user-images.githubusercontent.com/16514277/221991518-d3a46330-13ad-4308-b509-ff7ddd3ca5e9.jpg) Load the updated part from core parts. Its label is A1 (which is what is set in the part) but the label on the updated part is still the old label MD03A1. ![capture2](https://user-images.githubusercontent.com/16514277/221991557-db8a6d74-7b7c-4d5d-844e-2021c7c74139.jpg) This appears to be because of the title field in the .fz file for the upgraded obsoleted part it remains MD03A1 instance moduleIdRef="DualVNH249121052c4ad42279a5b27945f1a08b2" modelIndex="6486" path="C:/Program Files/Fritzing/fritzing-parts/core/Dual_VNH2SP30_Motor_Driver_7756e52_2.fzp" property name="part number" value="MD03A"/ title>MD03A1</title for the part loaded from core parts (and then saved as f .fzz file) the title is the expected A1 from the part. edit try quoting the xml as it got eaten by the post and I don't know how to escape it on github ... quoting didn't work so remove the greater than anad less thans. instance moduleIdRef="DualVNH249121052c4ad42279a5b27945f1a08b2" modelIndex="5848" path="C:/Program Files/Fritzing/fritzing-parts/core/Dual_VNH2SP30_Motor_Driver_7756e52_2.fzp" property name="part number" value="MD03A"/ title>A1</title To me it appears the obsolete mechanism isn't updating something during the update which leaves the title field with the old value. **Build:** Version 0.9.10 (bCD-2134-0-40d23c29 2022-07-01) 64 [Qt 5.15.2] **Operating System:** Windows 10 **Steps to reproduce:** See Current Behaviour above ## Expected Behaviour The label field for the part gets updated to A1 after the obsolete completes.

and it appears to not update the url field in the upgraded part (the resulting file doesn’t have the url in it. I’ll continue poking at the obsoleting issues and see what I can find out, but if someone else wants to have a bash, go for it!

Peter

vanepp · March 4, 2023, 6:47pm

OK, I have made pull requests for both the Dual_VNH2SP30_Motor_Driver obsoleting the old one and the replacement Dual_VNH5019_motor_driver (the VNH2SP30 is no longer available) as a new part.

Peter

vanepp · March 6, 2023, 12:33am

OK, I’m writing off github. I tried to modify a pull request to correct some problems and github tells me:

$ git push GitHub - vanepp/fritzing-parts: Electronic components for use in the Fritzing app (aka the parts library)
Username for ‘https://github.com’:
Password for ‘https://vanepp@github.com’:
To GitHub - vanepp/fritzing-parts: Electronic components for use in the Fritzing app (aka the parts library)
! [rejected] Dual_VNH2SP30_Motor_Driver_2 → Dual_VNH2SP30_Motor_Driver_2 (non-fast-forward)
error: failed to push some refs to ‘GitHub - vanepp/fritzing-parts: Electronic components for use in the Fritzing app (aka the parts library)’
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: ‘git pull …’) before pushing again.
hint: See the ‘Note about fast-forwards’ in ‘git push --help’ for details.

So I give up, github is too much for me. I think I managed to get the Dual_VNH5019_motor_driver part (which is a new part) up in a pull request, and I deleted a pull request for obsolete.py and the Dual_VNH2SP30_Motor_Driver_2 pull request above. I may try and redo the obsolete.py one again, but other than that I don’t know how to update parts on github and I’m going to stop trying. This is a zipped copy of the files for Dual_VNH2SP30_Motor_Driver_2 with its obsoleing information and the .fzz file that tests it, so perhaps you can get a pull request for it to work (I’d advise checking that the .fzz file works correctly to make sure I didn’t miss any files when copying the changed files from the repository though.)

Dual_VNH2SP30_Motor_Driver-files.fzpz (44.7 KB)

frustrated Peter

fai · March 8, 2023, 2:29pm

Hi Peter,
I am sorry to hear your frustration. I have been there too. Sometimes, git is annoying.

When I make a pull request, you are asking to merge one brach with another branch. Thus, once is open in github, you do need to anything else. The next commits and pulls to your vannep/fritzing-parts (on that branch) will be automatically added to the pull request. I guess that you are doing that too.

I cannot see your computer, and it is difficult to see what is going on. Are you using any program or just the terminal? I usually use SourceTree which allows to visualize the changes and branches. If you are using the terminal, could you write all the git commands that you used?