Now that development is starting again, there is some hope of a fix. It is still unclear (at least to me) how this problem occurs though. I suspect it may be permissions on files (and Fritzing not checking return codes on file writes). I’ve never seen the problem on Win 7 Pro, but I don’t have OneDrive or netbios file sharing enabled and that may be why.
Peter
Hi vanepp
Actually I saw it, but as hoping there’s a simple and easy way now, via the GUI,
instead of messing with the data files…
So that is my question now…
If it’s possible to do it via the GUI, as a supported feature…
Not as far as I am aware, as I said I haven’t done it. Unfortunately development died for the last couple of years and is only now restarting so capabilities haven’t changed any from the posts you see. Most of the fancy stuff such as v cuts isn’t technically supported but we have found work arounds that at least work if not easily.
Peter
Without knowing the purpose for ‘your’ v-cut, I can only assume you want to section the board.
One way to do that is this post. Note, I’ve updated/posted several posts on making a PCB ‘Board’ with cutouts. Line-cuts are just as simple to do.
Consider this info:
• PCB’s have different thicknesses, thus, cutting through and not-cutting through… i.e., the Depth of C-cut.
• If paneling is the goal (for snapping off smaller pcb’s) a normal cut is all you need.
• Identifying what the Vendor should do is recommended - add Notes to the Request For Quote (RFQ).
• Some manufacturers use Laser to cut - thus, no V-Cut. The Kerf is a clean cut.
• Some manufacturers use CNC/Mill to cut - they can define “Holding Tag’s”. Again, add Notes to RFQ (Holding Tags usually have a shallower height (versus the board thickness) to make snapping-off easier.
not being an E. engineer I’m not going to say something is wrong, but it appears capacitor C9 in the sample file (breadboard view) is flipped the wrong way, can someone verify this for me? Also, the wire on pin 21 (AREF) to the positive rail on the ATMEGA328 is troubling me. In several other breadboard examples (online) it is not there is this incorrect also? or perhaps optional? being just a hobbyist I cant be sure and with Digikey selling me all there non-working crap (I.C’s, PIC’s, crystals…) I have yet to get this circuit working properly.I Replaced ATMEGA328 from Digikey with Mouser’s and bootloaded just fine, Digikeys did not. All that remains to check/ (replace with Mouser parts) is the crystal and 22pf capacitors. this circuit seems to have a very generic setup across the board but mine doesn’t work. Faulty diagrams and faulty parts are all that’s left unchecked that’s why I’m here, to eliminate the faulty diagram, can anyone help? Thanks in advance for any responses.
You are correct, C9 is backwards in the example. I’ll see what I can do about getting it corrected, although that likely won’t be til the next release. A quick look indicates the .fzz file is in the fritzing code directory so the .fzz can be updated manually there before the next release. If you connected it as shown you may have damaged C9 and would be advised to replace it as it may cause power problems and be the source of your trouble.
It is optional. It is for an external voltage reference for the a/d converter. There is an explanation of the options here:
https://forum.arduino.cc/index.php?topic=116511.0
with it connected to 5V the A/D should just work, with it floating you may need to set the bit to connect it to internal 5V (if that isn’t the default which I didn’t check).
This I find quite odd. I’ve dealt with digikey for 40 years or more and never had a problem. The one time they did screw up and shipped the wrong part, they shipped the right part the next day without problem. I suspect something other than parts supplier is at work here, possibly power problems, as micros are quite sensitive to undervoltage on VCC probably especially during programming. How are you programming it? I don’t see a programming connection in the example circuit, although I agree if a 328 from mouser accepted the bootloader and the digikey one doesn’t using the same programmer that does indicate a problem. They are also static sensitive so that is a possibility as well (although I’m usually careless and have never had a problem that way). This circuit is quite simple, and so should work, what I would do is check the programming after you flash the chip. Hopefully whatever you are using to program has a verify mode which can read the chip after it is programmed and compare every byte in flash with the program file to make sure the programming occurred correctly. I’d start with the blink program (you will need to put a led and a resistor on the pin the arduino uses, D13 usually). I have the luxury of both a scope and a logic analyser which makes hardware debugging much easier, without them things are a lot harder. If you have a scope check the VCC supply to make sure it is always 5V (and not dropping below 4.5V at any time). Hope this helps!
Peter
The board shape is very easy - follow what I did here. No layers, no Pathing, Boolean…
For the Round Holes, the easiest (preferred) way is to simply use the part called “Hole”. Don’t need the copper ring (set that in the Inspector).
ok thanks…i am gonna try it now
ok quick question:
once i do this as instructed, and get my pcb; i can import that to friting, and add all other electronic parts and wire them right.
eventually, i need a top layer and bottom layer to run wires etc…i can still do that right…
Yes, that’s correct.
Note: There are a host of Drawing programs you can use; Inkscape, Gravit, Boxy, EZdraw… Paint, Draw, doodle… and many more.
However, all require knowing how to get what you want from them as they all do ‘it’ differently.
One useful program that does it without any issues (if not doing layers) is Open Office. It’s free and fully replaces MS Office. It contains a Drawing Program.
Silkscreen layers are default added in Fritzing so, no need to create your own unless you want a custom silkscreen. You can add graphics to the default silkscreen using the Part called “Silkscreen Image”, shown below.
The following Example uses OpenOffice(Drawing) to draw & export your (similar) shape, then is loaded into Friting…
Note: Line dimensions are shown at the bottom of the screen.
ok thanks.
i figured out finally after 15hrs…wooof…used inkscape and this link https://www.youtube.com/watch?v=jpIP1MyFQXs
good night !
I just published a pre-release. I don’t have the means to support XP or 32 bit versions. So currently, four builds are done: Linux 64 bit (recent Linux distributions >= 2016 should be good), MacOS High Sierra and Maverik, Windows 10 , 64 bit.
The Windows 10 version might or might not run on older versions, I don’t have the resources to test it or to maintain an older windows toolchain. Some problems might be easy to fix, so it would help if you try it, and leave me a note how it worked (create a new thread or issue on github). Look for the latest pre releases on github, e.g.
Once the release is finished, it will also be published via github first.
Greetings, Kjell
At a fairly brief test (a sketch and a part) the Win10 64 version appears to work fine on Win 7 Pro. The parts update is working again (the new version of libgit2 fixes that.) For others that want to try this, note that it is using the production app data directory, so before trying this make a backup copy of
C:\Users\user\AppData\Roaming\Fritzing
(where “user” in the above is your Windows user name) so you have a backup copy (which you should anyway) of your added parts in case of problems with the new version. I have switched to running the dev version as my default and would encourage any one else that can to do the same. It needs wide testing to flush out bugs before a release. I’d actually like to see the suggestion I made at the bottom of the roadmap
where the dev version uses a different documents directory, but that may be difficult to implement. In any case great work, one step closer to a new release!
Peter
I’m helping fix up some parts for the FRC robot folks to get them included in core parts. I’m intending on posting the fixed up parts here (as being easier than on github) so the original author can review them, but any of you are welcome to comment as well. The original discussion is here on github:
Unrelated to this part, but of interest: I am currently playing with making my own shaft encoders (the AMT103 is around $35 Can on digikey). I first used the Honeywell HOA0901-011 which was about $15 at digikey, but is now obsolete and $20 from the single source on ebay. Then I found the “Velocimetry Motor 334 line AB phase Encoder” on Ebay for $2.50 ea (unfortunately I bough all that were available at this price, but there are still some in the $3.50 range, still cheap compared to the alternatives). This is a small motor (low torque) with a 2mm shaft, a 334 line optical disk that can be removed (with difficulty!) from the motor shaft and a sensor like the Honeywell part, with active drive and I suspect comparitors on chip on a flimsy pcb that is easy to detach from the motors. This is worth it just for the optical part (which has no part number unfortunately), the motor and encoder disk are a bonus! I’ll probably produce a small board to hold the sensors (I have 3 so far where I destroyed the original board trying to put wires on it 
.) If you want cheap shaft encoders this is a good bet!
That said here is a copy of the first part that has been done, the AMT103 encoder part (in three forms, the original part, the probable final part and an alternative schematic version):
original part
AMT103-orig.fzpz (5.5 KB)
likely part
AMT103.fzpz (7.5 KB)
alternate schematic
AMT103-alt-sch.fzpz (6.0 KB)
all three have different moduleIds so you can load all three at the same time if you like. To make things easy without having to download anything, png images of a test sketch using all three parts:
fzp file:
Mostly ok, added reference file and fritzing version to the module line. Removed some unneeded properties and changed the varient from 6 to 1 (as this is the first version of this part). Added a description of the part from the data sheet so it will show up in inspector, added descriptions to each of the pin names so the data comes up when you hover over a pin in any view. Add a url for the part datasheet, added a 1 (for the varient number) to each of the file names (and renamed the files to match after I found a new Fritzing bug when I didn’t rename them the first time . Removed the terminalId definitions from all connector’s breadboard layer line as the terminalIds are not in the svg. This doesn’t hurt anything, Fritzing ignores it but the parts check script complains and it isn’t correct.
Breadboard:
Breadboard was mostly ok, it lacked a layerId (which breaks svg export in Fritzing), needed to be rescaled (as did all the svgs) . I increased the height of the encoder to match the real part (it was a couple of mm short in the original) and copied (probably poorly ) the connector from the encoder datasheet to indicate that it is a shrouded connector. I reduced the pin size to make the individual pins stand out better. Removed unnecessary transforms (possible performance issue, transforms imply a matrix multiplication at every render.)
schematic:
Again rescale the svg, change the units from px to in (px can cause scaling problems a Fritzing will guess at the original resolution 72dpi or 90dpi, I don’t think it knows about the current 96dpi), inches or mm isn’t subject to guessing. Made an alternate schematic with a standard box outline (alt schematic), but it isn’t much smaller than the one with the outline of the encoder and I think the outline of the encoder one is clearer and so should be the choice. Again removed unneeded transforms and unneeded parameters in the xml to reduce size / increase performance. The main user visible change here is adding terminalIds to the pins which corrects the “line terminates in the middle of the pin” problem you see in the original part. Without a terminalId Fritzing uses the center of the pin which looks ugly. I think the size of the original encoder is an example of the scale problem, as both sets of xml should be identical, but the possible part one is set to inches so scales correctly.
pcb, again rescaled and removed transforms. Fairly major changes here. In practice I don’t think it is likely the encoder will be mounted on the PCB. The connector (from the data sheet) doesn’t look like it would fit in a PCB, it is expecting an AMP connector and wires. Thus I replaced the connections with a 5 pin .1 header (and adjusted the hole size to 0.038 in, standard for .1 connectors). I also followed the original developer’s recommendation and removed the text in pcb view. The theory is that if the user wants the labels on silkscreen in pcb, they can add them via the text function in Fritzing, but if they are in the part, the user would have to make a new part to remove them. For reasons I don’t understand, the original part silkscreen renders very poorly in the gerbers (the xml looked pretty normal to me so I don’t know why exactly), I didn’t poke further because I wasn’t planning on using it on the final part. If you see something you don’t like or something I missed, please post here so I can correct it. The final objective is to get this series of parts added to the core parts distribution.
Peter
Now the router part
router.fzpz (5.1 KB)
router-orig.fzpz (6.2 KB)
Since this won’t fit on a pcb (it is entirely sockets) pcb view is suppressed. There is also an apparent Fritzing bug, in that the long url in this part causes the formatting of the description in Inspector to break.
breadboard view:
Breadboard is much the same as the original. Internally it was rescaled and unneeded xml and translates were removed. The user visible change is to move the connectors to align on a .1 in boundary and change the connectors to be smaller and at the edge of the connectors.
In schematic, same thing, rescaled removed unneeded translates, and xml add terminalIds to make the pins connect correctly. The major change is remove the replace the router outline with a more standard (and much smaller, which is why to do it!) box type schematic. In general the smaller the better in schematic to allow the most symbols on a single page.
On to the PCM part.
PCM-orig.fzpz (23.2 KB)
PCM.fzpz (25.0 KB)
As before the parts have different moduleIds and thus can be loaded together. One change (busing the CAN connectors) needs verification. I’m assuming that the CAN high connectors connect together as do the CAN low connectors, but I don’t have a module to verify that. If you click on one of the CAN pins (high or low) the other will also light up yellow to indicate they are internally connected together. If that isn’t correct, the bus needs to be deleted. As before I added a description of the device and the url to its web page to the fzp file and added descriptions to all the pins (so the description will come up if you hover over a pin). As with the router PCB view is supressed as being not useful. Breadboard is mostly the same, except I changed the connector pins to be smaller and invisible (they light up red if unconnected and green if connected). I can go back to the original if you prefer very nice job on breadboard by the way).
Schematic is a major change. This is what we were looking for in schematic:
The original IC one is functional but not very useful for figuring out the connections. As noted pcb has been supressed (the original IC footprint and the headers used for testing here show up, but the new part does not as PCB is suprressed.) On to the next part.
I’m looking for a generic TO252 / DPAK part.
Specifically for AOD4185, but a generic will work for me.
Datasheet: http://aosmd.com/res/data_sheets/AOD4185.pdf
At a quick look the generic dpac (search for mosfet and select basic FET pchannel and one of the cases available in Inspector is dpak which looks to be about the right spacing.) If it doesn’t suit and I’ll create a part from that that fits.
Peter
Now the PDP (Power Dirstribution Panel part. This one has substantial changes as the pin numbering in breadboard was an odd sequence and schematic was non existent (due to not enough connectors defined) and thus needs a good check. I don’t have a unit so am going by the documentation and the original part. Again PCB view is disabled as this isn’t useful on a PCB.
PDP-orig.fzpz (33.4 KB)
PDP.fzpz (44.9 KB)
breadboard:
The usual rescale and clean up xml, in addition this time a complete renumber of the pins starting with 0 at channel 0 - and proceeding in order around the perimeter. As well all the grounds are bused together (click on any ground and all the rest will light yellow) as do CAN high and CAN low. I copied the breadboard of one of the screw terminals to give a bit more life like representation of the power pins.
Schematic
Created as the original doesn’t render as it is a 36 pin IC but there are 44 pins which is what causes the red square in schematic.
Peter
