Need help with 255 Variable

[Joseph F]

I know never to allow a pwm to reach or exceed 255 due to the serout command. However can I create a variable and allow that variable to exceed 255? Also do i need to assign it as a word instead of a byte to allow it to work?

The reason i need this is for the pump delay I created. It currently uses 2 variables which both max out at around 240. The way its set up it gives me 11 seconds between times the pump cycles. The problem is I only lose 3psi in 11seconds from full (115 psi). I want to increase the delay without adding a 3rd variable.

Another question... With my current code the pump doesn't turn on until 11 seconds into the match (due to the variables counting up). Is there a way to start the variables at a certain value other than zero so that the pump turns on right away and then returns to its normal delay cycle?

[Mike Soukup]

You don't need to create a variable that's a word. If all you need is a counter, you can simulate a word with 2 bytes. You'll be able to count up to 65536.

pseudocode:

byte i, j

i = 0
j = 0


main loop:

if (i < 255)
{
i++
}
else
{
i = 0
j++
}

Mike

[Nate Smith]

Originally posted by Joseph F
I know never to allow a pwm to reach or exceed 255 due to the serout command. However can I create a variable and allow that variable to exceed 255? Also do i need to assign it as a word instead of a byte to allow it to work?

1. If you're exceeding 255 in any variable and don't want loss of data to occur, it needs to be a word variable.

2. The RC itself can handle any PBasic supported type of variable in your code. Where you run into the problem is if you try to put that variable in Serin or Serout. So, if the variable in question is in neither of these lines, you can do whatever you want with it.

[JHBurch]

>...can I create a variable and allow that variable to exceed 255? Also do i need to assign it as a word instead of a byte to allow it to work?

Never increment a byte variable past 255. If you do it will wrap around, i.e. 255+1=0. If you need to hold a larger number, declare it as a word. This lets you count up to 65535 before wrapping around to zero. One variable declared as a word takes up exactly the same amount of variable space as two variables declared as bytes.

If this still isn't enough, you can add a bit or two from another variable that you're not using all of. For example if you're using a byte variable for something that never gets higher than 15, declare it as a nibble instead (4 bits) and then use the other half of the byte to extend your count. Each added bit doubles how high you can count, but you'll have to increment it manually when you detect that your word variable is going to roll over.

>The reason i need this is for the pump delay I created.

Isn't there a pressure switch in the kit that you can feed back into one of the digital or analog inputs? Maybe someone else can add more details on this approach.

>Is there a way to start the variables at a certain value other than zero so that the pump turns on right away and then returns to its normal delay cycle?

Yes. Before your main loop you can initialize the variable to one less than the max number, that way the next time it gets incremented you'll turn on your pump and reset the count back to zero. Just make sure that the initialization statement is BEFORE "MainLoop:".

[Joseph F]

Thanks everyone for your speedy replies. I'll post what I did so that anyone else with a similar question or whoever is curious can see the program.

After posting I went into the stamp editor and created a test program. I checked back today for the answers and then double checked my program. I finally ended with...

in the Declare Variables Section
longpump Var word 'pneumatic pump delay


in the Initialize Inputs & Outputs Section
longpump = 870

Below the PWM Output Section I created a new Pnuematic Pump Delay Section In it read:

longpump = longpump + 1
if rc_sw1 = 0 then nopump
if p4_sw_aux1 = 1 then pumpon 'pump turns on when pneumatics fired
if p4_sw_aux2 = 1 then pumpon 'pump turns on when pneumatics fired
if longpump < 900 then waitpump
if longpump > 799 then pumpon
nopump:
longpump = 0
waitpump:
relay6_fwd = 0
relay6_rev = 0
goto pumpdone
pumpon:
longpump = 810
relay6_fwd = 1
relay6_rev = 0
pumpdone:


Since the delay was so long I added a feature that would automatically turn the pump on whenever I fired the cylinders. FYI our system only leaks about 3psi every 20-30 seconds which is why I needed such a large delay.. I may make it even larger.

My old code for anyone interested used variable coun and pump (both bytes) and read

'coun = coun + 1
'if rc_sw1 = 0 then pump_off
'if coun < 220 then pump_off2
'if coun < 250 then pump_on
'pump_off:
'coun = 0
'pump = 0
'pump_off2:
'relay6_fwd = 0
'relay6_rev = 0
'goto nextstep
'pump_on:
'pump = pump + 1
'if coun < 235 then extr1
'coun = coun - 1
'extr1:
'if pump < 220 then nextstep
'relay6_fwd = 1
'relay6_rev = 0
'coun = coun - 1
'pump = pump - 1
'nextstep:

(of course without the ' marks). It took the same amount of variable space but gave a much smaller maximum pump delay (only 11 seconds as set up, max of roughly 15-20 seconds)

[Joseph F]

i forgot to add. both these programs are tested and work as they are written in the manner in which they were intended. I have yet to find errors in either. (although there may be better ways of doing it).

[kmcclary]

OOC, Why are you using the delay method? We're given TWO sensors in this year's kit. You use both, and tie them to a pair of input bits. Simply set one to the high shutoff value you wish, and the other to the low turn on value.

Now your code is a couple line hysteresis routine, and you're done!

The code for this was given both in several threads here, as well as in one of the team updates.

- Keith McClary, Advisor, Huron High 830 Rat Pack

[Lloyd Burns]

One team near mine only got one pressure switch, so I helped them with a timer.

It sounds like the thread was started by some one using the pressure switch to turn off the compressor. What happens if you have a little leak and never get that high a pressure ?

Perhaps you should readjust the switch to turn _on_ the compressor at some user-selected lower pressure, and use the software timer to turn it back off. That way, if your pump can get the pressure above the low set point, the pump will turn off sometime, and you'll still have some pressure.

[Joseph F]

It sounds like the thread was started by some one using the pressure switch to turn off the compressor. What happens if you have a little leak and never get that high a pressure ?

Yes. I am using the switch to turn off the compressor. We don't have any trouble with leaks in our system currently, in fact it takes us roughly 20-30 seconds to lose 3 psi due to leaks. The compressor can easily overcome that to fill the system. Plus if we do use the pressure switch to turn on the compressor and a timer to turn it off, what happens if we misjudge the timer? The system will go above 120psi and the safety valve will pop (and i believe the valve is a one-use valve). I may be wrong about the valve, but thats my current understanding.

OOC, Why are you using the delay method? We're given TWO sensors in this year's kit. You use both, and tie them to a pair of input bits. Simply set one to the high shutoff value you wish, and the other to the low turn on value.

Sodder breaks, programs don't. I am worried with 2 switches that its twice as much sodder that can come lose and cause a wire to slip out messing up the system. In a 2 switch system if the high switch loses connection the system will cycle at the low pressure. If the low switch loses connection the pump will cycle at the high pressure. This can overheat the pump and kill the battery very quickly. In a single switch system if the switch loses connection the pump shuts off. While this does lose all our pneumatics for that round, we aren't totally dependent on them and can do quite a bit without them.

[thedillybar]

If you exceed 120 psi, the valve starts leaking. When you drop back under 120, the valve closes again.

[Joseph F]

If you exceed 120 psi, the valve starts leaking. When you drop back under 120, the valve closes again.

thanks for the clarification.

[kmcclary]

Originally posted by Lloyd Burns
One team near mine only got one pressure switch, so I helped them with a timer. [...] What happens if you have a little leak and never get that high a pressure?

If the leakage is THAT bad, you've got OTHER problems! But to answer your question, the compressor keeps running, and the overpressure valve keeps you limited to 120psi. In any case, two minutes of the compressor running and popping the safety valve isn't going to kill you, nor your battery.

Perhaps you should readjust the switch to turn _on_ the compressor at some user-selected lower pressure, and use the software timer to turn it back off. That way, if your pump can get the pressure above the low set point, the pump will turn off sometime, and you'll still have some pressure.

Now it DOES makes sense to use a timer as a failsafe, but it is really not necessary for normal operation. You can simply limit the maximum on time of the pump for any one "air request" and lock it off until either a pressure switch toggles, or a driver "manually override resets it" by some action on the OI such as running an unused thumbwheel up and down once.

Originally posted by Joseph F
[Solder] breaks, programs don't.

LOL! You never heard of a program breaking under "unexpected conditions"??? It's called a "bug". (Maybe he's never programmed, nor tried to run a Microsoft product before... ). Seriously though, in industry we more often use HARDWARE to protect us from SOFTWARE bugs than the other way around! Most of the time for cost savings Consumer software only does "sanity checks" to keep an eye on the hardware, and simply alerts the user to problems. In military and automotive programming though we do often spend the extra time, money, and effort to try to "program around failed hardware".

{I'm worried about [solder] joints failing, and here are the failure modes} [...]

Actually, a good solder joint is VERY reliable, as long as you have a good mechanical initial connection before soldering, and strain relief on the harness. In fact, they'll normally far outlast the rest of the system (including the computer) by decades!

BTW... That's not how a two switch system works, nor how it would fail.

You have a one bit variable as a "memory", that decides if the pump should run or not. It will be sent to the pump control at the end of each main loop. For system insurance in case everything fails, you initially set it to ON in the initialization routine so in the absence of any other signal it tries to start up.

During the loop, the High switch turns the pump bit OFF when pressure EXCEEDS it's setpoint. The Low switch turns it ON when it drops BELOW its set point. Between it the "memory" keeps the same condition. This gives you your hysteresis. The Low and High switches are set at something like 110 and 120 PSI respectively, so if you have a failure mode that causes an oscillation around EITHER ONE, you're still fine.

Seriously though, you're talking only TWO solder joints per switch. That's EASY to inspect. You can use input bits on opposite ends of the connector if you're nervous. If you're uncomfortable soldering, just let someone who is used to doing it make the joints. Now for the switch, just make sure you add some lock washers under the switch screws, and that will be secure.

If I remember correctly, these are normally closed switches that open when you exceed the pressure on a diaphragm. Switches CAN fail open or closed mechanically, but the most likely failure mode will be open from a loss of a connection, with a failed closed condition from a diaphragm break in the switch running a FAR second place. These switches are designed for millions of operations, and the mechanics in them don't break often.
Shorted electrical connections would normally be obvious during testing.

Let's look at the failure modes:

CASE 1 - HIGH switch disconnects or fails OPEN: depending on which switch is checked first in your logic, the pump either never starts up, or the pressure oscillates around the low pressure switch's pressure. Assuming you've set the low switch to something like 110 PSI (10 PSI hysteresis), if it is oscillating around that value you've still got FULL pressure to do things because the rules say your pneumatics must run at 60 PSI max. However you ARE allowed to start with full pressure, so if you set the logic so that this mode causes full failure and this happened before the start of the round, you'd notice your pump wasn't running then and have a chance to fix it. If it happens DURING the round and your pneumatics are only used for deployment and not motion, then given enough air storage you may not even NOTICE things stopping! Either way, no robot damage.

CASE 2 - HIGH Switch shorts or fails CLOSED: The pump keeps running, and the safety valve keeps popping, limiting the pressure limited to 120 PSI. That is noticeable, but your robot keeps running just fine. This won't damage the pump. For two minutes, since it won't even stall the pump from overpressure, it probably won't even impact your battery significantly. No robot damage, and you keep running just fine.

CASE 3 - LOW Switch disconnects or fails OPEN: Depending on the logic, either the pump never starts up, or else you go up ONCE, but never turn back on again after the first fillup when the pressure comes down. Similar situation to Case 1.
No robot damage, and you may not even notice it at first.

CASE 4 - LOW Switch connection shorts or fails CLOSED: The pump will run up to the high pressure once, then oscillate around the high pressure switch. This case DOES use up more battery, but again you've got full pressure so the robot runs fine. As before, no damage, and this would be noticeable on the Tether so you can correct it for the next round.

NONE of these situations are destructive to the robot, and you can operate just fine in several of them. You can INSTANTLY tell which switch failed by the pressure it oscillates around, if it doesn't restart, or it doesn't shut off and pops the valve.

If you've added enough air storage, and only use the pneumatics for "deployment" instead of something cyclical like "walking", there's a good chance you may not even run out of air before the round ends.

I still feel two switches is MUCH simpler. However, I do like your concept of using timers to limit effects as a backup.

Of course if you wish (and are REALLY bored), you can always review each case, and create the logic to test and handle error cases. For example, if you see the LOW switch thinks the pressure is too low AND the HIGH switch thinks it is too high, something is not right. Watching which one the pressure toggles around tells you the OTHER switch failed, and you fall back to a timer method using the good switch. The two switches now gives you REDUNDANCY.

But that makes the whole simple thing complicated again! The point here is that using two switches is SIMPLE, and it won't damage anything in ANY of the failure cases.

If you are REALLY worried about an automatic pressure control failing, then simply give your driver an "override switch". You run a "monitor" timer in the RC, and have it turn on a driver's LED if the program thinks the pump "has run too long". The driver then has an ON/OFF/ON SPDT Override Switch for manual pump control. Run the center to ground, and each of the two ends to to an input bit on the OI. Center = "Automatic", up = Manual On, and down = Manual Off. You can also do this with an unused thumbwheel as well by dividing its possible position value into thirds.

- Keith McClary, Advisor Huron High 830 Rat Pack

[Joseph F]

LOL! You never heard of a program breaking under "unexpected conditions"??? It's called a "bug". (Maybe he's never programmed, nor tried to run a Microsoft product before... ). Seriously though, in industry we more often use HARDWARE to protect us from SOFTWARE bugs than the other way around! Most of the time for cost savings Consumer software only does "sanity checks" to keep an eye on the hardware, and simply alerts the user to problems. In military and automotive programming though we do often spend the extra time, money, and effort to try to "program around failed hardware".

I wasn't talking about all programming. I'm talking specifically about the robot program. The conditions of the match shouldn't be far enough outside the realm of normal capabilities that it would cause the program to crash.

Actually, a good solder joint is VERY reliable, as long as you have a good mechanical initial connection before soldering, and strain relief on the harness.

Given the specifics of the competition odds are a wire will be ripped off long before the program gets confused enough to crash. Plus we dont have anyone who actually 'knows' how to sodder propperly, so our joints are probably sub-standard.

If you are REALLY worried about an automatic pressure control failing, then simply give your driver an "override switch".

I did program in an ovverride that turns the pump on whenever the pneumatics are fired. As for a manual on/off/auto switch its a good idea I hadn't concidered. I'll probably set up as much of it as I can until I actually get the robot back.

You can also do this with an unused thumbwheel as well by dividing its possible position value into thirds.

A good idea, unfortunately our control board has all but 1 switch in use currently. I programmed in a turn corrector controlled by our last availible wheel (our robot turns right for some odd reason).

Of course if you wish (and are REALLY bored), you can always review each case, and create the logic to test and handle error cases. For example, if you see the LOW switch thinks the pressure is too low AND the HIGH switch thinks it is too high, something is not right. Watching which one the pressure toggles around tells you the OTHER switch failed, and you fall back to a timer method using the good switch. The two switches now gives you REDUNDANCY.

wow. um. I am going through robot withdrawal currently but I havn't achieved that level of desperation just yet.... Actually its probably not as bad as it sounds, but of course this would assume I put in and soddered up the second switch. I might write the program for this eventually anyway, just for future refrence.

Thanks for all the help. I'll be printing out this thread eventually to keep all this usefull information.

[kmcclary]

Originally posted by Joseph F
The conditions of the match shouldn't be far enough outside the realm of normal capabilities that it would cause the program to crash.

I've never seen the robot program actually CRASH before. Stuck in infinite loops maybe, run out of time and miss a packet maybe, but have you actually had the computer CRASH on you?

What I'm talking protecting against in a program are LOGICAL errors. For example, if a timer variable is not checked correctly, it wraps around (overflow/underflow) forever and therefore never switches things to the next state.

Given the specifics of the competition odds are a wire will be ripped off long before the program gets confused enough to crash.

Hmmm... Well, that may or may not be true, because boy oh boy, have I seen some real doozies that passes for "software" in my day... ... But, you've got a very good point that this IS a physical event and wiring COULD get ripped out. That's why we tried to run things where any Battle Bots present couldn't get at them. You'd have to break the chassis apart (or go at it with diagonal cutters in the cranny of some L-channel from the INSIDE of the robot) to get at some of our wiring.

Plus we dont have anyone who actually 'knows' how to sodder propperly, so our joints are probably sub-standard.

Have your Electronics teacher check your work. If HE (or SHE) can't tell a good from a bad soldering joint, you've got OTHER problems at your school...

(BTW... it is "soldering", not "soddering"... )

Here are a few links for you on soldering to get you started:
http://www.circuittechctr.com/guides/7-1-1.htm
http://www.epemag.wimborne.co.uk/solderfaq.htm
http://www.aaroncake.net/electronics/solder.htm
There are lots more good references on the web. BTW, for practice, I'd recommend simply taking an old PCB and some wire out of some dead home electronics appliance or toy, and solder wires onto it anywhere until you're comfortable that you can attach and detach a wire cleanly to a board or a connector.

I did program in an ovverride that turns the pump on whenever the pneumatics are fired.

What turns it off? Only time, or does it go back across the high pressure setting then run the clock again? BTW, watch out for the logical possibility of the pump trying to switch on from your override, then off because the high pressure switch has not responded yet due to lags and thinks it is still "at pressure now", then back on again once the pressure switch responds a fraction of a second later. That quick "ON/OFF/ON" cycling COULD stall the compressor if the back pressure is too great from the first short "on" burst.

As for a manual on/off/auto switch its a good idea I hadn't concidered. I'll probably set up as much of it as I can until I actually get the robot back.

If we're allowed to do it NOW (are we?), I'd just recommend making a switch with a connector on it to plug in to an unused OI port (or if you don't have an unused one make a male & female "feed through" connector to stick in series with one of the current joystick connectors to tap off the AUX1 and AUX2 pins you need for the switch). I'm not sure if that is legal now that the six weeks is over. Someone please comment on that.

BTW, we planned ahead JUST for THIS kind of problem. Our auxilary control box brought out a LOT of extra signals "just in case". We're only using three of the ports, so we fanned out an ENTIRE port connector (4 pots and 5 bits) onto a terminal strip in our Aux box, so in case of emergencies like this one we already have extra controls available and wired at our panel, ready to instrument program fixes. If we need a new control at the contest site, we drop another pot or switch of the right type with short wires hanging off the back into the box panel, connect the wires to some unused bits on the terminal strip, label it in magic marker, and just USE it... NO soldering required. All of the rest of the current controls (other than Flightsticks) are also taken to lugs and a terminal strip inside the Aux box, with spare wire length, so we can move things around to reassign them to ANY aux channel, if necessary, in only seconds. Theoretically, other than punching the new hole for the control in the box, ANY control mods OR ADDITIONS should only take minutes on site.

A good idea, unfortunately our control board has all but 1 switch in use currently. I programmed in a turn corrector controlled by our last availible wheel (our robot turns right for some odd reason).

You've used up ALL FOUR PORTS??? WOW! You must be controlling an OCTOPUS!

Does that include fanning out the extra pot and the two aux bits for the CH Flightsticks as well??? (A port has four pots and four digital bits, but a CH Flightstick only uses three pots and two of the bits). If so, that's a LOT of controls!!! (SIXTEEN pots and SIXTEEN bits!) If not though, you've got two extra bits and an extra pot available on EACH joystick that you can tap. Add an "inline feedthrough" connector (male/female pair) to a port which just brings each wire across to its counterpart for the original device plugged into it, and tap off whatever signal you need. FRCtech2002 ruled we can secure wiring with hot melt glue, so encase the entire thing in hot melt to form an insulator and make a "brick" out of it. Now you can tap into ANY unused signal pin without disturbing the thing orignally plugged into it.

wow. um. I am going through robot withdrawal currently but I havn't achieved that level of desperation just yet....

<chuckle>...

Actually its probably not as bad as it sounds, but of course this would assume I put in and soddered up the second switch. I might write the program for this eventually anyway, just for future refrence.

As I said, the program is already written for you in Team Update #5. It is only a TWO LINE program! (Plus a couple of aliases...) Just drop it in now, assign the right input bits for it, and comment it out for the time being so it's ready to roll if other things don't work out.

Thanks for all the help. I'll be printing out this thread eventually to keep all this usefull information.

Hey, no problem! Although this is our team's first FIRST contest, I've been a professional programmer and a robotics hobbyist for a LOT of years. If there is anything else I can do to help, please feel free to drop me a line.

Later!

- Keith McClary, Advisor Huron High 830 Rat Pack

[CaptainPlaid]

The auto/off/on option is a very good one. We have used it the past two years and it is very useful. I did it this year by using a two-position rotary switch for the Auto/Off selection. (The rotary switch was solely for looks. A toggle switch works fine.) Use a momentary pushbutton for the On function. This is useful if you lose a pressure switch (which I have never had happen) and also for testing things in the pits. If you are testing out the drive train and don't want your pump coming on every 20 seconds you can switch it to off. You will also want to use a momentary switch for the On function so you do not inadvertantly run the pump all the time. Check out our control system here. This is the code I use for the OI pump control:


if sw_pump_auto = 0 then end_override: 'OI Pump Switch set to Automatic (UP position)
if sw_pump_on = 1 then run_pump: 'OI Pump ON Override Switch is pressed

pump_on = 0 'OI Pump Switch is Off
goto end_override:

run_pump:
pump_on = 1
goto end_override:

end_override:



As far as one pressure switch or two we started this year with two and decided to go with one for weight. (Hey, 15 lbs over with cause desperate measures.) Regardless, we have noticed no change in performance. Here is the code we use for the one pressure switch control:



'Pressure Switch Program adapted from David Mittelman
'This program will allow us to bring the pressure up to 120psig
'and at the same time not overwork the pump
'For this program to work to variables need to be declared and have the following values:
'lastpressure = 1
'pneum_counter = 0

relay1_rev = 0

if pressure_115=0 then switchopen: 'Is the switch closed right now?
pump_on = 1 'compressor on
goto endroute: 'goto A
switchopen:


if lastpressure=0 then nochange: 'Was the switch closed before?
pneum_counter = 0 'reset counter
goto endroute: 'goto A
nochange:


if pump_on=0 then endroute: 'Is the compressor even on?
if pneum_counter < 220 then pumpitup: 'Is the counter equal to the time?
pump_on=0 'compressor off
goto endroute: 'goto A

pumpitup:
pneum_counter = pneum_counter + 1 'increments counter

endroute: 'A
lastpressure = pressure_115 'lastpressure = Switch value



I hope this helps. Any questions, post them here.