I am starting this new discussion thread as a fork from the Medeek Wall Plugin thread since the Medeek Electrical extension will now become a stand alone extension/plugin.

Its logo will be:



I've created a series of basic default outlets and switches which will form the basis of the plugins pre-assembled components.  There will be many to add in later but this should be enough to allow me to setup the tools for inserting switches and outlets.

https://3dwarehouse.sketchup.com/model/7944ef20-48c4-40ee-ad10-993d18156c55/Medeek-Electrical-Low-Poly-Count

This extension or plugin is designed from the outset to work directly with the Medeek Wall extension however in the future I may extend it so that it can be employed with any wall geometry.   The details on all of that are yet to be determined.

Conway's Game of Life or Saturday Night Fever, I'm not sure which:



If the grid is much bigger than 20x20 it really slows down, at least on my computer.

Something like this probably needs to run at a lower level than the Ruby API.

My code is below:



    ### Conway Gameboard ####

    model = Sketchup.active_model
    entities = model.active_entities
    @view = model.active_view
    @faces = []

    @cycles = 0
    ysize = 18
    xsize = 18
    blk = 12

    model.start_operation('Generate Game Board', true, false, true)

    for j in 0..(ysize-1)

       for i in 0..(xsize-1)
          i2 = i + 1
          j2 = j + 1
          pt1 = [(i*blk),(j*blk),0]
          pt2 = [(i2*blk),(j*blk),0]
          pt3 = [(i2*blk),(j2*blk),0]
          pt4 = [(i*blk),(j2*blk),0]
          face1 = entities.add_face(pt1, pt2, pt3, pt4)
         
          face1.reverse! if (rand(4)<2)

          @faces << face1
       end
    end

    model.commit_operation


    def calc_conway

       @update_array = []

       for facei in @faces
       
          adj_live_count = 0
         
          if facei.normal.samedirection? Z_AXIS
             facei_status = true
          else
             facei_status = false
          end
       
          adj_faces_list = @faces.find_all { |e| !facei.bounds.intersect(e.bounds).empty? }
          adj_faces_list.delete(facei)
         
          for face_adj in adj_faces_list
             if face_adj.normal.samedirection? Z_AXIS
                adj_live_count += 1
             end   
          end
       
          if facei_status
             # Cell is Live
             if adj_live_count < 2
                @update_array << true
             elsif adj_live_count < 4
                @update_array << false
             else
                @update_array << true
             end
          else
             # Cell is Dead
             if adj_live_count == 3
                @update_array << true
             else
                @update_array << false
             end
          end
       end

       counter = 0
       for facei in @faces
          if @update_array[counter]
             facei.reverse!
          end
          counter += 1
       end

       @view.refresh
       @cycles += 1

       if @cycles > 200
          UI.stop_timer(@conwaytimer)
       end
    end


    model.start_operation('Run Game of Life', true, false, true)

    @conwaytimer = UI.start_timer(0.02, true) { calc_conway }

    model.commit_operation

I posted up a small web page on a chess variant that I thought might be interesting based on my recent observations of the world chess championship between Magnus Carlsen and Fabiano Caruana. 

Not actually having played this variant before I'm not entirely sure what the enlarged game board will do to the overall game experience. regardless I think it will be interesting. 

I'm going to put together a prototype board and some archer pieces and try it out with my son, Samuel.

http://design.medeek.com/mdk_chess/medeekchess.html

I don't know about the rest of you but when I look at the new wind speed maps in the ASCE 7-16, in particular the eastern United States I find the contour lines a bit confusing.  With that in mind I spent a couple minutes this morning trying to fill in some of blanks so to speak, see below:



Its obvious that there a number of saddle points in the isolines and that is what complicates things at first glance.  I am curious how well these hand sketched isolines would correlate with the ASCE hazard tool.

The way the map is shown in the printed manual doesn't define the isolines in enough detail in my opinion, too much is left to interpretation and user error.  The one spot value at the end of Lake Michigan is a case in point. 

I know there are a lot of plugins out there that do this well and I am not really interested in competing against them.

I just want a simple door and window plugin that I can integrate tightly with my other plugins.

The window module will have the following options (subject to change):

1. Window Type: Picture, Slider, Single Hung
2. Frame Color
3. Frame Width
4. Frame Depth
5. Glass Thickness
6. Sash Width
7. Sash Depth
8. RO Gap
9. Window Inset
10. Nail Fin: Yes/No
11. Nail Fin Length
12 Advanced Options: Yes/No

The global settings will allow the user to set up the defaults for all of these settings and others. The window location and size will be selected via three points with a preview vector showing the exterior facing direction in some sort of fashion.

I haven't thought through all of the advanced options yet but mullions will probably be one as well as other embellishments.

I have increased the limits of the top and bottom chord loads.

Starting to think about the parameters of the Medeek RC Plugin starting with columns. 

Here is an example of a typical rebar cage.  Given the longitudinal bar spacing this column would require additional ties for the middle bars.



View model here:

https://3dwarehouse.sketchup.com/model/8cd4dea1-701b-42c6-baa0-2f3fd958de2d/RC-Column

The icon or logo for this plugin will be.

Medeek RC Plugin Icon:

Started to put the Wall Plugin together in earnest today.  A lot of competing interests so I'm still not sure on the date of first release yet, but at least I'm putting something together now.



For the Imperial Version the First and Second Menu Items (Ext. Wall Type) are currently:

First Menu:

1.)  Wall Mode:  Line, Polyline
2.)  Wall Type:  Exterior, Interior
3.)  Wall Justification:  Front, Center, Back
4.)  Wall Height (in.):  97
5.)  Wall Header Height (in.):  80
6.)  Stud Size:  2x2, 2x4, 2x6, 2x8, 2x10, 2x12
7.)  Stud Spacing (in.):  12,16,19.2,24,32,48
8.)  Stud Direction: Left, Right
9.)  Corner Offset (in.): 0
10.)  Top Plate:  1,2,3
11.)  Top Plate Thickness (in.): 1.5
12.)  Bottom Plate:  1,2,3
13.)  Bottom Plate Thickness (in.): 1.5
14.)  Adv. Wall Options: YES,NO


Second Menu (Adv. Wall Options):

1.)  Wall Sheathing: YES,NO
2.)  Sheathing Thickness:  3/8,7/16,15/32,1/2,19/32,5/8,23/32,3/4
3.)  Wall Cladding:  YES,NO
4.)  Cladding Thickness:  3/8,7/16,15/32,1/2,19/32,5/8,23/32,3/4
5.)  Wall Gypsum:  YES,NO
6.)  Gypsum Thickness:  1/4,3/8,1/2,5/8

I will start with the (single wall) line mode first and then progress to the polyline once I have the basic system working.  Then the addition of doors and windows and advanced options which will automatically insert doors and windows into the openings.

I've been thinking about brick facade and I'm not entirely sure how I'm going to incorporate this into the plugin yet.  Typical air gap is 1":



A 5.5" thick stud wall with 1/2" sheathing and a 1" air gap with 3.5" thick brick fits on a 10" stemwall with a 1/2" overhang of the brick.  Does anyone have any wall details/sections that they would like to see implemented in the plugin?

Here is the same wall but with a 4" x 6" brick ledge:



Notice the APA detail the brick ledge does not project below the structural sheathing, this probably makes more sense since you probably don't want the butt end of the sheathing sitting against the concrete and absorbing moisture, even though there usually will be a foam strip between the sill plate and the concrete.



I've also seen details where the sheathing laps down over the brick ledge about a 1/2", this probably makes sense in helping to keep the bugs out but then it puts the sheathing into more direct contact with the concrete.  More discussion on this subject is warranted.  I've never actually had to provide a wall detail for brick since most of the construction locally is with hardi-plank siding so my experience with brick is theoretical at best.

I haven't fully committed yet to coding all of my engineering calculators within the SketchUp API, but I am heading that direction as I further contemplate my next Sketchup Plugin: Medeek Structural Plugin.

The largest obstacle is the ability to generate MS Excel files and PDF documents (reports). For this to really work I need a way to have my plugin's calculations export their data into nicely formatted spreadsheets and/or PDF reports. I have no idea where to even start and don't even know if this sort of thing is remotely possible with SketchUp, the API or Ruby, I'm assuming it is because I am sure other people have run into this same sort of thing as me.

Any assistance or direction in this regard would be greatly appreciated.

Ultimately, I am hoping to create a structural plugin that will allow an engineer to do all of the lateral and vertical calcs for a typical residential or light commercial wood structure. The reason for using SketchUp for this sort of thing is the ability to leverage SketchUp's intuitive drawing interface to create all of the building primitives/elements and provide an easy to use method for viewing and inputting building geometry and other design criteria.

I've actually had the idea to create this type of program since about 3 years ago but the show stopper was always the graphical interface and 3D component of it. Not until I began tinkering with the API about a year ago and waded into a full blown plugin development (truss plugin) did I realize the potential available within SketchUp. SketchUp and its API solves the 3D interface hurdle magnificently and now I am hopefully on course to create the one piece of software that will be the apex of my engineering career and hopefully further automate and advance the field of residential structural engineering.

I've recently uploaded my latest volume of residential structural details to the CAD Library. 

Version 1.0.0 - 07.03.2016
- Created Medeek Foundation Plugin, utilizing SketchUp's Ruby API.
- Added slab on grade foundation type (rectangular outline only).
- Added garage curb and interior footing options.



View model here:

https://3dwarehouse.sketchup.com/model.html?id=1b5e9234-04a5-4e6f-bd4d-ec3006a2f6a4

https://www.qrvr.io/p/K7bzyt

The thing that would make this plugin particularly useful is if the user could define a polygon outline for the foundation, that will be next, then onto stemwall foundations.

For the next week or so I'm going to spend some of my free time on wood gusset plate engineering.  I'm going to post engineering questions and some quasi-engineering questions regarding the connections.  Realize that some of these questions are me thinking out loud, contemplating how best to approach this type of truss design.

I'm looking at the nailing of the gussets right now and I'm considering the difference between nails in single shear or double shear. For larger fasteners (ie. 16d nails) it would seem optimal to clinch them on the reverse side and then calculate them in double shear. My question is at what length of fastener exceeding the total thickness can I functionally clinch the nails and consider them in double shear.

For argument sake lets assume a 1.5" truss ply thickness and 1/2" gusset plates each side giving a total thickness of 2.5". An 8D common nail is 2.5", however I would not consider it in double shear in this application. If I were to use a 10D thru 16D common nail in this situation I would have at least 1/2" of nail or more to clinch so in those cases I think I could safely assume clinching was possible and nails are loaded in double shear. Would less than 1/2" of nail protrusion be too small to clinch?

To open up the calculations to as many options as possible I'm considering 8d, 10d, 12d and 16d nails with all the three possible nail types: common, box, sinker.

I also considering 6d and 7d nails but I'm not sure if I will allows those yet.

The plywood or OSB thickness will be: 3/8, 7/16, 15/32, 19/32, 23/32.

Giving this even more thought it would seem that certain gusset thicknesses and nail combinations would not be optimal if the possibility for clinching and double shear is not possible. For instance if I have 23/32" gusset plates on both sides and 1.5" truss ply for a total thickness of 3". If I were to use a common 10D nail or 12D nail I probably could not clinch and therefore double shear is not possible, hence I would have to nail the truss from both front and back. Would this not tend to cause the main member to have more tendency to split since there are double the nails in it.  It would also require roughly double the nails.

I'm also going to assume that the osb/ plywood is Structural I, this would be my recommendation anyways in an effort to eliminate defects and require a stronger material for the gusset plates.  This affects both the shear values of the gusset plates and the lateral loading capacity of the nails.

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.

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

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:

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.

Online access to the full 2012 IRC:

http://publicecodes.cyberregs.com/icod/irc/2012/index.htm