Is it possible to subtotal in PBASIC? Like, every time a cycle completes, a variable, lets call it Counter, goes up one?
I know in C++ to do that it’s simple, just one line of code:
Counter = Counter + 1;
or
Counter++;
If I can, how can I do that in PBASIC? My other programming sidekick thought it would just be:
Counter = Counter + 1
Then, once a cycle, Counter would increase one integer, and eventually a “If Statement” would reset it to zero. I’m not sure if that syntax is right, and I figured might as well ask, and save some time and lots of possible fustration, as was caused with the switch operated PWMs, as some of you know :D. So, if I’m right, thanks, if I’m completely wrong, well, don’t feel bad to be brutaly honest, even though that really isn’t the spirit here, which is good.
Yay! That makes everything so much easier! I think. Hmm, I wonder if I can tell you what I want this for. Nah, not now. I’ll tell you guys in a few weeks. Thanks.
Now, off to the nice bed, blanket, and best of all, pillow!
Goes to sleep with grin on face, dreaming about PBASIC…
Does what it does in nearly every programming language (despite the fact that it makes math profs crazy!).
Perhaps a better idea for what you are trying to do is:
Time = Time + 1 + Delta_T
Where Delta_T is the variable passed to you by the master CPU that tells you how many data packets you have missed since the last time you got a good packet of data from the master CPU.
If you use this construct, you will have a more reliable method to have something stay on for 2 seconds for example.
If you just use counter as you initially proposed, your loop time figures into the time that passes before you reach a set number. Also figured into the mix is the fact that you may have a noisy radio environment or you may have some other problem communicating with the OE.
In these cases, you can have the time until counter reaches a fixed number vary by mulitples of 2 or 3.
With Delta_T added in, your program takes into account the fact that you missed packets and thus your time estimations are more robust.
I understood everything you said up to the Delta_T part. All we want the Counter is to count how long a switch is on for, and to automatically turn it off. We hope it works, because it just makes our lives easier (the way our robot is set up). So, does the Delta_T really matter? If it does, can you “dumb-down” the language so I can understand it? Or maybe I just need more sleep.
You cannot count on how long it will take you to get through a loop of your program.
If you have a program that is complex, you may make it in 24 msec one time and 26 msec in another.
If you make it in 24 msec, you MAY be ready to receive the next packet of data that comes from the OI, if you take 26msec, you will definitely MISS the data packet and have to wait around until the next one arrives (which will be a while because they only come at best at 25 msec intervals).
Now, add to that that not all data packets make it through intact you you begin to realize that you will only get to increment your counter at variable intervals. The intervals are outside of your programs control.
So…
What is a clever sheep supposed to do?
Well, FIRST gives you some help. If you ask for it (by setting c_Delta_T = 1 in the default program and by including Delta_T in your SERIN command, which gets data from the master CPU), the master CPU will tell you how many data packets you missed since the last time you got data from it.
SO…
Rather than just adding 1 to counter each time through the loop, you can add in Delta_T, the number of data packets you missed. This will help you keep your clock up to speed even when your program is running slower (perhaps because you left a Debug statement in the code – you naughty little debugger you) or because you are at a competition and there are many other robots broadcasting on frequencies very near your own.
It is not a big deal but it is a better mouse trap if you care to build it.
That makes a bit more sense to me. Not completely, but enough so that I can explain it to someone who will. Thanks again, now we can possible make our robot all nice and happy.
Hmm, as it stands now, I just need to count an approx. time (say 3 seconds), and then something will occur. Do I need the Delta_T thing if I’m just counting approx. times? Or should I still try to implement it just for the heck of it? Can someone please help me?
Hmm, looks like I’ll have to use the Delta_T thingy. Luckily, I think that there’s at least one or two other people who will be able to explain how it works to me in more detail then can be explained here. Thanks for your help, now for a bit of code writting and most likely a lot of trial and error. Whee!
Where is Delta_T added to the serin command? I’ve figured out everything but that, I think. If all works, then just adding it to the serin command, and waiting about one hour (I’m still in school, we have a sub in my computer science class) untill i can get to the robot, and we shall see if it works. Yay!
*Originally posted by Joe Johnson *
**Rather than just adding 1 to counter each time through the loop, you can add in Delta_T, the number of data packets you missed. **
Joe,
I don’t remember whether Delta_T means the-number-of-packets-your-program-missed-since-you-successfully-received-a-data-packet, or the-number-of-cycles-since-you-last-successfully-received-a-data-packet. So the question is: should you add 1+Delta_T to your counter each time (if the former is true), or just Delta_T?
Yay! It works! I haven’t tried the Delta_T thing yet, because I’m not sure where it goes into the Serin command. If someone can tell me this, then I can make it even better, but as of now, we can use a relay with one two-pole toggle switch. Yay! Thanks guys! Now, who wants to tell me where the Delta_T goes into the Serin command?
*Originally posted by gwross *
**
I don’t remember whether Delta_T means the-number-of-packets-your-program-missed-since-you-successfully-received-a-data-packet, or the-number-of-cycles-since-you-last-successfully-received-a-data-packet. So the question is: should you add 1+Delta_T to your counter each time (if the former is true), or just Delta_T? **
delta_t contains the number of packets missed, so to do a counter you would need to say counter = counter + 1 + delta_t
*Originally posted by Ian W. *
**I haven’t tried the Delta_T thing yet, because I’m not sure where it goes into the Serin command.
**
You will notice in the code that there are two serin statements. The top one is commented out, but has all the variables listed in it in the proper order. The second one is the one that is actually used. put delta_t in the same spot as it is in the first one (almost for sure it would be last). You also need to change C_deta_t to 1 like Joe J. said in an earlier message.
*Originally posted by Ian W. *
**Yay! It works! I haven’t tried the Delta_T thing yet, because I’m not sure where it goes into the Serin command. If someone can tell me this, then I can make it even better, but as of now, we can use a relay with one two-pole toggle switch. Yay! Thanks guys! Now, who wants to tell me where the Delta_T goes into the Serin command? **
Looking at the commented out serin command in the default program (the one that shows you the order in which the variables in your real serin command must be), it shows delta_t in the second to last position. So, unles you’re using res01 (and I’m not sure I’ve ever even seen what this variable is supposed to be used for – it’s probably just reserved for future use)… unless you want to read res01 just for fun, you’ll want to have delta_t at the very end of your serin command.
The way my brain works is that I file things away with flags on them that might be useful someday.
This whole process is more or less a mystery to me. It is more reliable than it ought to be which is either evidence of a higher being or that some people have all the luck.
In any case… checking my mental records under “Delta_T” I found a “delta_t is misnamed, it should be called packets_missed” flag in the file.
This is why I included the information in my post.
In actual fact, I don’t know if I am right now that it comes down to it. I know that I have done it for as long as I can recall, but that is no proof.
The actual implementation is due to Eric Rasmussen at FIRST. Several years ago (prior to Innovation First taking on the controller), he and I were having a conversation about how it would be nice if the Stamp2 on the robot could know something about time (more than just loop count I mean). As a result of this conversation (and perhaps 10’s of others from other FIRST fanatics ;-), Eric came up with this Delta_T thing. Innovation First adopted it as a legacy bit of code. He’s a very clever sheep that Eric. But I digress…
Now that it comes to it, I don’t know if I am right. I THINK I am right, but perhaps not.
I posed this question to InnovationFIRST last year. Here is the text of their reply. It includes some information about some of those other little undocumented gremlins in the code. I hope it helps.
Warren
Text follows:
The PB_mode contains data about the enable and disable of the robot. The
last bit of the PB_mode byte, PB_mode.bit7, (aliased as comp_mode) indicates
the status of the Competition Control, either Enabled (1) or Disabled (0).
This indicates the starting and stopping of rounds at the competitions. The
remaining bits are reserved.
The packet_num varies from 0 - 255 and is incremented with each new packet.
The number is incremented 40 times per second.
The delta_t refers to missed packets. If delta_t = 0, no packets are being
missed. Thus if delta_t = 1, one packet of data was missed. Data packets
will be missed if your code takes longer than 25ms to updata(excute 1 loop).
The res01 contain info about the version number and is reserved.
