RCTIME / Clear

melora

Hello,

First of all, I'm very new to this microcontroller, so if what I ask is stupidly obvious, forgive me, please.

I'm using a Basic Stamp 2.

I'm trying to learn to use RCTIME. I've connected the circuit as shown in the manual and loaded the example program RCTIME1.BS2.

It seems to work fine, most of the time; if I shine a light on the CdS cell, the number goes down, if I cover it, the number goes up. Well and good.

But if I cover the CdS cell well enough, for long enough, the number goes up and doesn't drop back again (shining more light on the surface makes the number drop some, but it remains much higher than it should). Like it's saturated or some such. Can I avoid this by changing the circuit and/or code?

And here is my second question: When the above state has been reached, I can reset from it by clicking on the Clear button in the Debug Terminal. The moment I click it, the numbers go back to what they were when I first ran the program. I haven't found any place in the manual where it explains what this button does, but it appears to restart the program. What is this Clear button doing?

Zoot

The "clear" button just blanks out the debug screen.

Post your full program as you downloaded it to the Stamp so we can take a look.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

melora

RC PIN 7
result VAR Word
Main:
DO
HIGH RC ' charge the cap
PAUSE 1 ' for 1 ms
RCTIME RC, 1, result ' measure RC discharge time
DEBUG HOME, DEC result ' display value
PAUSE 50
LOOP
END

Thanks for the info on Clear. That answered both questions, actually, because I realized that I needed to change

DEBUG HOME, DEC result ' display value

to

DEBUG HOME, DEC result, " " ' display value

If, for example, the system printed "123435" and the next result was "456", the screen would show 456435 -- digits were not getting blanked out... until I clicked on Clear. You answered both my questions.

Many thanks for your quick help.

Zoot

No problem. Actually, you might want to check out CLREOL (as in "CLeaR to End Of Line") -- this "clears" the entire rest of the line in the debug display following whatever was printed, e.g.

DO
DEBUG DEC SomeValue, CLREOL
DEBUG HOME
LOOP

This way no matter the text length of SomeValue, you won't see the old characters "ghosted". You can also format so that the output is always the same number of characters.

DO
DEBUG DEC5 SomeValue ' *always* prints 5 characters (digits), so 1 would print as 00001
DEBUG HOME
LOOP

See the formatters under DEBUG in the Pbasic manual.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

melora

Cool. CLREOL is just the thing. Thanks again.

erco

melora: Zoot done good! His solution is perfect and I'm glad it worked for you. What I think may have happened in your original program is that you have the perfect storm of delays in your example.

First, the PBasic editor's screen can't always keep up with the Stamp when there are a lot of debugs. Debug is a very slow command to execute, and it will bring any decent program to a crawl (so you always want to delete them or comment them out once your program runs as you intend). Sometimes the editor's communication rate lags the stamp's output, and the values displayed take a while to catch up. This time delay keeps getting longer, up to some max limit.

Second, the RCtime command takes longer to execute with a high resistance value (as when you cover the photocell) since it is measuring the time to discharge a cap through a higher resistance. This delay may be compounding your problem.

I suspect that once you uncover the photocell, you may get good data after some delay, up to the size limitations in the editor's communication buffer. Run your original program and try covering the photocell for short periods, then slowly and methodically increase the time it's covered, and I think you might just see this delay I'm rattling on about.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

melora

Good points. I hadn't thought about the communications delay, but the increased cap discharge time did occur to me. I'll try to keep those things in mind, so maybe, just maybe, I won't be so mystified next time. Thanks.