Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

replace LBT2088AH part with generic family of led matrix parts #235

Open
wants to merge 2 commits into
base: develop
from

Conversation

@mMerlin
Copy link
Contributor

mMerlin commented Feb 11, 2020

Handles 4 different sizes of 8x8 generic LED dot matrix displays, with cathodes on either rows or columns, and with standard circular pcb pads, or oblong pads used for IC chips. Part number can be set using inspector.

Parts update configured for the obsoleted LBT2088H specific part. Simple update test by @vanepp worked. More complex test messed up the pcb view. Investigation in progress. Sketch corruption suspected from the work flow used.

@mMerlin

This comment has been minimized.

Copy link
Contributor Author

mMerlin commented Feb 11, 2020

@KjellMorgenstern I assume you get notifications about build failures. cannot find package "github.com/cpuguy83/go-md2man/v2/md2man" looks like something is missing, but travis is not in my skill set.

@KjellMorgenstern

This comment has been minimized.

Copy link
Member

KjellMorgenstern commented Feb 11, 2020

Hi, can you rebased against the develop branch?
Also, maybe i have overlooked documentation about the nighlyparts branch which needs to be updated.

@mMerlin

This comment has been minimized.

Copy link
Contributor Author

mMerlin commented Feb 11, 2020

nightlyparts reference: https://github.com/fritzing/fritzing-parts/blob/develop/CONTRIBUTING.md
I've never done a rebase. Time to learn something new.

vanepp had a look at my failing sample update file. Found some issues, and made it work better.

@KjellMorgenstern

This comment has been minimized.

Copy link
Member

KjellMorgenstern commented Feb 11, 2020

If you are lucky, it is as simple as choosing "develop" as base branch above. I'll try.

@KjellMorgenstern KjellMorgenstern changed the base branch from nightlyParts to develop Feb 11, 2020
@KjellMorgenstern

This comment has been minimized.

Copy link
Member

KjellMorgenstern commented Feb 11, 2020

Ok, doesn't rebase automatically. Still, it will be fairly simple, let me know if I can help.

@mMerlin

This comment has been minimized.

Copy link
Contributor Author

mMerlin commented Feb 11, 2020

@KjellMorgenstern I think that's got it. After some reading and cross checks, it amounted to:

git checkout --track origin/develop
git merge upstream/develop
git rebase --onto develop upstream/nightlyParts led_matrix
git push --force origin
@KjellMorgenstern

This comment has been minimized.

Copy link
Member

KjellMorgenstern commented Feb 11, 2020

Did you execute it? With the push, changes should have shown up here automatically.
My approach would be:

# get PR235 to my local system
hub pr checkout 235

# do the rebase (cherry-pick would also work, I often find it more intuitive to type, but it is more commands)
git rebase --onto origin/develop origin/nightlyParts

# have a quick check
git show HEAD --name-only

# publish it back to PR235
git push -f

Of course those command might vary, depending on how you current local repo looks like.

@mMerlin

This comment has been minimized.

Copy link
Contributor Author

mMerlin commented Feb 11, 2020

Yes I ran that. I do not recognize that hub pr command. That look like something specific to github pull requests. Guessing is supposed to do a checkout to match the existing pr, to base the following commands on. The git show command reports exactly the expected new and obsoleted part files. The pr here shows fritzing:develop. I guess from your shortcut attempt. I don't know what more I can do or check. I have no knowledge about what the conflicting files being reported. Other than a guess they are related to switching from nightlyParts to develop.

Do I need to create a new pull request from the rebased branch?

@KjellMorgenstern

This comment has been minimized.

Copy link
Member

KjellMorgenstern commented Feb 11, 2020

"git push --force origin"
I think you where on the develop branch. In that case, you have updated your fork of develop, but not the PR. This might cause conflicts when you later sync upstream develop. To update the PR, changes need to go to the led_matrix branch.

@KjellMorgenstern

This comment has been minimized.

Copy link
Member

KjellMorgenstern commented Feb 11, 2020

Yes, hub is a CLI tool for using github from the command line. It can create issues, forks, and manage pull requests.

@KjellMorgenstern

This comment has been minimized.

Copy link
Member

KjellMorgenstern commented Feb 11, 2020

Please don't start over. For the learning effect, you could try to figure out how to solve it without starting over, or opening a new PR. But to save time, I can also just push my version :-)

@mMerlin

This comment has been minimized.

Copy link
Contributor Author

mMerlin commented Feb 11, 2020

For 'learning', to do the rebase, I first cloned my local repository, and did the work there. In the original local repo, git status now says

Your branch and 'origin/led_matrix' have diverged,
and have 41 and 64 different commits each, respectively.

So it sure looks like the rebase was pushed.

Also, for learning, I don't know what I need to know, to figure out what is/went wrong. Where to start. Can you provide a pointer? I deal with manuals and documentation quite well, but need some idea of what the topic is to get started.

If starting over, it would be easy to create a new branch off of develop, and reapply the changes there. Already did that once, when I saw the (incorrect) reference to nightlyParts. It is a single commit. Just need to do the 5 git mv commands, then rsync the new and modified files. All in my notes, because I was carefully tracking the steps done. 🙂 for learning

With the difference in your notes, do I need to do the rebase again, starting from a different point? Not used to what to expect, but this pr seems to be showing 64 commits and 253 files. Not the 1 and 36 expected.

Why do say I didn't push? In the local repo that I did the rebase in, git pull, git push show already up to date, and git status shows On branch led_matrix Your branch is up to date with 'origin/led_matrix'. git show HEAD --name-only shows the commit with the parts.

EDIT:
hmmmm, git show HEAD --name-only in the original local repo shows the same commit. Same hash, but, in the rebase repo

commit 818029858fd2fc4cd39dac3d076e7f7fc0f089a6 (HEAD -> led_matrix, origin/led_matrix, origin/HEAD)

in the original repo

commit 818029858fd2fc4cd39dac3d076e7f7fc0f089a6 (HEAD -> led_matrix)

Redo a rebase? From a fresh copy of my original local repo?

@KjellMorgenstern

This comment has been minimized.

Copy link
Member

KjellMorgenstern commented Feb 11, 2020

You didn't push anything to "led_matrix" yet.

@mMerlin

This comment has been minimized.

Copy link
Contributor Author

mMerlin commented Feb 11, 2020

git rebase --onto develop upstream/nightlyParts led_matrix
git push --force origin

From my research, I thought that the rebase would leave me in led_matrix branch, at the end of the rebase.

@KjellMorgenstern

This comment has been minimized.

Copy link
Member

KjellMorgenstern commented Feb 11, 2020

One command further back "git checkout --track origin/develop" ...

@mMerlin

This comment has been minimized.

Copy link
Contributor Author

mMerlin commented Feb 11, 2020

That was to make sure that my local develop branch was synchronized with upstream before doing the rebase. Since that was an input to the rebase.

Collecting information to show the current state, I found the problem. When I cloned the local repo, I did not change origin back to github. So

% git remote -v
origin	/home/phil/development/FritzingProjects/FritzingParts/mmerlin/fritzing-parts (fetch)
origin	/home/phil/development/FritzingProjects/FritzingParts/mmerlin/fritzing-parts (push)
upstream	https://github.com/fritzing/fritzing-parts (fetch)
upstream	https://github.com/fritzing/fritzing-parts (push)

And the push I did was back to the other local repo. Sigh. Let me think a bit on how to continue from here.

EDIT: should I be able to just set another remote and force push to that?

@KjellMorgenstern

This comment has been minimized.

Copy link
Member

KjellMorgenstern commented Feb 11, 2020

Regarding how to learn git... i think there are a few basic commands to learn to get started, like the happy flow: clone, add, commit, push.
Then git pull and git mergetool to resolve conflicts.
Then just go through what you are doing now several times, not giving up (deleting the folder and cloning again counts as giving up ;-) ).
Using it on a daily basis for more than a decade certainly helps, too

@mMerlin mMerlin force-pushed the mMerlin:led_matrix branch from eafd431 to 8180298 Feb 11, 2020
@mMerlin

This comment has been minimized.

Copy link
Contributor Author

mMerlin commented Feb 11, 2020

Been doing things like that. Adding in creating new project branches. Messed up because I got off of the main path, into things I had not used before. I cloned here, intending to keep a snapshot point, incase I messed up, that was what actually caused the problem.

git remote add ghub https://github.com/mMerlin/fritzing-parts
git fetch ghub
git co led_matrix
git push --force --set-upstream ghub HEAD

Seems to have done it. I see a new message here about the force push.

@mMerlin

This comment has been minimized.

Copy link
Contributor Author

mMerlin commented Feb 11, 2020

Hi, can you rebased against the develop branch?
Also, maybe i have overlooked documentation about the nighlyparts branch which needs to be updated.

Already handled, but before I updated my local repository,

git co develop
grep -ir "nightlyparts" *

found it, and currently

git co master
grep -ir "nightlyparts" *

shows the same reference still in CONTRIBUTING.md, plus a couple of lines in README.md

Nothing found in the fritzing-app wiki, and the fritzing-parts wiki is currently empty.

@vanepp

This comment has been minimized.

Copy link
Contributor

vanepp commented Feb 12, 2020

While I'm glad to see github doesn't only bite me when I try and update parts (and I haven't yet tried the git commands posted in the forum to see if I can sync my github parts repo to the real parts repository), I think we need a simple howto (which I can write if I ever figure out how to do this) on keeping a cloned repository on github in sync with the master. This is such a common task that I'm surprised there isn't a tutorial on github (or else where) but I haven't been able to find one. The usual ones are from a local to a remote repository, none with a local repository, a writable by me repository on github and a cloned repository that you are making pull requests against. While at present not many other than me are making parts, even if they were I suspect like me they may end up posting in the forum because they can't figure out how to make the pull request on github.

@KjellMorgenstern

This comment has been minimized.

Copy link
Member

KjellMorgenstern commented Feb 12, 2020

@vanepp Have you tried the keyword „fork“ „How to keep a fork in sync with an upstream repository“?
Also, one advise would be to not have long lived feature branches. Create a branch, like „led_matrix“, make a pull request and delete it. If you keep a branch, you will have to rebase it frequently.
Maybe one thing that is noteworthy is that I ask pull request to be fast forward commits on the develop branch. Usually you don’t notice. The difference is for long lived branches, that you should frequently rebase instead of merge.

@KjellMorgenstern

This comment has been minimized.

Copy link
Member

KjellMorgenstern commented Feb 12, 2020

@mMerlin At a first glance, this PR looks great. I also tried a simple „obsolete“, and it worked. I would like to investigate the issue (disconnecting) described in the forum a bit more.

@KjellMorgenstern

This comment has been minimized.

Copy link
Member

KjellMorgenstern commented Feb 12, 2020

After updating the obsolete part:
image

image

File with the obsolete part:
dot.fzz.gz

@KjellMorgenstern

This comment has been minimized.

Copy link
Member

KjellMorgenstern commented Feb 12, 2020

We need to figure out if this is an issue somewhat triggered by the part, and if there is a workaround for that, for example by avoiding an offset of the connectors.
Assuming the part is sane, the issue should also be fixed on the application side.

@mMerlin

This comment has been minimized.

Copy link
Contributor Author

mMerlin commented Feb 12, 2020

There is some updated information on the forum at https://forum.fritzing.org/t/part-update-pcb-view-mess-possible-corruption-in-sketch/8455/5 if you have not seen it yet. With further testing and results done with the update process for that part. I recognize issues in your screen shots as matching what I saw and documented there. You did not see (or at least show here) all that I found. With the symptoms, the (my) current estimate is (at least) bugs in the code. Until we have some simpler cases that work, and can be made to fail in specific ways by simple changes, that is an assumption. As a start though, we could regress the parts database (checkout old commit) to a point before some other part was obsoleted, create a new test file with that part, and try updating. Time to dig out some git commands to locate commits with files being moved to obsolete. Preferably something with more than a couple of pins, and with replacedBy attributes for (some of) the connections. If that has the same kind of symptoms, it should add weight to the theory that there are bugs in that block of code causing the problems. grep found a few candidates. The diodes might be useful simple case to use for further testing, if they fail.

% grep -m1 "connector.*replacedby" *
0223_0eb44bbb4c4f50c21567b8c79110a3c3_5.fzp:  <connector type="male" id="connector130" name="Enable" replacedby="ENABLE">
Arduino Ethernet Shield.fzp:        <connector id='connector15' name='D0RX' type='female' replacedby='RX/D0'>
Arduino Fio.fzp:        <connector id="connector15" name="GND" replacedby="connector23" type="male">
arduino.fzp:        <connector id="connector15" name="D0RX" replacedby="D0/RX" type="female">
Arduino_Leonardo_Rev3.fzp:<connector id='connector84' type='female' name='IOREF' replacedby="connector85pin">
Arduino LilyPad.fzp:        <connector id="connector15" name="D0" type="female" replacedby="connector49">
arduino_mega.fzp:        <connector id="connector1" name="GND" replacedby="connector237" type="female">
Arduino Mini.fzp:        <connector id="connector15" name="+5V" replacedby="connector56" type="female">
Arduino Mini Pro.fzp:        <connector id='connector15' name='BLK' type='female' replacedby='GND'>
Arduino Nano3.fzp:<connector id='connector55' type='male' name='D12/MISO' replacedby="connector30">
Arduino Nano_v30.fzp:        <connector id="connector15" name="D12" replacedby="D12/MISO" type="male" replacedby="connector30">
Arduino-Pro-Mini-v11.fzp:<connector id='connector14' type='male' name='DTR' replacedby='DTR'>
Arduino_UNO_R3.fzp:        <connector id="connector28" name="reserved" type="female" replacedby="N/C">
avr_isp_10_pin.fzp:        <connector id="connector3" type="male" name="sck" replacedby="connector6">
RJ45_TRXCOM.fzp:        <connector id="connector3" type="male" name="Transmit CT"  replacedby="connector3">
SMD_mega2560.fzp:<connector id='connector0' type='male' name='(OC0B) PG5' replacedby='connector0'>
sparkfun-discretesemi-diode-1n4148.fzp:<p layer="breadboard" svgId="connector0pin" replacedby="connector1pin"/>
sparkfun-discretesemi-diode-hv.fzp:<p layer="breadboard" svgId="connector0pin" replacedby="connector1pin"/>
sparkfun-discretesemi-diode-pth.fzp:<p layer="breadboard" svgId="connector0pin" replacedby="connector1pin"/>

For the "simple test case" path, one way is to create a perfectly good part in a test branch (a clone of an existing good part), create a fzz with that, obsolete the part with what it was clone from, and test and update. Assuming that works, deliberately make changes to the obsolete part, to make specific things different from the replacement, and repeat. Saving (part file) snapshots of any failing cases (regression test cases). Since some of the current issues seem to stem from (at least breadboard) (mis)alignment, some of those tests will need to change the view graphic images. Not necessarily the pins/pads/connections. Changing the outer graphics will change the bounding box, and (I think) placement coordinates. I think it would be better to use the corner of the bounding box for the pin/terminal centers as the placement origin, but symptoms indicate the corner of the image graphics is used. Which has varying distances from the pins, and is not even close to 0.1in multiples from there.

We need to figure out if this is an issue somewhat triggered by the part, and if there is a workaround for that, for example by avoiding an offset of the connectors.

Do you mean the use of transform="translate()" in the new part images? or something else?

If that is a factor, it might be for the obsoleted part as well. But with these part images, it is a fairly easy bulk edit. As long as do not need to get rid of all of the wrapper transforms that adjust the local origin to make most coordinates into nice easy multiples of 0.1 inch. That would take more work. And be a significant issue with images created with inkscape. These hand coded svg images are cleanly structured, making it at least practical. There are not a lot of transforms, but still need to calculate new coordinates for everything wrapped inside. I could probably write a program to do that, but that would take time too. More time, but it could become another "conversion" tool, if actually needed. Better to fix the code doing the update. Assuming that is the real cause.

I COULD redo this pr, to not obsolete the old part. I could get more practice with rebase 🙂 There is no direct conflict. Just prefer to not have the Inspector keep offering the key words for the old part in the drop downs. But if we can not move forward with the symptoms being seen until they are resolved (tracked to a root cause that is not either the new part, or the way I obsoleted the old part), then that is an option. It can be obsoleted as a separate pull request when enough information is available to permit it.

@KjellMorgenstern

This comment has been minimized.

Copy link
Member

KjellMorgenstern commented Feb 12, 2020

No need to touch the transforms,

 width="1.51in"
 height="1.51in"
 viewBox="0 0 151 151"

I think this is perfectly good.
The issue is probably to be found in the application, but if there is a workaround, it should be used, so that it works well with Fritzing version < 0.9.5 (so, all versions out there...)

You have a 0.2.2 fritzingVersion. That should be > 0.5 it think, since that is the latest version so are where fritzing tries to apply some magic to work around part format issues. From a guts feeling, it should be 0.9.4, as this is the version were are testing it with the most.

The referenceFile tag seems to do no harm, but it is unused and kind of confusing.
With those minor changes fixed, I think we can integrate the PR.

The obsoletion issue should be dealt with in an new ticket, would be great to reproduce it with somehting simpler like a diode.

@mMerlin

This comment has been minimized.

Copy link
Contributor Author

mMerlin commented Feb 12, 2020

@vanepp

While I'm glad to see github doesn't only bite me when I try and update parts (and I haven't yet tried the git commands posted in the forum to see if I can sync my github parts repo to the real parts repository), I think we need a simple howto (which I can write if I ever figure out how to do this) on keeping a cloned repository on github in sync with the master. This is such a common task that I'm surprised there isn't a tutorial on github (or else where) but I haven't been able to find one.

Here you go 😄 https://github.com/fritzing/fritzing-parts/wiki/contributing-new-part-process

@KjellMorgenstern Could you scan that as well. It is intended to be an end to end happy path. I know some git, but I don't have 10 years of daily exposure.

Ah! for offsets, you meant the mapping between physical units and internal coordinate. I was quite careful with that, getting nice clean numbers.

The fritzing version was deliberately set low. I researched the code to see how it is used. The way I interpret that, the version number should be the lowest version of the software application that knows how to process the part information. The current code does alternate processing for less than / greater than specific version numbers. This does not have any features not in the original part, and afaik, nothing to trigger the existing version number checks. So I set it the same as the original part, figuring that any version that could handle that part could also handle these. 0.9.4 was where I started as well, until I read the references in the code. Maybe the version of parts editor that created it would make sense here, but this was all done with a text editor. SVG included. So parts editor never even saw it.

The referenceFile attributes I will be happy to remove. And ignore the complaint from FritzingCheckPart.py

Are you going to want another rebase, or is another commit enough? With that description, should I really change the fritzing version as well?

Reproducing the update problems with simpler parts in on the list. Along with things like the git cycle documentation dumped into the fritzing-parts wiki. And some actual using of Fritzing for the local robotics society.

@vanepp

This comment has been minimized.

Copy link
Contributor

vanepp commented Feb 12, 2020

I think the " for example by avoiding an offset of the connectors." comment refers to the pins not being exactly on .1in boundaries (and at .1 pitch) in breadboard and schematic (obviously pcb has to be the exact position.) The " I think it would be better to use the corner of the bounding box for the pin/terminal centers as the placement origin, but symptoms indicate the corner of the image graphics is used. " doesn't appear to be that simple. Fritzing appears to be using a voting algorithm of some kind to set pin origins. The theory in the forums was that pin0 is used as the base, but testing indicates that isn't true. It seems to vote on a center line some how, this shows up when there are 2mm connectors in breadboard, the .1 pins will sometimes not be on the grid. I would expect to be able to measure the offset in x and y, and adjust the svg to move the .1 pins to be on the grid. That doesn't work. Moving the pins in x and y so they should align to the grid (I Was assuming the start point was one of the 2mm connectors and moving just the .1 connectors should be linear) moves, but not on to the grid it shifts to a new position. I tried for a few days with 4 .1aligned connectors and moved them one at a time to a non aligned .1 position expecting as one connector moved all the rest would too. Doesn't happen, more than one connector needs to move before alignment will change. I never was able to figure out what Fritzing uses as the base for the connector coords, another thing on my list of things to look at in the source that I haven''t gotten to yet.

@KjellMorgenstern

This comment has been minimized.

Copy link
Member

KjellMorgenstern commented Feb 12, 2020

@vanepp That doesn't sound like a heuristic (voting algorithm) at all, more like a numeric problem. If you look into it, be suspicious about each "==" comparision. On a computer 2PI + 3PI == 5*PI will most certainly return false because floating point errors.

@vanepp

This comment has been minimized.

Copy link
Contributor

vanepp commented Feb 12, 2020

@KjellMorgenstern "That doesn't sound like a heuristic (voting algorithm) at all, more like a numeric problem." Good point! I couldn't find any pattern that worked, and didn't think of floating point round off type problems which are much more likely than a voting algorithm. I'll add that to the bug list for when I get back to that. Python has a floating point "matches close enough" library, I expect there is something similar in Fritzing for the same reason and I bet it has been forgotten in the code that sets initial connector position. Thanks!

@mMerlin

This comment has been minimized.

Copy link
Contributor Author

mMerlin commented Feb 12, 2020

but symptoms indicate the corner of the image graphics is used.
@vanepp
doesn't appear to be that simple.

I was talking about the position of the part itself, as reported by Inspector.

I was basing my analysis on these observations.

  • setting the location of a part in Inspector to a simple number (0,0) does not usually put the connector pins on the .1 grid
  • positioning 2 different parts at the same coordinate in Inspector does not align the part connector pins
  • for the 2 parts connector offsets are not a multiple of .1 inch.

Take for example a diode and capacitor. On breadboard view, without a breadboard to get in the way, use inspector to position them both to 0,0. With align to grid, show grid on, .1in spacing, place a resistor so the right end is just above the left end of the diode connector. What I see is that the tip of the connector for the diode graphic is horizontally aligned with the vertical .1in grid, but the top of the diode graphics is on the grid line, not the connector. The connectors for the capacitor are not on either grid, but the left edge of the capacitor graphic is on the grid, where the wire arcs out, and the top of capacitor graphic is on the grid line. With the resistor snapped in place, look at the coordinate shown by inspector. -0.415, -0.050. left 0.415in and up .05in. The resistor connections are 0.4 inch apart, but that extra .015 is because the graphics extends a little past that. From the rounded end on the end of the connector line. The graphic is visually .1in tall, and vertical offset is half that.

The origin (placement point) for each of those cases is the top left of the graphical bounding box for the part. Which is actually larger than the bounding box shown with a part is selected. When using align to grid, the connector is snapped to the grid, but the part location is off the grid. I have not checked, but I assume that the selected part bounding box is based on the SVG viewBox, but the render graphics can extend beyond that (especially for bendable legs), and that graphical rendered bounding box is used to define the origin/anchor point.

If the placement (origin, anchor) point was the top left connection point in the part, the parts could easily be placed in exact positions using Inspector. WIth rotations that are not multiples of 90 degrees making things harder. Which would probably be handled by Inspector applying a fixed (calculated per part) offset to the location values. The delta from the existing bounding box to the centre point of the top left connection in the part. With rounding so do not get those 0.001 values.

@vanepp

This comment has been minimized.

Copy link
Contributor

vanepp commented Feb 12, 2020

I think I have found a workaround to this problem. I finally thought to have a look at the original part's breadboard svg, and indeed the top row of connectors are misaligned by 0.011in in y. The bottom row are x 0..822 y 02.50 (in) the top row are x 0.822 y 2.061 (in). So I edited fritzing-parts/svg/obsolete/breadboard/red_led_matrix8x8.svg and adjusted group "0.3" (the top row connectors to be at 2.050 in y rather than the current 2.061 (which causes a transform that I would normally have removed, but left in this time to make a minimal change) and saved the svg. Now the LBT2088AH-test.fzz when loaded and updated updates correctly in all three views (at least as far as I can see.) That suggests by doing something bad (modifying the original svg slightly in the obsolete folder) we can fix this problem. My original test part (test.fzz) looks to load fine with the modified svg in obsolete (which I admit is a not very complete test) so old sketches should still be fine. It also looks to tell us where the bug lies, as it appears to be an alignment change in the connectors that trips it. I'll have to think about your post above a bit to comment on it (just saw it as I am posting this.) I think this is normal, the connectors align independent of the view box, except sometimes (in Inkscape at least) if you do not do a resize page to document to update the viewbox you can cause connectors to be misaligned (such as offset 0.05in from the grid in x, y or both even with all connectors aligned on 0.1in centers.) I think this is part of the connector alignment issue that I mentioned above.

@mMerlin

This comment has been minimized.

Copy link
Contributor Author

mMerlin commented Feb 13, 2020

@vanepp So the svg images are not stored in the fz/fzz sketch file? I sort of thought snapshots of parts used in the sketch were kept with the drawing. Maybe that is only for custom user parts (fzpz)? I seem to remember an explicit test when I was doing my initial custom fzpz parts files. To make sure that a user could display the sketch properly without first loading my custom part that was used in it. Since that testing worked, I assumed the parts were embedded in the sketch file. Again, maybe, especially with what you say, that only applies to the user parts.

I think this is normal, the connectors align independent of the view box

Yes part (grid) alignment in the view will (better be) based on the connector position. My comment is that the part position shown by Inspector is based on the overall graphic, not the (reference) connector position. It makes the reported coordinates not very useful for getting the connectors aligned. In breadboard and schematic views. For pcb, the actual physical part boundaries are also important. Which is not necessarily the same as the silkscreen, or other visible graphic boundary. There is an "outline" id that can be used in (at least) pcb svg files. I made note of it when I did the initial research for part creation, but have never looked at part that used it. There are a few that exist, but they are almost all empty. A quick grep and scan only spotted 4 that were not empty. Most pcb svg files do not even have it. But that is what probably should be used on pcb view for physical interference checking. Which is still separate from the anchor position to use for the part.

Did you see the contribution process wiki document? It includes the git commands to resync the local, forked, and upstream repositories. The pull request section is a bit vague, because I was not in a position to walk through and document the prompts. Summary at the end.

@KjellMorgenstern Bump. Looking for feedback on my comment about what needs changing before accepting the pull request, and how to send the changes once done.

@vanepp

This comment has been minimized.

Copy link
Contributor

vanepp commented Feb 13, 2020

@mMerlin "So the svg images are not stored in the fz/fzz sketch file? I sort of thought snapshots of parts used in the sketch were kept with the drawing. " Not for parts in core. Only parts in the mine parts bin to become (which is local and may not be on other systems) are included in the fzz file. The files from the mine parts bin end up in temp (and having the same moduleId but a different version in the mine parts bin causes problems, another bug :-) ., as Fritzing prefers the mine parts bin and takes a potentially incorrect part (if the versions are different.)

" My comment is that the part position shown by Inspector is based on the overall graphic, not the (reference) connector position." There is something odd (perhaps a bug) with the coordinates in Inspector. While working on an accordion interface for someone a while back he needed parts in a particular place on the pcb to match the physical position of magnets in the accordion, I discovered that when units are set to mm you can only set some values (I suspect there is a conversion to other units in there, with a not fine enough granularity), so trying to increase a coordinate by 1.5 mm would in fact increase it by 1.345 not 1.5, and I couldn't get the exact fractional mm I wanted. Another on the long list of things to look at when I have time.

"There is an "outline" id that can be used in (at least) pcb svg files. " I believe the outline layer is what is used when loading logo files and cutouts in pcb. I think the single path additive/subtractive path generates an outline layer to do the cutout. It also AFAIK sets the border of the pcb. The logo code has a number of bugs (Kjell fixed 5 or more of them a while back) and is quite difficult to use @opera_night in the Fritizing forums is the expert there and has had the most luck with it. I usually end up with a mess, I don't think I have ever generated a successful cutout.

"Did you see the contribution process wiki document? " Yes I did, I will probably try to figure out how to edit the wiki and add pointers to the only 3 sets of tutorials that are specific to 0.9.3b/0.94, all the rest I know of are for older versions pre parts editor. I also need to try the git commands and see if I can sync my parts repositories which I haven't done yet.

As to the pull request, I'll see if I can upload the svg file I changed which makes the update work, as I think it would be useful to include it so as not to break things during the update.

red_led_matrix8x8.svg.zip

It doesn't accept svg files so I added a .zip to the end (without zipping it) and it now appears happy.
This wants to be in fritzing-parts/svg/obsolete/breadboard to make the update happy (and I think not break anything else.) This just aligns the connectors on the .1 grid in breadboard.

@mMerlin

This comment has been minimized.

Copy link
Contributor Author

mMerlin commented Feb 13, 2020

@vanepp
< (which causes a transform that I would normally have removed, but left in this time to make a minimal change)
minimal change he says. Maybe graphically, but I tried to do a diff between the versions. Looks like you ran that file through FritzingCheckPart either before or after editing (with inkscape?). The original was not 'checked', so way different layout. So I tried running both the original and the file you provided through FritzingCheckPart, figuring to compare the outputs. Not very good there either. There was some synchronization between blocks, but the attribute orders were different. I thought that part of what FritzingCheckPart was doing, was sorting some things to make compares like this possible. I can visually match the differences shown by diff, (slowly) one at a time, but the raw diff is still too different. Didn't you find a practical (and safe) way to sort the attribute keys?

I'm going to see if I can replicate the changes you did, without totally rewriting the svg file. So that git can see what the actually changes are.

This also needs to be tested with an old part / old drawing, to see if it breaks if the upgrade is declined. I am thinking that might break in the same way the the update broke without adjustment to the obsolete svg.

EDIT
I did a global text edit on obsolete/breadboard/red_led_matrix8x8.svg, changing all references from "158.682" to "158.288" (group gorn 0.4 instead of .3: the bottom row). That picked up a strange path element as well. A closed loop of 4 zero length line segments. So 9 lines modified. Tested with my slightly more complex sample file. Opened without updating, and everything still looked ok. No bogus wires, no disconnections, and moving the LED matrix part on each of the views maintained the connections. Closed without saving, reopen, this time doing the update. Again, everything looked and responded correctly. Looks like this is a valid work around.

To be added to the part obsoleting documentation. And maybe we can "blame" something call brd2svg for the original offset glitch. The desc in the svg files says "Fritzing breadboard generated by brd2svg". Or maybe "Generator: Adobe Illustrator 16.0.0, SVG Export Plug-In . SVG Version: 6.00 Build 0)" in the generator comment.

@vanepp

This comment has been minimized.

Copy link
Contributor

vanepp commented Feb 13, 2020

@mMerlin "minimal change he says. " No, I didn't run it through check part, just Inkscape (although that can be bad enough.) Because Inkscape is written in python, the attribute order usually comes out different as the dictionaries output them in random order. It may also change items it doesn't like that Illustrator did for CSS compatibility (perhaps not always correctly) which may explain the 4 zero length line segments change (because I didn't do anything but move the one row without ungrouping everything which causes a tranform.) I had forgotten that a diff of an Inkscape modified svg file is usually hopeless. There isn't much Check part can do because lxml does the same thing (and worse yet, I have a custom pretty printer in it which changes the format still more.) I'll poke at whether there is a way in Check part or more likely the pretty printer, which is after lxml is done producing the document, to output a sorted in some manner svg so diff would work against Inkscape modified svgs as long as they were both run through Check part first. That won't fix things like the 4 zero length line segments though so it may not help enough.

"brd2svg " is part of Eagle2fritzing which takes an Eagle board file and converts it (with varying success) to a Fritzing part, so it could be the cause (or its original input anyway), although I'm surprised there was an Eagle file for a component, perhaps the author put it on a board to make the part more easily, assuming there was an Eagle footprint for it, although the pin numbering isn't screwed up enough for a usual Eagle2Fritzing board (although perhaps one with a single component would operate correctly, I usually do boards with components that get connector definitions that aren't wanted in Fritzing). The missing pin in the sequence is usually a Parts Editor bug, so there may be multiple causes. It may also do footprints and I've just never done one though, although brd2svg takes a .brd file as input normally and I think the footprints are a different format. Changing the original file with a text editor to only change "158.682" to "158.288" and only in that one group, should produce the desired minimal change without changing the format, so diff should only find that change. That really would be the minimal change but I didn't think of it: svg edit with Inkscape :-) . If you only have a hammer everything looks like a nail.

edit:

OK, I edited the original file with vi and only changed the y coord of the 8 pins so a diff shows only the 8 changes and tested both the original LBT2088AH-test.fzz without updating (works) and with updating, (also works.) So this really should be the minimal svg change. I'll add looking at check part being able to do the same thing to the think about list. An additional problem (which I have a solution to) is that fp round off tends to change all the attribute values during a save. I have python code (which I wasn't planning on using in this revision of check part) that reduces the accuracy from 8 digits after the decimal to 4 significant digits so 4.999999999 becomes 5 and 4.100999999 becomes
4.101. and 510356.01999899 becomes 510400 (after round off.) This reduces the size of svgs without making (usually, there may be corner cases I haven't found yet!) any change in Fritzings rendering, it doesn't need 8 digits of significance. It might marginally help rendering too as there is a bit less disk I/O to read the svg files, as well as making the svgs easier for humans to read. In any case here is the really minimal svg:

red_led_matrix8x8.svg.zip

edit:

File an issue #3621 in fritzing-app for this, with an svg with only pin 15 moved up 0.011in. Breaks all the pins. With a 1 attribute change should be somewhat easy to trace.

set fritzingVersion to current
apply workaround for failing part updates to led matrix
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants
You can’t perform that action at this time.