Monopitch and Attic trusses are the next items I will tackle.

I've had a good bit of experience dealing with attic trusses in my own designs.  The big difference in configuration is the use of a piggyback where the truss height gets too tall for shipping.  I think it it would be cool to allow a user variable that enforces a max height and then draws a piggy back truss or the simpler configuration based on span, pitch and this max. truss height specified by the user:






Also with this type of truss I've noticed that the top chord section where no triangulation is present (diagonal ceiling) the truss depth is often inadequate for insulation.  Hence the need to split the top chord as shown in the first drawing with the overhanging portion 2x4 or 2x6 and the upper top chord 2x8 or deeper.

The piggyback is usually a small king post truss composed of 2x4 members all around.  The ceiling web of a piggyback is often 2x6 but I've seen 2x4 as well.

With more elaborate and longer spanning attic trusses I've even seen the bottom chord turned into an integrated floor truss where more depth is needed.

The simplest attic truss only involves six members:



Then to further increase the complications added a raised heel, typically not needed though since this type of truss is generally 8/12 pitch or higher.

If anyone has any other features or additional options that they would want to see included in an attic truss design please chime in.  This one really intrigues me, much more challenging than the common truss types.

I've had a number of requests for monopitch or monoslope trusses.  Shown below is a sample of potential configurations of this type of truss.  Has anyone ever seen a (5/3) or (6/4) or a (3/1) monopitch truss?  The first number is the number of top panels and the second number is the number of bottom panels to clarify.

For the fink truss all raised heel types are now active:





The algorithm is now smart enough to determine when to use a wedge, slider or vertical member with strut.  Depending on the heel height, and the pitch a wedge is either a 3.5" or 5.5" deep.  Likewise the slider is also auto selected to be either a 3.5" or 5.5" member.

I've also setup the plugin so it is now an .rbz file and can be installed from within SketchUp (preferences).

Another important change is the wrapping of the geometry creation portion of the script so that any changes to a model can be easily reversed with "undo"

I have the raised/energy heel working now for a fink truss where a vertical member and strut is required (heel height greater than 12" approx.).  Still working on the wedge and slider cases, they are actually easier to calculate and program, but I figured I would tackle the difficult one first.

When the angle between the strut and top chord exceeds 10 degrees I then apply a scarf cut to the strut at its centerline (try a raised heel height that exceeds 24" and you will notice the difference).

Here is an example of a fink truss with a 18" raised heel.  Notice there is no scarf cut at the top of the strut where it meets the top chord. 

In order to better document the development of the Medeek Truss Plugin I have created this forum and topic.  Please feel free to post to this topic directly or start your own on related subjects.

I have recently created a new map for Washington ground snow loads.  The data used in this map combines previous data from older snow load studies with updated data from automated SNOTEL sites.  The snow load calculations are based on a inverse distance weighting algorithm.  The new map can be viewed here:

http://design.medeek.com/resources/snow/washingtongroundsnowloads.html

In an effort to make the data as transparent as possible I have included links to each stations data and its log Pearson III analysis from within the detailed report.

Added two details/sheets for portal frame details and a detail for gable end bracing.

I am currently testing some new features with the Medeek API.

One of these is to offer state snow loads in addition to the ASCE 7-10 national values for ground snow loads.

Note the addition of the variable "localdata" which when set equal to "1" will trigger a local lookup of the snow load values.  By default without setting the localdata variable the API will only give national level values (normal behavior) and the response from the API will remain the same as previous revisions of the API.

Also note that when a localdata lookup is triggered the API must perform a reverse geolocation of the latitude and longitude.  You will probably notice the response time from the API increase by approximately one second.

Currently the states that have snow load data are:

New York
Massachusetts
Utah
Montana

Each State has different methods at arriving at their snow loads, so the addition of each State's data can be a time consuming process.

The plan is to add all of the States that have data that differs evenly slightly from the ASCE 7 ground snow load map.

---------------

Google has a reverse geocode API that I use to get the address based on the latitude and longitude.  Based on the city/county/state I then make a determination with the API as how to determine the local snow loads, each state is different and from there is also depends on each county/municipality depending on the state, so adding new local data can be significant work.

For instance Nevada County in California is based on tabulated values for each elevation however there are an East and West zone and also a small transition zone between them.  The snow load for locations within the east and west zone are merely a function of elevation and linear interpolation between the tabulated values, using the elevation service from google with the tables computation is a snap.  However, snow loads within the transition zone require interpolation for each zone and then interpolation between the two zone based on distances between the zonal boundaries.  It is rather complicated but quite easy to program once you wrap your head around it.   Then to make matters even more complicated the municipality of Truckee with the county has its own special tabulated values and transition zone, so this requires its own programming.

When you use the local data option you always will get the ASCE snow load in addition to any local snow load data.  If there is no data for a location you will notice the API returns "NO DATA" in the local snow load field and the local source field.

As suggested by a current client I will probably add in the geocode (address input option) since it may be easier than first finding the lat/long for a particular location.

I have since incorporated the local data into the regular API so you don't have to use the TEST address to now use the local data option.

I have updated the documentation to include the new options, please take a look at:

http://design.medeek.com/resources/medeekapi.html

Haven't posted in a while, but I'll put up some new information shortly.

Seems like sometimes you need to read between the lines with the code.  One thing I just realized is that the requirement to sheath the interior wall with Gypsum does not apply to certain bracing methods (ie. PFH, ABW).  So my assumption is that the penalty you normally take in calculating the wind and seismic factors with the gypsum omitted goes away with this type of bracing.  Updated calculations for all braced walls show below. 



Based on these calculations the only modification required to the plan is to increase the length of the interior braced wall(s) from 48" to 54" in order to get my 9ft of braced wall panel, originally this was 8ft of braced wall panel.  8ft will pass the seismic requirement but not the wind load.  Initially I thought the seismic loads would dominate with this analysis since I was shooting for SDC D2 but after applying the adjustment factors for the wind it became clear that the wind was just as much a problem.  The reasons for this are: 12/12 pitch of this roof (think large sail), tall wall (10ft), high basic wind speed, large open interior, and high exposure all compound together to make the wind a major factor in the bracing requirements.

Braced Wall Plan below:

This is the latest version of the 4828B, the porch now is 3 risers high and the vestibule has gotten a bit more spacious.





PDF files are here:

http://design.medeek.com/plansets/garages/GARAGE4828B-A6D-3/PDF/GARAGE4828B-A6D-3_ELEVATIONS_CONCEPT8.pdf

http://design.medeek.com/plansets/garages/GARAGE4828B-A6D-3/PDF/GARAGE4828B-A6D-3_FLOORPLANS_CONCEPT4.pdf

Started working on the floor plans for this planset.  Two different versions, one for the 10ft door and the other for the 9ft door.

I'm currently also working on a modified version of planset GARAGE4828-A6D-3.  This new plan has a very similar attic space but the three garage doors are centered and the entry door is on the side of the garage.   It also have a few more windows on the main floor.  I've created some concepts below with different configurations of the garage doors for everyones review:



9ft doors centered on dormers



10ft doors, off center from dormers



10ft doors centered on dormers



9ft doors off centered from dormers



9ft doors off centered from dormers, with arched headers

We have recently added the CAD Library for those who might need some resources for designing their own building project.  The AutoCAD details will be some of the more standard details that I use throughout the plansets.  The Solidworks models will be mostly components that I have created for generating the 3D models of the different designs.  Check out the new CAD Library here:

http://design.medeek.com/cad/cadlibrary.html

I've been using phpBB now for about a year and I've finally decided to switch to SMF by Simple Machines.  It seems like a much better forum software.  My main reason for switch was the amount of spam I was receiving with phpBB, the spam controls are very limited, at least out of the box.

Hopefully, everyone finds this forum software to their liking.  I've also added the member map mod which is a nice bonus.  If anyone has any recommendations for stuff they would like to see added please advise.