Hey Ron.

I'm in complete agreement with you in the other thread about having a one stop area containing script examples. We know that some can be found in the Cloud and through forum searches, but this is time consuming, has the possibility to have something missed, and they don't always come with simple to understand explanations. I'm all for learning the scripting language rather than having it handed to me on a plate, but seeing a working example personally helps me see how the different elements work.

Anyway, I can help with a startup script with the following example...

# This will clear the selected servo 
# speeds for initialisation. (Zero is 
# servo reset).

ServoSpeed(d0, 0)
ServoSpeed(d1, 0)
ServoSpeed(d2, 0)
ServoSpeed(d3, 0)
ServoSpeed(d4, 0)
ServoSpeed(d5, 0)


# Move the servos into initialisation 
# positions where you want the servos 
# to start from. (Change the last set
# of numbers to how 
# you want them.)

Servo(d0, 2)
Servo(d1, 180)
Servo(d2, 18)
Servo(d3, 77)
Servo(d4, 163)
Servo(d5, 105)


# This will set the servo speed for 
# these servos which will be used 
# from now on.

ServoSpeed(d0, 5)
ServoSpeed(d1, 5)
ServoSpeed(d2, 5)
ServoSpeed(d3, 5)
ServoSpeed(d4, 5)
ServoSpeed(d5, 5)

# Then add any start up
# scripts here...

To do a closedown script, you could add a script control (something like an Off button. I have one on my K-9 mobile app) and create something similar to the script above. The only thing you need to remember is to press this before you kill the power. As far as I'm aware, there is no other way to do it.

Hope that helps.

Steve.

I don't know of any way to run a shutdown script either when you shut down power. We have brought up this problem in the past and haven't found a good answer. However I've been thinking that maybe some type of timer circuit connected to a relay that the main power would run through could be added that would delay shutdown when the power button was pushed. Then a second switch could be added that would be triggered at the same time as the power button. The second switch could be monitored by an ADC port on EZB and watched by a looping shut down script. When the script sees the ADC voltage change it would run the shutdown routine script. The shutdown script would have to finish before the timer circuit released the relay to shut down power.

Another simpler way would be just to have a button you need to push or a voice recognition command that would run a shutdown script. But as Steve mentioned you would have to remember to run it each time before you shut down power. I don't like to have to remember things so I don't like this last option. mad

@Dave.

I have to be honest and agree with you about my idea of remembering to "press a button" to run a shut down script. My Victor project which was based on a Roomba used this, because I had to reset the Roomba's state to allow it to charge it's battery. If I forgot and shut the project down or killed the v4's power without running the shutdown script, the Roomba wouldn't charge. I had to reopen the project, power on the EZ-B again, then run he script to reset the Roomba (or manually reset it) to allow it to charge. It was a pain in the neck sometimes. eyeroll

I do like the idea of using a relay and timer though. I'll have to give that some thought myself for future projects.

Ya, the more I thing about it the more I think it could work. I just saw this BattleSwitch in anouther threaad that would work.

BattleSwitch

This may work also:

Timed relay

I think I have a timer with a relay around somewhere. I will dig it up and that will be one thing less to buy. I may need to latch it on startup with a push button and a relay. I will send a signal from the ezb when it is time to shut down. The timer can run for "x" seconds then remove power.

Ron R

The forum tag EZ-Script should give you plenty of examples to go by, however the tags aren't always used as they should be so you'll likely have to wade through the rubbish to get to what you need.

Or, just check my forum posts and cloud, pretty much all of my cloud projects are script based and most give a link to the forum posts they marry up to. My forum posts should help too, however be aware there may be some syntax changes in the EZ-Script since I wrote the posts.

My Ping Roam script topic has a lot of detail in it, including some scans of my code with my hand written notes on it which show my process of working out the sequence of events that needs to happen.

The EZ-Script manual is pretty explanatory too.

Not to mention the many example projects which come with ARC which DJ has provided working examples of pretty much every script function.

The rest is pure logic.

Does anyone know of any examples which work with the Date-Time functions? There is zero about what needs to go in the arguments for the functions in the Script Manual. MonthName() I figured out. MinDate() and MaxDate() return (and I believe set) the range of dates that can be worked with by the other functions (I think). They usually are associated with a date-time picker. But even there, what format do the arguments go in for setting those values? The rest, who knows. Is it MS date-time format doubles? Ascii text? How many arguments? What order. The manual just totally leaves you hanging. What good are the functions if there is no explanation of their usage? I'm referring to these: AddDays() AddMonths() AddYears() AddHours() AddMinute() AddSeconds() FmtNum() FmtDate() CDateTime()

Hi Rich... Good to hear from you... I have tried to do some scripting and so far it does what I hoped. I visited your old list of scripting info. I had forgot you had posted it.

My MINI ME will be more animated driven by events or voice commands. I think I got the idea how this script works now that that I am using the Auto Position control.

Thanks to all, Dave , Steve and Rich. As soon as I figure out how to load a video to this forum will post my Mini Me robot update.

Ron R

@Andy, Post the vid to Youtube. Then use the "Add Youtube Viedo" button below this message and cut and paste the link to your Youtube vid into the box that pops up. Save it and your video is posted here.

@WBS00001, Good questions and your view has been echoed in other posts. I think DJ sometimes forgets us common folk are not as brilliant and intuitive as he is and assumes we'll just "get it". eek

After a bit more searching in C# code, I have divined the Operations of the date and time functions. I have divided it up into 2 sections. The list of the functions with brief extras, and a NOTES section with more detail. You can find the writeup here: https://synthiam.com/Community/Questions/8317&page=2

At or near the bottom.

My wish for an EZ Robot Script 101Tutorial.

When a new script writer sits down to write a script, often he/she has no idea where to start or what their robot can do. Maybe they have built some Auto Position frames and actions, but maybe not. This tutorial would be used to open the door to a world of robotics. it would give guidance to the basics and progress to the more complex. The Robot examples located elsewhere would then have more value and could be used to learn from.

My thoughts:

Here is an example a new script writer might want for a first script. When turning on a robot, JD for example, all the servos quickly move to a home position. If the last position, the robot was left in, was not near the home position, the servos move very quickly to their position. Obviously this could cause a problem, and maybe damage. In section 1 of any tutorial this should be addressed. This has been presented and answered in this post, but it would be nice to be in a tutorial.

Section 2 could be simple movements of servos showing how to control speed and movement, etc.

As the user progresses through the sections, the scripts get more involved and complex. One script builds on the last script written. Camera usage, tracking, movement panels, voice commands etc. get covered and an example given using previous knowledge learned. (Rich touched on this in his "Richie" Tutorial). Community members could drop their examples into the sections to help show how functions work.

This is something I think would be of value to those who have no understanding of robotic but want to learn. It also show the power and features available in the EZB controller / Software.

My Thanks.

Thanks to anyone who reads this and agrees. It was something I feel would be helpful to all.

Ron R

All programming languages are basically the same... in that they can do pretty much the same thing, albeit using different terminologies and syntax... I started out using (20 years ago) the Basic Stamp microcontroller, then the Basic Atom microcontroller (more powerful than the Stamp) and then the Adruino.... And finally ARC scripting (which is the easiest of them all)... Once you learn one, the rest are easy....

@Ron, just learn the syntax and let your imagination guide you. There is no right or wrong way to code (just more efficient ways), just like there is no right or wrong way to draw a picture.... If the code doesn't work, you'll either get an error or what you expected the code would do... it didn't do.... Make changes and try again... This is the learning part.

Just start out simple.... copy sample code and play with it... ARC has a plethora of sample code built in as examples....

How do you think I learned?... no one taught me. I didn't go to school for programming.... I learned from screwin' around with other peoples sample code.... Eventually you get proficient enough to write your own stuff...

How did you learn to do your job? Time and paying attention, right?... My advice is to start with code snippets and see what they do and how changing them affects the outcome when you run the script... (Like I said, ARC is full of code examples....)

Allow me to begin by saying I echo what Richard R. said in his post. The only thing I would disagree with would be the statement that there is no right or wrong way to program. But that's because I come from a professional programmers point of view. As far as the person who is new to using the script language, however, I would agree. As the saying goes, just do it. Right or wrong, good or bad, just do something.

In the PC world, a bit of advice where programming is concerned is "try it and see what happens. You can't break it." For the most part this is true. In robotics, however you can break it. If you do, then you shrug and say, "Well, at least I learned something". Hopefully, it's not your finger or an eye.

Still, there is a lot you can do before you actually apply any code to your robot. And, in that mode, you can't "break it". Use the debug window and copious Print() statements sprinkled in the code to see what is happening. Go step by step and break down your code into small sections to try things. You don't have to write the whole opus in one go. Or even in one script for that matter.

Now, one thing to keep in mind where ARC is concerned is it's basic philosophy: Use Controls to do things. The script language is just for those things you can't do with just controls alone or there is no control for. With the new Plug-In feature coming, there should, eventually, be fewer and fewer cases of that. Fundamentally, it is like the axiom where using computers is concerned. It says that "If you are adding hardware to a computer device, you are defeating the purpose of using a computer in the first place." Of course, that's not always possible because, as things stand now, the computer simply isn't fast enough to do everything it could. So you end up adding some additional hardware. In a similar way, using the script language to do something is defeating the purpose of using ARC.

Think of the Controls as pre-written script programs. All you do is copy and use it. In reality, however, they are not written with the Script language. They, and the script linguage itself, are written with a higher level, fully implemented programming language. Thus they can do more than anything in the Script language can do. They have access to things the Script language does not. The Script language is primitive by comparison. It is meant to be.

So, before writing that super duper script program, think. Could I do this with a control instead? If so, use it. Don't reinvent the wheel. Or, at least, call that control from a script. That's a tutorial in itself actually.

The Autopositioner control is a prime example of that. The one major fault of it is that it always works with all the servos in every frame. At the least, the same set of servos. You cannot just set a given Frame up with only some of the servos. It's all or nothing. That becomes a problem when all you want to do is move an arm a certain way, regardless if the robot is sitting or standing. That's why, in addition to the main Autopositioner, I have separate ones for every limb and pairs of limbs (and the head). Since you can't resize the window for that control (Hint, DJ), you fill up a screen fast, even with 3 virtual screens available. One robot takes up the whole screen.

Alternately, that is where a script can come in handy. With it you can move just one servo to wherever you wish. So, in that regard, go for it!

Finally, as far as tutorials are concerned. People would have different approaches to writing them. People like me would not be able to restrain themselves from teaching "best practices" along with the writing of the code itself. That's because I come from a program maintenance as well as a programming point of view. I consider the best way to be able to maintain the code, long term, as well as write it for readability. Writing good code is not just about making it work. So I would probably not be a good candidate to create such tutorials. So ingrained is it all in me, I would probably be incapable of writing a "For Dummies" type of programming book. I would be conflicted the whole time I was writing it. The editor would fire me after the first draft of the introduction alone.

@Richard R & @WBS00001 Thanks for the replies. I got a lot from your statements. The " Just go do" is important. Like you both said, "if it doesn't work, try again"... Another big take is, use what is already built. I really just need script to sequence what I need and when, not build it all. I think I finally got it! I don't have to re-invent the wheel.

I have tried some scripts and a few work and a few don't but I am having fun, and learning.

Ron R