Digitally controlled solder station

[dannyf]

In the post about a minimalist frequency meter, I talked about the possibility to use the (7-segment) display in a solder station.

I have since put together the code pieces and have one running on a breadboard.

Basic structure:

1) it is a solder station that drives A1321 cores (Hakko 936 handles). Those cores come with a ptc temperature sensor.
2) the temperature is displayed on a 4-digit led display (either common anode or common cathode - the firmware can drive both). Display is in xxx.y format.
3) the target temperature can be adjusted via an encoder, in discrete steps (5c for now). The target temperature will be displayed. 5 seconds after no user adjustments, it will revert to displaying the handle's actual temperature.

Here is the basic schematic - encoder and power supply not shown. RV1 simulates the A1321 core.

The green arrow points to the heater-on indicator: it is lit when the heater is on.

The basic framework comes from the frequency meter - I actually still have code for tmr1/tmr2 in the code base - unused here. Too lazy to take them out.

Power will come from a 20v laptop power supply (19.6v, 9amp?).

I would expect temperature to be stable within 1c, and heat-up time to be 15-20 seconds to 200c, based on other stations I have built using the same set-up.

Code compiles to about 1.1KB.

[dannyf]

I was asked why the led was wired the particular way and how the led display module works.

1) how the led display module works.

The led module is coded to drive individual segments and digits, based on a set of logic names: LED_DIG1..4 for digit 1 through 4, and LED_SEGA..SEGDOT for segment A through G and the dot. A set of macros, DIG_ON() and DIG_OFF() are used to turn on / off the digits, and SEG_ON() and SEG_OFF() are used to turn off the segments - Both macros are dependent on if the led is common anode or common cathode.

The actual display routine has a static variable to keep track of the current digit being displayed. So each invocation of the display routine will advance the display from one digit to the next.

The LED_DIGx and LED_SEGx names are then mapped to LED_PINx:

Code: [Select]

#define LED_SEGA LED4_PIN11
#define LED_SEGB LED4_PIN7
#define LED_SEGC LED4_PIN4
#define LED_SEGD LED4_PIN2
#define LED_SEGE LED4_PIN1
#define LED_SEGF LED4_PIN10
#define LED_SEGG LED4_PIN5
#define LED_SEGDOT LED4_PIN3

The above scheme maps the segments to pins on a typical 4-digit 7 segment led display.

The user then will provide his/her mapping, from LED4_PINx to actual GPIO pins, like this:

Code: [Select]

#define LED4_PIN1 GPIOA->PIN0
#define LED4_PIN2 GPIOA->PIN1
#define LED4_PIN3 GPIOA->PIN2
#define LED4_PIN4 GPIOA->PIN3
#define LED4_PIN5 GPIOA->PIN4

So any calls to turn on LED_SEGE gets translated into calls to turn on GPIOA->PIN0, by the compiler. All the user needs to do is to tell how LED_SEGE gets mapped to GPIOA->PIN0.

Such a system provides a mechanism for a user to quickly change pin assignment, without the need to actually change the underlying code, when he moves the code from one application to another.

2) why we wired the led this particular way?

We wanted to let the led display sits right on top of the mcu. So the mcu's pin2 (PORTA.0) is connected to the led's PIN1, the mcu's pin3 (PORTA.1) is connected to the led's PIN2, ...

This particular configuration is needed to achieve the ease of connection. You can obviously reconfigure the wiring to your liking so that any pins on your mcu can be connected to any pins on the led display and it would work, after a recompilation of the header / source file.

The display routine is called from within a timer isr, every few ms. So once's the display routine is configured, and the timer isr is running, the display is updated in the background without user intervention.

All the user does is to update a display buffer (4 bytes for a 4-digit display). The isr and the display routine do their magic after that.

[dannyf]

This basic approach can be utilized to drive more (or less, if you so desire) digits.

Here is an example of 8-digit counter.

If you couple it with a frequency counter routine, you get an 8-digit frequency counter: the display routine is completely transparent to the user program. All the user program does is to load the display buffer with the right segment information and the isr + display routines do their magic.

The display below, for example, is generated by the following main loop:

Code: [Select]

tmp += 1; //which item to display?
ltmp = tmp / 10;
lRAM[7]=ledfont_num[ltmp % 10]; ltmp /= 10; //dot on digit8 indicates heater status
lRAM[6]=ledfont_num[ltmp % 10]; ltmp /= 10; //dot on digit7 indicates heater status
lRAM[5]=ledfont_num[ltmp % 10]; ltmp /= 10; //dot on digit6 indicates heater status
lRAM[4]=ledfont_num[ltmp % 10]; ltmp /= 10; //dot on digit5 indicates heater status
lRAM[3]=ledfont_num[ltmp % 10]; ltmp /= 10; //dot on digit4 indicates heater status
lRAM[2]=ledfont_num[ltmp % 10]; ltmp /= 10;
lRAM[1]=ledfont_num[ltmp % 10]; ltmp /= 10;
lRAM[0]=ledfont_num[ltmp % 10]; ltmp /= 10;

lRAM[8] is the display buffer. ledfont_num[] is the segment font information for numeric values ('0'..'9'). ltmp is the value to be displayed: every 10 ticks of tmp advances ltmp by 1.

[dannyf]

You can add more digits to the display; and if you load it up with different font information, you can display for example alphabetic characters, or signs.

[dannyf]

I added a couple features:

1) user selectable Celsius or Fahrenheit display;
2) user selectable initial temperature;

Temperature range: 200C -> 450C, in 5C increments.

All done via a cheap encoder,

[dannyf]

I am mostly done with the code at this point, .

Here is the schematic:

1. mcu is a 28-pin PIC - 16F1936 specifically. But the code should compile, with minor modifications, for other 28-pin chips, like 16F886, or 18F2xK20/K22. You just need 6x2 consecutive output pins to drive the led, 1 adc pin and after other IO pins. With some modification, it should work on other mcus as well.

2. The 4-digit, 7-segment led sits on top of the mcu. No current limiting resistor. Current consumption is about 60ma between the led and the mcu.

3. The code drives Hakko cores with PTC sensors (A1321). With some modification, it can be made to work with cores with thermalcouple sensors (A1322 or T12).

4. Temperature sensing is done via the PTC, calibrated to Hakko clones: the resistance curve in the code is purposefully reduced by 10ohm. A trimmer (RV2) is built in the circuit to allow additional calibration specific to your own cores.

5. The code drives either common anode or common cathode leds. Jumpper attached to RC2 tells the mcu if the display is common anode (high) or common cathode (low).

6. User settings / input done via an el cheapo encoder (with a built-in switch).

7. Unit works in both Celsius or Fahrenheit, user selectable.

The driver is designed to be cheap. Depending on your parts box, it shouldn't take you more than $20 to build it.

[dannyf]

User interfact:

1) temperature adjustments: by turning the encoder at any time, in 5C increments (or its Fahrenheit equivalent). As you turn the encoder, the display will show the target tempeature, in XXXC (for Celsius) or XXXF (for Fahrenheit) format. After a couple seconds of inaction, the display reverts to heater temperature.

2) Target temperature saving: user can display the target temperature at any time by pressing the encoder. Target temperature setting will be  shown in the XXXC or XXXF format. If you press and hold the encoder, after a couple seconds, the target temperature setting will be saved in EEPROM - the dot on digit 1 will light up to indicate that saving to EEPROM is successful. Next time the unit boots up, it will go straight to this temperature.

3) Celsius or Fahrenheit switch: if you press and hold the encoder while the unit is booting up, it will switch between Celsius or Fahrenheit display settings - if the unit is current in Celsius, it will display in Fahrenheit; and vice versa. The setting will be saved in EEPROM so it will be permanent. ie. you only need to press and hold the encoder while booting up the unit if you wish to switch the temperature display setting. Default is Fahrenheit.

4) Adjustable temperature range is 200C - 450C, in 5C steps.

5) Power supply: any DC source north of 12v. I used a HP laptop power supply (19.6v).

6) Mosfet: preferrably a logic level mosfet capable of 30v/10amp. FDS from Fairchild or those SOIC8 mosfets from Siliconix / Vishay are pretty good. OnSemi makes some too. You can also use regular mosfets, just make sure that their Vgs(th) is low (in the low 3v range): I used FDP3672 (3.2 - 3.4v Vgs).

[dannyf]

Code running on a 16F886: sign-on message, indicating firmware 1.04, temperature display in C (digit 4)

[dannyf]

Heater is being turned on, displaying current temperature, in 0.1C (or 0.1F if that is the display setting).

[dannyf]

Target temperature (235C) saved into eeprom: