Script was probably executing faster than pins could respond to that particular command (flooded data channel. Scripts steps execute with 0 delay unless you add one. Put a 1ms sleep between the steps and you will see it toggling at 1ms.

The digital ports can send serial at I believe 300,000 bps (and the ones which are UART can receive at same speed) so, your test is invalid, not the speed of the script or port. (datasheet should have the max serial speed. Answering from my phone so I can't look now, but it is in the EZ-B v4 tutorial).

Alan

Hi, Alan. The script inside my PC is certainly very fast ! You say I'm flooding the data channel with too much information. I toggled every 100 ms. It's very slow speed.This shouldn't be too fast for a 300Kb channel ! My script did only the toggling, nothing else. Toggling at the pin has a very random period of about 2-3 seconds(!) Something else should be flooding the channel and disturbing the timing (from the Movement Panel or somewhere else)

So you are saying the script toggled, slept 100ms then toggled back and repeated? That should have worked fine. What I was saying is if you had no sleep statement of any kind your script could flood the data channel with so many commands that the EZ-B would only catch occasional ones which would exhibit that symptom.

Alan

Leonardo,

I think you are comparing Apples with Oranges.

The fundamental difference between your PIC and EZR solution based in a ARC.is where your robot code runs.

1. When you program in assembly, C or SPIN, your code is compiled on the desktop and uploaded (flashed) to the micro-controller. After the upload your code will be executed on the micro-controller.

2. When you use EZR/ARC your EZ-Script is parsed, evaluated and executed on the fly on the PC, every-time you need to perform a hardware operation (read, write, pwm, etc) ARC. sends the request to the micro-controller (EZB) and the request is processed on the EZB and if there is value is returned to ARC.

The request is synchronous that means ARC.sends a command and waits for a response (applies only to read/get commands)

Another important aspect even if you have multiple scripts running at the same time ARC.has a Queue and only one hardware command/request is executed in the micro-controller.

If you have one bad script e.g. a loop with an analog read, no delays it's easy to understand you will have a problem.

Why ?

because the loop cycle without any delay will run as fast as possible but everything else (other scripts or ARC.actions) will be affected.

Micro-controllers are more limited than desktop but they provide real-time predictable, synchronized execution and response to events (timers, interrupts)

In the next post i'll provide and example how real-time can be an issue.

Take this EZ-Script example:

:loop
ToggleDigital(D0)
Sleep(1000)
goto(loop)

Reading the code, you will say Toggle the port D0 every 1000 ms/1 second ?

the reality when you measure the execution cycles you will get:

1012 1007 1013 1015 1001 1251 1023 1022 998 1001 1060 1011 1493 1003 1003 1007 1002 1004 1002 1016 1000 1020 1000 1006 1428 1035 1038 1004 1021 994 1003 1016 1000 1003 1014 1002 1004

Note: milliseconds between each toggle/cycle (measured at the hardware side):

so let's remove the delay, to see how fast the code runs.

:loop
ToggleDigital(D0)
goto(loop)

result:

251 225 18 29 236 248 292 204 25 237 250 274 13 208 22 239 250 308 188 40 7 217 249 279 221 23

So the question is how fast is this ?

Do you trust your code to implement a loop to run syncronized each 40 ms, 400ms or 1000ms ?

So to make short if you have a script that is sensitive to timing (reading pulses, kalman filters, time based data e.g. combining gyro & compass & accelerometer data) writing pulses, you need to run the code on the micro-controller.

I understand very well what you said. To avoid communication problems, my script has to run slow or it could flood the communication channel, and something could be delayed or even lost ! This is difficult to manage! I now understand why my code in ezb seems sometimes to behavior in an impredictable way !

It just takes a little different thought process from what you are used to. You'll get it soon.

Neither way of thinking about the tasks is inherently better, they are just different. A lot of people combine EZ-B with Arduino or custom PICs to get the best of both worlds.

Alan

Alan,

mentioned something which is my option too:

Quote:

Neither way of thinking about the tasks is inherently better, they are just different. A lot of people combine EZ-B with Arduino or custom PICs to get the best of both worlds.

ARC is a high level tool, hides a lot of boring details, but, it's important to understand what's going under the hood.

When you can't do it at high level, you buy a EZ-Bit, shield, or you add your favorite micro-controller to the solution.

ptp , in addition to possible channel flooding, you say there is also no guarantee about the time needed to perform each operation . To be sure, you have to avoid everything that's time-critical. The question now is: what can I use ezb for? perhaps only as a wi-fi communicator for simple operations. No complex processing seems possible.

I thought I could make robots using only EZB, no PICs. Now I know I was wrong . Ezb needs some pic to help.

Not necessarily. It depends on what you want the robot to do. PICs are good for high precision repeatable functions. EZ-B /ARC is good for highly intelligent flexible functions and fast development.

For a few advanced users, PICs add useful adjunt capabilities, but for many many more users (10's of thousands of EZ-B's sold) the EZ-B is sufficient.

It really depends on what it is you want your robot to do.

Rather than starting with testing the limits of the platform, better to determine what your end goal is and see if the platform can perform that goal. Lots of us participate here to provide assistance and review your scripts and projects to help make sure they are performing optimally based on the functions you are trying to achieve.

Alan

Ok ,Alan. Help me to understand if my project might be EZ-only-no- pic .

I had made a simple rover, with 3 sonars and a pic, going about at 10 inches per sec , capable of avoiding obstacles and searching for alternative paths when approaching them. To achieve that i had realtime a/d conversion of analog sonars, comparison and processing of their data, decision of alternative paths and actuation of motors. All done by a pic.

Then I thought "let's see if i can do the same thing using ezb only". This way I could learn to use this interesting new tool and possibly make complex robots with less hardware and easier software to implement.

I wrote scripts to do that with ezb, and at once faced big problems. Statements were not executed, or executed in a random and impredictable way. It seems that there are communication problems, even if it works at 3,5 Mbit/sec (!) as says the datasheet. PC has to ask EZBv4 for frequent reading/a-d conversion/ comparison of 3 sonars, then say to ezb what to do. Is this hard word work for ezb?

Are you using Analog sensors or digital sonar sensors? Analog sensors do have much slower read time and need sleep statements between the reads to prevent data channel flooding. The upcoming EZ-B v4/x2 (there will be upgrade kits available) dramatically increases the number of analog reads per second, but will still require careful scripting.

Here is a link to a script that does what you describe but using a single digital PING sensor. It could be pretty easily modified to use multiple sensors or analog sensors.

https://synthiam.com/Community/Questions/3449

and updated with lots of notes:

https://synthiam.com/Community/Questions/4750

Alan

Thank you for that intersting information. Meanwhile, I managed, with the help member "PTP" , to have a code working well enough with my robot and sensors. I'll study it , to get a know-how in scripts. Programming that way is new for me, being used to basic or assembler on pics. I'll try to learn.

One thing I have learned: Pc+ ezb can do many things, but cannot be the solution if you want a very fast, precise, and stable closed-loop control system . If so, you need a local control system. EZb would be great in giving it commands, getting digital and/or analog data, etc.

Scripts can be as fast as you want them to be. There are settings for each frame. One of them is the speed You can change it to be -1, 0, 2 etc.

@learnado you got it - that's what has been stated to you since the first question. You can also read more about it in the explore section. Closed loop control systems are best to be microcontroller based with a single function. The ezb can talk to the micro and give it instructions. But the ezb should never ever ever ever ever be considered a realtime control system, because it is absolutely not a realtime control system and nor is it promoted as such. Much like your computer runs Windows, it is also not a realtime OS and depends on hardware peripherals to do specific tasks.

Lastly, consider your automobile. It has a stereo and an engine an seats and wheels and Windows and and and... Well, they are all separate systems that form the "automobile". All advanced robots are constructed the same way - so are airplanes and your house and even your clothes.

With the ezb, communication depends on wifi connectivity. You can read more about wifi using Google. Wifi is a wireless technology for connecting devices via communication protocols. The most common protocol used for Internet and connected devices is tcp over ip. The ezb also uses tcp. There are many many many many many many layers between the software and the ezb - including wireless transmission. Wireless transmission cannot be real time, nor can the stack of driver and OS dependencies...

OK, DJ. Everything has its job. To check an analog signal crossing a thereshold is better to have an hardware comparator, giving its output in 50 nS ! Years ago I wrote a musical program playing music from a PC. Compiled basic and a fast PC. It should work, I thought. But music seemed played by an insane musician, and I understood that PCs are not real-time systems.