Bridging the Table Gap Part TWO

 In Part ONE, I explained the problem I am trying to solve and what my solution is.  Now I am going to take it a step further.

Here I have built a portion of a cliff over the double hinge.  The right side is four studs wide and the left side is one stud wide.  You can also see how the single stud wide left side slides up and down from the discontinuity in the picture.

Here the hinge is separated and the left and right side are connected to the modules that they will join together.

It was at this point I decided that a single stud width of a full cliff was not going to work.  Transporting and assembling that would be very difficult.  Rebuilding it at every show would be time consuming and not practical.  So I made it two studs wide.  While that may not sound like a lot, in the Brick world that is a  100% improvement in structure stability.  

The final result from the front.  I used several layers of cardboard to simulate the table gap.  From experience it has taken about this thickness of cardboard to attempt to compensate for the table gap, mostly unsuccessful since the remainder of the MOC would have to elevated also.

I have pointed out the discontinuity.  It goes together nicely, but the connection is not on an even stud count.

As this picture shows the 2 x 4 sand green tile is not lined up and the vertical distance is not an even stud distance either.  Thus there is no way to use plates or tiles to secure the connection.  What is holding it together is the bar/clip arrangement that was discussed in Part ONE.

 

Bridging the Table Gap Part ONE

 One of the big issues when setting up for a show is bridging the tables.   Normally the display is over 14 feet.  The only true bridge is the one from the end module to the Space Port.  But this is towards the end of the display and never falls on the table gap.  Normally it will come some where after the main entrance and before the display starts to curve.

There are two main issues.  First is the obvious table gap and the fact that two tables are not necessarily the EXACT same height. Remember that Lego dimensions are extremely precise.  Also we have seen tables that have a small (1/8 to 1/4 inch) rim around the table, which is causes a height imbalance.  The other issue is the weight of the MOC.  Some tables, especially the plastic fold up tables, will sag in the middle because of the weight.  This causes the module interface to be rising on an angle when the module on the other table is flat.  Connecting the two becomes difficult.

If I try to place the table gap underneath the middle of a module, then both ends of that module are placed in distress.  There is just not a good answer with the existing design.

My solution is a hinged connector.

 What this is a double hinge.  If you look carefully at the first picture, the goal of this connector is to connect an edge any just about any angle to another edge at a different angle.  One hinge joint will not do this.  It will take to serial hinges to adjust to the level and angle.  Obviously these is a limit to what can be compensated.  Also there is no guarantee that the linear distance between the two will be a Lego dimension.  But that can be compensated for with scenery and landscaping.

These two pictures show the connection between two cliff modules.  It is very similar to the other connections that will be made.Technic bricks are used to connect to the modules on either side.  Then a 1 x 2 modified plate with bar and one with two clips are used to connect and form the movable hinge.  There are three connection on the right side.  This is meant to be the more permanent side.  The left side with only two connections, is meant to be where final connection is made.  It will be easier to make two rather than three connections.

 

Kaos not Harmony

 

For multiple reasons I am resurrecting what was my second Brick Controller.  This was started in 2019.  But between our moving from the Bay Area and Covid, it never got beyond the original PCB.  That PCB had issues in the design. Here is a link to one post, but there is a whole series of posts in 2019.

The firmware was developed with Harmony version 2.06.  This version is no longer supported. The Light Buddy 1 had a similar processor, a PIC32MX270 vs a PIC32MX470 in the Brick Controller.  The Light Buddy 1 firmware was developed using Harmony version 3.0.

Here is my setup

• Win 11
• XC32 4.40 and 2.40
• MPLAB 6.25 uses PICKit5 and custom PCB
• MPLAB 6.10 uses PKOB3 on Curiosity PCB
• Debug using only hardware breakpoints

I took the original PCB and used the Light Buddy 1 firmware as a basis  to start the upgrade in Harmony 3.  The original design with multiple peripherals did not work. I stripped it down to nothing except CORE, UART2, System Console and DEBUG. As long as app.c had nothing in it, the program would generally run. If I added a SYS_CONSOLE_PRINT command or even toggle a GPIO port, then it would throw an exception. Generally 0x07 or 0x0A. For a while it was at a consistent address, but when trying to look at disassembly, the address would move.

I moved the code to the Curiosity board with exactly the same results.  Please note the Curiosity board has a built in debugger.  Also note this is a generation 3 debugger so I was limited to using MPLAB version 6.10.  But this also means the debugger is probably not driving the problem.

But if i just program the custom PCB with the firmware it works as expected.  this includes the toggling of the onboard LEDs and using UART2 for a console message output.

I  tried

• Slowing down the clock speed
• No prefetch
• Longer FLASH wait states
• No interrupts
• deleted the linker file and used the default one

and probably a few other things I have forgotten about, since I had been at it for multiple days.

I posted in the Microchip Forum and received and interesting reply.  They suggested I use the following menu item in MPLAB. 

 

And the debugger starting working, kind of.  In MPLAB 6.25, the debugging process was slow and sluggish.  If I closed out the project and then loaded the project into MPLAB 6.10, it worked more as expected.  Occasionally the exceptions would come back and I would have use the above menu item  

My conclusion is that in MPLAB 6.25 the debugging process leaves some errant code in the processor.  While starting the debugging process erases memory, evidently what gets erased by starting a debug session and what this menu item does, are different.

On to testing everything else. and working on the schematic design of the upgraded PCB.