Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
No floppy blinkers
billy2
Member, OS Professional, Mentor, Developers, User Group Leader Posts: 2,068 PRO
Why do motorcycle blinkers flop? Have you ever seen a bike going down the rode and it's blinkers are bouncing all over the place? Who thought this was a good idea?
A floppy blinker:
It's just not cool.
So one idea was to attach a blinker to the front shock.
First design candidate:
Here it is installed:
These are much brighter than the original bulb type blinker:
After installing and seeing their brightness, I decided to use a single led emitter:
Wanting to re-use assets from the previous 2 led design, I branched into a single led design effort. Why? because all the feature are already built, I just have to change them to a single design. This is much less work than starting over in a new document. Will the single led ever merge back into the dual led? Never, I now have 2 workspaces forever and that's ok.
Why not just copy the document and start another design? Design management, with all my motorcycle designs, I put all front blinker designs in a document using my convention. In the future it's easier for me to find the front blinker design single led. It's a management thing.
So is branching a good design pattern for what if scenarios? We wanted to make changes before the version which can't be done with the branch design pattern. We're now using the derived pattern for what if scenarios allowing us to make changes any where in the design stack. This is working better for us for what if design scenarios. At a project level, I think branching is useful. There needs to be more discussions on this topic.
I'm sending the new design out for printing.
Updated design & mesh in virtual mockup:
Will post more when the new ones arrive.
A floppy blinker:
It's just not cool.
So one idea was to attach a blinker to the front shock.
First design candidate:
Here it is installed:
These are much brighter than the original bulb type blinker:
After installing and seeing their brightness, I decided to use a single led emitter:
Wanting to re-use assets from the previous 2 led design, I branched into a single led design effort. Why? because all the feature are already built, I just have to change them to a single design. This is much less work than starting over in a new document. Will the single led ever merge back into the dual led? Never, I now have 2 workspaces forever and that's ok.
Why not just copy the document and start another design? Design management, with all my motorcycle designs, I put all front blinker designs in a document using my convention. In the future it's easier for me to find the front blinker design single led. It's a management thing.
So is branching a good design pattern for what if scenarios? We wanted to make changes before the version which can't be done with the branch design pattern. We're now using the derived pattern for what if scenarios allowing us to make changes any where in the design stack. This is working better for us for what if design scenarios. At a project level, I think branching is useful. There needs to be more discussions on this topic.
I'm sending the new design out for printing.
Updated design & mesh in virtual mockup:
Will post more when the new ones arrive.
0
Comments
When are we going to go for a ride? Highway 1 is now open.
Nice design! How does it look at night from the front? And what did you use for the LED?
Onshape, Inc.
Funnily enough, having a carbon fiber printer and access to a machine shop really helps!
https://cad.onshape.com/documents/f4495c84340862e9cc887d44/w/fd9c966246b54451e8edc624/e/aa7e8d75752b5c19c58b9214
Not trying to hijack your thread - just sharing (its a public doc
Also, it is possible to branch from previous versions. If you want to create a branch from a previous micro-version, you can also do that through a little workaround. Here is a round-about way that you can create a branch from a previous version. Something like this:
- create a version of the "current" model (lets say we're at V3 on Branch 1 and we want to branch from an un-named point between V1 and V2).
- Expand the version tree to see all changes and find the point at which you want to branch. Restore this to the workspace.
- Now, create V4 with the "restored" model state.
- Create a branch from V4 (Now you have the previous model state as a new branch, Branch 2).
- Go back to Branch 1 and restore V3 to get back to your current model.
I tried this, and it seems to work. However, you also lose some visibility to what actually happened there, which may make it unsuitable if you're using branching to see a higher-level project evolution.The LED is something from china, I think most LED's are made over there now. The nice thing is that their's are 12v, heat sinked & ready for packaging. The US is focused on replacing LEDs in fixtures for lighting.
I worry it might be too bright for night, is that possible being too bright?
I'm normally off the road at night, so it shouldn't be a problem.
It produces 4 watts, so it's good to have it tied to the shock, I mean heat sink.
LED's are no longer an electrical or optics problems, LED's are all about heat transfer now days.
Did you print the battery holder? The lithium's are a lot smaller.
The holder material is Onyx (carbon impregnated nylon) - think abs with high impact resistance and very low crack propagation
Let me know if you need any parts
You can RMB on the history entry and find "Create version here" button to add a version at any moment in the past - no need to restore history, just branch from there.
That's a clever way to break up a linear history. I'll have to try it, thanks for the tip. It's nice to open up the version graph and see the different ideas used to create a design. I think it's worth capturing.
Many times I'll try something only to delete the features. I've always wished I could capture all my ideas bad & good in a graphical way. Infact, I just need to update my work flow to include it so I don't have to edit it in later.
I'm going to add a hinge to my design but not sure it'll pan out. I will version "before hinge" that way if it doesn't pan out, I can branch keeping the hinge that didn't work and continue on to something else. Like lana says, if you forget to mark the version before something, you can always go back and create it.
Currently I have to drop the forks to install blinkers which is painful. Hoping I can make it easier with a hinge.
The derived pattern is also known as the "master model", "base part" or "part inside part". You do so much in a part and then derive this into many others which are all different. The problem with this is trying to determine when to stop the 1st part, the common part. The second part that derives the 1st part is where all the "what ifs" happen.
Many use this approach.
It's simple to setup and utilize, I think it's a mess when trying to document it though.