Trusses are now created as components with each individual member of the truss a group. Arrays of trusses are multiple instances of the same component.

I think this plugin may actually have some potential now.

A couple more screenshots for fun.  A well designed truss is a beautiful thing to behold:





I really appreciate everyone's feedback, this has helped guide me in the right direction on all of this and improved my understanding of SketchUp immensely.

22' truss, notice the change in the web configurations as compared to the 24' truss. 



There still may be a few kinks to work out in the algorithm that determines how many webs to place but overall I'm pretty pleased with what I have so far. 

I've officially added the attic truss updates to the plugin so they are now live.

This is the same truss I used in my 28'x48' garage:



Now I need to work on the energy heel option for this truss type.

I'm testing the attic truss.  At the moment I've only got one configuration which is probably about right for an attic truss that spans about 24-28 feet.  You can see below that pushing it out to span 36 feet is a bit of a stretch:



The piggyback option is enabled by enforcing a max. height in the inputs.

The left and right overhangs can now be set independently, however the right overhang defaults to match the left overhang to help speed user input:



I've also created a new page for the plugin with some basic documentation:

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

Just an FYI, the energy heels are enabled fully for the fink truss but not for any other truss type and the TRIAL version is actually not limited in any way.  I will probably keep it that way until the plugin is significant enough to actually warrant charging for it.

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: