CraigMattson.net

Knobs, Wiring and Buttons - Progressing on the A320 FCU

14 March 2022

I haven't had a lot of time the last few weeks to work on the FCU much further, however there are a couple of updates worth sharing.

Minor redesign to the back plate

I had this grand idea to make insertable Korry's into place and have them as removable independent units. Unfortunately, those LED lights wouldn't fit inside the chamber I had printed and the outcome wasn't great. To get around the need to glue and design all of those components, I had completed another design - this time where the chamber was integrated to the backplate. As I wasn't too sure about the tolerances here, I had printed a few different sizes to work with the Korry inserts but I really only had one shot at getting the backplate done.

Figure 1 - Backplate Update with Korry and Button Holders in Place

With this out of the way, the next step was to insert buttons and led lights into each of these new chambers. Again, this took several goes that I had pre-empted and thus the creation of different sizes - but thankfully things like leaving a large gap to slip the buttons in really helped out here. It was fiddly though, and you really get to know just how tight (i.e. < 0.1mm inaccuracies) things may fit or require a bit of filing and cutting to get things in snug.

Figure 2 - Korrys and wiring all in place

With the screens in place, it's starting to come along. 

Installing the Rotary Encoders

I've spent a bit of time going back and forth on getting a good, repeatable push-pull rotary encoder working and in the middle of doing this had learned a few more quirks about the printer - especially printing such small volume items. For the Rotary Encoders in particular, when I began I was printing shells, stalks and knobs altogether with the same material. As I started printing smaller volumes, I started getting stringy mess and prints that wouldn't be loose enough around the rotary encoder itself.

Having not had to level this printer for a few months, I figured at the very least I'd clean up the bed, re-level it manually and give the internals a good clean too (ensure the filament isn't slipping in the extruder from a build-up of gunk). I'd 3D Print a calibration cube and everything was within known tolerances (< 0.1mm on the Z axis but otherwise everything else recorded a perfect 2mm). I had printed a few other things at the same time and they also come out well without stringing. It finally dawned on me that perhaps the part was 'too hot' and wasn't given enough time to 'cool down' before applying the next layer. So to remedy the next print, instead of printing one stalk - I printed all the working parts and things kind of went back to normal.

The reality is that when you start playing with your printer - you start having to 'learn' all the quirks again. Having a more level bed and now knowing about volume of prints to help dissipate heat means you're back to calibrating your software settings to compensate too. So it's fair to say that it took quite a few goes before usable prints were coming out. 

Figure 3 - Rotary Encoder installed

With the first prototype in place things are looking on the up. This particular switch has the right clearance off the button at the back and works perfectly. I perhaps had unrealistic expectations that the same will occur for the other ones - but unfortunately it didn't quite work that way. For the second rotary encoder, the disc didn't quite go all the way down on the rotary encoder so the disc itself in the 'release' mode was touching right up against the pull mechanism - not a great outcome. It's fair to say that in hindsight, I would probably use a longer stalk button to remove that margin of error and perhaps had a bit more of a gap and maybe a spring to help. In any case, something to improve on.

Things get a bit more challenging for the altitude selector. There's an outer ring that selects either increments of 100 or 1,000 - this would need to sit around the stalk and be some kind of a compression fit to hold the selection. I don't expect this mechanism to last long - and perhaps a second encoder or toggle switch might have helped (there are plenty of options on Thingiverse). Behind the scenes would be a microswitch that by using very little friction at all, can sit on the microswitch when activated.

Figure 4 - Altitude Selector mechanism
Figure 5 - Notch to prevent turning too far

With the selector and activator connected together, and the microswitch installed - we should be able to select 100 or 1,000 with some creative license by rotating the ring. The final piece of the puzzle was working out how far the grip should protrude. Apart from having to print this a few times, this was perhaps the easiest part to assemble and now the knob and selector fit reasonably well.

What's next?

I'm at the final stages now of the assembly itself leaving behind some fiddly and trivial components.

  • An Arduino Mega 2560 needs to be wired up. I've got some proto boards ready to solder all the wires to.
  • A shell for the components to sit in. This is currently printing whilst typing.
  • Printing some Korry labels - this will likely be a transparency on a white sheet of paper.
  • Get this all running and working in Flight Simulator, via SimConnect.
  • Final decorations - black shroud for the LCD screens for example.
Figure 6 - Current State - Front
Figure 7 - Current State - Back

It's fair to say that should this be a repeatable design, I think I would embrace sacrificing imitation for simplicity. For example, the Korry 'pull' action might very well be replaced with additional push buttons on the face. That would then leave the rotary encoders available for a very simple installation. The same applies for the 100/1,000 selector - that might well be a toggle button or a switch. The Korry switches themselves could be made significantly smaller with a larger button - possibly a Cherry MX style key switch. The 1602 LED screens might well stay, although a future version I want to wire up using custom 7-segment displays and LED status lights. None-the-less, it's been a great learning project and hopefully we're only one or two posts away from testing a flight from Melbourne to Sydney.


Build a SQL Server Instance in a Hurry (aka SQL Server on Docker)

09 February 2022

If you're a developer working in the .NET stack, you no doubt have had to install SQL Server - a royal pain if you don't have the installation media handy, or have memorised which options to select just to get something ready to restore a database to. Once it's installed, you also have to dedicate a port and part of your every-day memory to running it. It can be quite the hog if you have a couple of reasonable sized databases running. In the last 5 or so years, I've liked to keep a small footprint on my devices. As it stands, my muck-about laptop is a Lenovo ThinkPad T440s - rocking an i7 4600u with 12GB of RAM (4GB built in + 8GB Module). A good sturdy machine with good battery life. Unfortunately, the memory is max'd out and that doesn't leave much room for running things like SQL Server to run in the background.

If you haven't heard, SQL Server is available as a docker container and has been since ~2018. As such, I was happy to remove SQL Server from my laptop and just spin up SQL Server when needed. There's not a whole lot to it - you specify the image and a few environment variables and volumes, and you in effect have a portable version of SQL Server. Indeed - SQL Server on Docker is currently powering this website.

Per below, create the following docker-compose.yaml file in a directory. I'd recommend you creating a directory for each instance, as the script creates a directory structure relative to where the docker-compose.yaml file is run from.

version: "3"

services:

  mssql:

    image: mcr.microsoft.com/mssql/server:2019-latest

    ports:
      - 6000:1433

    user: root

    volumes:
      - ./_db/data:/var/opt/mssql/data:rw
      - ./_db/log:/var/opt/mssql/log:rw
      - ./_db/secrets:/var/opt/mssql/secrets:rw
      - ./_db/backups:/var/opt/mssql/backups:rw
      
    restart: always

    environment:
      ACCEPT_EULA: Y
      SA_PASSWORD: Password1234
      MSSQL_PID: Developer # change this to Express if you're not licensed, Standard and Enterprise are also available here

Because we're providing our own volumes such that we can keep this setup portable, the user: root line is (or at least was) a cheat way to allow all write access to /var/opt/mssql otherwise you'd need to run your chown / chmod scripts to set the directory permissions. For volumes, I like to separate my data and log DBs, so those are listed separately. Maintaining your secrets directory will enable portability and you'll probably want somewhere to store your backups. I usually set restart: always as I context-switch by running my docker-compose up / down commands. Finally - the environment variables are specified in the dockerhub link. The three key ones are to accept the EULA automatically (otherwise the startup will hang), set a password and set the product ID to match what you're licensed for.

You'll also note that I override the port. I usually set a particular port range per application I run - such that I can store all my configurations in SSMS under the port. Let's say I have 5 applications, I might do 3000-3999 for application 1, 4000-4999 for application 2 and so-on. This allows me to save a configuration as "localhost,3000" and "localhost,4000" with the SA password already set.

It really is that simple*. Except for one bug when mounting your volumes this way. That is, if you try to restore a backup you'll need to have the file created at your /_db/data directory. You can do this any way you want. The easiest options for me have been:-

  • Create the database the normal way in SSMS, then run your Restore script.
  • Run "touch /var/opt/mssql/data/file.mdf" and "touch /var/opt/mssql/log/file_log.ldf" so that there's an empty file to write to avoiding the need to create the database in the first place.
  • Create the files in /_db/data and /_db/log yourself.

These avoid the: The operating system returned the error '2(The system cannot find the file specified.)' while attempting 'RestoreContainer::ValidateTargetForCreation' on '/var/opt/mssql/data/ error you'll see in your docker outputs.

So... after you've copied and pasted the script above, and saved it in a directory called docker-compose.yaml and you want to run your own instance? Simples. Once you have docker installed (and therefore docker-compose), the next step is to execute the following commands:

  • To start: docker-compose up -d (nb - if you omit the -d your command window will be attached to logs)
  • To stop: docker-compose down

That's it. A docker-compose file with Docker installed and you've got yourself a SQL Server instance in seconds (as long as you have the image downloaded already otherwise you'll need to wait for those couple of GB's to come down).


« < 1 2 3 4 5 6 7 8 9 > »