Hamilton Shaker Carrier Modelling "Odd" Design

dev discussion
1

Hi everyone,

In PR#130 ShakerCarrier integration #130 I created a resource model for Hamilton’s L4 Shaker Carrier (Hamilton cat. no.: 187001):

def PLT_CAR_L4_SHAKER(name: str) -> MFXCarrier:
  """ Hamilton cat. no.: 187001
  Template carrier with 4 positions for Hamilton Heater Shaker.
  Occupies 7 tracks (7T). Can be screwed onto the deck.
  """
  return MFXCarrier(
    name=name,
    size_x=157.5,
    size_y=497.0,
    size_z=8.0,
    sites=create_homogeneous_carrier_sites([
        Coordinate(6.0, 2, 8.0),
        Coordinate(6.0, 123, 8.0),
        Coordinate(6.0, 244.0, 8.0),
        Coordinate(6.0, 365.0, 8.0),
      ],
      site_size_x=145.5,
      site_size_y=104.0,
    ),
    model="PLT_CAR_L4_SHAKER"
  )

Simple, nice, and completely incorrect (but workable with the HHS).

I am currently working on an updated more accurate version but would like to know whether anyone else has come across what I can only describe as (to me) “odd design”:

251220_Moschner_MFXShakerCarrier_model_question
251220_Moschner_MFXShakerCarrier_model_question2038×1516 850 KB

“Sites” for child resources (i.e. usually a small Hamilton machine like Hamilton Heater Shaker, Hamilton Heater Cooler, Hamilton Tilt module, …) are not defined by a “frame” (i.e. indentation in the top surface or walls).
Instead sites are defined by the 2x2 hole grid that is used to fasten child resources onto the carrier.

However, as shown in the infographic above, there are two different 2x2 hole grids on each site.

And - the odd part - the relative orientation of the “small” to “large” hole grid is different between every single site :see_no_evil_monkey: (noted in orange)

As you can see from the infographic, this is due to a difference in each hole grids “stepping distance”:

  • 124 mm for the small/blue hole grid (use for fixing e.g. the HHC)
  • 120 mm for the large/purple hole grid (use for fixing e.g. the HHS)

This represents a big question as to how we want to model this?

A simple “each site has a center_x-center_y to which a childs “ccb” should be aligned to, does not work.

We would need to tell each child resource which center - the one from the small or the large hole grid - it would need to align to.

Curious to hear what people think :smiling_face:

PS.: I’m sure there must be some reason for this design that I don’t know about :person_shrugging:t2:
Also, these measurements are made by me, and might therefore be wrong.

1 Like
2

that challenges our resource model

the good news is the mfx carriers already have quite flexible modeling: we require the user to specify the ResourceHolders explicitly when instantiating the carrier (base + sites), since the sites are screwed in. When instantiating a carrier we assign the modules that exist on the carrier, this isn’t done later. So mfx_carrier[0] for example will be a HeaterShaker rather than a pain PlateHolder as is the case in normal plate carriers. Not necessarily a super pretty solution, but a starting point:

mfx_carrier_tapped_plate_holder_example = hamilton_mfx_carrier_L5_base(
  name="mfx_carrier_tapped_plate_holder_example",
  modules={
    0: mfx_plateholder_dwp_0,
  }
)

(from cookbook recipe 1)

the solution will probably involve specifying the “site type” (big / small = purple / blue) in addition to the index (assuming we can’t figure this out automatically.)

modules={
  (0, "big"): mfx_plateholder_dwp_0,
}

…

1 Like
3

Mhmmm… okay, I think having these “site specification tags” (?) for each site - like you are suggesting “big”/”small” is a good fix.

I do wonder thought why these differing hole grids exist and whether this might come back to hunt us :joy:

Once I’m back in the lab I can take some more measurements to check whether this might be the best assignment strategy.

One idea I had as an alternative to having big/small + site index:

Assign child resources the oldest PLR way: assign_child_resource to location.

but we must be able to index MFX carriers, so can bake into this specific MFX carrier sth like:

modules={         
    Coordinate(x=5, y=60,z=18): HHS_1,     
    Coordinate(x=10, y=300,z=18): HHC_1,   
}

and the resource identifies the index for each child based on the y coordinate of each child’s origin falling into the area of the expected site?

Curious to hear what people think :slight_smile: