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

Added parts for FRC. Namely, RoboRio, PDP, VRM, PCM, AMT103, TalonSRX #141

Closed
wants to merge 7 commits into from

Conversation

@Nitaym
Copy link

commented Mar 17, 2018

Added parts for First Robotics Competition.
Namely:

  • NI RoboRio
  • PDP
  • VRM
  • PCM
  • AMT103
  • TalonSRX ESC

I did not complete PCBs as they are not relevant for these parts

@Nitaym Nitaym changed the base branch from master to nightlyParts Mar 17, 2018

@StefanCamilleri

This comment has been minimized.

Copy link

commented Jul 9, 2018

Thanks for making this contribution to the FRC community. I'd like to start using this right away. Is it possible for you to package it and submit it to the fritzing forum with the other parts?
http://forum.fritzing.org/c/parts-submit

@Nitaym

This comment has been minimized.

Copy link
Author

commented Jul 10, 2018

Sure - I'm not sure why the merge request wasn't approved.
I'll post it to the forum

@el-j

This comment has been minimized.

Copy link
Member

commented Jul 10, 2018

Hello and sorry for the delay! I will check the requests today and make the merge if anything is ok.

@el-j

This comment has been minimized.

Copy link
Member

commented Jul 10, 2018

thanks for this good work so far in breadboard-view.
i found bugs in the schematic and in the pcb-view.
besides the connector bugs, the pcb-footprints do not fit the pinout of the boards, and the schematic symbols are not well made.
please fix these issues so it can be merged to the parts-repository.

thank you

image

image

@Nitaym

This comment has been minimized.

Copy link
Author

commented Jul 10, 2018

Hi!

Thanks for the notes. These parts are actually not applicable for schematic / PCB - You can only get them packaged as the breadboard version shows.

Is there a way to note that in the fritzing part?

Thanks
Nitay

@el-j

This comment has been minimized.

Copy link
Member

commented Jul 11, 2018

in this case i would suggest to make a footprint linke the pinout of the packaged board. like the arduino boards or the raspberry ... so people can use these footprint to design a pcb that can get attached to the packaged boards in real life. for schematic it's the same. look at the arduino boards. it's a "proper" sized rectangle with the pinout the board have.

greetings

@Nitaym

This comment has been minimized.

Copy link
Author

commented Jul 14, 2018

I've edited the schematic and pcb for AMT103. Could you verify that the formats are correct before I move on to the bigger ones?

By the way, is there a way to create the pcb / schematics automatically? It's over a hundred pins

@el-j

This comment has been minimized.

Copy link
Member

commented Jul 16, 2018

sooo i checked your new commit. first of all, yes you can do the schematic like this. the easiest would be a rectangle, but your approach is nice as well.

there where issues:

  • when you copy a path in illustrator it will count up the ids. so the fzp could not find the svg-connectors because there ids where destroyed. i hope i fixed it the right way ... see my commit.

  • the breadboard image missed the "_breadboard" in the svg name. so it could not be found when loading the part. fixed as well

because of the automatic creation. there is a tool to create all files from an "unproteced" eagle brd file... look at:
https://github.com/fritzing/eagle2fritzing

when there is not brd file ...
i mostly start from a generic ic, where i can get all 3-graphics and the fzp with all the connectors and id's. so it is "just" about giving it a "real-shape".

@Nitaym Nitaym force-pushed the Nitaym:frc-parts branch from c7ef318 to b2dafd0 Jan 11, 2019

@el-j

This comment has been minimized.

Copy link
Member

commented Feb 18, 2019

Hej.

RRio
VRM
are both broken in pcb and schematic view
as well as i assume that the pcb for roborio does not make any sens....
as well for FRC and PRio and VRM

image

image

please fix, otherwise i cannot merge ... thanks

@el-j

This comment has been minimized.

@KjellMorgenstern

This comment has been minimized.

Copy link
Member

commented May 7, 2019

Looks like those parts were never completed. Suggesting to close this PR.

@Nitaym

This comment has been minimized.

Copy link
Author

commented May 8, 2019

I actually never got around to finishing them. Is there a way to simple disable the PCB and Schematic? As you said - There's not much sense in both of them - Only in breadboard.

The problem them is just that it's very tedious to add all pins one by one. Do you know any way to automate it?

@KjellMorgenstern

This comment has been minimized.

Copy link
Member

commented May 14, 2019

Eventually it might make sense to split this Pull Request, so that part that are already fine or easy to fix can be merged.

@vanepp

This comment has been minimized.

Copy link
Contributor

commented Jul 9, 2019

I'm willing (and have time) to fix up the parts, except I can't find them. I managed to get something (but it is only the bin files, not the part files which is what I would need) via

git fetch upstream pull/141/head:pr-141

if someone can tell me how to get at the parts themselves I'll try and fix them up.

Peter

@KjellMorgenstern KjellMorgenstern force-pushed the Nitaym:frc-parts branch from c149d2b to afd6306 Jul 10, 2019

@KjellMorgenstern KjellMorgenstern changed the base branch from nightlyParts to develop Jul 10, 2019

@KjellMorgenstern

This comment has been minimized.

Copy link
Member

commented Jul 10, 2019

I rebased the PR onto the 'develop' (not nightlyParts anymore) branch, maybe that helps.

git fetch origin pull/141/head:pr-141 #my remote is 'origin', not 'upstream'

Listing the files shows several .svg files and the following ones.
git diff --name-only pr-141 develop

bins/more/frc-mono.png
bins/more/frc.fzb
bins/more/frc.png
core/AMT103.fzp
core/PCM.fzp
core/PDP.fzp
core/RoboRio.fzp
core/TalonSRX.fzp
core/VRM.fzp
core/YumoE6B2.fzp
core/router.fzp

@Nitaym

This comment has been minimized.

Copy link
Author

commented Jul 10, 2019

@vanepp

This comment has been minimized.

Copy link
Contributor

commented Jul 10, 2019

Looks like there is something wrong (or something I am not doing correctly more probably) with my remote branch of frtizing-parts. I cloned fritzing-parts locally which gives me branch develop (when my remote gives me branch master)

git clone https://github.com/fritzing/fritzing-parts.git

then

git fetch origin pull/141/head:pr-141

and

git diff --name-only develop

bins/more/frc-mono.png
bins/more/frc.fzb
bins/more/frc.png
core/AMT103.fzp
core/PCM.fzp
core/PDP.fzp
core/RoboRio.fzp
core/TalonSRX.fzp
core/VRM.fzp
core/YumoE6B2.fzp
core/router.fzp
...

which shows the bins as well as the fzp and svg files which were missing last time. I'll make the fixes and then will probably be back to figure out what to do with them once I have them (maybe make a pull request of my own will be easiest, unless one of you know another way to do it). I'll poke at my remote repository and see if I can fix it up to work correctly, because I need it to be correct. Learning github is almost as bad as learning Fritzing parts making :-) .

Peter

@vanepp

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

I ended up having to delete my fork of Fritzing-parts and redo the fork to get my copy in sync with the master (I suspect something I did screwed it up so it could no longer sync as the suggested methods of syncing didn't work, it claimed to be identical to upline, but didn't have the develop branch, now it does). I'm currently making changes to the AMT103 part (mostly internal in nature and not user visible, but some are user visible) and I'd like to suggest an alternative schematic (although in some ways I like the current one other than its size). I think the easiest way to do this, if @Nitaym doesn't object, is for me to post the parts as I complete them in the Fritzing forum in parts help so anyone interested can download them, try them in Fritzing and suggest changes. Does anyone have an objection to this plan?

Peter

@Nitaym

This comment has been minimized.

Copy link
Author

commented Jul 11, 2019

@vanepp

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

@Nitaym : Hopefully with the re forked copy of Fritzing-parts I will be OK. The last time I submitted a few parts something went wrong and it refused to make more pull requests. I suspect that is when my forked repository got screwed up. My intent is to submit the fixed up parts here to be added to core, the forum is just an easier place to post review versions to make sure you don't object to the changes I'm making. I completely agree that core parts is where this wants to be. I've just posted the first fixed up part (the AMT103 encoder) in this thread in the forums for review:

http://forum.fritzing.org/t/frc-parts-for-review/7315

The new part has been run through my part checking python script and thus shouldn't have any problems getting approved. If you see changes you don't like post and I'll correct them. I'll start on the next part now.

Peter

@vanepp

This comment has been minimized.

Copy link
Contributor

commented Jul 31, 2019

OK, what I think are all the parts have been fixed up and posted to the referenced forum article. If you would have a look at them and see if there is anything wrong (the roboRIO and TalonSRX have the most changes) and check that these are all the parts, we should be ready to go. If they check out, it will probably be easiest to cancel this pull request and let me make one with the new parts or you can download the fzpz files and unpack them and modify this pull request. Note there are some unused (as far as I can see anyway) svg files in this pull request.

Peter

@vanepp

This comment has been minimized.

Copy link
Contributor

commented Aug 23, 2019

@Nitaym , @KjellMorgenstern I haven't forgotten this one, the corrected parts are all posted for review in the forum. If there isn't a hurry (which there may be with the start of a new school year soon) I'm inclined to wait til I finish the update to FritzingCheckPart.py to work with travis-ci to make sure all the parts pass all the tests (I think they will now, but a test of the final code is the best bet.) Thoughts?

Peter

@KjellMorgenstern

This comment has been minimized.

Copy link
Member

commented Aug 23, 2019

FritzingCheckPart script improvements are welcome (I'd even rate them higher priority, the earlier we have it the easier it will be to avoid future part errors). But just because the script improvements are not finished we should not stop adding new parts. All the parts so far have been added without this script in travis-ci...

@vanepp

This comment has been minimized.

Copy link
Contributor

commented Aug 23, 2019

OK, I'll make a new pull request with the fixed parts, as I think the script is going to take some time. I'm thinking it needs a proper test suite that trips all the error conditions (and I suspect some of them wont be able to occur because xml parsing may have failed before it gets that far) and that is likely to take a long time. I should have a new pull request with the fixed parts together in a day or two I expect. I need to verify the bin files are still ok and convert from fzpz format to core (one of the things I want to add to the script.) as the parts are all in fzpz format for the forum at present.

Peter

@KjellMorgenstern

This comment has been minimized.

Copy link
Member

commented Aug 29, 2019

I am closing this pull request because it has been replaced with PR #214

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.