Have Decided that I Like Railroad Bridges

That is, N-Scale, railroad bridges as they allow me to continue designing and printing small models.

The first one that I did was a pretty much a complete creation based on things that I saw from Google.  I started to paint and weather it but have decided that it needs to be reprinted and re-assembled.  Speaking of which...these are obviously (if you know about 3D Printing) these are printed in pieces and assembled like a kit.   Aayway, there are a number of issues with this model including the need for some extra support at the end ramps and the height and width of the walkway.

My second bridge is a reasonably accurate replica of a plate and girder bridge in particular the one shown below...but only the section to the right and not curved!  And also...one version, the one shown, without the walkway shown in the plans, and one with a solid roadbed and walkway as shown in the plans.

Both of these models are largely printed using a 250 micron nozzle (with the same extrusion width) for the details.  Check out the rivets below.

Current project is a truss bridge, this one of my own design with the goal of looking good as opposed to matching anything in reality.  If I do another bridge I would like to replicate something from full scale but I have not found a subject.

Since N-Scale is even smaller that what I have been doing for FoW (1:160 versus 1:100) it poses equal parts of a challenge for my printers and for my dexterity while fitting into the man cave even better!

The first two models are on Thingiverse for your printing pleasure.  The third will be soon as well.

Demo for the Python Interface Class for Onion to Arduino Integration

The code for this demo (Demo.py) is on GitHub with the interface itself.  Below is an illustration of the demo breadboard with pictures of the individual components:

But where, you ask, is the Onion Arduino dock?  For some reason mine has stopped accepting a flash so I substituted a China Clone Nano instead.  The Onion library still works as if it were on the Uno and I was able to complete the demo!

The point of the demo is to provide an example of each interface function in operation.   In thinking about how to do this I came up with the above:

• Range finder to illustrate pwmPulseHigh
• Buzzer that sounds when a distance threshold has been breached to illustrate pwmWrite (though I am not taking advantage of different volumes that are possible with PWM)
• Potentiometer, or variable resistor, as part of a voltage divider illustrating the reading of voltage using an analog pin.  The voltage reading is used to adjust the sensitivity of threshold where the alarm sounds
• Servo to illustrate the servo control capability of the interface.  It moves to show the position of the above variable resistor.
• Push button to illustrate the internal pull-up capability of the Arduino as well as a digitalRead.  Pushing the button ends our demo script.

And finally, a video clip of the demo in operation!

Python Interface Class for Onion to Arduino Integration via I2C

One of the docks available with the Omega Onion micro computer features an integrated Arduino Uno in the standard Uno form factor for use with the various shields available for the Uno.   Any needed integration between the Uno and the Onion is done using I2C.  Some time ago I had written a Python library to integrate a Rpi with an Arduino so I decided to port that interface to use I2C.

The interface is driven from the Python side as the I2C library provided by the Onion only supports slave mode for the Arduino side.   I2C is both more complex and more simple than using serial communications.   Once you understand the message flow as discussed in the previous article the actual command and response flow is quite simple:

    'DR13' -->                             from Python to Arduino
    <-- '0,1,Digital read from pin 13'     from Arduino to Python

Commands that provide two arguments would have a comma separating the first and second argument (e.g. DW13,20).  The narrative after the value is there only if debug is on.

The standard commands implemented in the first version of this library are shown below:

    (P)in mode commands
    pinModeInput(pin)
    pinModeOutput(pin)

    (D)igital commands
    setHigh(pin)
    setLow(pin)
    digitalRead(pin)
    digitalWrite(pin, value)
 
    (A)nalog commands
    analogWrite(pin, value)
    analogRead(pin)
    pwmRead(pin)
    pwmPulseLow(pin, trigger)

    pwmPulseHigh(pin, trigger)

    (S)ervo commands
    attachServo(servo, pin)
    commandServo(servo, command)
    detachServo(servo)
 
    (H)ousekeeping and debugging commands
    setDebugOn()
    setDebugOff()
    setExceptionOn()
    setExceptionOff()

The most rudimentary possible example of this library in operation is shown below:

from Onion2Arduino import interfaceClass

true = 1
false = 0

# Bring in the interface we are demo'ing!
o2a = interfaceClass()

# No debug and errors will not cause an exception
o2a.setDebugOff()
o2a.setExceptionOff()

# Pin assignments for our demo hardware
BUTTON=7

# Initialization where appropriate
o2a.pinModeInputPullup(BUTTON)

# Loop until button is pressed
running = true
while running:

    # If the button has been pressed then we end this all now!
    if int(o2a.digitalRead(BUTTON)) != 1:
        running = false


print 'Done!'

There is no error handling shown above.  There are two ways to implement error handling with one being to raise and handle exceptions on error and the second being to interrogate the interfaces status after each transaction (o2a.returnStatus in the above case).

Obviously the Arduino side of this library can do more depending on a given application.  Anything that needs real time attention would need to be handled here as the Onion is not going to be reacting in real time!

The code for the interface is located on GitHub and an example of it in operation follows.

Back to Playing with Some Micro-Electronics

Introduction

It has been a while but I decided that I needed to spend some time with a little single board computer that I recently purchased as part of a Kickstarter initiative but have been ignoring until now.  The computer is the Onion Omega and it's mission is to enable the Internet of Things.  It is smaller than either the Raspberry Pi or the Beaglebone Black that I have also messed with and it supports an onboard integrated WiFi hotspot as part of its reason for being.

Onion in Breakout Dock Connected to Arduino Dock for Programming

Getting the Arduino Dock Setup

The writeup in the Onion Wiki is pretty good in terms of how to get things setup and I am not going to repeat it here.   The one thing that I will call out is the importance of having any sketch you download to the Arduino dock include the following code or you will be having to reprogram the dock every time you upload a sketch that does not contain this code!

Here is the note from the Wiki that should have told me that I needed to do this had I not breezed right past it:

What this translates to from a code perspective can be found in the sample sketch that will be found later in this article.

Using I2C for Communications - Debugging Setup

My initial thought was to use serial communications between the Onion and the Arduino Dock but the architecture does not support this as an option as I2C is the recommended solution.  So I went looking for a nice example to get started.  I may have missed something but I could not find the example that I was looking for...which was...a matching pair of a Python application talking to an Arduino sketch!  I found a Python application but not its counterpart so I wrote one.

But not until I setup a way to do some debugging using the Serial.print statements that I am used to using.   I did this via the setup shown below where I connect the serial pins on the Onion Arduino Dock to the Serial2 pins on an Arduino Mega running the 'MultiSerialMega' sketch.  In this manner I am able to see my debugging statements echoed on a serial console as if the Onion Arduino Dock were directly attached.

Onion in Arduino Dock Connected to Another Arduino for Debugging

Using I2C for Communications - Sample Scripts

As promised above, here are the sample scripts and here is a dialog of their operation with the left column being what is displayed from the Arduino and the right the output from the Python script.  I think the scripts will be reasonably easy to follow once the general flow, as seen from the Arduino side is discussed.  A caveat here...I don't know enough about the native I2C dialog to describe it in anything but terms that relate to what I am seeing in the examples!  I would also note that these two scripts started with this one for the Arduino and this one for Python.

The Arduino Sketch:

• Included libraries: Obvious ones being the OnionLibrary and the one for Wire.   The not so obvious one being the avr timing library.  I honestly only really just noticed that one so am not sure whether it is actually needed!
• Setup: Setup two handler functions, one for when data is received and one for when data is requested requested.
• Loop: Nothing here for this example as all the magic happens in the two event handlers we setup above.
• receiveEvent:  
• The parameter passed is the number of bytes to be received (though the script does not use this data).  
• The first byte will always be the register address passed from the master.  For our purposes this provides a routing indicator and is stored in a global variable 'addr'.
• We then loop until we have read the data that was sent to us.  We read into another global variable 'data' which will be used later.  This is where we should really think about using the parameter that was passed to us but for purposes of this example I am ok with what we have done!
• Finally, the all important reset sequence!  If the 'addr' was "DE" and the 'data' was "AD" then do a software reset per the Arduino Dock guidelines.  If you do not do this then your will not be able to re-flash the dock from the IDE and will have to go back to the initial setup!!!
• requestEvent:
• I have setup a global variable 'seq' so we can see the number of times we have been into the default handler of the switch in the event handler (more below).
• This handler is where we use the global 'addr' as our routing indicator by virtue of the switch statement:
• '6' responds with two bytes ("QE")
• '9' responds with the last contents of 'data'
• Everything else gets the incremented value of 'seq' from above. 

I think that everything in the Python script will be self explanatory given comments, the dialogs from its execution, and these notes:

• Lack of a type error on the second write of the first write test:  There is a comment from the original author indicating that this should fail with a type error.  It did not for me but this may be a result of different error levels in Python.  I will mess with this later.
• No 'addr' on the third write of the first write test:  This test sends an array of bytes using the Wire.write function.   The first byte of that array will be received in my sample Arduino script as the routing indicator!

My next task will be to use I2C communications to drive a Python/Arduino integration library that I wrote a couple years ago using serial communications.

3D Print Technologies - Three Tanks from Three Technologies - The End

I finally got around to painting the three Jagdpanthers from my test of different 3D Printing technologies.  This is the final article in this series!  The first article in the series is here.

FDM, SLS, SLA

FDM

SLS

SLA