Hi Guys,
Last week was the Open Compute Project summit 2017 in Santa Clara. While being a great place to be during this period of the year, this has been a great oppportunity for me and ggiamarchi to introduce what we are expecting to do for the OCP toolchain project based on ohub.
We worked really hard on building a working mockup of the design workflow, and I liked to introduce it to you.
The idea is to design parts within FreeCAD (mostly sheetmetal for IT industry)
This example is a sheet Metal Blade which is used to support computer Motherboard into the RuggedPOD project. It has been totally designed using FreeCAD. I made the screenshot using the STEP importer as I am currently working on it and it is my testbed.
Our intend is that when a user save the file, it goes to a web backend platform called ohub. This platform will be used to publish, browse and provide feedback on components, like github is doing with source code. It will also keep track of design change request, and might have a lot of enhancement like we had the chance to discuss with @blacey.
The next step for an end user or a design reviewer is to go on the web platform and login
And the browse the projects which are available
Select one of them and discover the main intent of it.
Then navigate through the design files of the part which are contained within the project
and finally look at a specific part using an interactive 3D viewer and provide feedbacks within my next post
vejmarie
OCP toolchain first mockup following OCP summit
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
Be nice to others! Read the FreeCAD code of conduct!
- vejmarie
- Posts: 713
- Joined: Mon Jan 04, 2016 4:52 pm
- Location: Somewhere between France, USA and Taiwan
- Contact:
Re: OCP toolchain first mockup following OCP summit
Then we do have a 3D file browsr which keep track of the geometry
And from which a user can interact with the design team.
Feedback are tagged and attach to the original design through the shape name.
We do have this workflow working within the github repo. Still a crazy amount of work ahead, and if some of you wants to help us to accelerate Open hardware adoption you are more than welcome to join the project.
ggiamarchi has started to work on the connector for FreeCAD if you want to help him he is on the forum !
Feel free to bring your ideas, comment and so on !
vejmarie
And from which a user can interact with the design team.
Feedback are tagged and attach to the original design through the shape name.
We do have this workflow working within the github repo. Still a crazy amount of work ahead, and if some of you wants to help us to accelerate Open hardware adoption you are more than welcome to join the project.
ggiamarchi has started to work on the connector for FreeCAD if you want to help him he is on the forum !
Feel free to bring your ideas, comment and so on !
vejmarie
- vejmarie
- Posts: 713
- Joined: Mon Jan 04, 2016 4:52 pm
- Location: Somewhere between France, USA and Taiwan
- Contact:
Re: OCP toolchain first mockup following OCP summit
I forgot to mention that the intend is that the feedback are provided within FreeCAD when the designer part of the team works on it avoiding him the painful process to login on a web platform through a browser.
vejmarie
vejmarie
- kkremitzki
- Veteran
- Posts: 2515
- Joined: Thu Mar 03, 2016 9:52 pm
- Location: Illinois
Re: OCP toolchain first mockup following OCP summit
This seems like a really cool idea! I'd prefer a platform like this rather than GrabCAD takes off.
The idea of collaboration tools within FreeCAD sounds cool too. If there's a sort of push & pull mechanism for files, the pull could grab some sort of feedback container that can be added to a file. A similar sort of container could be used as a neutral, never-run container of Python code associated with a file. Indeed you might want to just make feedback in the form of code for a user's consideration.
The idea of collaboration tools within FreeCAD sounds cool too. If there's a sort of push & pull mechanism for files, the pull could grab some sort of feedback container that can be added to a file. A similar sort of container could be used as a neutral, never-run container of Python code associated with a file. Indeed you might want to just make feedback in the form of code for a user's consideration.
- vejmarie
- Posts: 713
- Joined: Mon Jan 04, 2016 4:52 pm
- Location: Somewhere between France, USA and Taiwan
- Contact:
Re: OCP toolchain first mockup following OCP summit
The platform in the end will be much more than grabcad due to the interaction and the fact that it will support for each project EDA, Documentation file, source code and CAD ! (lot of work ahead)kkremitzki wrote:This seems like a really cool idea! I'd prefer a platform like this rather than GrabCAD takes off.
The idea of collaboration tools within FreeCAD sounds cool too. If there's a sort of push & pull mechanism for files, the pull could grab some sort of feedback container that can be added to a file. A similar sort of container could be used as a neutral, never-run container of Python code associated with a file. Indeed you might want to just make feedback in the form of code for a user's consideration.
Second thing is that we are building the plateform with an Open Source approach, while I do not think Grabcad is public. To me Grabcad is a youtube for CAD file, while we try to build the github
Re: OCP toolchain first mockup following OCP summit
Looks really nice so far.
Re: OCP toolchain first mockup following OCP summit
With the exception that with Grabcad you need to registered to even only watch the video!vejmarie wrote:To me Grabcad is a youtube for CAD file
Your work is very impressive!
Re: OCP toolchain first mockup following OCP summit
Very cool!
One headache I've experienced, that this might help address, is synchronicity between different repositories for different domains in the same project. For example, I've been working on some OSHW electronics, which have hardware files in a separate repo from the firmware that runs on the device, which is different again to the software that works with the device. For our workflow, it does make sense to have the separate repos, but at the expense of some bookkeeping to keep track of things like "board spin 2 March 2017 (deadbeef1) only works with firmware after 0dd0ddf00".
We don't actually do this, but I've considered being rigorous with tags (these are all git repos) like "add compatibility with hardware 123456789" or "drop firmware 000000007", so that a program could generate out a nice graphic to explain interdependencies, and answer questions like "I have hardware labelled v1.2.3 - what's the best firmware?".
Would be great to see a nice GUI to solve this problem - especially if it could be implemented by tags in plain language to the relevant repositories. This is important, because a particular interested person might only have visibility of one repo at a particular time (eg,if I'm on a plane trying to fix issue 1234 in the firmware). -Ian-
One headache I've experienced, that this might help address, is synchronicity between different repositories for different domains in the same project. For example, I've been working on some OSHW electronics, which have hardware files in a separate repo from the firmware that runs on the device, which is different again to the software that works with the device. For our workflow, it does make sense to have the separate repos, but at the expense of some bookkeeping to keep track of things like "board spin 2 March 2017 (deadbeef1) only works with firmware after 0dd0ddf00".
We don't actually do this, but I've considered being rigorous with tags (these are all git repos) like "add compatibility with hardware 123456789" or "drop firmware 000000007", so that a program could generate out a nice graphic to explain interdependencies, and answer questions like "I have hardware labelled v1.2.3 - what's the best firmware?".
Would be great to see a nice GUI to solve this problem - especially if it could be implemented by tags in plain language to the relevant repositories. This is important, because a particular interested person might only have visibility of one repo at a particular time (eg,if I'm on a plane trying to fix issue 1234 in the firmware). -Ian-
- vejmarie
- Posts: 713
- Joined: Mon Jan 04, 2016 4:52 pm
- Location: Somewhere between France, USA and Taiwan
- Contact:
Re: OCP toolchain first mockup following OCP summit
Yep we are aligned on this, as we experience the same issue in OCP. This is even worse, because we have procjets which are using same parts, and we will need to track down part changes requested by one project and "approval" from the other project to avoid creating incompatibility within the branch. A lot to think which is the most interesting thingian.rees wrote:Very cool!
One headache I've experienced, that this might help address, is synchronicity between different repositories for different domains in the same project. For example, I've been working on some OSHW electronics, which have hardware files in a separate repo from the firmware that runs on the device, which is different again to the software that works with the device. For our workflow, it does make sense to have the separate repos, but at the expense of some bookkeeping to keep track of things like "board spin 2 March 2017 (deadbeef1) only works with firmware after 0dd0ddf00".
We don't actually do this, but I've considered being rigorous with tags (these are all git repos) like "add compatibility with hardware 123456789" or "drop firmware 000000007", so that a program could generate out a nice graphic to explain interdependencies, and answer questions like "I have hardware labelled v1.2.3 - what's the best firmware?".
Would be great to see a nice GUI to solve this problem - especially if it could be implemented by tags in plain language to the relevant repositories. This is important, because a particular interested person might only have visibility of one repo at a particular time (eg,if I'm on a plane trying to fix issue 1234 in the firmware). -Ian-