Pollmode question

Bob - Fremont

Hello everyone,

I am relatively new to the Basic Stamp but am moving right along.· I have a question about the Pollmode command.· The documentation is somewhat confusing.

I am monitoring four (4) switches (bits 4,5,6 & 7) and need to keep track of which switch event occured last.· The switches will not be on for very long so It seems that Polling is the way to go.· I will periodically read the value in memory location 128 to find out which switch was last pressed.· Regarding the Pollmode, which mode should I use to keep memory location 128 constantlyy updated as the switch events occur.· In other words, do not disable Polling until I intentionally issue a Pollmode 0 command later in the program.

Any help will be greatly appreciated.

·

Tracy Allen

POLLMODE 10 will cause location 128 to latch POLLIN switch events, even brief events,so long as they span two PPBASIC instructions. But it won't tell you the order of occurance. The program might find from scatchpad location 128 that switch p4 and p7 have both been pressed in the past 2 seconds, but not which came first. To sort that out, the program will need to read the inputs more rapidly What are typical timing values for your application?

Here is an essay on POLLING: www.emesys.com/BS2poll.htm

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Bob - Fremont

Hi Tracy,

Thanks for the quick reply.· Long time durations will pass between the switch events, probably 15 to 20 seconds.· The event will only last a short duration, probably around 250 ms (as the pillow block passes by a photosensor.· This is an elevator loading system for silicon wafers where the elevator will lift the wafer loader to the appropriate tube height·on a diffusion furnace, and then load the wafers into that furnace tube.· The operator will select which tube #.· I'm keeping track of what direction the loader is traveling and which sensor·was last passed in order to decide which direction to turn the motor the next time·a different location is selected by the operator.

I thought Mode 10 was Mode 2 + 8 (deactivate), but I juust realized it's actually Mode 3 + 8.

Thanks again for your help.

Bob H·

Bob - Fremont

Well, I'm obviously doing something wrong; Here's what I've got.

SENSOR1 CON 4
SENSOR2 CON 5
SENSOR3 CON 6
SENSOR4 CON 7

MAINIO
POLLMODE 0 ' CLEAR POLL MEMORY LOC AND DISABLE POLLING
POLLIN SENSOR1,0 ' INTERRUPT WHEN TUBE 1 IS PRESSED
POLLIN SENSOR2,0 ' INTERRUPT WHEN TUBE 2 IS PRESSED
POLLIN SENSOR3,0 ' INTERRUPT WHEN TUBE 3 IS PRESSED
POLLIN SENSOR4,0 ' INTERRUPT WHEN TUBE 4 IS PRESSED
POLLMODE 10

MAIN:

DEBUG "INB = ", " ", DEC INB 'INB CHANGES TO A VALUE EQUAL
' TO WHICHEVER SWITCH I PRESS

GET 128,CURRENT_POS ' GET BYTE VALUE OF LOC 128

DEBUG "CURRENT POSITION IS ", DEC CURRENT_POS

GOTO MAIN:

On the Debug line that prints INB, everything looks fine. While it's looping, the value changes as I press different switches.

However, whichever switch I press first (16,32,64,128), that value shows up on the Debug line showing Current_Pos. That first value never changes regardless of which subsequant switches are pressed. If before the GOTO MAIN: line, I insert a POLLMODE 10 command, location 128 resets to zero and then changes to whatever key I press and stays there until I let go. Then it resets to zero until I press another switch. I'm trying to make it retain the value of the last switch event until the next event occurs.

Like I aid, obviously I'm doing something wrong but it's not obvious enough for me to see it. Any hints?

Regards, Bob

Tracy Allen

Hi Bob,

That's great, when the Stamp shows up in the center of the high tech producton plant!

Mode 10=8+2 is in fact like mode 2, except the events are latched.

250 ms is a long time, long enough that a polling loop wrtten in PBASIC might work fine to sort out the order of events.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Bob - Fremont

Hi Tracy,

Does that mean I can not accomplish what I want using the Polling function?

Bob

Bruce Bates

Bob -

I think what Tracy is saying is that it should work fine, but I don't want to put words in his mouth :-)

If PBASIC POLLING doesn't work out for you for some unforseen reason, you might want to look into using a Priority Encoder (see attached). A Priority Encoder accepts multiple inputs, and produces as its output the actual number of the last, highest priority,·active input. Once that number is fielded, the chip is reset, and it's ready to field the next active input.

I realize that the priority part is·not essential to·your criteria, but that's just the way this chip happens to operate. Due to the prioritization, data collisions are avoided. I hope you find this chip helpful.

Regards,

Bruce Bates


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->

Bob - Fremont

Thanks a lot! I got it all sorted out. Using some if-then statements, I'm able to keep the last switch event without it being overwritten by a zero in between switch events.

Thanks again,
Bob

Tracy Allen

Hi Bob,

Yes, that is the way it works--Location 128 only identifies the first switch to be activated. What I meant by my previous post is not that POLLMODE 10 won't work, but that it might not be necessary. POLLMODE 10 is most useful when the pulses are on the order of a a milliseconds long, so there is danger that an ordinary polling loop would miss them. There are other tricks possible with even shorter pulses, using a capacitor or RC circuit on the input as a pulse stretcher. But that is a moot point here, because the 250 millisecond pulses from your switches are quite long with respect to the millisecond timing of the Stamp.

A lot depends on what other tasks your program has to accomplish while it is waiting for input from the switches.

I use the POLLING functions most often with POLLWAIT. The following is an example loop, that might be used when the Stamp only has to detect the switch action, with the added benefit that the Stamp operates at minimum power consuption while it waits. The program sets up polling on port inB, and then enters a loop where it spends most of its time sleeping in the POLLWAIT command, and it only executes the rest when a button is actually pressed. Note that there is no POLLMODE command within the loop. I use this kind of loop to synchronize my data logger with a periodic real time clock interrupt. Something like a rain gage or the occasional switch can go into the same loop.

SP128 VAR NIB
SP135 VAR BYTE

POLLIN 4,0
POLLIN 5,0
POLLIN 6,0
POLLIN 7,0
POLLMODE 2   ' can use either mode 2 or 10, either works the same

DO
  GET 128, SP128   ' use this location to sort out which event caused wakup
  DEBUG BIN4 inB, TAB, BIN4 SP128, CR
  DO : LOOP UNTIL INB=$F   ' wait for all keys to be released
  POLLWAIT 2   ' sleep and wait in cycles of 60 milliseconds until a swtich is pressed
LOOP

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Tracy Allen

Alternative...

Here is an ordinary polling loop that looks for a change in the state of the switches, and retains the most recent value. This works so long as the subroutine "states" is executed at least once every ~200 milliseconds, in order to catch the transitions. The rest of the time the program can be occupied with other tasks. You indicated that the switches would close for ~250 milliseconds at ~30 second intervals.

old VAR Nib
new VAR Nib
recent VAR Nib
change VAR Nib

old = ~inB   ' read inverse of switch state 
DO
  GOSUB States
  IF change THEN DEBUG  BIN4 recent  ' show only when changed
  ' other tasks here
LOOP

States:  ' detects and retains most recent switch
  new = ~inB   ' read inverse of switch states
  change = new ^ old & new  ' nonzero only when a bit has changed from 0 to 1
  old = new
  IF change THEN recent = change   ' retain the most recent switch activation
  RETURN

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Post Edited (Tracy Allen) : 6/28/2006 7:39:07 PM GMT

Bob - Fremont

and still thanks again.

I think your second idea is best for me. Although I described my situation as being very simple, I do need to keep track of several ofther issues like, fault inputs, up/down/in/out directions, I/O between the stamp and the higher level control system etc. Also, I do need to react very quickluy when the Polled event passes the sensor where I want the motor to stop at. I can not tolerate very much delay here. Probably 5 to 10ms, maybe more. The DC motor I'm using does have a brake which seems to work well if I apply the brake at the same time I de-energize the motor. So, as long as I react quickly to turn off the motor when my polled event matches my desired location, I should be ok.

Based on the timing tests I've done so far, it seems I should have no problem. As things stand now, I've fabricated circuit boards with all of the driver chips and IO connectors. All the IO signals are going to and from keypad switches and LEDs. Since the Elevator Systems are still being fabricated, I really won't know for sure how everything works until we get down to imperical testing on the actual systems.

BTW, if there a document anywhere which summaraizes the time it takes to execute certain operations? This would be helpful for me to get a better handle on this whole stamp thing. For example what are the timing differences between IF/THEN and CASE/SELECT etc. etc.

One more thing; You've been extremely helpfull getting me through this problem and I expect I'll have a lot more questions before this project is finished. I intend to use this product as often as I can since there's nothing more helpful than support from knowledgeable and willing compadres. Also, as I become more familiar, my questions will be less and less (I hope!).

Harbor

Bob Fremont said...
BTW, if there a document anywhere which summaraizes the time it takes to execute certain operations? This would be helpful for me to get a better handle on this whole stamp thing. For example what are the timing differences between IF/THEN and CASE/SELECT etc. etc.

Lest Tracy be too modest, let me answer that, Bob.·Tracy probably knows as much about the execution characteristics of the Basic Stamp family as anyone outside the labs in Parallax. Here is a link to his page on execution timings:

http://www.emesystems.com/BS2speed.htm

You will find a lot more useful information there. Tracy's site is almost essential to using the Stamps for professional quality solutions. I was just visiting there tonight to remember what he has said about Stamp behavior in re-chargeable battery systems, where brown-outs may occur.

I'm guessing all this detailed knowledge came from using the Stamps in your company products, Tracy. Whatever the motive, I thank you. In the few early instances where I double checked your results they were dependable, so now I just use them. (Since we are not using Stamps to generate revenue here. Just enjoyment.)

Thanks for publishing all that data. Much appreciated.

Bob - Fremont

Tracy's site definitely answers a lot of my questions.

After browsing through the posts in this forum, it seems you are guys are like a close knit family. Refreshing!

Can anybody tell me the most complex project the Stamp has ever been involved with? The only reason I ask is because when I first embarked on this mission, I wondered if the Stamp had the horsepower to accomplish what I needed. As time goes on, I'm realizing that my task is a very simple one which could probably have been accomplished with a simpler and cheaper device. Of course, the support I've received in just a couple days certainly adds to the value. In fact, that's the reason I ask my question so that I can evaluate the true value of the Stamp. It seems I really underestimated it. I have more projects coming up where I think I will stick with the Stamp.

Tracy Allen

Thanks for the kudos; appreciated! Some of the pages on my site are old now, now that there are more Stamps and PBASIC 2.5. The PBASIC 2.5 commands SELECT-CASE are not listed in the timing page. However, those commands are really built up out of the older commands, for example, SELECT-CASE is parsed by the STAMPW IDE into simpler commands of IF-THEN-GOTO with internally created branch addresses, and that is what gets RUN into the Stamp. There is more about that translation at www.emesys.com/BS2pbasic25.htm. The multibank Stamps like the '2p do in fact have some new commands, like AUXIO and POLLing and the special i/o commands like I2C.

These fora are indeed a close community with both old and new members. It always amazes me, the interesting projects that people take on and actually do get working. One example of the community spirit and a complicated project is the milling machine thread in the Sandbox forum, now grown to over 500 posts. http://forums.parallax.com/showthread.php?p=539099

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com