new day, new problem (count function)

tercou1

Hi guys

I have a section of code that works perfectly, it measures one, two and three liters of water depending on what mode it's in... see attachment

current flow rate TEST-rotary.bs2

now the problem is that when i introduce this code into the main code... see attachment

MAIN program so far.bs2

the count function counts pulses but I can't seem to find any consistancy, unlike before, when I did the section of code on it's own, where am I going wrong? I would welcome any and all ideas, I have to have it finished by the end of the week!!

If you need any more info, just ask,

Terry

stamptrol

When you introduced the longer program, you built-in several ways for the program to take much longer to complete a single loop. It is very likely your program is missing many pulses.

A common method to deal with this situation is to have the pulses counted by a standalone counter which the Stamp can then interrogate when it is ready to update itself as to how much water has been delivered. There are several inexpensive chips which can be cascaded to give sufficient counting capacity for your application.

The alternative is to change the program to ensure the Stamp program can execute a full program scan in less time than occurs between flow pulses.

Cheers,

tercou1

stamptrol wrote: »

When you introduced the longer program, you built-in several ways for the program to take much longer to complete a single loop. It is very likely your program is missing many pulses.

A common method to deal with this situation is to have the pulses counted by a standalone counter which the Stamp can then interrogate when it is ready to update itself as to how much water has been delivered. There are several inexpensive chips which can be cascaded to give sufficient counting capacity for your application.

The alternative is to change the program to ensure the Stamp program can execute a full program scan in less time than occurs between flow pulses.

Cheers,

As you have probably guessed, this is my first project using a stamp, and your right I do seem to be losing a lot of pulses. I will have to use your second suggesetion because the circuit is already on PCB, how would you propose I do this? I just need a nudge in the right direction. Are you talking about a complete revamp of the code? or is it less drastic.

Thanks for the input so far

Terry

Mike Green

Read the description of the COUNT statement in the Stamp Manual or the Editor's help files. It counts pulses for a specified period of time. When the statement is finished, the Stamp ignores further pulses until another COUNT statement is executed. The Stamp is a "single-threaded" microcontroller. It does only one thing at a time. If things happen slowly enough, a program can be written with several functions interleaved. For example, servos require a control pulse about every 20ms. The pulse itself can take up to about 2.5ms to produce. If the program can perform other functions in the 17.5ms that's left, it looks like it's doing several things at the same time. If you're using a PING))) and a servo, the worst case time is over 20ms (18.5ms for the PING and 2.5ms for the servo pulse) plus the execution time of the statements in the program. Fortunately, servos can tolerate a little more than 20ms between pulses, but not much more. People solve this by getting a faster Stamp or an external controller like a ServoPAL.

stamptrol is suggesting either adding external hardware to remove the time-critical part from your Stamp code or rewriting your program to eliminate the time-critical portions.

Part of your problem is that you have a flow-meter that gives you a fluid flow rate (pulses per 100ms), but you have no time reference to compute the total volume. An external counter could give you that since the pulses actually represent a volume measure. You could also add a real-time-clock to give you elapsed time to the nearest second. If that's not a small enough unit, you could make your own clock with a crystal oscillator and counter to produce maybe a 100ms reference.

tercou1

Mike Green wrote: »

Part of your problem is that you have a flow-meter that gives you a fluid flow rate (pulses per 100ms), but you have no time reference to compute the total volume.

Thanks for the insight Mike, very intersesting... As for the pulses per 100ms (capture variable) that has been increased and I get a greater number of pulses but the totalpulses variable doesn't hold onto the total number of pulses whereas it does in the section on it's own (why is this), if I could get the total number of pulses to accumulate I wreckon my problem could be solved by recalibrating everything based on the number of pulses it takes to fill one, two, three liters etc.

Mike Green

You can't solve this problem without some additional hardware. Here's what's going on ...

In your test program, the program counts the number of pulses from the flowmeter for 100ms, then it does some computations and goes back (usually) and does some more counting. The computations and IF statement maybe take 10-20ms to execute and are relatively fixed in duration, so every 110 to 120ms, your program measures the flow rate and accumulates the pulse count. During the computations and IF tests, it's not counting and those pulses are lost, but most of the time (say 90%) the program is counting, so the total volume (total # of pulses) is pretty close to the actual water volume.

In your water meter project program, none of this is true. Your program measures the temperature. It displays things on an LCD. It operates a solenoid. It checks (and debounces) pushbuttons. It displays lots of debug information ... and it measures the flow rate for 100ms. The problem now is that all these other things take substantial amounts of time ... and the time varies widely depending on what the program is doing. Now the flow rate measurement period is a very small percentage of time that the program spends doing things as it cycles and that varies widely. Your program "knows" the flow rate, but it has no idea how much overall time is elapsing, thus the total pulse count is meaningless. The program has no real idea of the volume of water over time.

It would be possible to approximate the execution time of each section and subroutine in the program and keep track of this estimated time, then use that to calculate the total elapsed time and multiply that by the flow rate to get the estimated water volume. It's a lot of work. You can even account for the time taken by the DEBUG statements and the SEROUT statements for the LCD ... each character takes about 1ms at 9600 Baud. You can calculate the time used by the RCTIME statement based on the result value. You might want to do some averaging of successive time measurements because your time accounting is not going to be very accurate although it may be good enough for your purposes.

It would be a lot easier to use some kind of external time standard like this one. You have I/O pins to spare and you could add a piggyback real time clock module easily that would give you times to the nearest second. An SPI type interface would be the easiest to use.

For a discussion of Stamp execution times see this website. Click on the "app-notes" link at the bottom of the page.

Mike Green

The other option, if allowed by the project description, is to just forget the total volume and base everything on the flow rate, maybe keeping a running average over a large number of readings. There's no way to tell the total consumption, but you can estimate the consumption per day, week, or month based on the average flow rate.

tercou1

Mike your a gentleman, thanks ever so much for your time and effort, I have a much better understanding of my problem now. I can't express how much I appreciate it. Thank you, Thank you, Thank you