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.
Comments
Now that @NeilCooke has released a couple rounds of the semi-official wire features, I'm curious what your feature does that is different/better?
It's simpler. I'm not trying to document a wiring harness, nail board or read a net list.
Cable's dialog:
This isn't an either/or. Use whatever one works for you.
I have the source code and can make it work for me.
The "gravity" feature is really neat in there to make things look "natural"!
We do have a need for creating "representative" wiring quite often where the process of creating to-from tables is totally overkill (and would be slower)
We have a couple of "in house" featurescripts we built to support our workflows (with a bunch of stuff stolen from your feature!). If you are curious it goes like this
- A feature to create variables for our "standard" stuff like strip length for connector and wire/cable insulation diameters.
- A "wire stub" one to create bits of stripped wires based on AWG and a strip length. We locate these on mate connectors based on in-context faces.
- A "wire jumper" that creates a swept wire based on OD, I can take 2 mate connectors for the ends (it defaults to the "nearest" orientation and a single value for tangency, but also allows controlling tangency at the ends independently if needed.) It looks a bit like a simpler version of @billy2's feature (only takes inputs for the ends) but is all we need 90% of the time and really quick to use. It also includes a drop down for setting the insulation color from "standard ones". I later added options to only generate the path (so that you can build "segments" using several of these features instead of supporting additional points), and to use an existing path (either from earlier "jumper" features or using a "freeform spline" or other method to generate the path). I also report the resulting length in a table
- I also created a spinoff of the wire jumper feature for creating "flexible conduits", the main difference is the added option to create straight bits at the ends (that go into conduit fittings) and warning about min bend radius.
Here's an example of the kind of thing we generate for user documentation:And how it gets used in customer facing documents:
The toolset I built lets us this quite quickly so we don't need anything else for the "illustration purpose" wires, but for actual harnesses that we design and create drawings for, I am really looking forward to using your feature (especially if there a "straighten" function by the time we are at that stage in our next project!).
Yours is definitely a more complete package and I've used it. I'm just wanting something that I can add higher level details to my designs. I'm not showing the exact details, but allocating the space for harnesses and pneumatics. If you've ever seen a robotic work cell, allocating space for inter-connects is important. I focus on power separation from signals. I want to make sure the pneumatic water traps aren't positioned over electronic chassis's. RF signals and tempest designs, what's clean/what's not. I'm looking for the best bus solutions that minimize cabling. Is TCP/IP better than CAN bus? Are motors with integrated controllers the future. We need more signals, feedback, all automation tries again if there's a fault. And here's one that popped up last week, can you touch 240v? Have you ever killed anyone with your design? These are things I worry about.
We've both have been doing this for a long time. I remember installing the 1st cabling solution for solidworks at medtronic's which took 2 days to just load the library. They didn't buy, thank goodness. Cable design in CAD has a long way to go.
Designing cabling harnesses is important and I think you're on the right track. What you've done looks really good.
What do I have that you need?
-you have gravity
-long straight's, sweeping doesn't really look like a cable
-scaling, if you change the design by 600x will it still work?
What do we need?
The reason I wrote cable was to figure out why the robots were destroying the cabling going to the end effector. Turns out the cables weren't long enough for all the robot's positions. The guys who ran the wires didn't check all the positions and wire length for those positions. So, if you make the cable longer, what does the cable look like at a position that's not demanding long throws. Route a cable on a robot, move through all the positions and find the longest length. Fix the cable length and now go back through all the positions and show the slack. I'm thinking industry needs better restraining methods for things you hang on the outside of a robot. The #1 problem in automation are the things you hang on the outside of a robot. They don't last.
I'm trying to figure out ribbon cables. As soon as I started using Cables I wished I could route flat cabling.
Neil I don't think you'll ever be done writing a cabling app. When are you retiring?
@eric_pesty
Is the label in the color version an image in a sketch using one of the custom FS which makes it opaque?
How are you making the line drawings like that (with grayed out parts)? Is that done with Onshape drawings or something else?
@billy2
How are you exercising the various positions of the robot and updating the cables. In-context? Some skeleton model which drives the cables?
That looks really good.
It's a trade off between CAD time and building it and taking photos to document. Yours looks really good, how long compared to building a prototyping and taking pictures? That's what a lot of people do.
Also, I'm not going to do that amount of detail, I'm too old, I'm not interested. I'd have someone else do it if it's fast enough. We built a piece of equipment and didn't have enough power in the building to run it. These are the problems I face.
Detailing a robotic cell that makes medical products is insane to document. You get a little longer in those cases. Cardinal Health never thought it was worth the CAD time. They took pictures and documented.
@S1mon
An example is in the cable feature script. I'm using assembly positions to control robot positions. Then the cables are in contexted to its own part studio with reference to the robot in top assembly. Cables has to run in a part studio, so cable are created in a part studio. I also use a cable assembly to maintain the cables in the top assembly. When I change the cable part studio, specifically by adding new cables, I go to the cable assembly and delete everything. With nothing in the cable assembly I add the cable part studio which gives me all the cables. Boom, they're all in the top level assembly. The problem with cables is trying to remember which cables you added. You don't want to be in the top assembly wondering which new cables you just added.
PM me your login email and I'll share it with you. Please don't make a copy of it. The cable updates and computes the length. It's doesn't show the relaxed state yet. You can easily go through the positions and see which is the longest cable length.
The pain is to update the in context after changing a position, and the fact that it's 2 levels deep in the menu doesn't help. Don't get me wrong, I like telling OS when to update, I just wish it was a little easier. I'm pushing for a hot-key assignment. I'm even looking at seeing if I can update an in context in the api and then routing the signal to update through a feature script in the part studio.
I've assembled the robot zero's to zero's in Onshape mates. The goal was to transfer OS positions using the API to the robot's controller. The way they program robots is crazy using way points.
I have a linear motor in my office that I'm control over TCP/IP. Haven't updated motor position with OS yet, but it's something I've been wanting to do. Whatever the motor is doing on my desk, I want my OS model to reflect this.
Good questions!
The label text is drawn in Onshape... It's not really the right tool for the job but it that way we can create a drawing of it (and include a 1:1 view to export as DXF and provide to the label shop).
I actually just created (/am in the process of creating... started on Monday) a new custom feature to make it easier for our workflow. We ended up settling for creating solids of the text (rather than a split surface) as it's better behaved (easier to manage colors, no "overlapping" edges showing up when done in multiple steps like splits, consistent behavior between shaded and line views).
The feature works like this:
- select sketches and regions to turn into "text" (or images/lines etc). We often break it up into multiple sketches to keep things manageable.
- extrude these to a solid
- attempt to boolean to get rid of overlapping solids
- create a closed composite
- Set color to all the faces
- Boolean out of "substrate" and composite together (this ensures the graphics are coplanar with substrate while removing any risk of the base part showing through).
We developed the process manually but it was a pain to do as it involved re-selecting stuff in several features every time the text changed (which is often when developing something like this!) so I think we'll get good mileage out of that feature.
Regarding the second part:
The base views are generated in Onshape. We use the "adjust line styles" to create the "emphasized lines" (with the template using grey lines). It's a bit of a pain to manually select all the edges you want to highlight but you do get pretty good at using box selection to creatively add and remove from the selection set. We would really like to be able to set line weights by part/component as it would help a lot!. The worst is that it often gets scrambled when you update the models (i.e. black lines move around)
We then export to SVG and import into office products (mostly PPT or Docx) to create the final document. Being able to work with vector files all the way really helps keep the quality up and makes it worth the trouble!
However we wanted a set of clear and easy to follow user documentation based mostly on images (think IKEA instructions) that could be printed black and white.
This is actually hard to achieve with pictures as you need really good lighting and careful setup to get anything reasonably "professional-looking" (and hard to highlight only the stuff you care about). It's also a pain if anything changes and you have to re-create the picture. Even then it's never going to look as good as line drawings.
Note that these are not instructions for a "one off" machines either (think 1000s of units) so it's a lot easier to justify the effort!
It's a thin edge between being a good/bad idea. If you can make it work and keep the costs down, it looks great.
I'm not sure most companies would pay the CAD costs, CAD people are pretty expensive for creating such fine documentation.
One thing that could help is having a web presence with all this fine documentation. It doesn't currently exist now, but I'm thinking more companies will make better cloud sites for people to purchase items. If the site is driven by your documentation style, your company will do well.
This is getting further away from cables, but I'm curious if your company looked at Cadasio at all for these kinds of illustrations? (also app store link) It seems like it would cut out some of the steps, but I've never tried it, and I don't know how often you need to do this kind of stuff.
Looks like I am causing this thread to derail a bit... Short answer is that we did briefly consider Cadasio but it didn't look quite "feature rich" enough for us. The industry we work in fairly conservative so we need old fashioned printed guides as the primary (and a PDF version on our website as a "secondary"). Plus having the final output in Office means it can be edited by by a greater range of people around the office.
Yeah the development manager would prefer us to spend less time on documentation... And we do have a couple people that aren't "primary" designers (tech sales and customer support) that would normally handle most of it but in this case there was a lot of them to do and it was also our first major project in Onshape so we were developing the process as we go.
One thing I will say is that we were not able to achieve that quality using SW for two reasons: we rely heavily on configurations to get the right CAD views (no other information needed...) and second exporting to SVG give much crisper results. One trick we use to set a custom sheet size to match the size of the image in the document which streamlines the process and ensures all the line weights look the same in the end (compared to exporting raster images and resizing). We did use a SW addon called "Composer" in the past but since we had just one license (expensive, not super intuitive), it meant only one person could work on the documentation so that was not good (part of the reason not to go with something like Cadasio).
Overall though we're pretty happy with where we are at with the process... A few improvements to Onshape to make it easier/less work to fix line colors would streamline the process but we are really happy with the quality of the end result. Good documentation also cuts on number of calls to tech support so that is another incentive to put the work up front!
I don't want to stop the party, I wish there were easier ways to achieve these goals. At least you're organized, most companies, it's a free-for-all and it's a mess.
After 9 years of cloud based computing, I'm surprised that our models aren't being shown on our company's website. Automatic updates with each version/release. All you do is create and you never have to document!
Keep going with this dream you have, I'm going to begin working on a webgl viewer and a new website, maybe we'll meet in the middle somewhere.
I hear you...
I experimented with using the API to generate images for our online product configurator but it got shot down as not "good enough looking", the lack of option to have perspective turned on (and to a lesser extent lack of control of lighting). I'm not sure showing a "live" 3D view would help with that complaint (although it might be "cool enough" to overcome the aesthetic concerns...), i'm not sure the configurator software is ready to accept that anyway.
Here's an example of what I was up against and the "get image" from the API just was too much of a step backwards: https://carmanah.com/custom-rrfb-crosswalk/
Now if we could access render studio output through the API we could potentially have the "best of both worlds"!
I was hoping to build something that taps into onshape's configurations and allows a web presence. That way if you can build a configuration then you could run a website. I'm thinking driving the website from the design engineers perspective.
I wrote this along time ago before you could get the 3D out of onshape. enclosure 8020
Webgl is a better rendering package than the render studio. I don't understand why we can't have real time rendering inside OS all the time. One of the webgl tasks is to create metalized shaders and apply them to parts coming from OS. I was going to read the material and swap the shaders and try to make the OS model look real. Perspectives is just a setting in the draw rendering function.
Speed is an issue, OS takes 70ms just to get to the 1st server. Each part has an already image in it and they're faster to access than asking to create an image. OS does a good job of caching images for you and the 2nd time is always faster. If you use the example above, if you toggle between 2 sizes it's instantaneous because OS caches the results. If you limit the choices, it can be really quick. Type in a height of 400 and it'll come up instantly, that's because I just did it.
One problem, if no one pings the page, OS archives the data. That's why it can be really slow. This isn't that big of a deal since you can run a cron job that refreshes your document once a week and keep it fresh for everyone.
You'd still have to entertain someone while the data is loading. One thought is throw up a crapping low resolution version with the better version sent at the same time. That way their spinning something while the real data is coming. You could also cache and image on your server and show that while the data is processing.
I think it could happen. We'll see. I'm going to build my new site at google gcp and see about spinning up the minimal server to handle this stuff. I want https, caching & sockets as a minimum. And then it needs to be in a container. Can a app do it or does it have to be a virtual server? We will see.
I was able to setup a script to generate usable images from the API but it just didn't look good enough.
I agree that the the "live" rendering within Onshape could be a lot nicer given today's available hardware and webgl architecture. We'll get there eventually!