Legacy Forum: Preserving Nearly 20 Years of Community History - A Time Capsule of Discussions, Memories, and Shared Experiences.

RoboBasic Command Question

Hitec robotics including ROBONOVA humanoid, HSR-8498HB servos, MR C-3024 Controllers and RoboBasic
11 postsPage 1 of 1
11 postsPage 1 of 1

RoboBasic Command Question

Post by XenoEvil » Tue Jul 25, 2006 11:18 am

Post by XenoEvil
Tue Jul 25, 2006 11:18 am

Hi,

Could somone tell me what the
GOTO AUTO
FILL 255,10000
actually does at the begining of the Templet Program.

Does the controller support any sort of interupt to program flow which can be connected to external sensors.

Also, what about the ACTION command. Where or how are the actions stored and given numbers.

Thanks. :D
Hi,

Could somone tell me what the
GOTO AUTO
FILL 255,10000
actually does at the begining of the Templet Program.

Does the controller support any sort of interupt to program flow which can be connected to external sensors.

Also, what about the ACTION command. Where or how are the actions stored and given numbers.

Thanks. :D
XenoEvil
Robot Builder
Robot Builder
User avatar
Posts: 15
Joined: Tue Jul 18, 2006 1:00 am

Post by hivemind » Tue Jul 25, 2006 6:35 pm

Post by hivemind
Tue Jul 25, 2006 6:35 pm

I could be wrong, but i believe the FILL 255,10000 is acting as some kind of a memory clear. For instance, when i test my robot i usually make an extremely small routine consisting of turning the motors on, setting the direction, the speed, a delay so i can move away and watch and then some poses (which of course would contine to get more complicated as the routine progreses) but i leave out the goto auto, the fill, all of the ir stuff and the program is only afew hundred bytes making it easy for my test quickly.

BUT, being so small, if i have a program error, say perhaps i throw a return in at the end of my routine with nothing to return to, the robot will go back to a previous program that i have written (for example: the overall template program) and usually has an error and i have to restart him. I believe with the FILL 255,10000 its filling the first 10,000 of memory so that a mistake would less likely screw up the program.

By removing this your program is all of a sudden 10,000 bytes smaller (how nice) and as long as you check your program you should be set. If you want to be safe you can keep it in there, but i usually remove it when im testing.

As for interupts, i think the closest you will get to that will be gyros. You can check things such as the accelerometer as soon as the program gets up, and anywhere in between, but i dont know of any way through robobasic to have interupts. (im new to this, so i could certainly be wrong, heh, i hope i am here)

hope that helps a little-
I could be wrong, but i believe the FILL 255,10000 is acting as some kind of a memory clear. For instance, when i test my robot i usually make an extremely small routine consisting of turning the motors on, setting the direction, the speed, a delay so i can move away and watch and then some poses (which of course would contine to get more complicated as the routine progreses) but i leave out the goto auto, the fill, all of the ir stuff and the program is only afew hundred bytes making it easy for my test quickly.

BUT, being so small, if i have a program error, say perhaps i throw a return in at the end of my routine with nothing to return to, the robot will go back to a previous program that i have written (for example: the overall template program) and usually has an error and i have to restart him. I believe with the FILL 255,10000 its filling the first 10,000 of memory so that a mistake would less likely screw up the program.

By removing this your program is all of a sudden 10,000 bytes smaller (how nice) and as long as you check your program you should be set. If you want to be safe you can keep it in there, but i usually remove it when im testing.

As for interupts, i think the closest you will get to that will be gyros. You can check things such as the accelerometer as soon as the program gets up, and anywhere in between, but i dont know of any way through robobasic to have interupts. (im new to this, so i could certainly be wrong, heh, i hope i am here)

hope that helps a little-
Image
hivemind
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 211
Joined: Sat Jul 01, 2006 1:00 am
Location: between my computer and robot.

Post by i-Bot » Wed Jul 26, 2006 9:29 am

Post by i-Bot
Wed Jul 26, 2006 9:29 am

The actual working of these commands in the template is:

GOTO AUTO translates into 2 IM Byte code strings

Location: Code:
0x0010 ASSIGN byte0, 0 ; the first byte variable is set to 0. This is later defined as RR
0x0015 GOTO $0x2728 ; Yes an absolute jump. The destination instruction location is always the same.

0x0018 FILL 255,10000 ; This fills the next 10,000 decimal (0x2710) locations of memory with FF, more important it increments instruction location

The next lines of DIM and CONST do not create IM Byte code, so the next IM code is made by the IF statement.

0x2728 IF 0x273A byte0 > 0x032 AND byte0 < 0x53 THEN 0x2872

0x273A


Therefore this program will install the template program high up in memory, and run it.

Subsequent program downloads will only write memory as far as their code extends, so it will stay there, even through clear memory, which only clears the program header.

I assume you can then use GOTO AUTO in a subsequent loaded program without the FILL, and jump to the start of the high memory code. Note that the variables will be used twice, this could be good to pass parameters to a high program.

This is the internals. I agree with hivemind on usage, and see no point to include the big FILL in subsequent programs, indeed that would seem to defeat the purpose. I did not check the role of the code in run time errors though.
The actual working of these commands in the template is:

GOTO AUTO translates into 2 IM Byte code strings

Location: Code:
0x0010 ASSIGN byte0, 0 ; the first byte variable is set to 0. This is later defined as RR
0x0015 GOTO $0x2728 ; Yes an absolute jump. The destination instruction location is always the same.

0x0018 FILL 255,10000 ; This fills the next 10,000 decimal (0x2710) locations of memory with FF, more important it increments instruction location

The next lines of DIM and CONST do not create IM Byte code, so the next IM code is made by the IF statement.

0x2728 IF 0x273A byte0 > 0x032 AND byte0 < 0x53 THEN 0x2872

0x273A


Therefore this program will install the template program high up in memory, and run it.

Subsequent program downloads will only write memory as far as their code extends, so it will stay there, even through clear memory, which only clears the program header.

I assume you can then use GOTO AUTO in a subsequent loaded program without the FILL, and jump to the start of the high memory code. Note that the variables will be used twice, this could be good to pass parameters to a high program.

This is the internals. I agree with hivemind on usage, and see no point to include the big FILL in subsequent programs, indeed that would seem to defeat the purpose. I did not check the role of the code in run time errors though.
i-Bot
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1142
Joined: Wed May 17, 2006 1:00 am

Post by i-Bot » Wed Jul 26, 2006 10:24 am

Post by i-Bot
Wed Jul 26, 2006 10:24 am

Oops If I had looked to the second part of your question XenoEvil, it would have been more clear.

The ACTION 0 statement is translated to IM Byte code as follows:

Location: code:

xxxx ASSIGN byte0, 0x32 ; the value varies between 0x32 and 0x51 for the 32 different ACTION numbers.

xxxx+0x06 GOSUB 0x2728 ; Gosub to Absolute location

Therefore once the template is installed in high memory, the actions may be used as defined in the template using the RR variable.

If this is your intention, then you must not include the full template in any subsequent programs which use the ACTION command. The FILL command would be offset by the size of the low memory program, and the code installed in the wrong place. Adjusting the fill length is a pain if you have to find the length program length from the IM code.

However the ACTION calls will not invoke the initialisation, which required the byte0 set to 0 as in GOTO AUTO. Thus I guess you should include the motor initialisation header as per the template in your program
Oops If I had looked to the second part of your question XenoEvil, it would have been more clear.

The ACTION 0 statement is translated to IM Byte code as follows:

Location: code:

xxxx ASSIGN byte0, 0x32 ; the value varies between 0x32 and 0x51 for the 32 different ACTION numbers.

xxxx+0x06 GOSUB 0x2728 ; Gosub to Absolute location

Therefore once the template is installed in high memory, the actions may be used as defined in the template using the RR variable.

If this is your intention, then you must not include the full template in any subsequent programs which use the ACTION command. The FILL command would be offset by the size of the low memory program, and the code installed in the wrong place. Adjusting the fill length is a pain if you have to find the length program length from the IM code.

However the ACTION calls will not invoke the initialisation, which required the byte0 set to 0 as in GOTO AUTO. Thus I guess you should include the motor initialisation header as per the template in your program
i-Bot
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1142
Joined: Wed May 17, 2006 1:00 am

Post by i-Bot » Wed Jul 26, 2006 10:24 am

Post by i-Bot
Wed Jul 26, 2006 10:24 am

Oops If I had looked to the second part of your question XenoEvil, it would have been more clear.

The ACTION 0 statement is translated to IM Byte code as follows:

Location: code:

xxxx ASSIGN byte0, 0x32 ; the value varies between 0x32 and 0x51 for the 32 different ACTION numbers.

xxxx+0x06 GOSUB 0x2728 ; Gosub to Absolute location

Therefore once the template is installed in high memory, the actions may be used as defined in the template using the RR variable.

If this is your intention, then you must not include the full template in any subsequent programs which use the ACTION command. The FILL command would be offset by the size of the low memory program, and the code installed in the wrong place. Adjusting the fill length is a pain if you have to find the length program length from the IM code.

However the ACTION calls will not invoke the initialisation, which required the byte0 set to 0 as in GOTO AUTO. Thus I guess you should include the motor initialisation header as per the template in your program
Oops If I had looked to the second part of your question XenoEvil, it would have been more clear.

The ACTION 0 statement is translated to IM Byte code as follows:

Location: code:

xxxx ASSIGN byte0, 0x32 ; the value varies between 0x32 and 0x51 for the 32 different ACTION numbers.

xxxx+0x06 GOSUB 0x2728 ; Gosub to Absolute location

Therefore once the template is installed in high memory, the actions may be used as defined in the template using the RR variable.

If this is your intention, then you must not include the full template in any subsequent programs which use the ACTION command. The FILL command would be offset by the size of the low memory program, and the code installed in the wrong place. Adjusting the fill length is a pain if you have to find the length program length from the IM code.

However the ACTION calls will not invoke the initialisation, which required the byte0 set to 0 as in GOTO AUTO. Thus I guess you should include the motor initialisation header as per the template in your program
i-Bot
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1142
Joined: Wed May 17, 2006 1:00 am

Post by XenoEvil » Tue Aug 01, 2006 1:23 pm

Post by XenoEvil
Tue Aug 01, 2006 1:23 pm

Thanks for the reply. It is not overly clear to me other than the byte code translation.

What I am reading from your reply is that the control board can support multiple programs sharing the same variable name space.

The GOTO AUTO will run the code that is stored at the default location. Any subsequent GOTO AUTO in another program (asuming you've ommitted the FILL statement) will still infact run the original program that had the FILL statement in it ?

Will it run time sliced or threaded programs I wonder ??????

So if I enter ACTION 15 for example, where is ACTION 15. Where did I enter a command that says this block of moves is action 15 ?
Thanks for the reply. It is not overly clear to me other than the byte code translation.

What I am reading from your reply is that the control board can support multiple programs sharing the same variable name space.

The GOTO AUTO will run the code that is stored at the default location. Any subsequent GOTO AUTO in another program (asuming you've ommitted the FILL statement) will still infact run the original program that had the FILL statement in it ?

Will it run time sliced or threaded programs I wonder ??????

So if I enter ACTION 15 for example, where is ACTION 15. Where did I enter a command that says this block of moves is action 15 ?
XenoEvil
Robot Builder
Robot Builder
User avatar
Posts: 15
Joined: Tue Jul 18, 2006 1:00 am

Post by i-Bot » Tue Aug 01, 2006 3:41 pm

Post by i-Bot
Tue Aug 01, 2006 3:41 pm

Sorry, if I didn't make it too clear. I can see how it works, just not sure if the value of the commands outweighs the complexity and delay for the download, maybe I am still missing something.

However,

It appears that AUTO is just a persistant label for location 10000 in program memory. GOTO AUTO is just the same as any other GOTO except no label is needed, and it sets the first variable to zero.

ACTION is the same as any other GOSUB, except the action number +32 is loaded into the first variable, and no label is needed.

From another low program you should use ACTION since it is a subroutine and will return

There is no multi threading or time slicing of the code.

ACTION 15 does a GOSUB AUTO with the value 65 (15+50) in the first variable. This is decoded by the action_proc: and the GOTO K15 selected which is left attack or whatever you like. Then it returns to the low program
Sorry, if I didn't make it too clear. I can see how it works, just not sure if the value of the commands outweighs the complexity and delay for the download, maybe I am still missing something.

However,

It appears that AUTO is just a persistant label for location 10000 in program memory. GOTO AUTO is just the same as any other GOTO except no label is needed, and it sets the first variable to zero.

ACTION is the same as any other GOSUB, except the action number +32 is loaded into the first variable, and no label is needed.

From another low program you should use ACTION since it is a subroutine and will return

There is no multi threading or time slicing of the code.

ACTION 15 does a GOSUB AUTO with the value 65 (15+50) in the first variable. This is decoded by the action_proc: and the GOTO K15 selected which is left attack or whatever you like. Then it returns to the low program
i-Bot
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 1142
Joined: Wed May 17, 2006 1:00 am

Post by XenoEvil » Fri Aug 04, 2006 8:24 am

Post by XenoEvil
Fri Aug 04, 2006 8:24 am

ah!!, now I understand.

Thanks, that was much clearer.

Thanks for your help.
ah!!, now I understand.

Thanks, that was much clearer.

Thanks for your help.
XenoEvil
Robot Builder
Robot Builder
User avatar
Posts: 15
Joined: Tue Jul 18, 2006 1:00 am

Post by Viking » Fri Aug 04, 2006 3:40 pm

Post by Viking
Fri Aug 04, 2006 3:40 pm

Has anyone observed that there is a difference when using MOVE24 and MOVE G24?
If I use RoboBasic to read the servo positions it will write a MOVE G24 command. But if I change the command to MOVE24 the servoes does something totally different?
According to the manual page 75 or so(PDF), it states that there is no difference between these two commands? :?:

-Viking
Has anyone observed that there is a difference when using MOVE24 and MOVE G24?
If I use RoboBasic to read the servo positions it will write a MOVE G24 command. But if I change the command to MOVE24 the servoes does something totally different?
According to the manual page 75 or so(PDF), it states that there is no difference between these two commands? :?:

-Viking
Viking
Robot Builder
Robot Builder
User avatar
Posts: 20
Joined: Wed Jul 19, 2006 1:00 am
Location: Denmark

Post by hivemind » Fri Aug 04, 2006 6:39 pm

Post by hivemind
Fri Aug 04, 2006 6:39 pm

I believe it is the same, the move24 just doesnt require an initial " , " and therefore if you have one it would throw all of your positions to the next servo and probably look rather interesting, but i just tested this command with my ankle servo only and it did the same given both commands (and like i said, the move24 doesnt want an initial comma or it will think your already going to the next servo)

:-)
I believe it is the same, the move24 just doesnt require an initial " , " and therefore if you have one it would throw all of your positions to the next servo and probably look rather interesting, but i just tested this command with my ankle servo only and it did the same given both commands (and like i said, the move24 doesnt want an initial comma or it will think your already going to the next servo)

:-)
Image
hivemind
Savvy Roboteer
Savvy Roboteer
User avatar
Posts: 211
Joined: Sat Jul 01, 2006 1:00 am
Location: between my computer and robot.

Post by Viking » Sat Aug 05, 2006 7:36 am

Post by Viking
Sat Aug 05, 2006 7:36 am

JEp Thats the reason - Thanks Hivemind
JEp Thats the reason - Thanks Hivemind
Viking
Robot Builder
Robot Builder
User avatar
Posts: 20
Joined: Wed Jul 19, 2006 1:00 am
Location: Denmark


11 postsPage 1 of 1
11 postsPage 1 of 1