Hi jo

My mission for CabinetSense is to provide an easy to use, affordable solution for the smaller cabinet firm. Sketchup is certainly both of that and only time will tell if I can deliver as well.

I hope to move CS in two directions, firstly as a design tool that will help sell as well as cement the specifications of the job; and secondly as a production tool that will accurately and seamlessly move the job to the shop floor.

Certainly as a production tool, cnc is on the radar. One of the inherent issues with Sketchup in this regard is that it represents arcs as a series of line segments. However, CabinetSense is not meant to be one-stop solution and I believe a viable solution to this is to simply defer any radius work to another program. CS would do the bulk of the case good processing including, drill points, dados... I'm still very much of a novice when it comes to cnc and the different ways you can communicate with them.... whether that be DXF or direct-to-machine coding. I have no timeframe for implementing this, but it is more of a learning exercise at this time rather than a work-in-progress.

Thanks for your input.

Paul

Hi jo-ke,

Yes, CabinetSense is finally available for download at http://www.cabinetsensesoftware.com. There is a 14-day free trial and it is available for both the Mac and Windows.

Feedback is most appreciated.

Paul

Very nice Kitchen d! I'm partial to that style myself.

CabinetSense is "still" in development, but it is getting very close to the point where I will be satisfied with its options and stability. My target date for release has been mid-year and I'm still close to meeting that target.

For those of you who might be fans of the cutlist plugin for SU...

I am pleased to announce that CabinetSense will be offering a modified version of this very popular plugin. Steve (Racz) and I have reached agreement on the best way to launch this offering and CabinetSense will have full permission to modify and resell Cutlist.

This modified version will be aware of all CabinetSense settings and in particular will offer grain control, banding reductions, and scribe allowances. It will also use Material selections and thickness as set in CabinetSense. For those of you already using cutlist, this version will continue to work with non CabinetSense models, so you won't need to have two versions installed.

Cutlist for CS will be available on a pay per use basis and optionally on all of the unlimited use packages at a minimal additional cost. Pricing will be finalized within the next couple of weeks.

Please visit http://www.steveracz.com/joomla/ For more information on the cutlist plugin.

Paul

Hello all

I have been developing DC's for my cabinet software over the past several months and it has been a struggle trying to get them to work in any kind of consistent manner. It wasn't uncommon for some of my attributes to share the definitions values with other instances, yet another attribute in the same DC wouldn't! To say the least it has been very frustrating.

About the only way that I could ever get consistency was to make every DC and every child DC unique, which makes any complex component to burdensome to use and kind of defeats the purpose of having a definition. Well.... after getting intimately acquainted with the dynamic_attributes dictionary, by watching how it changes as you develop and then use a DC, I've discovered a couple of things that have not only fixed my problems, but has restored my faith in DC's

I started developing my DC's under SU7, and I believe that most of my problems were from that time period... so this thread may be irrelevant if you've only been using SU8.

There are two things that I found that have fixed so many of my issues.

1. From what I can tell, there should always be a 1:1 mapping of the attributes between the component instance and definition dictionaries... but this is not always the case. When I say attributes, I am meaning the attributes that you create in the components attribute dialog... there are all kinds of other ancillary information stored in the definition that aren't shared with the instance. There were situations where my instance dictionary did not have all of the attributes declared... and when this happens, the instance picks up the value from the definition. This means that that particular attribute will be subject to the value of whatever the definition holds at any point in time (and it doesn't matter if the parent DC is made unique or not). When the attribute is present in the instance dictionary, it holds it's value private and respects any "uniqueness" invoked.

As an example; If you have a cabinet with several child DC's, it is the child DC's that experience the problem that I'm describing. Should you access the value from another DC or from ruby, you will get whatever the definitions value is at that point in time... which may not be what you were expecting. The cabinet, being the top level DC, will not share it's values regardless of missing instance attributes in the dictionary.

2. If you have an attribute whose value is empty, then it too will act as if it is undeclared, and pick up the value from the definition as well.

I have written a ruby script that will list the instance/definition dictionary key/value pairs for the selected DC and list it's missing information as well. There is also an option to recursively fix what ever you have selected, or the entire model if nothing is selected. The results are displayed on the ruby console, so you will need to open that first before running them. You can access the scripts though the plugin or context menus. Please take the necessary precautions in case you need to restore your models.

These fixes have made a huge difference for me and I hope they can help others who may be experiencing the same kind of issues.

Paul

csValidateDC.rb

The beta test is going well and hopefully I will meet my target date of mid/2011 for release. One of the exercises that I'm doing right now is to pull cabinets from the 3d warehouse and try to duplicate them to smallest detail. I think I've come pretty close, but you have a look. CabinetSense models are on the left.

Paul

I have developed a cabinet design program using Dynamic components... Please see thread http://forums.sketchucation.com/viewtopic.php?f=80&t=32789 for more info.

I am getting close to going into a beta test environment and would like to have a few people with cabinet knowledge give it a test. If you have an interest in this area and have some time to help out, please pm me.

Thanks... Paul

Hello Everyone,

I've been busy the past few weeks enhancing the software and have now finalized my first release candidate. I will be doing final testing over the next couple of weeks and when I'm satisfied with the stability of the product, I will be releasing it into beta test... and that's where you can help.

If you have experience building or designing cabinets and have some time that you could devote to giving the product a run through, I would love to hear from you. I can only manage communicating with around 10 testers, so if the response is larger than that, I won't be able to accommodate everyone. Please PM me regarding your interest. Any information you could provide regarding the style of cabinets you build (frameless vs FaceFrame...) and methods used would help me choose a team with the widest variety of knowledge.

thank you... Paul

Hi dedmin... good post. I agree totally with you in regards to the way SU handles duplicate dynamic components... I sure wish there was a way that you could just turn that off. It's vital that one understand how DC's work in order to avoid "unwanted" surprises. IMHO, though, they are still a very worthwhile and versatile feature.

I've taken the comments that you and Jim have provided me and have made a number of changes to the way my software works:

My export script now gives you the option of renumbering any duplicate cabinets and synchronizing it back to the SU model. I have taken Jim's advice and concatenated this information into the component info name field. When you pull up the DC's component options dialog, it will now display "Cabinet 1", "Cabinet 2"...

With regards to banding, you declare the banding requirement as none/primary/secondary for each side on every cabinet piece (EG. top, deck, left end...). What you can now do is substitute banding material names at export time. My software has a job DC that allows you to specify a number of things including what banding material should be used for primary and secondary. If I have a standard cabinet that declares which edges need to be banded (primary or secondary banding), the actual banding material used could vary for any job that i'm doing... so I now can record that for a specific job (eg. a kitchen that has 30 cabinets) I will use white pvc edgebanding as primary, and oak wood veneer as secondary. At export time, the banding info will be specified using your codes (WPVC-OAK-0-WPVC) instead of p-s-0-p. If you choose not to use the banding material substitution... the export reverts back to the p-p-s-s cutlist plus format.

I haven't had any problems with the inches internal format for mearsurements. The export program detects which end-user model units is being used and converts all dimensions to your selection. Lastly, I have been able to extract the component options label value from the DC. This will allow me to use this value (which could be non-english) as the report header for any exports. I believe that is what you were wanting.

Thank you for all the feedback that you have given me... I appreciate it very much.

Paul

Thanks for the link dedmin. The features demonstrated in the videos would make good additions to the software and I think it would make sense to plan for some of these in future versions.

The two main features that I liked were:

1. Architecural line drawings. These kind of documents are crucial if you are bidding on commercial work... as well as for forming the final specifications of any contract. At this time, I rely on Layout to provide this capability, but I would love to have this done automatically for me.

2. joinery hardware and placements. My software assumes that the cabinet builder will use their own methods for determining this (jigs, measurements, build notes, knowledge...). Programatically, it presents some challenges to try and implement this within the current feature set of dynamic components. A few months back, I submitted an enhancement request to the Sketchup team that would make this a relatively simple matter... I'm hoping that the level of complexity for SU to provide the feature won't be prohibitive and that it might fit strategicaly for growing their product.

What were the things that interested you the most, and which ones do you think are critical for the initial release?

My goal for the initial software release has been to provide a basic product that can design/layout cabinets and whose generated cutlist can be trusted regarding material, dimensions, grain orientation and banding. All placements and methods of joinery (dowels, biscuits, RTA fasteners) would be outside this domain. Perhaps my scope is too limited to make a good first release... it would be interesting to hear the viewpoints of others.

For those interested in my videos, I have done 3 to-date and plan more for the future. Please check my channel (http://www.youtube.com/user/CabinetSense?feature=mhsn) from time to time.

And as always, I welcome everyone's comments and views.

Paul

I have put a new video up today. As always any comments and recommendations would be most appreciated.

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

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

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 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

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

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.

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?

I have taken a look at the information you sent on Euro construction. Other than the thickness of your materials, It looks very similar to the way that I build my cabinets. The software does allow you to control the thickness and type of materials used. You can use a solid planted back or use a thin back that is inset into grooved cabinet walls. The toekicks that are shown can be detached so that you can use adjustable legs (which is what I do). I only use the toekick box for display purposes... the software allows you to suppress the export to the cutlist program. All in all, I didn't see anything that the program couldn't accomodate.

As for where you can get it. I still haven't released it... it is getting close... but work keeps getting in the way... lol. What I am looking for right now, is for confirmation of what I've done, items that need to be fixed or missing elements that need to be added. I'm not sure of the best way of handling that and am open to suggestions.

It's all done with Dynamic Components... the only exception being the export. It does support both Grain Direction and banding.

Some of the other features include control over insets and offsets, joinery (butt vs dado), frameless vs faceframe, Applied Ends, some control over carcass construction, and metric and imperial measure.

Can you give some examples of how European methods differ from American?

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