Last night I worked late into the night on what I thought would be a relatively simple start to what inevitably will become a complex iLogic SmartPart configuration.
As you can see in the image to the right (if you were to click on it ), I set up the basic parameters that describe a drawer as iLogic Rules. In the case of a drawer, the first question that needs to be answered is what is the material for the sides? The choices I’ve come up with so-far are Solid Lumber, Plywood, and Melamine—-which would be typical of most cabinet component manufacturers. Whatever the choices are in the real-world, they should determine what downstream options are available. The downstream options I included (so-far) are the side thickness, edge detail, and finish type.
I have written the iLogic Code that filters out whole parameter sets, such as shutting off the choice of Melamine and Plywood if Solid Lumber were selected (image above). I have also set up defaults for available choices, for instance: when Plywood is chosen as the main construction material, the plywood type is defaulted to ‘Euro Birch Economy’ and the thickness is defaulted to 0.5.These settings should also have the option to default to ‘last used’ but I’m not sure that is possible with iLogic by itself. I’ll look into it…
Last night I captured a bunch of images while creating the half-blind dovetailed drawer box so that I could give a quick overview of the modeling process…
I’m not going to go into anywhere near a tutorial detail level, but would be happy to create one at a later date if there is strong enough interest.
Everything in this model is centered on the YZ and XZ origin planes and rests on the XY origin plane. Some of the construction geometry serves no other purpose than as a visual aid in support of design intent.
The lines to the right of the dovetail profile below are merely to get a aesthetic clue as to the spacing of the tails…
…the single tail that was modeled is an extrusion with the Taper setting set to a parameter. This causes an angled hollow at the outside face of the tail that needs to be flushed-up with the outside face of the box. Continue reading →
In the image to the right you can see one of the incredibly complex iLogic iDrawer SmartParts line constrained in an assembly to the as of yet skeletal iCabinet.
I had hoped to get this out yesterday, but the website maintenance wound up taking a dozen hours or-so, and it wound up being one in the AM before the iDrawer was completed to the stage I needed it to be to insert into the assembly shown.
Now I need to go back and forth between the cabinet, drawer, and the iLogic rules which will mostly reside in the top, assembly level of the model. I also need to write the set of rules that control all of the options for the drawer, which, depending on the manufacturer, could be very extensive.
I may need to use the confidity configurator on this one, but time will tell. In the image below you can see the user parameters from the model , which need to be connected via rules to the iLogic parameters shown in the May 11Th post…
This is the first post for for a new and improved version of the iCabinet where I will discuss the limitations I have encountered so-far —as well as the likely solutions.
When I designed the last version, I based it on the cabinets I built for a previous shop I worked for as a worst-case scenario, but it is such an old-school style that I don’t think it would work well as a modular unit.
Those early cabinets were made from painted plywood, and were relatively light weight, but after switching to melamine in the 80′s, they became extremely heavy and were a strain to build and install.
There were many other drawbacks as well, so I decided to create a more updated design with adjustable legs & removable kick. The unit also makes far better use of materials.
Last night I fleshed out the case in order to run an assembly test. I ran into some limitations, but it’ll all work out in the end.
One of the limitations is that even though this unit will be a single, multi-solid part — it cannot be added to the Content Center with iLogic in place. If you try, you will get an error stating that there are external dependencies that need to be removed. Because the parts need to be placed as independent units, and they will need either iLogic or confidity configurations, Content Center is out. It cannot be placed via the Place iLogic Part command either, as we need to place and configure the same part over and over, and parts placed that way jump to the origin and freeze up if you configure them (very weird behavior). So copies will need to be made of the original part for every unit placed. Not too big of a deal, but a somewhat stumble-ass’d approach nonetheless.
[Update: The parts can be placed as iLogic parts. See the newer posts for details]
I received a Google Alert for the keyword BIM this AM that lead to a press release about a construction firm in Neenah, WI (a town just down the road from me). It was hard to figure who the release was aimed at, as it was a boilerplate ‘we use BIM, and are damn excited about it!” type of release, but with a bit of digging it became more interesting.
In the article, Peter gives an example of a workshop he performs. He gives a group a couple D-size drawings, one monochrome, and the other color. Starting with the monochrome drawing, he asks them to count the number of sinks in the drawing, and the group responds with 7, 8, or 9 sinks. He then asks them to count the sinks on the color drawing, where they all get the correct answer, 10. He doesn’t mention this, but I’ll bet it took less than half the time to get the rightanswer with the color drawing. In my experience, even the best people we had at one company made numerous mistakes on our black and white drawings. It is no wonder why, they looked like black spaghetti served up on king-sized toilet paper. It actually hurt your eyes trying to decipher the mess. Continue reading →