A Delphi Primer with RAD Studio 10.2

Hey hey, everyone!

Today is a day off for a public holiday – couldn’t tell you which one off the top of my head – in Germany.  They do a few of these in May and June, and this time around one of them fell on this Thursday.  I’ll be back in the office tomorrow, but I wanted to take a few hours to put this together as the real start of my “refresher” with Delphi.

A little personal background – the last version I did any serious work with was in 2009, while working for a company that did an automotive dealership ERP system.  They were working with Delphi 7, and had started looking into Visual Studio, but at the time VS was still insisting a lot of repetitive code for data access and it just pissed everyone off.

So – I went on after that and my memory of Delphi at that time was of the “old school” IDE (“IDE” = “Integrated Development Environment”, which just means the app that is designed to host your programming effort and the tools that accompany it – as opposed to picking up a bundle of various unrelated stuff and working haphazardly with it), we still had BDE, and all that.  I played around a little with XE3, but not enough to be re-proficient with it.  So let’s change that a bit, shall we?

I’m going to approach this as if I was a beginner, who has just signed on with a firm or just bought my own copy and plugged in my license key.

As it happens, I’m currently staying (temporarily living) in a teensy little cave of a one-bedroom apartment, and where I’m sitting right now I don’t have WiFi.  As a result, I got a battery of errors when I started up – everything was trying to run scripts on the page, but none of the failures were of a fatal nature.  I won’t detail those, because it’s entirely possible those were my own doing from a prior project.

In the “old school”, the first thing you’d get was a form designer, an object inspector, a VCL bar across the top, and probably a project manager.  None of these were docked, it was a multi-window app (“MDI” in the terminology of programming, which I guess you’d better get used to – MDI means “multiple-document interface”).  This was largely because of Delphi’s origins as a construction site for Windows GUI applications – it later grew into much, much more, but kept to its heritage in how it presented itself with a first impression of “let’s build a Windows app”.

Here, we get a single-window app (an “SDI” – “single document interface”) where all the tools are docked to one another.  The most prominent visual that pulls you in is an almost-center section of ‘new’ options for making new projects:

So…as a new user, the first thing I’d like to see is “Getting Started”.  Except…I’m in an unusual state of not being connected to the Internet right now, this requires an internet connection to get to, so maybe we’ll come back to that.

I guess we’ll just have to muscle through on our own.

So as a programming system, most tools revolve around a concept of a project, or an app, or some similar goal-oriented thing which will eventually be built and run independently on a computer of some kind.  In Delphi’s case, it’s a “Project Group” now (used to be just a “project”, but around Delphi 5 time frame most apps built for business in Delphi had multiple independent components that talked to one another and shared work across platforms in something like n-tier architecture, or via Web Service in Delphi 6, etc.).

Choosing “Create a new Project” from the screen selections here results in a dialog helping you to determine what kind of project you want:

I’ve never been a huge fan of C++ syntax, and since a beginner is going to be our target audience, let’s go with a Delphi app.  Highlighting “Delphi Projects” presents a list of various choices in the right-hand pane…

Some of these sound damned cool.  An Android service?  I’ve got an Android phone…as well as an NVidia Shield on my TV.  But that’s a little advanced for right now, so let’s stick with the basics.  Console apps are for black-and-white command-line stuff, generally with no UI, and that shit’s for Linux chumps J.  We’re programming for a Real OS, Windows.  Something people use daily.

Which reminds me – what are we going to build?  One of the things that people who want to learn to program generally don’t think about is the answer to that question.  “What the hell am I gonna make with this thing?”  That was one of my big stumbling blocks too, way back in the ‘90s when I bought my first copy of Borland C++, its fifty 3.5” floppy disks and its forty pounds of books.  I played around with that thing, but that’s all it was, I was playing.  I didn’t have the foggiest clue what to build then.

So let’s make up our minds.  All programming starts simple, let’s pay homage to the classics and do an old-fashioned “hello world”.  We’ll look at the parts of the development environment that help us do that, and I’ll highlight some advantages we get in Delphi that don’t really come easy.

The project that fits this description best for my purpose here is a VCL Forms App – as long as we’re going back home, let’s do it old-school style.

VCL means “Visual Component Library” – and it means the framework of pre-built stuff that is in the development system.  Frameworks are what drive programming systems.  Without a framework, all you’d really have is a compiler and text files, and you’d have to build quite simply everything by yourself.

And that would suck.  A lot.

So about five minutes after the first programmers started writing programs that could be stored on something other than a gigantic deck of #$%&ing tarot cards, they started writing frameworks.  Frameworks are pre-packaged blocks of code that represent things which get built a lot.  For example, take the humble little button on your screen.

Buttons get used all over the place.  So do things like text boxes, labels, even the window itself gets used quite a bit.  A good framework will have pre-built code that contains these things, so you the programmer don’t have to re-invent the damn wheel just so you can write “hello world” or something.

Delphi in its original state had VCL, and that was it.  Borland C++ had OWL (“Object Window Library”), Microsoft had MFC or something for its C++ side, Visual Basic had a bunch of “OCX” controls (I can’t remember if I ever even knew what OCX stood for).

I’m going to take a long tangent here.  If you want to dive in with the “hello world”, jump down a ways and skip all this talk about frameworks and libraries and stuff.  This info will be useful though, if not now, then later.

About Frameworks…

Originally VCL was one great big fat chunk of code that would get pulled into your app and you’d have a 600k executable that would pop up your window and say “hello world”.  At the time, that was pretty freaking huge, despite being really fast.  By the time Delphi 2 was released, it was even bigger, and because we had a forest of third-party controls one could buy, every one of those controls would have to be re-compiled into the original VCL code, which promised to become a real spaghetti mess.  About two years – and two product versions – after the v1 release, the VCL got split into many smaller interoperating chunks we called “packages”, so your 600k .exe file shrank down to a svelte 80-120k or so, and more importantly all those 3rd-party systems became self-contained bundles that didn’t threaten to corrupt the core VCL.

Another benefit to this was that it kept compile times reasonable.  When Delphi crashed the party in 1995, Windows apps were largely C++ stuff – which includes Visual Basic.  VB was built in C++, and itself was not a “compiled” app until much later.  The C++ compilers at the time, running on PC processors, could take hours to build an app and put it all together.  In the case of really big ones, it might be days.  Delphi popped up, and all that changed – Delphi could compile an app in seconds.  Usually in the single- or low-two-digit seconds.  And Delphi’s IDE was written using the Delphi compiler, and all million-odd lines of code in that could compile in minutes.  That was a really big deal.

Oh yeah – let’s talk for a sec about what “compiled” means.  Compilation at its most basic level means taking one kind of code and converting it into another.  Usually that’s in the context of taking something a human wrote and turning it into something that a PC chip and operating system can understand and act on.  This is in contrast to “interpreted” or “scripted” code, where something reads the instructions written and simply performs the actions described in them.  In a compiled app, the compiler reads your code, and it builds a self-contained output ‘thing’ (in our case here, an executable file), and then it goes back to bed.  The output is the actor, and it has within it all the instructions you gave, ready to go.  In an interpreted app, an interpreter holds your code in the form of a “script” and acts on it, line-by-line – it’s the interpreter that does all the action.  As a result, it is both slower and more limited in its possible actions.

Today, with the current crop of processors, compile times aren’t that big a deal any more.  When you can throw six or eight cores with possibly two threads per at a compiler, there’s not a whole lot out there which will take a great deal of time to build.  Similarly, most interpreters, despite being a bit clunky, operate like they’ve mainlined about a kilo of coke on a modern processor.  They’re still limited in a lot of ways (for example, one comes to mind which doesn’t support using all those cores and threads – it still just fumbles along running one process per CPU), but the big differential between compiled and interpreted isn’t quite the gulf it used to be.

Back to building our app, and the frameworks involved.  Today, pretty much everything Microsoft’s environment works with is “.NET”.  They have what’s called the “.NET Framework”.  Very original.  (For quite some time before and well after release, Microsoft had some serious communication problems – most people inside and out simply didn’t understand what ‘.NET’ was supposed to be about.)

Delphi has VCL – and several other frameworks.  These all appear as “components” which can be dropped into an app, “wired” together with settings and code, and will be compiled into it when you tell the IDE to build your program.  VCL has been, and probably always will be, largely about Windows.  The framework makes the creation of windows and controls by calling functions in the Windows operating system which themselves call functions in the hardware of your PC – the disk, memory, chip(s), video card(s), etc.

It also has “RTL” – the Run-Time Library.  RTL is a set of non-visual code bundles that encompass common operations not necessarily involved with building visual applications.  A good example of an RTL unit is “Math”.  There’s a unit actually called math, which is full of functions and procedures that all revolve around mathematical operations like rounding, modulus, sine/cosine, and even things like figuring out payment schedules, net present value, future value, etc.  I specifically call this out because one of my earliest self-designed apps used a lot of geometric functions to produce 2-dimensional graphics on demand, and I ended up reinventing a lot of Euclidian geometry in code to accomplish it – I was ignorant of the math unit in the RTL.  If I’d known about this thing, I’d have saved myself weeks of coding time.  Much of RTL doesn’t hinge on the Windows system, but is independent of this.  I mention that, because while Visual Studio is entirely about Windows…

Delphi doesn’t just do Windows any longer.

Delphi also has “FireMonkey” (don’t look at me, I didn’t name the thing), which is aimed at cross-platform programming – which means stuff built on the FM framework can run on Windows, iOS (Apple’s OS for phones and Macs), and Android.  There aren’t quite as many components in FM as in VCL, but there are plenty to get the job done.  And what you build for one, can then be built for each of the others – so a “hello world” for Windows can also be compiled and delivered to an iPhone and an Android device without changing your code.  Of course, if you use platform-exclusive functions (for example, Microsoft SQL Server might be your data repository), you will limit the cross-platform nature of FM to just that platform, so keep that in mind.

Other, smaller frameworks that Delphi makes available include

  • EMS “Enterprise Mobility Services”, which links to the ‘mobile enterprise application platform’, which I’m not at all familiar with and smells strangely of CORBA. Basically, if you’re starting up in Delphi and you don’t recognize what this is, avoid it.
  • DataSnap, a framework that enables you to divide your application’s working parts among multiple packaged applications/libraries, all of which can then connect to one another and trade data or invoke each others’ functionality, either on the same PC or spread out over a network.
  • Web Broker, a set of components that enable your apps to become web server extensions and generate content in the form of HTML or XML documents as responses to being called over HTTP.
  • IntraWeb, an app framework that enables you to cook up web apps with a visual interface.

In addition to these frameworks, Delphi also enables you to make calls directly to your platform API (which means making calls directly to the operating system of the computer on which you’re running) either as a straight-through call or by using pass-through calls that are contained in code units supplied with the RTL.  (These units don’t quite amount to a library, but they are provided to simplify making the connection to the operating system.)

Back to the application…

So, where were we?  Oh yeah, we were going to do “hello world” – and courtesy of all the work that went into building the VCL, it’s going to be dirt-simple to create the window, complete with a button and a pop-up dialog that contains our message.  We’ll do it with only one line of code – without the framework, it would be thousands of lines.

From the center pane of the IDE, choose “Create a new project…” and choose “Delphi Projects,” then “VCL Forms Application”; or alternatively you can use the menus File > New > VCL Forms Application…

Whichever route you chose, you land here:

I’m a bit of a stickler here, and despite my old-school start, I noticed over on the side there it says that my target platform is 32-bit Windows.

 

 

Well, to be truthful, I haven’t had a 32-bit CPU or operating system in my house since what, 2006?  Maybe 2007?  So let’s change that and add Win64 and make it our target.  This laptop is on 64-bit Windows, and that fits my goals just fine.

In the Project Manager on the right of the screen, right-click the “Target Platforms” entry and select “add platform” from the menu that appears.  You’ll be rewarded with this dialog:

Once you OK this, 64-bit Windows will be added to the targets, and it will be made “active” (it’ll be bold in that list).  Active means that when you compile, the executable that gets built will be for the target platform currently bolded.  I’m going to remove the 32-bit windows target, just because it clutters up my space and I don’t have anywhere right now where I need a 32-bit app.  Right-click on the unneeded one and delete it if you want to do the same.

In times gone by the VCL would be stretched out across the bottom of the menu bar as a set of square icons in a tabbed interface at the top of my IDE.  This got a bit unwieldy towards the Delphi 8 time frame (mid 2000s), because a vanilla install would end up with more than a dozen tabs, easily.  Since then it has grown to something like fifty categories, and there’s no really good way to present that many options in a GUI interface.  The current version packs the VCL controls as well as a bunch of 3rd-party and multi-framework options into a long expandable list called the “Tool Palette,” currently found at the bottom right of the IDE.

What we want is just a button…so how do we find it from among all these things?

Happily, that’s going to be easy.  There’s a ‘search’ box at the top of the Palette, just type “button” into that and see what pops up in the list.

TButton is what we want.  Either press “enter” or double tap that with a mouse, and Delphi will drop a TButton right in the center of your app window.

It deserves note that the “T” at the beginning of pretty much every component Delphi has ever seen stands for “Type”.  It represents a class of object – I’ll give you the broad rundown on “object” and “object orientation” some other time – and the class is what defines the object.  Think of a “class” as the same sort of thing as a “blueprint” or “recipe” or “design”.  It isn’t the object itself, but instructions of how to make that object.  Java totally fucked up in naming both their recipes and their existing elements classes, and that has caused who knows how much confusion for beginners over the years.  But that’s Java, and it hasn’t ever made a whole lot of sense outside of “how can we get Windows programmers to build stuff to run on Sun boxes?”  Another day for that, my prejudice is showing.

So “TButton” is the class which is used to create buttons.  Delphi dropped one on our form.  What now?

Now, we configure the button to look and feel the way we want.  To do this, we can drag it around the window, we can also grab its sides and corners to resize it.  Go ahead and do some of that.  I’ll wait.

All done?  Okay, when we want to change some of the more nitty-gritty bits about the stuff in our visual designers, we need the Object Inspector.  By default this is located in the lower-left corner of the IDE.  It shows you the properties and the events of the currently-selected item on the form.

(By the way, “Form” in Delphi terminology represents a “Window” of an app – so when you’re working on a “form” you’re working on what amounts to a window.  There’s some extra nuance to this, but for now when you’re starting it’s best to think of it that way.)

Select the button, and look at the Object Inspector.  A whole bunch of properties of the button are listed there.  “Properties” of a thing in the Delphi world are the qualities of that thing, the settings that make it look and feel and behave the way it does.  In the real world, things have properties too – your shirt for example, has properties “material,” “color,” “sleeve length.”  These properties for my shirt are “cotton,” “black,” and “short”.  The descriptor of the attribute of a property is called its value.  Think about the properties of the things around you.  How would you describe them to someone?

Back to the button.  Its most commonly used property is “Caption” which is the text that appears on the surface of the button shown to the user.  By default, the caption of the button is the same as its name.  We’re going to change these values now.

Change the property Caption to “Say &Hello”.  Notice that as you do, the form shows your change in real-time.  Also take note that the “&” didn’t show up – instead, the next character, the “H”, got underlined.  This indicates that the H will become a ‘hotkey’ when your app runs, and in addition to pressing it with a mouse click, the button will also respond to the key combination Alt+H.

Find the property “Name” in the Object Inspector.  By default components added to a Delphi app will be named as their class plus a number, iterating the numbers based on how many others of that class there are.  So we might see “Menu3”, “Button12”, and so on.  When you’re writing code, these default names are really hard to cope with, so get in the habit of naming things sensibly – try to keep in mind what they do and what they are, because your code can’t “see” when it is running.

For now, rename this button to “btnHello” – btn being an abbreviation of “button” and Hello telling us what this thing is supposed to do.

Do you see, in the top of the Object Inspector, there are actually two tabs there?  Properties and Events?  “Events” are things that happen to your objects, like mouse clicks, keyboard presses, and so on.  Take a scroll through the available events of a button just to get a feel for what they might be.

Each component will have a default event, and if you double-click on the component in the form you’ll automatically create an event of that type, which will be assigned in the Object Inspector to that event.  It basically opens up a little “hole” for your code to appear in, and when that event happens your code will be executed.

Double click either on the button itself, or in its “OnClick” event in the Object Inspector.  Both actions will result in the same outcome, you’ll end up in the code editor, your cursor itching to write a bit of code for a routine entitled “btnHelloClick”.

In that line, enter the following code:

Showmessage(‘Hello World’);

Capitalization doesn’t make any difference in the Delphi world, I just use it to make things look a little more sensible.  “ShowMessage” is a little routine from the VCL “dialogs” library that will take a single string value (strings are characters) and pop a dialog up with that string in it.  Our app is already referencing the dialogs part of the VCL, so we don’t have to add anything to this.  Our app is ready to run!

Up in the menu bar, there are two buttons with green right-pointing arrows that can be used to run the app – “run” and “run without debugging”.  Either one will work, but as a developer you’re going to want to use “run” most often, because debugging is what developers spend a very great deal of time doing, and your users won’t like it if you never debug your programs.  Fortunately, we won’t need any debugging in this app, because it’s very simple and you will get it right the first time.

Press “run” or hit the F9 key (same thing).  Delphi will compile your app – you’ll see a dialog indicating its progress – and will run it.  You will end up with this:

That’s your app!  You just wrote, compiled, and ran your first Windows application!  Congratulations!

Go ahead and press the button, see what happens.  I’ll be here.

Up pops a centered little dialog saying “Hello World”, right?  Pretty cool.  Note while you are pressing this, if you used “run” rather than “run without debugging” that at the bottom of the Delphi IDE there is a pane called the Event Log that registered things like “thread exit,” “thread start,” etc. – these are part of the integrated debugger, which we won’t talk about in this article, but is a really super-cool and very useful tool for when you’re writing more complex programs.

Go ahead and close down your app – you can either press the “X” button on the top-right corner or enter the Alt+F4 key combination, both will close the app and return you to the IDE.

Last thing for this article, let’s save this project.  It’s not a big deal to lose this, because it’s so simple, but saving it will let you know what files we’re dealing with.

There’s a couple of save buttons on the top of the IDE, one disk for “save” and two disks for “save all” – those are disk icons, by the way.  For the younger readers, those look like what we used to use to transfer data and programs around on, called “floppy disks.”  Ask your parents what they were.

Either choose the two-disk “save all”, or go to the menus and choose File > Save All.

Your first prompt will be to save “Unit1” – we didn’t rename this unit, because it’s the only one in your project.  Later, when there are more units in more complex projects, you’ll want to rename units as soon as you create them, for the same reason you rename components when you drop them on a form.  If you have a directory where you want to keep your code projects, navigate there and save Unit1 in the directory where you want to keep your Hello World project.  Note that if you don’t keep your projects separate, you’re likely to overwrite files and lose your work, so definitely use different directories for each project.  Get in that habit now.

After being prompted for Unit1, you’ll be prompted to save “Project1” as well.  Project1 is the name of the program you’ve just written, and Delphi will name its executable the same as your project file name.  So if you want to call this something else, now’s a good time to change its name.  “HelloWorld” would be a good, if not very original, title J.  (Delphi doesn’t like spaces in project names, by the way, that’s why there isn’t one in my suggestion.)

We’ll talk about what all those files are another time.  What’s important is that now when you compile your app (go ahead and do so now that you’ve saved the project – Ctrl+F9 will compile it, or you can go through the menus and choose Project > Compile HelloWorld), the executable will be found in this directory, in a “Win64” subdirectory.

We’ll deal with these…later

You can take that executable and run it on any 64-bit Windows computer you want now, it’s all yours and you get to do with it whatever you want.

 

That’s the one that matters.

 

 

So you’re done – you’ve built your first app in Delphi and you’re ready to tackle the world!  Congratulations again.

I think the next one of these I do, we’ll do a little bit with some data, and tap into a Microsoft SQL Server.  But for now, I’m going to go have a beer and build a model or something.  I’ll raise a glass for you, and hopefully I’ll see you next time!

 

 

Posted in Development, IT, PC Stuff, Programming, Software | Tagged , , , , , | Leave a comment

Just saw “Rogue One”…

…this isn’t going to be a review.  Just a comment.

HOLY SHIT THAT WAS AWESOME.

It was everything a Star Wars film should be.  And then some.

I’ll do a review sometime.  After I stop laughing and crying like a big pussy.

Posted in Uncategorized | Leave a comment

HMS Belfast…

…is all done up!  There isn’t going to be a lot of text in this post, I’ll update with a more comprehensive build log later, but for now I wanted to push up some shots of her from tonight showing that she’s done :).

I also want to point out the Zulu and the Victor Lima signals on her forward radio mast – gotta get those credits and more importantly, LOTS of fires (sadly no torps on the in-game version, but I can dream about the floods)!

On with the pictures (I’ll take the real hero shot tomorrow when I have some daylight to work with)!

 

And to think it all started only nine days ago in a small, boring cave…

 

Posted in Build Log, Contest Entry, Model Kits, Uncategorized, ww2 | Tagged , , , , | Leave a comment

Build Log: HMS Belfast, in 1:600 scale, by AirFix

Part 1:  Unboxing

Hi everyone!

I’m in the process of moving to Munich, and while that is going on, the Enterprise will be on hold – it’s mostly software coding at this point to make sure I’ve got all my lights and sounds are synched and good anyway, so there’s not a lot of hands-on action to report yet.  I will say that although I was excited at first to be using those Chinese import MP3 players as a hacky shortcut to adding sound to my model, ultimately they turned out to be a no-go.

Reason behind that is that the Arduino microcontroller I was using is very sensitive to voltage input, and will reset itself if voltage gets too low or spikes.  The USB input I had from my PC, as it turns out, is highly variable in just the kind of way an Arduino doesn’t appreciate.  As a result, it was impossible to predict with perfect accuracy what track was currently cued on the MP3 player – because the MP3 player wasn’t so sensitive.  So everything would look good, I’d start a track, test another function, and the Arduino would reset.  The track, however, would keep playing.

So I’m ditching those MP3 players.  They’ll be useful sometime if I just want to add one single track or a batch of sounds which I don’t particularly care about their order, but for what I want with the Enterprise, they won’t do.  I’m testing several Arduino-compatible sound boards now that are also dirt-cheap, and will come back with a report on those eventually.

But onward!

I’m staying for a couple months in a small studio apartment while I start my new job and move the family into a larger place down here, and to keep my hands busy, I brought this along:

It’s the Belfast!

It was a gift from Hugo back in our trip to visit the Belfast as part of BAD-ARMADA’s field outing, and I promised him I’d make it my next build after the Enterprise.  Since I’ve got some time on my hands here, I figured this would be a good place to do it as a from-the-box build, no extra third-party specials.  Just glue, files/sandpaper, a razor knife, and some paint.

This kit was a special edition produced for the Imperial War Museum, and to my knowledge it’s not available anywhere but at the Belfast itself (which is a museum ship in downtown London, and a great trip to take for a few hours if you’re at all interested in this sort of thing).

Let’s unbox it together, shall we?

If you’re buying this as a gift for someone, rest assured that everything needed is already in the kit.

Nominally, this kit comes with everything you need – technically you don’t have to buy a thing extra to get it constructed.  It has two synthetic Humbrol brushes, a tube of poly cement, and eight little pots of what look like Humbrol acrylics.  I won’t be using the paints or glue for this build, but I wanted to show you what’s in here.  The paint looks like it could use a good shake, so my recommendation if you’re going to use them is leave them in the little bag, put that into a second Ziploc bag, and throw them in with the cold laundry or something.  I don’t have the patience to shake pots that much.  Alternatively just stir them with some toothpicks after opening.

Probably could use a wash, but that’s not 100% necessary.

The sprues are contained in their own separate bag, all together.  I do recommend that you give these a gentle wash in the sink or a tub with warm water and a little dish soap.  I don’t always follow my own instructions, but there it is.  Dry them on a towel afterwards, don’t let them dry with beaded water on them or you might get a little calcium buildup if you have hard water.

Full inventory, ready to build.

The sprues themselves are pretty straightforward.  Two deck pieces, two hull pieces, and four sprues of general gear and detail.  Some of this shows a bit of flash on it, so the molds are probably a little bit old, but there’s nothing really excessive to deal with here.

At 1:600, the smallest thing you’re going to be dealing with are the lifeboats and the AA guns, both of which are 2mm-3mm in size, plus a few spotlights and some of what look to be depth-charge gear.  For me, this poses a bit of a challenge, since I have large hands, but the hardest part will be if I drop any of these little bastards on the floor.  So – advice #1:  cut your parts off while maintaining a good grip on them with tweezers or fingers, and do the cutting over a solid-color drop cloth or cutting mat.

Gets the job done. Nice photo section at the end.

Large painting guide, good to see that. Numbers correspond to numbers on the top of the little paint pots.

The instructions are serviceable.  They aren’t as comprehensive as something you’d get from Dragon or Tamiya, but they are fine for general purposes.  (I contrast Dragon’s, for example, in that they tend to include a sprue inventory with callouts on where parts are; Airfix doesn’t do that.)  A nice touch are some black and white photos at the end showing Belfast at sea, and one entering the Thames on her way past the Tower Bridge, presumably on her way to becoming the museum piece.  Finally, a painting guide at the end which includes detailing on the Walrus plane the ship was equipped with (which was later removed when radar proved to be a much more weight-effective spotting device).

If you didn’t have other basing plans already, this would be serviceable. Maybe glue it onto a wooden base cut to size?

In addition to the instructions, a cardstock display base is also included with backdrop photo and some basic stats on the vessel and a short blurb of her history.  It’s a nice touch, and it makes this kit a really good candidate as a gift for a younger family member who likes to build models.

All in all, I’d definitely grab this for a kid who’s getting into modeling, as the all-in-one nature of the box is really handy for some households that might be short on space (and when said child doesn’t necessarily have access to a lot of tools).  As an adult builder with a lot of goofy accessories, I’m looking forward to building this one just because I like the ship and had a great time visiting it.  In fact, I already have a nefarious plan in mind, which will involve basing the completed Belfast in the same frame as her worthy and fearsome opponent…

Dunt-Dunt-DAAA!
Revell makes the Scharnhorst in 1:570, which is close enough that the two can share a base and look roughly to scale with one another.

Posted in Uncategorized | Leave a comment

A few quick impressions…

…on the 10.2 version of Delphi:

First, the installer.  Because I saw it a lot.  And I mean, A LOT.  Why?  Because this installer refused to install to my laptop – even after it got wiped and a clean Windows 10 install, the installer simply didn’t know what to do with itself.  And, unlike in my era, the error messages provided during install are…cryptic.

Gee, yeah. Yah think?

 

 

 

 

 

 

So now I’m scratching my head and wondering what’s wrong with my vanilla laptop.

My desktop machine runs the installer without a hiccup.  The first time.  Then, I uninstalled RAD Studio, thinking maybe it was locked to one PC at a time.  Tried on the laptop.  No joy.  Went back to the desktop to re-install, and guess what I got?

Yep, you win a cookie.

 

 

 

 

 

 

You know what the next screen is that I called up on my laptop?

Take a wild guess.

 

 

 

 

 

 

 

I think it’s worth pointing out that this sort of problem will happen to trial users.  People who are considering buying the software will have this happen.  

And they’ll do just what I did.

Update

After a lot of screwing around with the web installer, I gave up and downloaded the ISO file – all 6.4GB of it.  I recommend you do the same.  Windows 10 mounts ISO images natively as if they were a standard ejectable drive (and it is with some regret that I guess I am therefore not going to need to install Virtual CloneDrive on any more new PCs), and can run the install directly from there.

So, my laptop has all it needs now.  I’m going to start doing some posts on using Delphi again as I get back into it, and I think I’m going to approach these from a perspective that I just don’t see around any more:  as if I was a beginner or a programmer new to Delphi completely.  Learning the IDE and frameworks are the biggest hurdle in any programming language / toolset, and often can prove to be a speed bump that just keeps people out.  So I’m going to try to pull that tiger’s teeth for you and we’ll start doing some of the basics just to see how easy things are with 10.2.

See you on that topic very soon!

Posted in PC Stuff, Software | Tagged , , | Leave a comment

Once more unto the breach…

I’m currently still sorting out the MP3 and display options for the controller that will handle everything in the Enterprise (gave up on my hack, got an MP3 chip, will detail in a future update), and wanted to cover something a little different this time around.

I’m digging back into Delphi!  (Btw – there’s a “Starter” edition available if you want to play around with it or learn it.)

Those of you who know me personally know I spent a good long time as a software dev and eventually as the product manager of the tools that I was really, really good at – Borland Delphi.  Well, after moving to Europe I was spending a lot of time managing teams that were doing largely Visual Studio and PHP stuff, and there wasn’t a lot of room for Delphi in my schedule there.  I’d fallen out of touch with it.  A lot of cool things happened in the interim, which has been almost ten years now.

Cool things like iOS and Android deployment, loads of IDE changes and improvements, AWS integrations, JSON adapters, all kinds of refactoring stuff, etc.

So I think I’ll be playing about with Delphi for a while – and I’ll approach it as “new” as I can and I’ll post updates for some of the cool stuff I do here.  So…keep an eye out, and I’ll fill you in when I do some neat stuff.  (Already thinking of ways I can tie my phone into my PC…)

Off we go!

Posted in Uncategorized | Leave a comment

A little teaser…

This is a little extra teaser to add to Build Log – Part 15.  Remember how I mentioned I didn’t have any controls to tell the board to do the things I’m programming into it?

Now I do.   (evil laughter in background)

Here’s what the first stab at it looks like:

My evil plan is coming together…

Am I the only one who’s getting just absolutely jittery over how cool this is going to be?

Posted in Build Log, Model Kits, Sci-Fi, Software | Tagged , , , | 1 Comment

The USS Enterprise (Refit) from Star Trek: The Motion Picture

Build Log:  Part 15

This update is going to be about some of the electronics that I’m designing and working with to control special effects on the model – the lighting of the torp launcher and the sounds that go along with the lighting effects.

First off, let’s spell out my requirements – there are three basic sound effects I want to establish:

First:  an ambient noise that will operate at all times that will provide a low-level of background effects.  I’ve mixed a 13-minute MP3 of various clips from ST:TMP of scenes from the engineering deck and the shuttle bay.

Second:  a music track “Enterprise Clears Moorings” from ST:WOK that will accompany a power-up lighting procedure that I have on a separate board purchased from Tenacontrols (given what I know now about programming the Arduino, I didn’t really need to buy this, but I’ve got it so I’ll use it).

Third:  a torpedo sound effect that will accompany the firing sequence of lights.

(I might decide to add a fourth for going to Warp, but I haven’t decided yet.)

These sounds fit into the actions I want the little computer to do:

  1. Start-up. When the power comes on, it should power basic lights and take us directly into…
  2. Idle State. Start the ambient background noise on a cycle, which will loop endlessly when nothing else is going on.
  3. Power-Up. This will halt whatever else is going on, then begin a process that will match the lighting sequence as seen on ST:WOK when the Enterprise leaves drydock, and will also play the theme tune “Enterprise Clears Moorings.”  After the tune is done the computer will return to (2), the idle state.
  4. Torpedo launch. Whatever else is going on, it should stop that and kick off the lighting sequence for launch while synchronizing the torpedo sound with the lighting.  Afterwards, return to (2), idle state.

So how are we going to do this?

I’m going to assume you aren’t big on electronics, so if you know this stuff already, skip this part.

The Arduino is a small computer, with a series of input and output pins.  You can program it to trigger the outputs based on what it might receive from inputs.

Certain electronic components produce current as a result of conditions around it – like changes in light, temperature, buttons being pressed, rheostats being turned, etc.  These are considered “sensors” – you have several natural sensors of your own:  eyes, skin, smell, etc.

Other electronic components do things when they receive current – like spin gears, light up, etc.  These are called “actuators,” but more often they’re referred to by their specific function.  LEDs, servomotors, transistors, etc. are all actuators.

So the Arduino, as a microcontroller, receives inputs from sensors and issues on/off to actuators.  There are about a jillion other add-ons that are built specifically for the Arduino, in many cases that snap onto the Arduino itself.  These are called “shields”, and they are pin-compatible with the Arduino’s rows of pins so they easily slide onto and off of the little computer.

The Arduino’s controlling circuits have “on” and “off” functions, “on” being represented by the board sending 5 Volts of current out the particular pin of the circuit.  “Off” receives no current.  All the outputs can operate in “digital” on/off style, and some of them can operate in “analog” mode – they’re still on/off, but they can emulate analog output by cycling a percent of the time by switching much faster than a human can perceive.  So to be completely “on” they turn on 100% of the time, and to be “half” on they cycle on/off 50% of the time, etc.

Remember the lighting from the Neck section that I made for the torpedo launcher?  Five lights – one for the background, then a red and white for each torpedo.  The background will light up, then to simulate a torpedo launch, the red on each side will cycle up, and at the point of launch the white behind it will flash.  See this video for an example:

In the video above, you see the torpedo red LEDs fade in and then go off – the fade-on is accomplished by using the analog outputs this way.

So I want to make sounds, and the easy way would normally be to pick up an MP3 player shield, but I’m a bit of a masochist, and the form factor of a full sized Arduino plus a shield is a bit tall for what I want to build as a base.  Plus, it’ll be cooler this way.

What I did instead, is I bought some el-cheapo MP3 players from Amazon – they were about $2-$3 each, self-contained little units that were meant for thumb-control.  I ended up with two different kinds (the first one shipped from Hong Kong and took longer than expected, so I ended up ordering a different set and when all was said and done I had both kinds).  One was a bare-bones model with just controls, the second had a similar layout for its controls, and had a tiny little LCD display in it.

Remarkably similar internally, these two players retail for between $2 and $3 on Amazon…often shipped from Hong Kong at no charge.

Internally they are both very similar, small circuit boards with a set of five button pads.  Each button pad has an internal and an external connection pad, and there’s a connector disc held in place by some tape that makes it into a momentary switch (momentaries are on for a “moment,” only on so long as they’re held connected).  When the buttons on the unit are pressed, the connector disc bends in and makes a connection between the inner and outer sections which results in an “on” result for as long as the button is held down.

I already did a little surgery on the board to the left, but you can figure out where the parts are.

Each one also has a 16-pin controller chip, a tiny flat battery pack, an earphone jack, an on-off dip switch, and a micro-SD card slot.

A lot of these connector pads are hooked up to the same circuit inside the MP3 player, some of them being ground, and others connecting to pins on the 16-pin chip.  The connector disc shorts the pads when the button is pushed.  We’re going to use this principle to make the Arduino pretend to be fingers pressing buttons.  There’s only so many outputs from the Arduino though, and fortunately we only need a few functions of the MP3 player.

Those functions are:

  • Navigation (forward or back)
  • Pause/Play

We might also have need of:

  • Power
  • Volume +/-

There are a few sites on the net that describe how to hack an MP3 player like these, and they show some of the connector pin-outs and which pins they connect to on the MP3 chip.  These may or may not be correct – I found a few errors when testing.

I picked up a pair cheap 2GB micro-SD cards (important to get the kind with adapters, or you may not be able to use them) for $5 on eBay, and these will serve just fine for my purpose here.  Also important is to note the capacity of your MP3 player, some can handle large SDs and some can’t.  You don’t need an expensive high-cap model for this purpose, and don’t blow money on SDs that are too big for your player.

As you saw in the video I’ve got the Arduino set up to trigger those lights in the right sequence for the firing, which I used transistors to control (I got five of them in a starter kit, but you can buy them really cheap on eBay or at an electronics store – they are unit “BC 547 K7 E”).

A transistor is a special actuator that basically operates as a switch.  It has three legs, called collector, base, and emitter.  When a little bit of current is applied to the base, the collector and the base are connected to one another.  These little gems enable you to control something considerably more power-hungry than your controller board can supply.  So if you were going to run a big motor and wanted to control it with the Arduino, you wouldn’t be able to get it powered up with the Arduino itself – but you’d power it from another source and run that power through the transistor.  You supply the positive through the collector arm, and connect the emitter to the positive of the motor, then connect the ground for the motor to the ground for the whole system.

The base on the transistor isn’t built to take a lot of current, it only needs a little tiny trickle to trigger it.  Easiest way to do that for these models of transistor is to put a 1k Ohm resistor in the path of the current from your Arduino’s pin.

Let’s go into the details of which pads do what for each of the MP3 players.  We’ll start with the simpler one, which doesn’t have a display (the number represents the pin on the chip):

Your mileage may vary – different factories might program their functions differently.

I think it’s important to note that you might end up with a different board or circuit layout – these things might be mass-produced in China, but they have a lot of different variations.  Seriously I’d recommend creating a table as I’ve done in the next example, and finding the right wiring solution from studying that.

Each time a button is pressed, it shorts the connection between the inner and outer pad, which connects two pins on the chip to one another – and the chip responds with the function given.  So, when you press “Play” on this model, it connects pins 7 and 8, so for this chip 7 + 8 = Play.

I snipped the battery off and connected leads to its wires – when the time came I’d link these to the Arduino’s 3.3V output.  I also soldered new leads to the inner and outer pads of the Vol +, and the inner and outer pads of the Next button.  This gives me leads attached to pins 6,7,8 and 16 of the chip.  Notice that using a combination of two of any of these, I can generate any of the commands available on the control board of the player.

Using a transistor on each wire, I could wire all the emitter arms of the four transistors to a common line (which would be a “bus”), and by turning on two transistors at a time I could pretend I was pressing buttons.

Here’s the problem – this model player has a convenience feature programmed into it that turns out to be really inconvenient for me:  it remembers where it left off when you last turned it off.  If it’s in the middle of playing a track, it’ll remember and when you turn it back on, and it’ll resume playing in the track where it left off.  My Arduino has no such memory unless I program one into it, which requires a persistent storage that would just be a huge pain in the ass to wire up and write to.

So if I had only one track that needed playing, this unit would be fine.  But I need several, and that memory feature is a real bugger.

That’s where the next model came in much more handy.

The one with the LCD display happens to reset itself to “zero” when it’s powered down and then up.  Whew!  That makes life a lot easier for me.  An added benefit, the volume control is set at a reasonable level by default, which is great (extra great since it has a weird volume control – you have to hold down the Vol while pressing >> or << to adjust the volume).  Slightly less convenient, the “zero” state powers up to a menu, but this is only a minor problem because once you tap the menu button once it begins to play at the first track.

Since I have the option of starting from a zeroed state, I basically only need three functions here:

  • Tap the menu button
  • Move (forward or back doesn’t matter)
  • Pause/Play

I wasn’t able to trace which pad went to which pin on the chip this time, so instead I used a jumper wire to map out what happens when I short any of the various pads against each other.  In my map, the pads are represented by a number – 1 for the 12 O’clock button and going clockwise, 5 being for the center button, plus “i” for inner and “o” for outer, see the image here:

Using that jumper wire (holding one end to one pad, and touching the other pad to the other), here are the functions:

For some reason this table didn’t come through very clear, sorry. You shouldn’t take my word for this anyway, since different factories are likely to have different code for their chip, even if the board looks similar.

 

 

 

 

 

 

Pl/Pa = Play / Pause

>> = Next

<< = Back

Vol = Volume toggle (this plus >> or << adjusts volume)

Menu = Menu button

X = no function

Other things I noticed while I was making this map that I’ll need to keep in mind while programming controls for this unit:

  • Back does a jump to the prior track – it does not return to zero on the current track.
  • Pause only holds within a track – advancing or backing up a track takes it off pause.
  • Volume, as mentioned, is a toggle that changes the << and >> circuits to change volume.
  • Boot of the MP3 player takes about 2s, and lands in a menu that takes one Menu tap to exit and start playing track 1.
  • Left Idle, after 30-40 seconds the LCD display turns off and requires a single button press (any button) to “wake up” and be receptive to further commands. The wake up tap elicits no response.

Based on this map, I really only need transistor-enabled connections to 1o, 2o, and 3i to produce the actions I require – I will connect the emitters of all three to 5o, which will give me Menu, Back, and Play/Pause function.

I’ll also put a transistor switch on the power for this player.  I’ll snip the battery off and connect it to the Arduino’s 3.3V output and stick a transistor control on that.  This gives me the ability to turn off the MP3 player and Reset it to “zero” state when I need to.

Additionally, the Tenacontrols board uses a momentary switch to trigger its power-up sequence.  I’ll slap a transistor there instead of a momentary switch, and control that through the Arduino too.  That enables me to control the Power-Up through software.

So now my functions are starting to shape up.  I’ll need two reference points:  what track I’m on, and whether I’m currently playing something.  (This second one is not really necessary since I’ll be playing something all the time, but there’s a slight chance that something might go askew and since I have no ability to handle exception cases post-facto in this code, I need to establish solid control up-front.)  I will have to have assumed knowledge in this little application that there are three tracks, and the order in which they appear on the storage card, because I have no real means by which to figure that out (technically I could hack further into the device to find where the LCD display gets length-of-track information and track # info, and use that, but I’m not that much of a masochist).

I’ll need to code the Arduino to do the actions described earlier in the following ways:

  1. Start-up. Always-on lights will be wired to the power directly so no action required there, the Arduino will Reset the MP3 player, tap Menu once, then Pause (tapping the menu automatically starts playing, so I’m establishing known control here and Pausing it).  Record the play-state as paused, and record what track we’re on (the first one), then enter Idle state.
  2. Idle State. Check the reference sites to find what track we’re on and whether we’re currently playing or paused.  Navigate to the ambient background noise by pressing the Back button an appropriate number of times, and then every 13 minutes use the Back button to re-navigate to the ambient track.
  3. Power-Up. Figure out where we are and whether we’re playing or paused.  If playing, Pause, then navigate to the “Enterprise Clears Moorings” track.  Pause  Trigger the Power-Up sequence on the Tenacontrols board.  Delay the right amount of time and Play the track when it will synch up properly with the lighting as seen on ST:WOK when the Enterprise leaves drydock.  1 second before the tune is done, Pause and enter (2) the idle state.
    1. I may amend this depending on whether I decide to “power down”, too. Not sure yet.
  4. Torpedo launch. Figure out where we are and whether we’re playing or paused.  If playing, Pause, then navigate to the Torpedo track.  Pause  Trigger the code for the torpedo cycle (which will include synching the sound effects with the lights).  If we’re in the middle of Powering Up, all that matters is that we disable the sound – let the lighting finish on its own, the torp will launch normally independent of all that.  Afterwards, return to (2), idle state.

Extra-cheap and available in a wide range of sizes, these prototyping boards can be had all over the Internet.

Some of the timing above will require manually observing and hard-coding times to get things right (particularly where buttons have to be pressed in rapid succession – I don’t know how sensitive that MP3 chip is).  Once I’m satisfied that the whole thing works on my breadboard and proof-of-concept harness, I’ll move the circuitry onto a permanent board and solder it up.

I’ve also bought some inexpensive computer speakers that run on their own wall-socket plug, and a headphone extension cable.  Inside the base of the model, I’ll secure the headphone cable so that it shows a port on the outside of the base.  The computer speakers will plug into that, and they’ll have their own volume control, so I can adjust according to the needs of the room.

A little size reference – the top left board is an Arduino Nano (cheap Chinese knock-off, actually)

I’ll also probably try to move the code onto a different Arduino platform – the standard “Mega” version is about the size of a credit card, and although this is perfectly acceptable, I’d like to see if I can get all this working with a “Nano” size board.  The “Nano” is about 2cm x 8cm, so from a form-factor perspective I could potentially move all my circuitry outside of main power directly into the secondary hull.  That’s not my intention, but it’d be neat if I could manage it.  The Nano also consumes less amperage than the Mega, which might be advantageous.  I haven’t added up the total Amps this whole affair will draw – lights, computer boards, MP3 player – and I’m pretty sure it’ll be <2.0, but I’d still like to conserve what energy I can.

Now this is all well and good, you’re probably thinking – but I’m missing a very, very important piece to this whole puzzle.  In the IT industry it’s called “HMI,” or “Human-Machine Interface.”  That amounts to the method by which I or other persons will tell this system to do the stuff it knows how to do, for us.  When I want it to do a power-up sequence, how do I tell it?  When I want it to fire torpedoes, how do I tell it?  I haven’t said anything at all about that stuff here.

I’ll settle one thing first off – there will be a main on/off switch to control the power for the entire operation.  But these other items?

That’s going to be a hell of a lot cooler, and I’ll cover that in the next installment, because I haven’t got all the parts yet.

…and it might end up looking a little bit like this :).

USS Enterprise – Build Log Part 14

Posted in Build Log, Model Kits, PC Stuff, Sci-Fi, Uncategorized | Tagged , , , | 1 Comment

The USS Enterprise (Refit) from Star Trek: The Motion Picture

Build Log:  Part 14

This is a mini-post to host a video showing how to assemble and solder various LED types for use in the Secondary Hull (LED tape, normal LEDs, SMDs, some soldering tips).  Watch at your own risk, and bring some coffee :).

Some points to note:

  • When soldering, treat your pen/iron like you would a sharp knife.  Anything it touches will melt if it is able to.
  • The short leg of an LED is the negative (-) one, and that’s the one that gets the resistor
  • Magnet wire is usually insulated, with a laquer that can be burned or sanded off (sanding is usually better)
  • Test everything, any time something can change.  Test it when you build it, test it when you connect it, test it when you install it.  It’s much better to discover a problem earlier.
  • Buy SMDs with leads attached.  They’re a pain in the ass to solder leads to.
  • Small solder is as good as, or better than, big solder

Update: I had several stills that I should share here, so I’m passing them on.

Also, I forgot to mention in the video that the way I’m wiring here is to run everything in a parallel circuit.  I hate series circuits, because if one light burns out the whole chain dies.  Parallel circuits use more resistors (a series would only need one at the negative end), so there’s more soldering, but it’s more fault-tolerant.  For example, my USS Reliant has had a couple of its navigation lights inexplicably stop working, but the rest are still running just fine – I’d have lost the entire set of navs if they’d been on a series circuit.

Always plan out your parts and lay them out before beginning work, so you don’t over- or under-do the parts you need.

Ignore the overlapping magnet wire here – this is an example of what a good solder looks like on LED tape – just little knobs, not big gloppy splotches.

 

 

 

 

 

 

 

 

I didn’t have to leave the LED’s legs this long, and probably should have snipped them a little. Note the short leg is always the negative (-) side, and that’s the one that needs a resistor.

A little scale comparison so you can see what some of these mini SMDs look like – this is why you buy them with leads attached.

 

 

 

 

 

 

 

 

USS Enterprise – Build Log Part 13  USS Enterprise – Build Log Part 15

Posted in Build Log, Model Kits, PC Stuff, Sci-Fi, Uncategorized | Tagged , , , | 1 Comment

The USS Enterprise (Refit) from Star Trek: The Motion Picture

Build Log:  Part 13

Well, it’s been a while, but I’ve got a few things done in the time since I last updated here.  I had almost begun on the secondary hull, but found a few things that needed handling before that was done up, so I put that part on hold until my next installment.  Instead, I did work on the neck and the O-Lounge, so let’s get to them!

The Officer’s Lounge

This room featured in the original Motion Picture as a meeting room where Kirk, McCoy, and Spock discussed the incoming V’Ger threat.  It didn’t feature in the Wrath of Khan at all, and in fact this room was replaced in the 1701-A ship with an Officer’s Mess (which was

Notice the colors of the uniforms, walls, and chairs. From a long distance we have to be able to give these impressions.

used in Undiscovered Country to host the diplomatic dinner with the Klingon Chancellor).  There is a 3rd-party piece available for the Officer’s Mess, but I’m building a non-A version about the time frame of Wrath of Khan, so I stuck with the stock O-Lounge part.

 

 

Left – the part before paint; Right – after soaking in an acetone bath. Good if I was going for an “Alien” Gieger look, but not so hot for Star Trek.

Initially I primed up the O-Lounge with a grey that turned out both too dark and too thick, it smothered the detail I wanted.  I should have known better than to go directly to this paint, as I’d got it from a craft store and had never used it on a model before.

My second big error:  when trying to strip the paint off, I soaked the part in acetone.  Very poor choice, as acetone will slowly melt polystyrene.  The bath pretty much wrecked the part (and in my search for a replacement that’s where I discovered that Don’s Light and Magic offers the O-Mess part).  Thankfully, I was able to secure a replacement of the original part through the kindness of someone on the SciFiModelAction boards.

Liquid mask up front, masking tape behind

First, the Officer’s Lounge has two big screens in its rear, and both of these I intend to have back-lit to appear like big TV screens.  To keep these safe, I used a liquid mask over them before priming, and put some masking tape on their back.  This way I just have white plastic that light can pass through easily.

Masked the areas where the part will glue onto the saucer, and primed it with black for light-blocking,

Primed and trees clipped

Chairs and screens ready, tree trunks glued on

then Tamiya light grey to match the walls in the film.  Next, since I’m going to install real-looking plants, I cut off the plastic trees that are scattered around the floor.  I have some 1/35th scale trees that I use for WW2 armor dioramas, and I clipped a branch or two from one to use as the trunks of the “real” trees that I was going to install here.  I glued them all in place with super glue, since they weren’t the same as the polystyrene.

The chairs, couches, and tables were next, because I can’t paint them easily after the foliage goes in.  I used an orangish color that I mixed to match the appearance in ST:TMP.  See the sort of “hallway” in the back, that goes up to the center screen?  That’s the set where the scene was filmed.

Crew and Decals for the Lounge

I then took a set of 1/350 people from a Tamiya navy crew set, painted them up in uniform colors based on both TMP and WOK, and cut the HDA Modelworx decals out to put into place.  Setting the decals was a simple matter of cutting them to fit, and gluing the figures just took a little CA super glue.  To get McCoy sitting properly in his chair took a little carving from behind the knees and waist to get it to bend right, but eventually it stuck properly.

Crew and decals in place

Once everyone was in the right place, I could glue the foliage to the trees.  Using the same deep green foliage from the 1/35th scale trees worked perfectly, giving a really nice look to the lounge.  A little sprinkle of light green fluff gave some contrast the foliage and added some depth to the effect.  Spray with satin finish to protect everything and add a little extra “stay put” factor, and it’s done.

The O-Lounge completed – even has Kirk, Bones, and Spock in the back section (this doesn’t look great when you’re right up in its face, but from one meter away it’s exactly what it needs to be).

The Fantail

The rear endcap for the secondary hull, the Fantail is one of the easiest of the subassemblies to make.  Four pieces make this one up – the fantail itself, the two side panels, and the overhead red lighting.  The faintail is a white plastic, while the other three are clear.

Side panels of the fantail masked.

After trimming and sanding, the fantail gets light-blocked.  When doing this, make sure to do your light-blocking on the outside of the piece, not the interior – the fantail has a limited amount of contact area with the secondary hull, and you don’t want to get paint on that.  It’ll interfere with your ability to glue it in place, so make sure to mask the rear properly before spraying/airbrushing.  After the black dried, some white Vallejo finished the painting.

The overhead part got zapped up with some crystal red clear paint (I used an airbrush to get a uniform coverage).  This ended up making the part a little too big for the socket it was to fit in, so I filed out the space where it belonged to ensure a good seating.  Some canopy glue on its back and that was done.

Light-blocking the fantail sides

The two side panels are a little funny.  When you look at the studio model, they are darker than the fantail itself, and they have not only those three blue horizontals, but a few small red spots on their lower halves.  I put some liquid mask into the horizontals, and blacked the pieces on their front (I pressed them into some blue-tac putty to hold them in place while spraying, and this also masked the rears to keep them from collecting extra paint).  Once the light-block was dry, I zapped them with some Tamiya light grey to provide contrast with the fantail.

Interior of the fantail with putty closing the light leaks

After the paint dried, I used a .5mm drill to put a few holes in the paint on the lower side, and to put one spot above the horizontals on each.  A little crystal blue in the horizontals (and the spot above them), followed by a drop of crystal red in the spots beneath them, and they were ready.  Glued in place with canopy glue, then checked for light leaks – which there were several around the sides.  I filled in the sides with plastic putty, and that took the leaks out of the picture.  Finally, after masking the back I applied a coat of automotive clear gloss on the exterior to protect everything and get it ready for decals.

Fantail is ready for action – the side panels look a little rough close-up, but at the one-meter judgment scale, they look great.

The “Neck”

This turned out to be deceptively complex, and just calling it “the neck” seems like an understatement.  It contains the torpedo launcher section, and is the first assembly of the model that actually has windows in it.  As well, it has two travel pod docking rings, which have some photo-etch parts to go with them.

Notice the lights in the travel pod docking ports.

Looking at the film shots, the travel-pod docks have lights on either side of them, which I decided to use fiber-optics for.  The holes are deep enough that a small drill bit will work fine, and a .25mm FO strand fits perfectly in there.  The fibers I was using were a bit stiff, and required some heating to get to bend properly – and once you cement them in place they become quite brittle, so my best advice here is maybe not to do that at all.  It was a royal pain in the ass, and I think I might skip that if I had to do it over again.  However, they’re done now, and I wouldn’t be doing you justice if I didn’t mention them.

Inserting fiber for the pod lighting

“Mushrooming” the ends of the FO

 

 

 

 

 

 

After threading the fibers through the drilled holes, I used a soldering iron to ‘mushroom’ the tips just a little, and then pulled them flush with the inside of the docks.

Travel pod PE parts – there are quite a few of these, make sure to get them oriented right (the little flat spot goes on bottom)

Next, I secured the photo-etch parts to the travel pod docking rings with some CA glue.  In hindsight, these PE parts should go on after the completed assembly has been painted, and a final dusting of the white overcoat can be applied to cover up the metal.  Having them in early resulted in the detail being obscured by several coats of hull color paint, and I ended up having to go back and wash the paint out of the docking rings with acetone before re-applying a thin coat to preserve the details.

 

Masking applied to the Raytheon zones

A big splotch of liquid mask then was applied to each side of the neck to provide a Raytheon lighting spot (in the film studio model, this area was lit up with a spotlight that wasn’t actually on the model, but you couldn’t tell that from the way they shot the scene).  A tiny dot of mask was also applied to the ends of the fiber optics in the pod rings.  Light-blocking time!  Masking up the edges to avoid screwing up the parts that would be glued together, the exterior of each part got a coat of black.

Light blocked…

…and hull color applied.  Notice on both that there is masking tape covering where the glue seams will be.

 

Once dry, I stripped off the masking film, sanded the edges where necessary (not really needed, but I wanted to be sure), and put on several coats of Vallejo white primer as a hull color.

Some of the interior printed on transparency sheet

After this the windows were going in, and even though they were circular ports through which not a lot can be seen, I printed out some interior hallways on transparency film to glue in place behind them.  Cutting small sections of these out and gluing them behind the windows gives a little variation in the amount of light passing through the windows, and I suppose someone with better up-close eyesight than mine might be able to make out the detail.

 

Some of the larger windows needed “convincing”.

Some of the window parts for the neck are a bit large, and don’t fit perfectly, so they had to be clamped while the canopy glue dried.  In hindsight, I might have been better off to slice these up with a Dremel or something, and apply them in pieces, but I did them whole.  I let them dry overnight to be sure.

 

 

Doesn’t hurt to cut some of these windows to make them easier to handle.

There are also two pieces which are molded to extend over the inside of the travel pod docks, and if you have put fiber in there, you’ll have to cut these in two pieces (discarding the middle section of them).  Not a big deal, they still attach fine after cutting.

 

 

 

“Floodlight” ports on base of neck

Double-layered with clear styrene and glazed with matt clear frosts them for lighting from underneath.

There are two “spotlight” sections on the lower rear of the neck, squarish holes that are intended to splash light up on the neck.  I didn’t like the way the clear parts for these holes protruded, so instead of those I just took some small pieces of clear styrene and glued them to close the holes up.  A bit of clear matte on these frosts them up and scatters light out from beneath them nicely.

Now it was time for the interior lighting.

Setting aside the two sides, I took an inventory of what lights would need to go into the neck section:

Lay out your lighting components to get ready to do some soldering.

2 LEDs to feed the fiber optics (one for each side) – I went with a 3mm cool white for each

2 LEDs to supply the Raytheon effects – I used 3mm cool white here too

4 3-chip LED strips for the interior lighting in warm white

This is what LED strip-lighting looks like when tinned up properly.

Those strips need a little description – they are sold as 5-meter rolls, which is more than most people will use on a model like this (or three, probably), and they aren’t wired up when you get them.  They do have conveniently-marked cutting lines, but the rest is up to you.  Having cut the four sections out, I also assembled wire leads that would be connected to them (using a hot iron and sandpaper to remove the lacquer insulation from the ends I wanted to use).  Tinning the strips basically means putting the tip of your iron on each of the

Once your wires are in place, they should resist a gentle tug.

copper receiving circles to heat them up and then touching solder to them to leave a drop on its surface.  The 36-gauge magnet wire I use here won’t tin well, so once it has been stripped of its insulation it’s basically ready to use.  Put the LED strip into a set of “helping hands” and hold the magnet wire in your off-hand.  Heat the solder up on the strip while holding the magnet wire against the drop.  As soon as the drop goes molten, wiggle the wire into the blob and remove the heat immediately.  A little blowing on it will solidify the metal right away, and a gentle tug on the magnet wire will confirm that it is locked onto the strip.  Repeat for the other connector.  Once both are connected, test your wiring with a battery or other source of current to make sure the soldering worked.  If they don’t, you’ll have to repeat the job.

Dirty, dirty solder

Clean solder looks shiny and “silvery”

Any time you use your soldering iron, clean it before using it again.  Having dirty solder will potentially screw up its ability to make an electrical connection, and it will be much harder to work with.  Clean solder on your iron will look silvery, while a dirty iron will have a lot of black slag on it.  Just use a wet sponge or soaked rag to wipe off the hot iron and keep it clean in between every use.

Placing the LED strips and FO feeder light – note the colored leads for pos/neg ends.

For each of the 3mm LEDs, a 470-Ohm resistor gets soldered on (make sure it goes on the negative side, which is the shorter of the two legs), and wire leads go on as well (color code your leads so they are always the same – usual convention in all electrical work is to use black for your negative, and colors for positives).  Test your connection to make sure it works.

LED strips have tape backings, and you can peel them off and stick them in place.  Although this is convenient, I don’t trust it for a long-term connection…I want this model to still look great in ten or twenty years, and I know tape adhesives dry out in that sort of timeframe.  Once the tape strips were anchored, I dabbed some CA on each one every centimeter or so.

The 3mm LEDs for the fiber went on next, also using CA to get them to stay put.

By the way, if you get tired of holding pieces in place while you wait for CA to set, you can pick up some ‘zip kicker’ in a spritz-bottle that forces CA to set instantly.  It’s a bit stinky, but it works great.  Once the LEDs for the fiber were locked down, I gently bent the fiber to meet the bulbs of the LEDs (some heat was required to soften the fibers, and this was really difficult to do – too much heat and the fiber melts, too little and it stays brittle and just shatters where it passes through its hole) and glued them on with CA.

Next, the Raytheon LEDs got a resistor put on, then lead wires.  Pop them in place behind the spots on the neck and secure with CA.

Wrap the wires where you can to avoid clutter, and always label your wires when they’re tested good. You’ll thank me for that some time.

Now we’ve got a bunch of loose wires hanging out, and that makes for later mistakes and accidents, so to make things a little more manageable we can twine a few together.  The fiber optics will be on the same circuit as the interior lighting, so that’s a good set of candidates right there.  Take the negative leads from the LED strips, and wind them around the black (negative) wire from the 3mm LED for the fiber.  Do the winding so that the last few centimeters of the magnet wire wrap around the tinned end of the negative lead.  You can then re-tin that lead to lock the magnet wires in place there.  Repeat with the positive leads from the strips around the white or colored (positive) lead of the 3mm fiber LED.  Now you’ll have only two sets of leads from each side – one for the interior lighting/fiber, and one for the Raytheon/floodlights.

Using masking tape, or some other form you are comfortable with, label your wires now.

Go ahead and test again using a battery or source of current to make sure everything still works.  You don’t want to glue everything together and find out later that somewhere you have a bad connection.

Since I’m paranoid about glue, I decided to apply hot-glue all over the place too, to make sure it all got triple-secured.

Crew inside the windows looking out.

So now all the wires and LEDs are in place, and I can fix the window dressing in place.  Using the transparencies I’d cut out earlier, I scissored a section and glued it behind some of the windows with canopy glue.  I also took two of the Tamiya naval crew figures and cut sections of them to go behind a couple of windows.  Don’t think they’ll really be all that visible, but their shadows will, and that’ll make things look like there are people walking around in there.

More crew observing the travel pod dock.

Time to work up the torpedo launcher.  It isn’t black, but a very dark grey, and the insides of each tube are glossy (during the 10-minute fly-by tour in ST:TMP you can pause it on one of the frames to get a really good close-up look at them).  I put some liquid mask in the ‘mouth’ of each tube, and some masking tape across the back, then just sprayed it with black followed by a dark grey.  You will probably have to do multiple coats (I did), because although the first coat might look good to the naked eye, it will still be light-permeable and won’t look very good.

Once the painting on the torp launcher is good, you have a choice – lit or no.  If you aren’t going to light it, light-block the back of it to prevent leakage and it’s ready to go.  If you are going to light this section…

First, widen the portion of the neck sections to enable the wiring to pass more easily.

Torpedoes fired in “The Motion Picture”

Next, you get to decide how the launcher will behave while firing.  In ST:TMP, a background light of red within both tubes fades in when the torps are armed and ready, and the torpedoes themselves are bright blue.  In WOK, there is no back-lighting and the torps are red.  Take this into account when determining which lights you choose.

 

 

“Wrath of Khan” torpedo launch

I went with a combination – I want the red back-lighting like TMP, and I want my torpedoes to be red like WOK.

First, I drilled a center-hole in the back of the torp launcher piece, and glued a red SMD with CA into it.  This will be the source of my backlighting.

Each torpedo tube is molded with a hole behind it, so that’s convenient.  Into each one I first put a red SMD, gluing it in place with CA.  Behind that, I then stuck a white SMD and glued it with CA.  After the CA was dry, I plopped some canopy glue in as well.

While you’re waiting for this to dry, paint the inside of the “mouth” that holds the torp launcher on each side of the neck.  Just use matt black here.

Get some painting done while you wait.

What I’m going to do with these is program an Arduino board (I’ll highlight that in a future installment of this build log) to fade-in the backlight, then do a fire-one / fire-two sequence using rapid fades of the two red and white SMDs to look like the firing sequence in the films.  I also have sound clips of torpedo firing which I’ll include on a cheap-ass Chinese MP3 player that will also be controlled by the Arduino board, and will play from whichever speakers I hook the thing up to.

There’s a final piece of the neck that goes into the rear of it when it’s complete, which I assume is some kind of venting port for the torpedo launchers.  It’s just black in the films, so I painted it matt black on the showing parts.  No lights, very simple.

Time to glue all the parts together!

Making sure to be very careful of the wiring…

I stuck the torp launcher carefully into one side of the neck (it takes some firm but gentle pressure to get it to seat properly) and glued it there with canopy glue.  Wait for the glue to dry.

Again being careful of the wires…

Next thing is to put some canopy glue into the other side of the neck where the torp launcher will sit.  Get your polystyrene cement out, and glue the small vent into the side that already has the torp launcher seated in it.  Before this is done drying (because you’ll need to adjust it a little), line the neck side with glue on the edges where the neck will come together and in the post holes and posts, then press the whole thing together firmly.

Check the fit of the torp launcher and the rear vent, and adjust them as needed to make sure they are lined up correctly.  The neck should fit together pretty well, I didn’t have too many seam problems, but to hold it while it dries is a bit of a pain.  Use some clamps to hold the pieces together (I wrap mine in a soft cloth and put them in a vise, and clamp in places where the vice is too big to grip).  Let it sit and cure for a day, and check in on it every fifteen minutes or so for the first hour, correcting the fit if necessary.

Styrene reinforcement strip – just cut to fit where you can slide it in, and make sure it has a good bit of glue on it.

Lay them in, front and back, and press them down. This will strengthen the bond holding the halves together.

Once the whole thing was cured, I cut out some strips of styrene to reinforce the neck’s connection, sliding them into the structure and bridging the two pieces.  I also used silicon black seal on the back of the torpedo launcher to guarantee zero light transmission between the neck and the torp launcher.

The few seams I had, didn’t take a lot of fixing – a little wipe with some plastic putty, a little sanding, and a short blast with some white Vallejo (masking all my windows) and it was clean.

Once this was done, I painted some of the larger highlights with an airbrush (the duck-egg blue on the ribbed top section, the silver “mouth” around the torp launcher, the light grey “throat”, and the light grey space directly beneath the launcher).

Finally, once I was satisfied with the paint job and the glue was completely cured, I put a coat of automotive gloss clear on the entire assembly (masking off the top and bottom where it’ll need to glue onto the other parts of the ship) so it’d be clean and ready for decals.

With that, it’s ready to roll!  Into a bag it goes, and in my next installment I’ll discuss the Arduino board for the torps as well as probably getting into the secondary hull.

Whooo-hooo!

She’s ready for prime time! Next stop, the secondary hull.

 

USS Enterprise – Build Log Part 12

Posted in Build Log, Model Kits, Sci-Fi | Tagged , , , | 1 Comment