Humble Pi

My  main reprap printer uses the same, none standard,  control electronics as some of nophead's earlier printers. It differs from the standard reprap gear in that the firmware is a slave to the PC. All the gcode decoding is done by the PC, and simple move, temperature, extrude commands are sent to the reprap electronics.



This is great in that if I want to change the Z height, or adjust the filament dimensions or temps. I simply edit a Python script.
Also, the PC communicates with the control electronics over ethernet, so the USB timing issues just don't occur.

To keep the embedded code simple a static IP address is used. Mine is set to 192.168.7.8 and it works great.

Now the arrival of my Mendel90 means that I have to make a USB connection to the Melzi controller every time I want to do a print. This is a pain as I don't have a PC near where the Mendel90 is.

I decided to try the Raspberry Pi print server. It's great. I simply TightVNC into the Pi, and run Pronterface from there.

So today, I started a large 6 hour print at 10am. Around four PM I think 'It's about time I got that Raspberry Pi running' so I plug everything in. As the Pi powers up, the main printer halts with about 1 layer to go and just sits there spewing plastic. WTF!

Of course, with inevitable fate I'd set the Pi to have the same static IP as the first printer and the bloody thing lost its comms. to the host software.
Bugger...

New Lathe

I've been trying to make a 0.3mm hot end for a friend who agreed to exchange one for a completed Melzi controller board for my Mendel90.
My lathe is really old, and had been used in WWII by my grandfather to make parts for the war effort. As a result, it's a bit worn, and not really up to this sort of thing.



So last week I decided to replace it with this:



It's a Myford M-Type from 1949. It is in great condition and although it has a shorter bed, it is a bigger lathe.

After almost breaking my back installing it, I successfully bored a 0.3mm hole for the extruder nozzle:



Here is the hot end complete:

Open source UMT code

Visit Tagbits to see the full range of tagger products described in this blog.

Got my Milestag UMT lasertag software working.
I will be advancing the features of the software, but currently it supports:

• Red,blue,green,yellow team id.
• Data clone from core board.
• Compatible with standard UMT audio samples.
• Ammo box, respawn box,and most referee commands.

The project is very modular, and could be converted to most lasertag applications. It is available under the z-lib license on github at: https://github.com/tonygoacher/UMT_Open_Source

Please contact me if you would like a customised version of the code, or a particular feature adding.

This is a Hi-Tech 'C' project, their is a 45 day evaluation of the compiler available at: http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en542849

UMT Software almost finished

Visit Tagbits to see the full range of tagger products described in this blog.

My Milestag microMT lasertag is coming along nicely. The infra red signal needs to be modulated at 56KHz to match the TSOP4856 sensors that are used to detect hits. I'm using the inbuilt PIC16f684 PWM to generate this frequency.

First I did a simple test to simply check I'd got the frequency right:



Not bad for a first attempt. I've already written the Milestag protocol transmit routine, but I tested the timings by simply turning a port output high or low as described here.
I replaced the port on off code with PWM on off code and got exactly what I wanted. Timed IR pulses modulated at 56KHz.



When I tested my shot packet against another lasertag unit, the second unit picked up the shot packet and seemed to interpret the shot power consistently, but with an incorrect shot power value. I need to look into this next.

Sparkfun serial LED display bracket

Visit Tagbits to see the full range of tagger products described in this blog.


The Milestag UMT lasertag system uses Sparkfun serial LED displays to show health, rounds etc. They are nice units but difficult to mount so I have designed a bracket to allow them to be neatly fitted and protected:



This has an integral 2mm acrylic sheet to protect the display, and a 2mm flange allows some leeway when making the cut out for it.

A small bracket is screwed in place at the back to hold the display in place, this also has a cut out to provide access to the display terminals:


It is available at the Tagbits shop here.

Clocking on

Visit Tagbits to see the full range of tagger products described in this blog.



I've been trying to get the Sparkfun serial LED display working with my Milestag UMT lasertag software. This is used to display clips, rounds, health etc. But I couldn't get it working.

The display can accept commands via either a standard serial port or a SPI port. I'm using SPI as with all the other interrupts going off in the software, I cannot guarantee bit timings so synchronous communications make more sense.

I'd already written a software SPI routine for the ISD1790 sound playback chip, so I went ahead and used this routine to access the display.
I could not get it to work, so I resorted to sticking my logic analyser on it:



From this I can see that the first byte sent to the display is 0x78 which is a blank segment. But it is being sent most significant bit first. This is normal for SPI, but the ISD1790 expects least significant bit first. I'd written the ISD SPI routine to spec.But had forgotten the none standard bit order.

I implemented a second routine to send MSB first and hey presto:

Milestag UMT software

Visit Tagbits to see the full range of tagger products described in this blog.


Update: Code finished here

I'm making good progress with my own version of the Milestag UMT software. Since getting the IR receive routine working, I can now control the ISD1790 audio playback chip and have implemented the IR clone and system message processing.

I've also implemented most of the game code. This is implemented as a state machine, with each gun mode having its own state. e.g. InGame, Dead, Re-loading, Hit, Game Over etc.

The interrupt driven IR receive routine passes a packet event (as a flag) to the foreground task, which then takes the appropriate action depending upon the current game state.

I've also got the IR transmit routine working. The PIC generates a 600uS periodic interrupt and implements (yet another) state machine to allow it to track which part of the IR signal it is currently sending. The IR packet consists of a 2.4mS header followed by one's of 1200uS and zeros of 600uS. Each bit has an inter bit delay of 600uS.

Here is a snapshot of the start of a packet:

The long header can be seen at the LHS of the display in between the two vertical lines. Following are a series of long and short pulses for 1's and zeros.

Here is a full packet sending a gun ID of 20 (0x14) and a team ID of 1, and shot power of 2 (0x12). Data is transmitted least significant bit first.
The vertical lines on the show show the start bit (bit 0) of each part of the transmission. The gun ID is 8 bits long and the shot power/team ID is only 6 bits long. See the full Milestag IR protocol documentation here.



All that remains is to modulate the IR signal to 56kHz using the PICs on board PWM.