Quote:

"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?

Needs to be updated. The EZ-B v3 supported 100 servo positions. The V4 supports 180 to make it closer to degrees (although some servos have more than 180 degrees of rotation, so you may still need to interpolate desired degrees to a servo position command).

I no longer have a V3, this change could have just been in ARC and not a difference in the hardware......

Alan

@thetechguru Thanks for the quick clarification. Probably a lot of that in there. I guess I'll just have to try each command and see what it actually does.

Quote:

Thanks for the quick clarification. Probably a lot of that in there. I guess I'll just have to try each command and see what it actually does.

Yeah, or ask and someone will jump in with clarification. DJ codes a lot faster than he writes, so there are several area the documentation has fallen behind. Now that you are a member of the community, a good thing to do is read the release note posts whenever an update cones out. DJ is pretty good at listing what is new/changed.

Alan

Guys, tanks for this discussion I was puzzled about"GetServo" command, now it's clear.

1. all code, whether threaded or not still executes in a linear fashion.

2. the "process" explanation of controls are mentioned in the activity tutorial of the learn section. Please read the tutorials, as they will help you. The phrase "Behaviors" best describes the approach. Each control is a behavior for your robot - referenced in intro videos and tutorials

As for the struggles you are experiencing, it may be because you're over complicating things due to what you learned years ago. With tens of thousands of users, there are only a handful per month who experience the similar struggled as this - which is a very low ratio, even though i'm part of it. I also come from the single threaded blocking code approach. We respond to all inquiries to help educate users, such as yourself. However, we can only help those who are willing to be helped. As stated earlier, don't look for similarities between 1990's Delphi and ADA with newer languages - that will hold you back in learning the current way computers work.

Very rarely does someone relate the old school single thread approach (warning: this does not mean linear, as I have mentioned is irrelevant attribute). The software that you are using right now is multi threaded. Every programming language in windows and Linux and OS X is multi threaded. Stating that ARC is multi threaded development is like putting an "electric starter" on a car advertisement. To anyone born in the last few decades, the term electric starter would mean remote-control starter, I suppose. But to anyone who remembers the day of having to manually crank their car engine will think differently. So the term multi-threaded is inherit to all programming languages today. The mere mention of such an attribute opens a whole new whack of questions and confusion to 99.9% of users who are so used to multi threaded apps, that the term isn't even in their vocabulary... because it's an everyday expectation of software.

Documentation is an interesting challenge when balancing between technical education and ease-of-use. While you're looking for a lengthy explanation about multi threaded approach, ironically using a multi threaded pc and quoting Delphi and ADA. It's a chicken and the egg perspective, with a twist... in today's age, there's a new challenge in knowing where the egg came from; the chicken or the carton!

The best part about this conversation is that it compliments what I'm working on. Now remember, ezrobot isn't a big company with a bunch of employees and such - there is 5 of us, so we depend on the friendship and cooperation of our community. In turn, we have the lowest priced product and free software. As well as being the CEO and office cleaner and inventor and visionary and tech support and web developer and video creator and tutorial editor and and and... Im also the only programmer - for all embedded firmware and windows software. So what I'm working on this week is a new tutorial section which puts you in charge! So you will be able to be super helpful to me and contribute what you've learned in the forum of tutorials on here, very shortly.

Everything that this conversation is teaching you - and every other bit of knowledge you've learned since EZ-Robot can be shared in our new upcoming tutorial section.

Single thread, Multi Thread? Is that the difference between being able to run two different apps on your smart phone rather then one?

Dave - no and yes. The simplest way to describe it is by saying that multiple routines of code can run parallel with each other - and be managed by parents with a family hierarchy - and exchange data through thread safe components and channels.

It all started back in the day of C++, which become popular for the concept of "Classes", which is compartmentalizing objects within objects in a family hierarchy. That opened a huge opportunity to make parallel processing easier because each "chunk" of data was identified as a class containing objects. Each object had a data type, which could be referenced, de-reference or casted to similar/compatible object types.

Now, with parallel processing/threading happening in C++, it was a huge challenge for programmers to manage threads. And by manage, this meant how to tell the progress of a thread process, tell the state of a thread process, or stop a thread process. Stopping was always tough because you want to stop a process gracefully. The original threading model was literally "Abort!", which would just stop where it was in the linear execution of instructions. This obviously wasn't the ideal approach, but programmers used very complicated ways to get around that. They would have "state" variables that were global and static which allowed the main threads to know the state of work done by child threads.

Oh, a real challenge was having background threads interacting with variables or objects owned by other threads - specifically GUI objects, such as buttons and text boxes. This was called cross-threading and caused programmers to pull their hair out. Hacks to objects were created by overriding a system level class that would tell the compiler to "INVOKE" the function on the thread of the parent object. Also there were variable declarations, such as VOLATILE which would inform the compiler that this variable was not to be trusted AKA used in multiple threads.

Complicated? Hell yeah! And i'm simplifying it - so it's even more complicated than that.

Anyway, eventually the threading concept became needed because cpu processing was reaching maximum potential. This created multi core processors so parallel processing could maintain the same MHZ processing speed but increase the number of instructions executed in parallel.

Java and .Net are the two languages known for making multi threaded apps popular. This is because they were developed today, not 20 years ago like other languages (specifically ones quoted such as Delphi which is pascal for win32). And i can go on about Win32 for a lengthy rant - but it's a whole new beast. The Win32 api was created in Windows 3.11 (windows for workgroups) and hasn't changed since. Only today, in 2015 is Microsoft taking the initiative with Windows 10 to introduce UWP, which deprecates Win32 API. That is why EZ-Robot's recent work with Microsoft on UWP UniversalBot is so important. See HERE and HERE

Now days, it's practically a challenge to find a programming language that does not include threading inherit in it's native design. What i mean by that is look at .Net for example. Most programs in old .Net were blocking because threading was still complicated. Blocking means, the code runs on the GUI thread. You can tell when a program is non-threaded (blocking) because when you press a button, the entire GUI locks up. Notice how the GUI doesn't lock up on ARC functions, other than loading some GUI windows - this is because ARC is threaded. Each control runs in it's own thread.

Now, with newer versions of .Net, specifically UWP, it's almost impossible to not write a threaded app. All methods that are called from a threaded method must return a TASK<> or be labelled as async. This can be really hard to understand for someone coming from a single threaded programming language.

Yes, Delphi and other languages had "threading ability" but it wasn't built into the native structure; or better yet, the structure of the language wasn't built around threading.

Now that you can see how complicated it would be to create a threaded App in even .Net - you understand the importance of ARC. Even if you were to create a C# robot app using the EZ-SDK, you will face huge challenges with threading - otherwise each time you press a button, the code will be executed on the main GUI thread and lock up the UI - preventing more than one thing happening at a time.

ARC users are lucky and kind of spoiled - because you don't need to worry about threading

@Dave.... I'll translate what @DJ just said.... multitasking is like having the ability to pee, eat and scratch at the same time..... Single tasking means you have to pee first, then scratch and then eat.....