Cabinet Design program for Sketchup
-
I store the grain as the X,Y,Z attribute with each individual component (IE. Deck. Right End, Left End, Back...). My export script then determines how to specify the length/width to Cutlistplus so that the grain is always the Length.
Banding info is held for each of the sides (top,bottom,left,right) of each component and is stored as primary/secondary banding. Cutlist Plus then interprets it according it's values as to what has been defined as primary/secondary banding.
I'm not sure what you mean by the non-english characters - I pass the info in a CSV file with the first row containing the headers.
I downloaded your panel.skp but the contents didn't have a component, only individual faces. could you check - maybe I did something wrong?
-
Don't open it directly - import it as a component. Can You export the labels as a header data - http://forums.sketchucation.com/viewtopic.php?f=80&t=29835&start=30.
I'm using just a plain text to adjust the banding for export to CutList, but use materials to paint on the edges and to calculate the real length of the banding - as CutList works only with straight edges. And I can change the texture of this material to match the real band - we sometimes use a different color for the edges. For grain direction I use a switch that just swaps length and width in the Options Window, but doesn't change actual sizes - it is just for exporting to CutList. I have a field for oversize the panel - again,this doesn't change the real sizes, just in the Options Window. This is needed when this panel is non-rectangular and to be cut to final shape. -
Thanks dedmin, I was able to import your panel.
After reviewing the link you provided, I believe I understand the issue of non-english characters now. The only report that I have done to this point is the csv export to Cutlist - and the headers are hard-coded to match what cutlist plus is expecting. The issue becomes important when the report is intended for you to view - you want the headers to be the external names (labels) that have meaning to you and not the internal (english) names that the program code uses. I haven't attempted this yet, but if I can get the label value out of the dictionary, I should be able to generate the proper headers. Thank you for highlighting this! It's a very important interface issue.
Panel.skp:
I let cutlist plus manipulate my cut sizes. If I want an oversize piece (typically it would be for scribing), I use the secondary banding indicator. In cutlist, I associate a negative value to this banding with the result being that the panel is cut oversized on the sides(s) that I want. I don't currently store banding material names within the components. I typically only have one project on the go at any one time, so I rely on my external notes to know what material to use. I don't track banding length requirements nor costs as it is fairly insignificant in my operations. Is this different for you?
I notice that you keep the joinery method (biscuit, dowel, screws...) rather than the joint (butt, dado). as well as the count of items needed for the panel. I need to address parts inventory before I release the software. I was initially thinking of only slides, hinges, and handles/pulls, but will re-think how far I should go.
-
My goal is to do as much in SketchUP as I can. Often I work together with the customer - we change colors, handles, legs, materials and etc. I need to code all the valuable information inside a dynamic components. Say for a handle - drilling distance, material, price. For a leg - variable height - from 80-100mm, material, price. This way I have all the info needed for building the project, for answering customer's questions and for calculating the final price. Everything is changing fast from project to project and I can change this data on the fly why building the project. My intend is to export all this data by similar components - say the panels share the same labels in the Component's options and I can export this as a sheet "panels" in OpenOffice CALC where the labels are the headers for the table and use Sum to get all the data. Then for the legs, handles and etc. And this makes sense - for order list and etc. You hardly order all the stuff to the same supplier. This way there is no central database to carry on - everything is with the components, easy to see and change - simple and flexible. For the joinery - we have jigs and a system for drilling and we need only to now what kind of joinery is needed and to calculate price and quantity - again, easy to change on the fly.
-
@krisidious said:
I worked in a cabinet shop here in America for 3 years.... and I have to say they are moving toward European methods and measurements.
That's good to hear, Kris.... hopefully we'll all be working off the same units....
-
@unknownuser said:
I have developed a Cabinet Design program for Sketchup which may be of interest to this forum. You can watch a preview of the software at http://www.youtube.com/watch?v=763bsw5Y0Gk - your comments would be appreciated.
Paul
Hi Paul, so do you expect to release this plugin?
-
Hi Andrew,
I do plan to release the plugin but have no fixed date as to when that will be. A lot depends on how much time I can take away from cabinet building, but my goal is to have it ready within the next few months.
I have been using the software in my business for the past year and am satisfied with the stability of it. It does what I need, but question whether it can handle the requirements of others. One of the purposes of this thread is to gather any reactions that could improve the product before release.
My next step is to start producing a series of product how-to videos that I hope will generate further discussion and awareness.
Your comments are always welcome. Please keep checking back for further discussions and video announcements.
Paul
-
-
Hi Bob, I did take a look at the tomatoes plugin last year and took another look this morning to see if the concept was still the same - which it appears to be. It lets you easily create cabinets, but lacks the ability to modify the dimensions or contents afterwards - that's a task that you do on your own or through another tool like FredoScale. I think that on smaller projects, tomatoes could be a good tool to use. I'm not sure how effective it would be on a large scale project where changeseems to be the one constant.
With my components, you can alter all parameters after the fact - add a drawer; change doors/drawer fronts, counts, and reveals; if you change the type of drawer slide used, the drawer box size will recalculate automatically; change material thickness and all affected components are adjusted for you... You can create a model cabinet based on how you build and then store that in your components list. Once it is in that list, you can use it over and over again without having to do any work other than specifying its width - In that respect it is similar to tomatoes.
Paul
-
How do You handle different sizes of the same cabinet - I mean the names. Say we insert cabinet A, then another copy of the same cabinet A, but this time change the dimensions and put a different door. In the final cutlist how we gonna know which parts belong to winch cabinet? Now I'm making the copies unique and use this naming conventions - cab_part#1, for the copy cab_1_part#1
-
Dear Paul,
If you could ensure that your design software applies equally to EU/UK and USA standards, then I'm sure it would be well received. In that respect, Tomatoes might be helpful in gauging the degree of conformity with EU standards. The versatility of your software should appeal to the professional kitchen cabinet designer.
Kind regards,
Bob -
That's a very good point Bob, thank-you, I will look at it again from that perspective. I think you hit the nail on the head regarding your comment about meeting different standards, it is one of my top concerns.
Paul
-
Hi dedmin,
The solution I'm currently using is to have the export program make each cabinet unique. The sub-assembly in the cutlist plus export will contain the unique cabinet reference name (EG. Cabinet(1)). The part that I don't like about doing it this way, is that there is no direct tie-back to the sketchup model.
Paul
-
Yes, that is one of the problems with dynamic components.
-
@watkins said:
Have you seen this?
Kind regards,
BobThis plugin creates only groups with strange names, a lot of reversed faces and the export doesn't group the parts, nor determines width, height and thickness. Not practical at all.
-
@dedmin said:
How do You handle different sizes of the same cabinet - I mean the names. Say we insert cabinet A, then another copy of the same cabinet A, but this time change the dimensions and put a different door. In the final cutlist how we gonna know which parts belong to winch cabinet? Now I'm making the copies unique and use this naming conventions - cab_part#1, for the copy cab_1_part#1
It is possible to have an attribute that is dynamic and uses dimensions/values directly from the model to create the name or attribute.
-
I didn't know that. But what happens to the internal links between nested components? As the position of the shelf is linked to the side and the like?
-
I'm not sure what happens with the internal links, but I think there are 2 names for a component. One being the SketchUp definition name, the other being the DC name. In the following image, the Component Info name is dynamic while the name used internally remains "Shell". This way, the generated name can be used for reporting.
Here is an example of a cabinet whose name is created from the dimensions:
http://sketchup.google.com/3dwarehouse/details?mid=374be90c75e3c8703fe047712e43e185&prevstart=0
And it's name formula:
=concatenate(if(Type=30.5,"B",if(Type=28.5,"A",if(Type=26.5,"V","D"))),"27P2",if(Shallow_Depth=23.75," ","S"),if(aWidth<>27," (modified width "," "),if(aWidth<>27,aWidth," "),if(aWidth<>27,")"," ")) -
Thanks, Jim. Yes, when the option change, it creates a new component but the names are so messy! Needs a further investigation.
-
Thanks Jim. I use the component info name when I export the cutlist data. I had been searching for a way of getting a unique cabinet number to attach to the name when the DC gets created. I was hoping to reference some external component (like a project file DC), but haven't had any luck figuring out how to do so.
Maybe the solution to this problem lies somewhere between your thoughts and what I'm doing currently (creating the unique name for export purposes only). Maybe I should be actually updatingthe cabinet DC's via a ruby script and generating a unique name at that time. It could be an option when the export is being generated. If the option is ignored, the system would still generate the unique numbers for reporting, but would not update the model. I think that's an acceptable workaround. thoughts?
Paul
Advertisement