Programing help...

Posted by Adam Anderson.

Student on team #236, Lyme Old Lyme High School, from Lyme Old Lyme High School and Northeast Utilities.

Posted on 1/22/2000 2:07 PM MST

I am a student programer, and i am looking for a way to do a timer in the stamp to fire a motor for a certian amount of time, but i am at a loss of a way to do this, i thought i would create a counter that counts the cycles of the program, but i can not find out how many cycles per second that the controlers CPU can do… anyone have any info on this method or any other methods that could accomplish this task…
-Adam Anderson-

Posted by Joe Johnson.   [PICTURE: SAME | NEW | HELP]

Engineer on team #47, Chief Delphi, from Pontiac Central High School and Delphi Automotive Systems.

Posted on 1/22/2000 4:59 PM MST

In Reply to: Programing help… posted by Adam Anderson on 1/22/2000 2:07 PM MST:

I have not looked at the code this year, but I think that the concept is still the same in 2000.

Basically, your data packet sent by the operator interface has a time stamp that tells you how many data packets have gone by since the last time you got a data packet.

Actually, I think that it is a combination of the operator interface CPU and the ‘Master’ CPU on the robot interface that puts in the DT into the data packets available to the ‘Slave’ CPU (the Basic Stamp 2 chip).

Anyway, to implement a kind of rough timer, you can increment or decrement a counter by DT every time through the loop.

As to the exact time through the loop, this is not as easy as it might seem. One way to get an estimate is to have the counter count to 1000 or so and then time that. If you have an oscilliscope then all you have to do is toggle an output each time through the loop and read the time directly. Other methods exist as well.

A word of caution: If your program depends on precise timing you may be asking for trouble.

Good luck.

Joe J.

Posted by Quentin Lewis.

Engineer on team #42, P.A.R.T.S - Prececision Alvirne Robotics Technology Systems, from Alvirne, Hudson NH.

Posted on 1/22/2000 6:27 PM MST

In Reply to: Programing help… posted by Adam Anderson on 1/22/2000 2:07 PM MST:

> I am a student programer, and i am looking for a way to do a timer in
> the stamp to fire a motor for a certian amount of time, but i am at a
> loss of a way to do this, i thought i would create a counter that counts
> the cycles of the program, but i can not find out how many
> cycles per second that the controlers CPU can do… anyone have any
> info on this method or any other methods that could accomplish this task…

Well, you could toggle an output every time through the loop and measure it with a scope…and therby GROCK the time to go through the loop.

If you don;t have a scope, you could set-up a variable and toggle an output every 1000 times through the loop…or even every 32000 times through the loop…you might be able to measure that time with a stopwatch, and then you divide by 32000 to give you the time each loop takes to execute.

Be aware that these times change as you add or subtract from your program…so you might need to keep this ‘calibration’ factor in there (commented out) in case you need to recalibrate it later on.

I would not rely on tight timing loops…if you need a delay with say +/- 20%…no problem. If you are looking for very tight tolorances on the timer, I might try using a sensor to monitor a limit or progress of whatever you are trying to ‘wait for’.

-Quentin

Posted by Rick Berube.

Engineer on team #121, Rhode Warriors, from Middletown H.S…

Posted on 1/22/2000 8:27 PM MST

In Reply to: Programing help… posted by Adam Anderson on 1/22/2000 2:07 PM MST:

: I am a student programer, and i am looking for a way to do a timer in the stamp to fire a motor for a certian amount of time, but i am at a loss of a way to do this, i thought i would create a counter that counts the cycles of the program, but i can not find out how many cycles per second that the controlers CPU can do… anyone have any info on this method or any other methods that could accomplish this task…
: -Adam Anderson-

Adam, the Delta_T variable available to you is about 1/40th of a second granularity at best, so if your talking about having to control something much slower, your probably OK using this method of crude time. I believe Delta_T is defined as a measure of when the Robot Controller (Master processor) receives the data from the Operator Interface. I’m pretty sure that it should always be equal to one, unless one of two things happen. 1) master CPU receives invalid data (noisy/corrupted data likely); 2) your PBasic program has taken too long to loop and one or more Delta_T ticks has elapsed in the process. You should check with Innovation First to ensure my definition of Delta_T here is correct however.

If you are looking to fire a motor for a certain amount of time however, there are several instructions which will allow you to delay your loop for a precise amount of time. The PAUSE statement for example, provides 1mS granularity, the SHIFTOUT on the order of 25 uSec! You have some options here, provided your willing to keep track of your own time within the loop! Hey DOS did it! (but you are probably too young to know about DOS :wink:

I also believe there is nothing stopping you from using more than one SEROUT() and or SERIN() statement in your program! Keep in mind you must execute the proper SERIN() statement in your program at least once every 150-170 mS, or the Robot Controller will reset itself thinking your Pbasic program has crashed!! Keep an eye on the Basic Run Err and Basic Run LEDs on your Robot Controller to watch for this condition.

Hope this helps,

Rick Berube

Posted by Rick Berube.

Engineer on team #121, Rhode Warriors, from Middletown H.S…

Posted on 1/22/2000 8:42 PM MST

In Reply to: Re: Programing help… posted by Rick Berube on 1/22/2000 8:27 PM MST:

Adam,

one more thing. If you do decide to go the route of delaying in your program using PBasic statement timing, check out ‘The BASIC Stamp IIsx documentation v1.3’ at the Parallax website, for the accurate timing information for each statement. Remember that the SxII is 2.5 times faster than the BS2, so many of the statement’s timing numbers have changed as well!

I believe the link I provided here is accurate to get that document.

Good luck,

RickB

Posted by Nate Smith.

Other on team #66, GM Powertrain/Ypsilanti HS/Willow Run HS, from Eastern Michigan University and GM Powertrain.

Posted on 1/23/2000 11:49 AM MST

In Reply to: Programing help… posted by Adam Anderson on 1/22/2000 2:07 PM MST:

Adam,
One possibility is the packet_num variable that you can retrieve from the Master uP in the robot controller. From my work with the dashboard port spec, which also uses this packet number, I can tell you that the number changes roughly 40 times a second. So, if you wanted to, for example, have a motor run for roughly six seconds, you could use code similar to this(using sample variables of course):
--------START PBASIC CODE---------
'Start Motor
if p3_sw_trig = 1 goto startmotor
goto skipstart
startmotor:
startpacket = packet_num
endpacket = packetnum + 240 '6sec x 40cyc/sec = 240
motorrunning = 1
relay3_fwd = 1
skipstart:
if motorrunning = 1 goto checkmotor
goto skipcheck
checkmotor:
if endpacket >= packet_num goto stopmotor
goto skipstop
stopmotor:
relay3_fwd = 0
motorrunning = 0
goto skipcheck
skipstop:
motorrunning = 1
relay3_fwd = 1
skipcheck:
---------END PBASIC CODE-----------
Note that you would have to declare motorrunning, startpacket, and endpacket at the top of your program, as well as uncomment the packet_num declaration and set c_packet_num equal to 1 in the DEFINE CONSTANTS FOR INITIALIZATION section. This code also only works for times up to roughly 6 seconds, after which the endpacket calculation would roll over 255 and the program would reach the desired packet number before the desired time frame is reached. Hope this helps…

Nate Smith

Posted by Jerry Eckert.

Engineer from Looking for a team in Raleigh, NC sponsored by .

Posted on 1/24/2000 12:11 AM MST

In Reply to: Re: Programing help… posted by Nate Smith on 1/23/2000 11:49 AM MST:

First, I second the previous comment that using a software timing loop to control the motor operation is not a wise thing to do. It is not a very precise control mechanism - you will be much better off using some type of mechanical limit switch or sensor such as a reed switch or the optical sensor (if they are included in the kit this year).

There are two errors in the example program:

(1) The initialization code is run each time through the loop while the trigger is depressed. This causes the motor to start running when the trigger is depressed, but the timer doesn’t start until the switch is released.

(2) The termination test will not work properly if packet_num is .leq. 15 when the timer starts (i.e., end_packet does not wrap).

Also, you can save some bytes and cycles by inverting the sense of the tests. For example, instead of.

IF a = 1 THEN L1
GOTO L2
L1:
foo
L2:
bar

Use the following:

IF a = 0 THEN L2
foo
L2:
bar

Here’s a rewritten version of the example program.

IF motor_running = 1 THEN check_time
IF trigger = 0 THEN skip_check ’ nothing to do

’ Initialize the timer

motor_running = 1 ’ turn motor on

start_packet = packet_num
end_packet = packet_num + (run_time * 40)
test_wrapped = 0 ’ assume end_packet didn’t wrap
IF end_packet .gt. start_packet THEN skip_check ’ don’t need to check time because we just turned on
test_wrapped = 1 ’ bad assumption
GOTO skip_check ’ don’t neet to check time this time through

CHECK_TIME:

BRANCH test_wrapped, [L1, L2]

L1: ’ test_wrapped = 0

IF packet_num .geq. start_packet AND packet_num .lt. end_packet THEN skip_check ’ not time yet
GOTO motor_off

L2:

IF packet_num .geq. start_packet OR packet_num .lt. end_packet THEN skip_check ’ not time yet

MOTOR_OFF:

motor_running = 0

SKIP_CHECK:

*** NOTES ***

(1) In the above ‘.geq.’ is greater/equal, .lt. is less than. Three quarters of this posting was eaten when I used the symbols, presumably because the ^&$^ applicating tried to parse them as HTML tags.

(2) START_PACKET and END_PACKET are declared as bytes; MOTOR_RUNNING and TEST_WRAPPED are bit variables.

(3) RUN_TIME can be either a constant or variable containing the time delay in seconds. The maximum value is limited by the delay between consecutive executions of the code loop. The code provided assumes that if the motor is running and not being turned off, that the next loop will execute before PACKET_NUM wraps past START_PACKET.

(4) The constant 40 used in computing END_PACKET is based a statement made in a previous reply that PACKET_NUM is incremented approximately 40 times/second. Your mileage may vary.

Jerry

(Sorry for not including the note I am replying to, but it was mangled by the HTML parser…)

Posted by Jerry Eckert.

Engineer from Looking for a team in Raleigh, NC sponsored by .

Posted on 1/24/2000 12:17 AM MST

In Reply to: Re: Programing help… posted by Jerry Eckert on 1/24/2000 12:11 AM MST:

Also:

.gt. = greater than
.leq. = less than/equal

Posted by Tony K.

Student on team #292, PantherTech, from Western High School and DaimlerChrysler.

Posted on 1/23/2000 2:11 PM MST

In Reply to: Programing help… posted by Adam Anderson on 1/22/2000 2:07 PM MST:

A word of advice:

Nothing beats manual control!

Why are you trying to time a motor? I’d first check to see if the same thing can be accomplished using a limit switch, potentiometer, etc (has anyone used the gyro yet???) I’m not trying to discourage you, but I watched teams work furiously in the pits last year because their automated code wasn’t working properly. Just make sure you have a backup plan.

TonyK

Posted by Adam Anderson.

Student on team #236, Lyme Old Lyme High School, from Lyme Old Lyme High School and Northeast Utilities.

Posted on 1/23/2000 6:10 PM MST

In Reply to: Re: Programing help… posted by Tony K on 1/23/2000 2:11 PM MST:

: A word of advice:

: Nothing beats manual control!

: Why are you trying to time a motor?

I am Trying to time a motor so that i can create diffrent stages of opening… each requires about a second of fireing to advance or retrete to the next/prevous position… and i was thinkning of using the gyro… i just have to ask the coach… but this is more of a challange they presented to the programers while they finish building and testing diffrent ideas for the robot…

I’d first check to see if the same thing can be accomplished using a limit switch, potentiometer, etc (has anyone used the gyro yet???) I’m not trying to discourage you, but I watched teams work furiously in the pits last year because their automated code wasn’t working properly. Just make sure you have a backup plan.

: TonyK