PIC16F628
PIC16F628_V1.fzpz (7.2 KB)
PIC16F628_V2.fzpz (7.6 KB)
↧
New Part: PIC16F628
↧
New Part: PIC16F628
Looks good, (V2 better than V1 
), but you need to set the fzp file to
<label>16F628</ label>
instead of
<label>IC</label>
and probably
<property name="chip label">16F628</property>
instead of
<property name="chip label">IC</property>
(although I think the label field will be what it uses to label the svg.)
So the chip in breadboard is called 16F628 instead of IC as at present.
Peter
↧
↧
Part request TO252 DPAK MOSFET
↧
Part request TO252 DPAK MOSFET
Yes it shows as TO220 in breadboard, but the footprint in pcb is smd. It is hard to show smd parts in breadboard, the usual answer is a carrier board that converts from smd to dip to get the .1 in spacing breadboard uses.
Peter
↧
Tiva C LaunchPad TM4C123GXL
Tiva C TM4C123G.fzpz (38.2 KB)
↧
↧
FRC parts for review
Now the roboRIO part. For this one I switched to a part that I made a couple of years ago that had the schematic already. The delay in posting this was caused by cleaning up a 2+ year old part (I knew a lot less about part making at that point) but it is now done and I have some improved tools for cleaning up parts because this was to complex to do manually in any reasonable amount of time.
roboRIO.fzpz (221.6 KB)
breadboard
schematic
The power and grounds have been bused, one thing I’m not sure of is if the alternate connections on the MXP connector for SPI and I2C are shared with the associated pins on the dedicated SPI and I2C connectors. I have assumed not (the manual doesn’t say and I don’t have a unit to test). If they are common, then additional bus elements need to be added to indicate that.
↧
Tiva C LaunchPad TM4C123GXL
Not a bad part, but it has a number of problems. When I started to clean it up I discovered there is already a TM4C123GXL part which looks (as far as I can see) identical done about a year ago. I cleaned it up some, but was apparently lazy and didn’t do it completely. I will fix it up to be a core level part and repost it. In your part the main user visible error I see is the j4 / j2 labels in breadboard (and possibly the underlying pin numbers) don’t match the board shown in
http://www.ti.com/lit/ug/spmu296/spmu296.pdf
the first one is correct, but the rest are backwards PB2 PF3 instead of PF3 PB2 as in the pdf and the other part. Schematic isn’t aligned on .1 boundaries and pcb doesn’t have the correct hole size for header pins (it looks like I didn’t do anything with pcb on the original part, so it is likely wrong too).
Peter
↧
TI Launchpad TM4C123GXL
As someone has submitted a new part that has problems, I came back to this part (which previously had a non fuctioning pcb view) and corrected it to be a fully functional part ready to be submitted to core, which I will do in due course. As I changed the pin numbers to be in sequence this part has a new moduleId as it isn’t compatible with the fixed part above.
TI Launchpad TM4C123GXL_complete.fzpz (39.2 KB)
Note all the non connector populated debug pads are present in this version as well.
Peter
↧
Proposed parts factory change
I’m (slowly) working on making some fixes to the parts factory code. As part of that I intend to fix the dual row header code which is currently broken in breadboard (it doesn’t generate a dual row header although it does in pcb). As part of finishing off the TM4C123GXL part I implemented a new layout in schematic which I intend on trying to make parts factory emit in the case of a dual row header:
in this schematic the two center 20 pin connectors are dual row (manually done on breadboard). The change is the two drawings after the pin labels which show a picture of the actual connector and associate the schematic pins with their physical connection on the header. It may be necessary (or desirable) to be able to select whether the extra picture is there or not. I’m putting this here to see if anyone sees a problem that I am not with doing this. Comments are welcome. If you want to see this in an actual sketch, download the new TM4C123GXL part I just posted, that is where this schematic came from.
Peter
↧
↧
FRC parts for review
Next the TalonSRX. This part needs a good review (preferably with the hardware at hand, because the documentation isn’t clear) as it is essentially a new part. The original part didn’t have the data port implemented, which is likely fatal, as that is where the encoder (one of the previous parts) connects. While reading the documentation to figure out the pin numbering on the data port I tried to swipe the image in the pdf for breadboard. It turns out that image is a bitmap and Inkscape (or me using Inkscape ) had trouble converting it to vector. So I recreated it using lines, somewhat time consuming but successful I think. The CAN ports appear to be under the negative input wire but the documentation isn’t clear. So I moved them (on .1 boundaries) to beside the negative input terminal and assumed CAN 0 is closest to the negative wire (that needs to be moved if that isn’t the case!). The data port is shown with the dust cover removed so the connector is visible.
New part:
TalonSRX.fzpz (14.1 KB)
Original part:
TalonSRX-orig.fzpz (5.1 KB)
breadboard
schematic
The connection in the middle of the pin is caused by no terminalIds in the svg.
Peter
↧
FRC parts for review
On to the VRM module. This one has relatively few changes.
VRM-orig.fzpz (8.9 KB)
VRM.fzpz (9.8 KB)
Breadboard
most of the change here (other than rescaling and correcting colors and font sizes which are by and large invisible) is to reduce the size of the connectors to more closely match the size of the tabs on the real unit.
schematlc
More changes here, as the original has only 16 pins against the 18 in breadboard and thus schematic was entirely broken (the red screen of too few connectors, or in this case the green screen with two connections to the center of the part).
as with most of these pcb is surpressed as not useful.
Peter
↧
FRC parts for review
Now the final part, and a new (to me at least) Fritzing bug, the YumoE6B2 encoder.
YumoE6B2-orig.fzpz (5.0 KB)
YumoE6B2.fzpz (6.5 KB)
breadboard:
There are three parts here the previously posted (but now updated) AMT103 encoder and the YumoE6B2. The most user visible change in breadboard is changing the connection to a cable as in real life with the wires color coded according to the data sheet.
schematic
here we see the new Fritzing bug: The first encoder was originally enc1 (instead of the current cui-enc1) however with the YumoE6B2 also with label enc there were two enc1s which were different parts. We need to find out a way to detect a label is already in use and increment the count (even across different parts) to avoid confusion. Otherwise schematic is pretty identical, I added terminalIds to get the pin join proper and reduced the size of the encoder outline to save precious schematic space. Unlike most of these parts, both encoders have a pcb section as they connect via wires to (probably) .1 in headers on a board and are useful in places other than the First parts. Since it is unlikely the encoder would be mounted on a PCB, I removed the encoder outline from pcb silkscreen. As well the original part has a problem in pcb, where it is only one layer (I didn’t check to see why), it only appears and is routable on the bottom layer instead of both layers as in the new part.
This should be all the parts in the pull request, so once the author checks them to make sure I haven’t screwed anything up we should be able to submit them to core parts.
Peter
↧
Part not meeting
Hi all, am trying to use a Part, a Conductive button from the sparkfun library, but the copper doesn’t meet on the pcb connections, its noted as a working part so im wondering if there is something in my settings?.
I have tried enlarging the element in the SVG that the track connects too
but it still doesn’t meet. Anyone have any advice? Thanks in advance.
↧
↧
Part not meeting
↧
Part not meeting
↧
Part not meeting
You are likely seeing this Fritzing bug:
which isn’t fixed yet. I assume you added the square pads external to the part, if so that is what is causing the DRC errors. If you add the square pad to the copper layer of the pcb svg so it is part of the part the drc error should go away. If you post the .fzz file above (upload is the 7th icon from the left in the reply menu) one of us can have a look and find you a solution. A narrower trace than the wide one should also fiz the problem without needing the square pad should also fix the problem.
Peter
↧
A PCB 'Board' Making App For Use with Fritzing (Preliminary)
After gaining enough knowledge about making SVG’s and their use in Fritzing, I decided to write an App to facilitate making a custom ‘Board’. Originally, I intended it to be a Plug-In but now focusing on Stand-Alone…
The main goals are:
• Make it easy for users that don’t want to bother with Graphic programs such as Inkscape/etc.
• Include ability to make:
• Multiple Cutouts
• V-Cuts
• Custom Board Shapes
• Usable for Fritzing’s Gerber export files (including Contour and Silkscreen files)
• Keep it Simple by allowing only Straight Lines (no Curved lines)
This is a Video preview of the App - I intend to release it soon and wanted to get some comments on usefulness and if worth the time to go through the hurdles…
The Shape and Cutout Data was previously done and video shows them being loaded.
Rather than posting a ‘beta’ here, This video should convey the general use.
Also, below are screenshots of the Exported Silkscreen with markings of how the Data Points for the tables should be done (Board-Shape is ClockWise, Cutouts are CounterClockWise for SVG’s intrinsic differencing).
Also below, an Example of Two PCB’s on a single Board (for cost savings when having them made). The boards are separated by a 0.2mm wide Rectangular Cutout (for a V-cut) with holding tabs at each end…
(Note: V-Cuts are simply a milled cut using a V-bit but, some vendors use a Straight bits or Lasers (i.e., No ‘V’)
Comments, Idea’s… Thanks
↧
↧
Script to automate connector creation in the fzp file
I have cleaned up, documented and released on github a python script to add or modify terminal definitions in the fzp file. There are two major uses: renumber a fzp file whose pins are out of order / out of sequence or add more connectors to an existing fzp file. The script can be found here:
It creates a file with the xml boiler plate for connectors like this:
FritzingCreateFzpConnectors.py t 1
which creates file t (and complains if it already exists) which contains this:
<connector id="connector0" type="male" name="">
<description></description>
<views>
<breadboardView>
<p svgId="connector0pin" layer="breadboard"/>
</breadboardView>
<schematicView>
<p svgId="connector0pin" layer="schematic" terminalId="connector0terminal"/>
</schematicView>
<pcbView>
<p svgId="connector0pin" layer="copper0"/>
<p svgId="connector0pin" layer="copper1"/>
</pcbView>
</views>
</connector>
The expectation is you will use a text editor to add/replace the connectors section of the fzp file with the contents of the file the script generated. If you increase the first number (the number of connectors to create) it will create more in sequence. If you add another number after the count such as:
FritzingCreateFzpConnectors.py t 10 4
it will create connectors 4 to 14 in sequence. Getopt type flags allow you to modify the output in various ways I find useful. Note that the name and description fields are blank, ready to have appropriate text either copied in to them from an existing fzp file (if you are renumbering the fzp) or have values appropriate to the pin added manually. You can also suppress the pcb view section of the connector (you need to manually remove the view definition though) if you don’t want or need a pcb view in the part. This assumes you are manually editing the part files (which is what I usually do).
Peter
↧
A PCB 'Board' Making App For Use with Fritzing (Preliminary)
Looks good, although I’m a poor one to comment because I rarely make boards , that said easier is always desirable.
Peter
↧
Project ERROR: Easiest to copy the Boost library to ..., so that you have .../boost_1_xx_0
Hi, all:
I actually manually installed boost via sudo ./b2 install, it seems there is NO boost.pc generated in ANY pkgconfig. In such, I always obtained the ERROR message:
Project ERROR: Easiest to copy the Boost library to ..., so that you have .../boost_1_xx_0
Just wonder how to modify pri/boostdetect.pri to have the manually installed boost detected?
Cheers
Pei
↧