waitpeq with multiple pins

Sariel · 2012-01-19 10:47

I have looked around the old posts for a way to do this, and It seems not possible. has anyone figured out a way to use waitpeq with 2 inputs. Furthermore, can one use inputs stored as a variable do this? I was thinking of doing an XOR on the two, then making that the subject of waitpeq. I have tried this, but it seems to not do it's job:

CON
'' Clock settings
  _CLKMODE      = XTAL1 +PLL16X 
  _XINFREQ      = 5_000_000        

  LeftSW        = 23            ' actuator connections
  RightSW       = 18 
                                  
VAR
  long XORstuff
PUB Main
                                 
  XORstuff := LeftSW ^ RightSW
  waitpeq(|< XORStuff, |< XORStuff, 0)

'  <rest of program here>

Obviously, there is a lot more going on with my IO's, and I would want this line to make sure that the pins drop low, then continue on... I know I may be a bit confused, but at the end of this all, I would like to use this as a way to debounce 2 switches at once. Timing is a bit odd in my application, and using the standard waitcnt method of debouncing is not working right for me.

JonnyMac · 2012-01-19 10:54

Are you you just wanting to hold until there is a change of state on either of those two inputs? What about this?:

state := ina & SW_MASK
  waitpne(state, SW_MASK, 0)

Sariel · 2012-01-19 11:11

The left and right actuators are on sensors controlled by leaf switches that are hit when the operator puts a wire in both sides of the equipment. They are normally low, then toggle high briefly, then back low. I want my program to waitcnt's till they both go high, does some other work, then waits for them both to go low again, then continues from the top. Doing a waitcnt at the falling edge is causing me to either make false calls because it is too short, or skips steps because it is too long.

I wrote this bit of code as a quick example.... will post the real code in a sec. have to go to the other computer (and I see where waitpne is more appropriate for this)

JonnyMac: I am a bit confused by your example. How can that monitor 2 pins at once?

Sariel · 2012-01-19 11:24

here is the source. The area in question is in the top file, at the very end of the "MakeScreen" method.

Champ Tracker v304 - Archive [Date 2012.01.19 Time 13.21].zip

MagIO2 · 2012-01-19 11:28

Waitpeq and waitpne both use a logical AND to extract the bits from INA which are defined in the mask. The result is then compared with the state. WAITPEQ waits until the result is equal to the state and WAITPNE waits until the result in no longer equal to the state.

So, you can wait for all 32 pins if you want ...

Circuitsoft · 2012-01-19 11:29

Set SW_MASK to the bitmask you want to watch for on the I/O pins, so for pins 3 and 4 you would do %1100. WaitPNE will wait until the state of the two pins, defined by the mask is different from "state". If you want to wait until they both change, then:

state := (!ina) & SW_MASK
waitpeq(state, SW_MASK, 0)

MagIO2 · 2012-01-19 11:37

I think what you want is somrthing like:

CON
'' Clock settings
  _CLKMODE      = XTAL1 +PLL16X 
  _XINFREQ      = 5_000_000        

  LeftSW        = 23            ' actuator connections
  RightSW       = 18 
                                  
VAR
  long mask
  
PUB Main
  mask := constant( |<LeftSW + |<RightSW ) 
          
  ' .....                   
  waitpeq(mask, mask, 0)     ' this waits until both pins are 1
  ' .....
  waitpeq(0, mask, 0) ' this waits until both pins are 0

Sariel · 2012-01-19 12:08

Ahhhhhhhh... I think it is slowly sinking in. So, ina used without brackets does not define pins individually. It references the entire register that contains the pin data.

Yeah... MagIO2. that looks about right, and I think I understand what is going on with it. But alas, it is still not behaving. I think the machine I am interfacing to has a really screwy sense of timing, and my device is still missing some cycles. Now would be a good time to have an o'scope and be able to time it out better. I thought waiting for pin states would work better than an arbitrary pause, but this idea is falling apart too.

JonnyMac · 2012-01-19 12:48

JonnyMac: I am a bit confused by your example. How can that monitor 2 pins at once?

Sorry I was a little sparse -- thankfully, others gave you what you needed. That said... the Propeller manual is your friend (and available as a PDF from the IDE). If you read about WAITPEQ and WAITPNE you will find that you can monitor any number of IO pins with either.

MagIO2 · 2012-01-19 14:58

You should have a look at ViewPort from hanno. Allows you to sample pins with 80Msamples and shows the result in a nice PC GUI. Where is the need for a scope?
www.hannoware.com

JasonDorie · 2012-01-19 15:05

You may be having issues with what's called "bounce" - As a mechanical switch engages and disengages, there will be a period of time while the contact is scraping, jiggling, etc, causing many connections and disconnections in a very short period of time. Since the Prop is running -really- fast, it'll likely see them all.

The way to combat this is to wait for your first transition, pause for an amount of time large enough to let the mechanical transition happen, then wait for your next state change. This is called "debouncing" and it's a very common thing to have to do in code that deals with mechanical switches.

(Disclaimer - I haven't looked at your code, so I'm kinda guessing here)

kwinn · 2012-01-19 16:51

I think Jason has hit on your problem. Any mechanical switch will have contact bounce so you need to wait for that to settle. This will usually take some mSeconds. In most cases reading the input multiple times until you get the expected input several times in a row will do this.

Sariel · 2012-01-20 04:37

You may be having issues with what's called "bounce"

Yeah I thought of that right at the end of shift last night, and tried to put in a pause of a few ms before the waitpeq instruction, but it was doing the same thing. As for the o'scope, I would use it to see what kind of time frame I have to catch this sensor for the left and right actuator hitting, and try to time my spin accordingly.

little more background on my device...
We have been using a prop and the display to show the operator a list of colors to be terminated on this machine:
http://www.ebay.com/itm/AMP-SCSI-Champomator-2-5-terminator-crimp-machine-/300472508897It

It has 2 pneumatic solenoids that are toggled by leaf switches. When the machine senses a wire on the left and right side (if both are to be populated) the solinoids move crimp punches to push the wire into place. those crimp punches have 12v sensors on them (full schematic in the source) that detect for it's computer that it termed sucessfully. I am interfacing to those sensors so my device knows when to advance to the next color set. Operators used to have a clip board that told them the wire number/color to use next, but that was quite time consuming. I had one working well, but it was for a single product and I had to personally change the source on the prop in order to have a new product run. It is saving so much time that I am adding in an SD card so they can load different color lists from a txt file. They look on the screen and term. much faster than scanning an excel document for every wire pair.

Another feature is that they wanted to be able to go back a step in case they grabbed the wrong pair, the machine screwed up, or whatever. I am finding that adding the few lines in to scan the up and down buttons to go forward or back is putting a bit of a delay in there, and it is now missing cycles. I am not anywhere close to being able to do this in PASM, or I would just go that route.

I think for now I am going to experiment a bit more with the delay before the waitpeq.

Sariel · 2012-01-20 04:51

MagIO2 wrote: »

You should have a look at ViewPort from hanno. Allows you to sample pins with 80Msamples and shows the result in a nice PC GUI. Where is the need for a scope?
www.hannoware.com

Oh yeah. I have been drooling over that for some time now.... I think I have the wife convinced to unleash the purse a little to get me that software for home use. Unfortunately, the boss isn't convinced yet.

Sariel · 2012-01-20 05:43

EUREKA! (but I'm not running around the plant fresh out of a bath.. .wait.. that's a history lesson not for here). I think she is working now. I made the user have to push "Enter", then they are able to hit up or down to skip steps in either direction. This took a lot of the lag out of the program, then I completely eliminated the waitpeq statement, and just did a "waitcnt(clkfreq/3 + cnt)" statement just to purely debounce, and it just ran through twice without failure. And without a moment to lose. they are prepping for thier next work order now, and need this thing within the hour. Good lessons here:

1.) ina[1] references pins just like doing a "MiscVariable[1] catches the 2nd var in a group, just with bits instead of bytes, words or longs.
2.) waitpne and waitpeq are good. In the right context. This obviously was not the right context.

The architecture is making more and more sense every day.

Thank you for all of your help guys. Again, I learn so much every time I visit these forums, and even more when I talk to the Masters.

Lawson · 2012-01-20 09:04

Sounds like you're doing sequential logic for machine control. The tool to use for this is a Finite-State Machine run inside a scan loop that's paced to run every 10mS or something. Basically, your machine is always in one "state" that fully defines the outputs of the machine. To switch between states, each state looks at a limited number of input(s) and makes state transition decisions based on those inputs. This is a bit more work up-front, but results in reliable and predictable function of the machine. Using a state machine also makes alterations to the machine's logic easier as the state-machine diagram is easy for people to understand and the translation of the diagram to code is "mechanical".

Lawson

Sariel · 2012-01-20 10:43

The tool to use for this is a Finite-State Machine

I didn't think of it that way, but yeah, I guess it is a type of state machine. But that term has either confused me, or I am just wrong. Couldn't you classify anything as a state machine? By the link you gave, it is stated that...

It is conceived as an abstract machine that can be in one of a finite number of states. The machine is in only one state at a time; the state it is in at any given time is called the current state. It can change from one state to another when initiated by a triggering event or condition

It would be my view that logic gates are state machines, the propeller.... everything. That article goes on to say that even AI and Biology (I am sitting down. that is my state. but then my chair starts on fire, and I jump up, leaving me in a different state. Does that mean that I am a state machine?) to some degree can be identified as a state machine. Am I totally wrong with this, but isn't that the same thing as saying "A lemon and a tire are the same thing because they are both made of matter"?

..... not really a propeller discussion, but interesting none-the-less.

JonnyMac · 2012-01-20 11:16

You know, I forgot that I wrote a multi-input debouncing object some time ago -- I only remembered that I did when a friend asked me to review his program and was using it. This may be helpful to you.

-- http://obex.parallax.com/objects/489/

Lawson · 2012-01-20 12:06

Sariel wrote: »

It would be my view that logic gates are state machines, the propeller.... everything.

Everything electronic certainly uses state machines internally. I think that much of the work surrounding state machines was done so that designing chips with thousands of gates takes less than a lifetime and performs as expected.

Sariel wrote: »

That article goes on to say that even AI and Biology (I am sitting down. that is my state. but then my chair starts on fire, and I jump up, leaving me in a different state. Does that mean that I am a state machine?) to some degree can be identified as a state machine. Am I totally wrong with this, but isn't that the same thing as saying "A lemon and a tire are the same thing because they are both made of matter"?

..... not really a propeller discussion, but interesting none-the-less.

I guess, the finite state machine is a very general concept. It's a poor model for systems with a large/infinite number of states. I.e. a state machine for PID control would be hell to layout, much easier to just define the transfer function of the controller and directly use that. On the other hand, a digital combination lock would be easily described as a finite state machine.

The other good thing with state machines is that they don't halt execution. This property makes it easy to run several inside the same scan loop. (as long as there is time and no accidental variable name overlap) If I ever need to do more than 8 things at once on a Prop, I'll start making state machines first.

Lawson

waitpeq with multiple pins

Comments