thanx for the parts L298N
Thanks, it’s a great part!
As @Navrug mentioned, it would be useful to get the schematics too. I tried to directly edit its SVG or replace it with the one from:
but with no luck… 
If you have a url for the board (a quick google search doesn’t find one) which has the mechanical dimensions and the pinout I’ll have a look at creating schematic and pcb (despite the claim “all working” pcb and schematic are both broken in the part above.)
Peter
1 Like
Thank you!!! I’ve already found the pinout, but it’s quite difficult to find the datasheet with measures… I’ll keep trying! 
Edit: @vanepp, I could have found it.
The linked data sheet includes outer dimensions for the board, but to create an accurate part the offsets to the connections is also needed.
That said, this is a “board” so it does not really have a PCB footprint beyond the mounting holes, so the pdf would be enough to create a usable part file.
OK here is an improved part with schematic and a somewhat odd pcb. Since a pcb won’t really fit this, pcb here has the outline of the board (which someone with a board needs to check for accuracy!) which as @microMerlin said is really only the mounting holes, but has a 6 pin header which you can install and run wires to the appropriate pins on the module.
L298N-DC-motor-driver-improved.fzpz (28.3 KB)
Peter
1 Like
Thank you for this part.
Hello…I’m using the l298n motor driver for my sensor based car the sensor is working but the motor is not rotating when I check the voltage at out1 and out2 it is zero then I had used to power source one connected Arduino and another to l298 still not working.
Check that you have the enable pins connected to +5V either by installing the jumpers between ENA and 5V (just above it) and ENB and 5V on the other end or that you are driving them from the micro with a high level. If they are low the motor won’t run. Also check the L298N ground is connected to the Arduino ground (if not, none of the signals will be driven!)
Peter
Pls Help me find this componen, i need this type of fan motor driver
We would need a web site for what you want. I’d guess it is probably this
but the site for what you have would be needed to find or make a part.
Peter
That’s an awesome H-Bridge! 
hi peter,
is this h-bridge 100% functional on all 13(!) connections?
so long
pc
Assuming you are referring to the l298n part there are 17 connections and they are all functional.
Peter
super ! … 17? (but with jumpers)
Yes, both the 5V enable and the two 5V power pullups are intended to be jumpers but need to be connectors in Fritzing.
Peter
well done !
pushbutton works, too …
thanks very much …
My students use this part a lot and I would like to put it as a core part. However, to keep cleaning the core parts, I think there are necessary a couple of small improvements.
- The label is currently “Mod”, but we agreed to use “A” for assembled boards like this one, see Suggestions for additional documentation
- The family is set to “L298N-motor-driver”, but maybe it is very specific. A similar core part, MD03A1, has “motor driver” as family, which is the opposite end (very unspecific). I suggest changing both of them to “H-bridge motor driver”.
- Change the variant from “variant 1” to “L298-Module”
- The pins in the PCB are outside the silkscreen. Is this correct?
- The description has an excessive return of carriages between the different paragraphs.
Thoughts?
If we make these changes, do we need to obsolete the parts?
My changes were made before we moved to A for assembly, so that is trivial to change and should be changed.
I tend to use very specific to the module family names so there is little chance they will conflict with a core part. I agree that we need a better standard for family names, @microMerlin likely has opinions on this topic too 
, I think he prefers the rather non specific so you can choose a part based on a family name. I suspect the correct answer is to start a discussion on how we would like to see the family standardized and then write that standard (which as far as I know hasn’t happened yet.) Until that discussion is settled I have no problem with naming them both H-bridge motor driver with the variant being the model of the part. Again easy to do and easy to change if we manage to come up with a standard it doesn’t meet.
Yes. This board is entirely screw terminals. The idea is the pins are outside the board so you solder wires in to the pads and run the wire to the screw terminals on the module (as that is the only way to connect to it.) It just isn’t specified anywhere but maybe in the forum post (and maybe not anywhere )
They can and should be removed assuming I can figure out which of the html markups are doing them (I’m not particularly html literate 
)
A search for MD03A1 in core parts on 0.9.10 isn’t coming up with anything, I’ll try a broader search and see what appears. A search for motor driver doesn’t show anything either (other than a lot of motor drivers that should be probably combined in to one family.) Do you have a search term that will bring it up in core parts on 0.9.10 or have you possibly loaded an external part that is being found? If it isn’t in core parts it shouldn’t need obsoleting.
We also at some point need to sort out and document obsoleting. The current requirements are I think broken, just changing the view box size appears to be able to break obsoleting as I recall from a previous go around trying to obsolete something.
Peter
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.
Yes
I can help with that. I don’t do a lot of html, but it is in the skill set. Whitespace is straight forward once some basic concepts are understood. About where things are collapsed to a single space, or kept as is. This mixes with css, which might not be understood by people getting started.
For this, I believe you mean the feature that allows replacing an obsolete part in a sketch with it’s new version? Yes, the interactions are very unclear. 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.