Two-digit 7-segment led indicator

2-digit 7-segment v0.2.fzpz (14.8 KB)

Contributions are welcome, https://github.com/ReDetection/2digit-7segment
Build Status

1 Like

You have a fair number of problems. From the parts checking script (available on github) edited for brevity :slight_smile:

(warnings deleted)

Both breadboard and schematic lack layerIds in the svg. The only thing this affects is export of the part as an svg (the part won’t show up).

Error 69: File
‘svg.breadboard.125-seven-segment_60ac6a288b245897b2d6acdaaf1d3581_1_breadboard.svg.bak’
At line 17

Found a drawing element before a layerId (or no layerId)

Error 69: File
‘svg.schematic.125-seven-segment_60ac6a288b245897b2d6acdaaf1d3581_1_schematic.svg.bak’
At line 12

Found a drawing element before a layerId (or no layerId)

Error 18: File
‘part.125-seven-segment_edd752848691e8bf069be053932fe577_4.fzp.bak’

Connector connector4terminal is in the fzp file but not the svg file. (typo?)

svg svg.schematic.125-seven-segment_60ac6a288b245897b2d6acdaaf1d3581_1_schematic.svg.bak

This lack is what is causing the lines in schematic in this sketch to terminate in the middle of the pin instead of the end as they should.

led_test.fzz (20.5 KB)

then pcb is mostly broken. It lacks a part outline for the part on the silkscreen (which the script doesn’t notice but I do) and non of the pads have holes making the pcb useless.

Error 65: File
‘svg.pcb.125-seven-segment_60ac6a288b245897b2d6acdaaf1d3581_1_pcb.svg.bak’
At line 50

Connector connector0pad is an ellipse not a circle, (gerber generation will break.)

Error 74: File
‘svg.pcb.125-seven-segment_60ac6a288b245897b2d6acdaaf1d3581_1_pcb.svg.bak’
At line 50

Connector connector0pad has no radius no hole will be generated

You likely have been bit by a translate in pcb layer. There is one message for each of the 10 pads and indeed exporting gerbers results in no holes in the pads.

Peter

Cool! Thanks a lot for the analysis, I wouldn’t expect this quick and guiding response :slight_smile: Thanks!

Is this the script you’re talking about? https://github.com/vanepp/FritzingCheckPart
I’m definitely going to check this out as it seems to affect me too (I’m building a pretty simple controller board with these leds), so I’ll try to fix issues, however I don’t know how quickly it happen.

Why there is no mention of this script on the http://fritzing.org/testing-quality-check/ page? I think it’s worth mentioning there.

I also look forward to integrate your script as part of travis-ci process so it can check things automatically :sunglasses:

Having finished the last task I’ll poke at the problems and post a fixed up version in a bit as an example of what needs to change.

Yep that’s the one (there is a fork on the Fritzing repro, but it is currently behind a bit).

Probably because it has only been available for a month, and is basically alpha code (no widespread testing yet). As far as I know I’m pretty much the only one using it so far.

The Fritzing developers pointed me at travis-ci as what they were going to use as a test framework, but at a quick look I couldn’t figure out what to do with it, so I went with the script. If you can integrate it I expect the developers will be interested.

edit: OK here is my corrected version of your part. This is a new part so you can load it beside the original and look at them both. First in all views I rescaled to the standard 1px = 1 thousandth of an inch. I resized breadboard to put the pins on .1 boundaries but mostly to increase the size of the display to life size (25mm * 19mm) and reduced the size of the pins. Schematic the major change is to add terminalIds although I also moved the pins to .1 boundaries. PCB is mostly change the pads to circles and set the drill size to 0.030 (typical size for IC leads) and add a silkscreen layer with the outline of the display so you can tell where it will be on the board.

2-digit 7-segment_fixed.fzpz (13.5 KB)

Peter

2 Likes

Just noticed I have wrong physical dimensions a day ago, and now I see your updated part :heart_eyes:
I’ll commit it to my repo on your behalf. Thanks a lot, I really appreciate your contribution!

Turns out, the cause of the most of my problems was the Sketch app which is very convenient to use but unfortunately not designed to draw printed or real-world things as it only operates in pixels. Some schematics terminals were missed because I used another seven-segment display and just removed extra terminals. I never thought terminal id mean something because they can be easily remapped in the part editor tool.

However, PCB still seems to be wrong – top and bottom terminals have 0.4 distance while it should be 0.6. This time I tried to use Inkscape and I was able to align them but it wasn’t a pleasure to use Inkscape. Is this the recommended tool? For simple things like circles, notepad will be fine, but I doubt bezier paths are comfortable to write this way and Inkscape trades this for many other inconveniences.

I updated my original post with the new part file, as well as put everything on Github. Look, I also integrated your script to check part sources. Once an error occurs, the script will indicate failure by non-zero return code so Travis recognize that. Example config for Travis, example build. Build Status

EDIT: seems that I messed up with terminal pads during Inkscaping. Ouch. Need some bulletproof way to edit SVG files.

Ah, I just used what was close to the original not knowing what the actual spacing was supposed to be. Easy enough to change which I see you have done.

I’m not sure about recommended :slight_smile: it is however open source and thus used by many of us so I use it more so I can help others than any other reason. Illustrator and Corel draw are also used by some folks. Most of the time the px conversion works fine, but sometimes Fritzing gets confused and picks the wrong scale. It also makes checking things in the python script (which it isn’t doing yet) more difficult.

Looks like there may be a scaling issue in the pad path. I think I grabbed a working pad from another part in the one I fixed and when I compare the two
d s from the working and non working one the only thing that stands out is
this:

…-32.98069 v -65.96127 c 0,-18.21784… in mine that works and
…-32.98069 V 642.7607 c 0,-18.21784… in yours that gives odd results.

I don’t know enough about paths to know if that’s the problem but I suspect the V in yours being 10 time that of the one thar works is probably the issue.

That looks good, I’m thinking about more changes to the script as someone (perhaps you?) just made a pull request to make it work on the Mac and I have discovered a python script in Fritzing parts that can unzip the fzpz file for itself so I’ll look at swiping that code to improve things plus a few more improvements. I’ll have a look at the return codes, I don’t remember if I used different codes for warnings (which can be ignored) and errors (which will break something in fritzing). If I didn’t I’ll likely change it to 0 for no errors 1 for warnings and 2 for errors. However it may take me a while because I’m also making slow progress on fixing Fritzing bugs in the source and that is chewing up my time.

Peter

Sure that’s me. This PR is also required to make travis work. So far I set it up using my fork, but it would be better to switch to yours. I am 100% sure this PR works on macOS/Linux, would be cool if you can check on Windows.

To be honest, I don’t think it’s a good idea. Anything other than zero return code treated as unsuccessful, and I’m not speaking about CI only, I’m speaking about UNIX practices. Consider having a flag to treat warnings as errors, so if any warning seen, return code will also be non-zero.

I tried your and I see no difference. Please let me explain, probably we’re talking about different things. At the moment part looks perfect on the breadboard, perfect on the schematics, and perfect on the PCB view of the Fritzing, but if I select Export for Production → PDF, I see top pads corrupted. I tried to copy bottom pads to the top pads but this only made bottom pads corrupted as well, so I’m slightly confused.
PDF example here, also images how it looks:
18

We are talking about the same thing, I’m just using the gerber output rather than pdf (the generator code is the same for both), but you are right just changing the v doesn’t fix it (I tried it and it breaks in the svg). This is the gerber output from your 2-digit 7-segment v0.2.fzpz with the copy / paste in Inkscape addition of a single pad from my fixed version above. I don’t know why your path doesn’t work correctly since the only difference seems to be that one v parameter.

An easy fix is to just copy / paste in the svg editor the pads from the
2-digit 7-segment_fixed.fzpz pcb svg above although I’d rather know why yours doesn’t work.

Peter

Hi there!

I did some investigation into SVG format and it turns out capital or small letters only differ in absolute and relative. So after two more hours of digging, I gave up and just fixed your version to have correct height using text editor. :smiley:

Pads looks pretty for me now even in production images, as fas as I can tell gerber now looks good too. I will check once more after printing and etching, but also I will appreciate if you could take a quick look.

2digit 7segment - 0.2.1.fzpz (14.5 KB) (same prefix so it will overwrite existing part)

Your testscript gives one warning, and I can’t decide if I should remove second copper definition – this is handy sometimes to have an extra keepout near the holes. What is the proper way?

This is a through hole part as both copper0 and copper1 views are present.
If you wanted a smd part remove the copper0 definition from line 43

Looks fine to me. It is possible the fault is in the Fritzing gerber/pdf code rather than the xml.
Unfortunately the text editor is the usual best way to move paths around. If moved in Inkscape it uses translates to do the move and usually won’t remove them even if ungrouped. I’m thinking about seeing if I can figure out how to preprocess to remove translates in the check script as this should be a performance increase (translates require a matrix multiply at every rendering AFAIK).

This message is information rather than a warning. The part is correct as it stands, as a through hole part it wants pads on both sides of a 2 layer board and thus needs both copper1 and copper0. For an SMD part you only want the copper1 layer so the part is only on one copper layer and doesn’t interfere with the bottom layer. This tends to confuse new part makers (it isn’t documented anywhere that I know of) and thus this information message.

Peter

My bad, I even wasn’t able to properly understand the checker message – sure this is through hole component. Lesson learned – don’t do this in the late night.

Looks like I can no longer edit my original post to update the part. Hopefully people will read the topic or visit my github before downloading corrupted version.

Thanks again for all the help! :+1: