A couple ideas for my reflow oven. Need advice, and input

TC

Hello all,

I am at my final design options for my reflow oven. And I have a few questions that need answered.

What parts I have now:
~ (2) 25A eBay SSR's, one for the top heater and one for the bottom
~ (2) MAX31855 thermocouple development boards, with K- thermocouples
~ Noritake 24x6 VFD display, running at 115,200 baud
~ Quad encoder with push select
~ SPDT button with dual color LED(2 leg)
~ eBay DS1307 real time clock with CR2023 back up battery (had to modify board)
~ eBay SD card adapter
~ 24LC512 EEPROM for Propeller main code and extra space

I will start with what I think will be the easy questions first.

Question 1;

The dual color LED (2 pin) I am using for lighting the SPDT button was salvaged from some product. I do not have the specs for the LED, so I went to DigiKey to get an average starting point on what the voltage and current could be. I went with 2.1V @ 20ma for both the red and the green die. From what I calculated, I needed 62Ω resistor for each die, and since each leg of the LED is going to a I/O on the prop, I split the calculated value in half, and I have (2) 33Ω resistors. One resistor between the prop I/O pin and the LED pin.

When I light up the red side (P0 = 1, P1 = 0) it is good and bright, but when I light up the green side (P0 = 0, P1 = 1) it is about half the brightness of the red side.

Is there anything I could do to make the green brighter? And what do you think is the problem?


Question 2;

I want this oven to have the ability to run different reflow profiles (even though I might just ever use one), and different heating profiles for testing. My first thought was to make up profiles that would be stored on the 24LC512. But then I wondered "How do I change them? or add another one?" So I came up with the idea of using a SD card to store the oven profiles, and the prop just read off the SD card. Another reason for the SD card is to be able to log the temperatures, time, etc.. for a profile, and copy it to a graph. I was thinking of using CSV format and "copy and paste" to excel.

What would be the best way to create and modify profiles on the SD card that the prop can read from and use? And what would be my best option for storing log data to the SD card?


Question 3;

Since I have the SD card for storing oven profiles (depends on last question) I have 32K of EEPROM space I am not using. So I figured I would use it for the ovens menu data. Maybe for any boarders, common strings, custom characters, etc... Stuff that does not have to be on the props 32K space.

What options for loading the extra half of the EEPROM do I have? How would you keep tract where everything is at and how much space is each thing (strings, boarders, etc) is taking up?


Question 3;

The RTC has a square wave output, that can be changed from 1Hz, 4.096KHz, 8(something)KHz, and 32(something)KHz. I was thinking of using that to my advantage. I was thinking of taking the square wave output from the RTC and hooking it to a prop pin (with a 150Ω in series). Then setting the output to 4.096KHZ and having the prop count the pulses. It would start at 0, go to 4096, then reset to 0. And it would add one to the counter every time the RTC would pulse its output. I was thinking of using one Cog to monitor the pulses and control the counter. and having other parts of the code just read the counter value from the the counter Cog. I was going to do this just so things would be synchronized. For example, I want the PID to update every 1/10 of a second. I want every cycle of my simple PWM (what I am calling it) to be one second. And I figured since the RTC is made to keep tract of time, why not off load that from the prop.

I know it could be a stupid idea, and a wast of time to peruse it. So that is why I am asking

Would off loading time tracking from the prop be a good idea? and if so, could the prop be able to read a pulse on a I/O, and increment a counter in spin?


Last question.

I thought it would be cool to have some way to monitor the RTC's backup battery. And if the voltage was getting low, inform me so I can change the battery. The board I got has a pin that hooks to the positive side of the battery. So with a meter, I can read the battery voltage. I was only thinking of reading the battery voltage only when the oven is turned on. There is no need to have the oven check the battery more than that. I don't want to add precision equipment just to check the voltage of a backup battery.

What ideas do you have for the prop to monitor the backup battery voltage?

Thanks everyone, and I am extremely sorry for all the questions. I am not asking anyone person to answer all of them at one time. Please answer any one of the questions you would like.
TC

T Chap

TC, different color LED's can have different brightness values. You experiment with two different R values. Or, you can find one value but use a PWM with reduced duty on the brighter color to average out the intensity.

If you have an SD card connected, you can create a file and write the time stamp or at least a starting minute/second stamp followed by the temp. You only need to log every second at a minimum, if not slower than that, 10 seconds for example. So you can have a predefined log length of 6 minutes at 10 second intervals on the eeprom or SD for later evaluation. 6 reads per minute, over 6 minutes is only 36 reads. If storing only a second timer 0 - 360 seconds(6 minutes), that is a word required per time stamp. If the temp is logged in F, that could be done in a word, so only 1 long per read, 36 longs required per 6 minutes stored to eeprom. You can then designate an imaginary partition on the eeprom for X number of data logs, and access the address with a simple incremental value. You can similarly designate a range of addresses for your profile storing areas. You have a lot of space to work with at 32k. The question then is how to write the value back to the PC to evaluate it. I would create a simple app in Xojo(Real Basic) that would read the values out from each log and you can even display it on a graph with some limited effort to implement a graph, however there are softwares available for plotting a graph that are not too much effort to set up. As far as keeping track of your eeprom data, that is very simple. Just define the addresses you want to start at for profiles, the define the starting address for logging, menus etc. You then increment through these "sections" to access the fixed length data. The other ideas mentioned seem way overkill for temperature purposes, except of course if those things are something you just want to learn and practice on. Temperature is a slow medium to monitor so having sync is not important. But in short, counting that pulse is easy. It is a simple matter to put an ADC on the battery.

Mark_T

and since each leg of the LED is going to a I/O on the prop, I split the calculated value in half, and I have (2) 33Ω resistors. One resistor between the prop I/O pin and the LED pin.

No need to do that, one resistor in series with the LED is fine. If you want separate resistors for
each polarity you'll need each resistor to have a 1N4148 diode in series, the two diodes in reverse
directions, then you can choose the resistors separately.

Or more simply use PWM to dim the red.

Would off loading time tracking from the prop be a good idea? and if so, could the prop be able to read a pulse on a I/O, and increment a counter in spin?

Use the RTC for reporting times into log files and the display, but for internal delays and so forth waitcnt() is
fine.

What ideas do you have for the prop to monitor the backup battery voltage?

Any attempt to monitor it is likely to drastically reduce its life, don't do this, just replace the
battery every 5 to 10 years.

TC

T Chap wrote: »

TC, different color LED's can have different brightness values. You experiment with two different R values. Or, you can find one value but use a PWM with reduced duty on the brighter color to average out the intensity.

I was wondering if I could use PWM that way. I have a couple MAX6957 collecting dust. It offers I/O expansion with content current outputs fro LED's. I could use it for the LED, the button, and for the SSR's to isolate the prop from a possible SSR short to mains voltage. I would rather fry it then the prop.

If you have an SD card connected, you can create a file and write the time stamp or at least a starting minute/second stamp followed by the temp.

Just a little FYI, because I forgot to post it.

Since I have 2 SSR's, and 2 thermocouples. I was going to create 2 heating zones in the oven. A upper zone, and a lower zone. That way I could use the oven with PCB's and heat shrink without the chance of "toasting" the heat shrink, by setting the upper heating zone to 0degs.

You only need to log every second at a minimum, if not slower than that, 10 seconds for example. So you can have a predefined log length of 6 minutes at 10 second intervals on the eeprom or SD for later evaluation. 6 reads per minute, over 6 minutes is only 36 reads. If storing only a second timer 0 - 360 seconds(6 minutes), that is a word required per time stamp. If the temp is logged in F, that could be done in a word, so only 1 long per read, 36 longs required per 6 minutes stored to eeprom. You can then designate an imaginary partition on the eeprom for X number of data logs, and access the address with a simple incremental value. You can similarly designate a range of addresses for your profile storing areas.

I was wanting to log the temperature every second. Don't really need a time stamp. Just at what second was the temp logged. And for logging the temp data, I was thinking of averaging the thermocouple outputs. I personally don't see a need to graph both temp readings.

Just wondering, what would be the benefit of storing the oven log data to the EEPROM, when I could just store it directly to the SD card?

You have a lot of space to work with at 32k. The question then is how to write the value back to the PC to evaluate it. I would create a simple app in Xojo(Real Basic) that would read the values out from each log and you can even display it on a graph with some limited effort to implement a graph, however there are softwares available for plotting a graph that are not too much effort to set up.

I took a very quick look at Xoio, and from what I can tell it must be bought. I really don't want to have to buy a program just for this DIY reflow oven. I will take I better look at Xoio when I get home tonight, and see if I can find a version that would work for this.

As far as keeping track of your eeprom data, that is very simple. Just define the addresses you want to start at for profiles, the define the starting address for logging, menus etc. You then increment through these "sections" to access the fixed length data.

What ideas do you(or anyone) have to keep track of the addresses? For example;

Within the prop IDE, I can make a DAT section with a name of things I want to store. Then I could just point to the name and get the data in memory. But with the extra space, I cant save stuff with a name. I have to use a address. What would be a good option to keep track of the addresses to put into my code?

Also, things being stored in the extra EEPROM are not going to be the same size. if I place a border around the out side of the screen, it is easier to send all 144 (24x6) characters first, then move the cursor to locations within the border. That would mean the border would use 144 bytes. But then I would also have strings that would vary in length. What would be some options to keep track of everything?

The other ideas mentioned seem way overkill for temperature purposes, except of course if those things are something you just want to learn and practice on.

I wanted this project to push me to learn more. I agree, most of the stuff is overkill. But whats the saying, "Go big, or go home".

Temperature is a slow medium to monitor so having sync is not important. But in short, counting that pulse is easy.

Also another thing I wanted to experiment with.

It is a simple matter to put an ADC on the battery.

would a ADC0801(or equivalent work)?

TC

Mark_T wrote: »

No need to do that, one resistor in series with the LED is fine. If you want separate resistors for
each polarity you'll need each resistor to have a 1N4148 diode in series, the two diodes in reverse
directions, then you can choose the resistors separately.

I like that idea, simple and to the point.

Use the RTC for reporting times into log files and the display, but for internal delays and so forth waitcnt() is
fine.

I was wondering if it would be fine to do. Plus, I would not have to worry about missing a pulse.

Any attempt to monitor it is likely to drastically reduce its life, don't do this, just replace the
battery every 5 to 10 years.

Also another thing I was wondering about. could the ADC drain the battery faster.

T Chap

TC, here is an example of something I did in Xojo years ago when I was messing with temp profiles. At one point I started adding a graph to the app so it could flip to a mode of looking at the profile versus the actual temp. Xojo is the coolest thing ever, especially for Prop uses having a very easy way to build interactive GUI's for projects.

TC

T Chap wrote: »

TC, here is an example of something I did in Xojo years ago when I was messing with temp profiles. At one point I started adding a graph to the app so it could flip to a mode of looking at the profile versus the actual temp. Xojo is the coolest thing ever, especially for Prop uses having a very easy way to build interactive GUI's for projects.

OK, now that is cool. I will diffidently look in to it a lot more.