Wbs, those old languages with a single threaded approach is what makes relearning coding today difficult. The approach you wrote is incredibly inefficient and very expensive on processor and network resources.

First, you only need to assign a servo speed once, not looping.

Second, the threaded approach is to set the speed and servo position once and let the processing be offloaded onto the ezb and servo. Releasing cpu cycles for other threaded tasks.

The Auto Position is a good tool to begin using. Specifically for poses.

For the last 10-15 years, cpu processing has been approaching speed limitations. The approach of using multiple cores has become what the operating system and newer programming languages rely on. At the heart of the kernel (in any current OS) is a layer which distributes instructions across multiple cores and creates a threading interface for the OS and programs. There are a few different approaches during programming for using threads which evolve with compilers and libraries.

ARC and other robot software/libraries (such as ROS) use a an approach which run processes separately as jobs. Each "job" in ARC is a control. They run parallel and communicate using ControlCommands().

While you can surely hack EZ-Script (or any current language) to write old school code, it's not going to always work as expected once you start adding additional processes (controls).

For example, the correct approach for you script to simply move a servo to a pose would be to create Auto Position poses and execute them with the ControlCommand(), accessible from the Cheat Sheet (see the LEARN section and the ACTIVITIES course) for information on how it works.

If you were to do something like this...

ServoSpeed(d2, 4)
Servo(d2, 120)

Soon as you execute the Servo() command, it is non-blocking (as all commands in EZ-Script are non-blocking unless stated with the word WAIT). This means the Servo() command will instruct the EZ-B to begin moving the servo to position 120. The servo is a WRITE only device, meaning it doesn't report back the position of itself. It only moves when told - so there is no way to know it has moved unless you use the Auto Position. The Auto Position is a very very easy control with very very very very complicated code in the backend. It will report when an action has been completed executing, which you can monitor by using the following command after initiating a ControlCommand() on an Auto Position Action.

WaitUntil( $AutoPositionStatus = 0)

For more information on the dozens and dozens of example projects demonstrating EZ-Script, check the EXAMPLES in ARC. There is an entire lesson in the LEARN section located under ACTIVITIES regarding the Examples in ARC.

@WBS00001 You PC programmers think differently than us (me specifically) robot programmers... I learned "robot" style programming first (if you can call robot programming a type of programming that is) 20 years ago messing with the Basic Stamp/Basic Atom microcontrollers. Those old school micros had very slow processors, limited code space and were not capable of multi threading.... Your code had to be small, super efficient and compact. You had to do things like read your pings or IR sensors in between motor pulsing ... Anyway, I later learned some PC programming.... What I am trying to say is I think there is a different approach when programming for robotics....

Yeah, to state what has already been mentioned... the

Getservo()

command is only a value established by the software or in other words the last position that ARC told the servo to got to.... whether the servo made it to that position is a different story.... As mentioned, the basic hobby servo is a "dumb" device which unless you hack it to read the internal pot there is no way for it to report back to ARC it's actual position....

@Bob, sorry for getting side tracked here....

Thank you both for responding.

@Rich Okay, so if it's redundant, why was it done every iteration in the original code loop? I mean, isn't that the same thing; checking a value using GetServo every half second? Repeating that loop until $X gets to 157? Or am I missing something here?

@DJ Sures Yes, the really "old" languages used a single thread approach (Modula 2, early Basic, early C) but the more modern ones I mentioned (Delphi, ADA) did not just use a single threaded approach. They were multi-threaded from the get-go. As were the programs I wrote with them. Multi-core is one of the latest darlings of the industry, along with Object Oriented design, Composites, Patterns, and distributed processing. All of those things have been incorporated into them for some time now.

Thing is, the Script manual makes no reference to it's true nature and gives the impression of being single threaded. Especially considering it's linear nature of code construction. The system is mulit-threaded, multi-core in nature, fine. That would be something nice to be included in the Script manual right up front. It's the sort of information someone like me needs as opposed to going through dozens and dozens of examples. Though I have to wonder if that information is in any of them either. That bit of knowledge would have put an entirely different light on my thinking about the code.

And, I have looked at several of the examples and the Script course but nowhere was any of this mentioned. No introduction. No "Advanced Concepts," nothing of that sort. How is one supposed to know this? The closest I came to a hint about it was in the Personality Generator section with the single line " This control can run in the background while your robot operates. " And that was specific to the example.

Finally, please keep in mind this is not "my" script. I merely addressed one aspect of what was happening and copied the rest as is. For instance, setting the servo speed on every iteration of the loop is not part of what I was pointing out. I merely copied the given section of code for that part. I had no idea why that was done in the original code so I just copied that part as it was. For all I knew, that was necessary to do on every iteration.

@WBS00001 Dude LOL.... If I had a nickel for every "I am an experience PC programmer since forever" guy to come on here and have issue with the way things are done with ARC and the ezb, I would be... well you know the saying.... You're not the first let's just say, but eventually they all come around. Most of them, anyway..... Anyway, stick around (by the way I am not criticising you at all) you'll see that you might be over thinking things a bit.... Remember, we're programming robots not PCs....

@Richard R Thanks for your comments. I understand what you're saying about the different philosophies when it comes to different programming environments. But, to me, programming is programming with a certain set of best practices associated with it regardless of implementation and point of view. This environment, for example, is simply a multi-threaded, multi-core approach. While it's called blocking and non-blocking here, it's still just multi-processing/multi-tasking vs single tasking. The same practices can be applied to both. The main difference here is that the robot's processing is transitory in large measure. Move this servo to here, rotate that one to there, get an A-D value, etc. No big time on-going processing for the most part. The scripting language is great in that it hides the dirty details and grunt work and I intend to use it in my own development environment.

Just saw your new post. I don't have a problem with the way things are done here. In fact, if there had been an explanation of how the the scripting language actually performed it's tasks, I would have never presented the example I did and all this would have never have been posted. But there wasn't. I have no intention of trying to change anything, nor will I ever post anything on the subject again. I'll just keep my opinions to myself and stroll merrily on my way doing my own thing.

Quote:

@Rich Okay, so if it's redundant, why was it done every iteration in the original code loop? I mean, isn't that the same thing; checking a value using GetServo every half second? Repeating that loop until $X gets to 157? Or am I missing something here?

I could have sworn your code used the Servo() command not ServoUp(). With the Servo() command it's redundant.

ServoUp() or ServoDown() in a loop to move servos in increments until a position does not make repeating until it's at position redundant and the position is changing and can be tracked in the software.

This is an example of redundant code, which I thought I was commenting on (possibly in my haste as I was on my phone at the time).

Servo(D1, 0)
Sleep(1000)
Print("Moving servo")
Servo(D1, 180)
$x = GetServo(D1)
RepeatUntil($x = 180)
$x = GetServo(D1)
Sleep(10)
EndRepeatUntil
Print("Servo in position")

Basically, the code (which is pointless) would presume the servo position is read from the servo and polled every 10ms until it reaches position 180 and then reports that it's in position. The reality is the repeat part of the code wouldn't repeat since the software, as soon as you send the Servo(D1, 180) command, would think the servo is at position 180 even if servo speed was so slow it took 10 seconds to get there.

@WBS00001 You got it all wrong, we don't want you to keep your opinions to yourself.... Nobody learns anything that way.... What I was trying to say was... "it is better to sand with the grain not against it".... You have to keep an open mind to different ways here (me included) because as I mentioned programming robotics is different than PC software development....

I had to change the way I thought about programming when I first came here too... I was programming old style micros ... ez robot had a weird new multi tasking controller that I had trouble understanding the why's and how's at first.... Once I got that "eureka" moment the Basic Atom microcontroller I was using for the past few years quickly got tossed.... Now almost 2 years on I am still in the ez robot "honeymoon" phase....

@Rich Ah, I see what you're saying. Yes, a simple servo command would be redundant and pointless as opposed to ServoUp. Okay, that clears that up, thanks.

The GetServo command is inadequately explained in the Script manual it would seem. The description leads one to believe it gets the current mechanical position of the servo in that it says "Returns the servo Position value of the specified port." I gather it actually returns the value of where it's supposed to be as opposed to where it actually is. The manual also says "Servo position is between 0 and 100". To me that says it returns a value in the range of 0 to 100 (percentage?) and not 0 to 180. Which makes me wonder how it ever gets to the value of 150 as presented in the example? Is that a mistake in the manual or am I not reading it right?