Not the forum - surprisingly the forum is a good place to escape. This week has been frustrations programming with a library that is incomplete and full of bugs. I've spent the last week - 18 hours a day - fixing someones bugs in a framework before I can use it.

This forum stuff is a breeze!

@DJ.... We do our best to keep you entertained.... Now you got us all excited about the ezb4 1/2 and other goodies you are working on....

oh yeah! 2016 is a big year - boy this thread got really off topic. Think of it as chatting while we wait for the project to be posted

While we wait for your project, here's the latest update which will not auto-start the camera when it's added to the project for you: https://synthiam.com/Community/Questions/8766

Also there is a performance setting for data channel flooding, which may be of help to you. Information about it is in the link above. Also, there is a help hover icon on the setting in the software.

Let me know!

indeed, @DJ, this is certainly a question of discipline in the scripting that I don't always apply to my programming in EZB. EZB allows for some... very inspirational scripting sometimes !

For what regards the camera issue it switches sources by itself, no apparent reason beside the fact that it seems to happen after some connectivity bugs. It does not happen between close/open ARC actions.

Thanks again.

here it is, sorry.

FYI the performance data channel did improve the whole thing a lot! Thanks!

Thanks for posting - here's some information to help your project. BTW, great project with lots of features, it was fun to review!

1. Many loops that are eating up resources without Sleep(). A loop without a Sleep() will use as much CPU as available. This means it could potentially use more CPU than even the camera video stream. A Sleep() allows the CPU to do something else.

2. Code formatting will make logic errors easier to notice. The ALT-F shortcut when editing code will automatically format code for you. There are many logic errors in conditions - specifically redundant conditions in nearly all scripts. Although if the logic works, it really only uses additional resources, but it is a good idea to format the code with ALT-F. It will help in the future when code is revisited. Also, with the latest ARC, there are dramatic stability improvements which will benefit from the number of scripts that your project uses.

3. With plenty of Read commands, the project may benefit from tweaking the data channel flood setting in the Connection Control Settings. There is a question mark, which you can hover the mouse over to read how it works. Use the benchmark utility in a blank project to experiment with a value which is right for your PC and network. This will dramatically increase READ performance (on my computer from 5 reads per second to 70 reads per second).

4. The comment #3 also applies to the number of Digital Controls and GetDigital() commands redundant in code. The Digitial Controls and the GetDigital() EZ-Script commands are both reading from the same digital ports. This means twice (200%) the number of communication channel reads, which is an excess amount of unneeded data requests, resulting in 200% less performance. This also applies to the ADC as well - as there are meters and getadc() commands redundant throughout the project. My recommendation on both ADC and Digital is to set variables and use the Variable Watcher to see their values.

5. ARC version appears to be quite old. As mentioned, there have been dramatic stability and performance improvements with newer versions. Specifically the way the EZ-Script engine handles threads - and the ability to adjust data channel flood protection. Your ARC version 4 months old.

[feature] <EZBuilderVersionMajor>2015</EZBuilderVersionMajor> <EZBuilderVersionMinor>8</EZBuilderVersionMinor> <EZBuilderVersionBuild>9</EZBuilderVersionBuild> [/feature]

6. The Mobile Interface has a camera control with a strange address. It appears the address is for an IP Cam? If so, the address field of the mobile interface is for EZ-B v4 cameras, not any camera. By default, the mobile interface will display the video of the first camera control added to the project. I'm not certain what the behavior would be on a mobile interface with an IP Camera URL specified - but i can be quite accurate to say it won't work due to the protocol being specific to EZ-Robot.

http://192.168.11.179/videostream.cgi?rate=0&user=elfege&pwd=*******

Let's take a look at one of the scripts which stands out. Here's an example with the Reconnect All in Script Manager.

The Original Code:

:loop0
 if(isconnected(2)=1)
ControlCommand("Script Manager", ScriptStart, "PowerON")
 goto(loop)
 else 
 ControlCommand("Connection", connect2)
 endif 
 if(isconnected(2)=1)
 ControlCommand("Script Manager", ScriptStart, "PowerON")
 goto(loop)
 else 
 goto(loop0)
 endif 
 
 
 :loop

 if(isconnected(0)=1) 
 if(isconnected(1)=1)
 if(isconnected(2)=1)
 
Print("All boards are connected")
goto(continueboot)
endif
Endif 
Endif 

if(isconnected(0)=0)
sleep(100)
ControlCommand("Connection", connect0)
endif 


if(isconnected(0)=0)
goto(loop)

endif 

 if(isconnected(1)=0)
 sleep(100)
ControlCommand("Connection", connect1)

Endif
Goto(loop)

:continueboot
halt()

There are no delays in the above code, which will use as much CPU as available. A loop without a Sleep() will consume literally as much CPU as it can. So, unless this is the most important script in the project, even more important than the camera control or anything else, it should have a Sleep() in there.

Also it has redundant conditions, which i notice happens often in nearly every script. This can cause our human brains to sometimes struggle when re-visiting the code. Always a good suggestion to revisit scripts and condense/format them. We will never write a perfect script the first time.

For example, here is the above script modified. You will notice how I used logical conditions to prioritize which board is connected first, as duplicating the desired functionality that I believe the original script was attempting. Also I have added a delay in the loop to be friendly on the CPU. Lastly, the code is formatted nicely which makes it easier to read, specifically if revisited in the future.

:loop

# board #2 we want connected first
IF (isconnected(2) = true)
  ControlCommand("Script Manager", ScriptStart, "PowerON")
ELSE
  ControlCommand("Connection", connect2)
ENDIF

  # board 0 is connected second
IF (isconnected(2) = true && isConnected(0) = false)
  ControlCommand("Connection", connect2)
ENDIF

  # board 1 is connected third
IF (isconnected(2) = true && isConnected(0) = true && isConnected(1) = false)
  ControlCommand("Connection", connect0)
ENDIF

  # if all boards are connected, let's get outta here
IF (isconnected(2) = true && isConnected(0) = true && isConnected(1) = true)

  print("All Boards Connected")

  halt()
ENDIF

sleep(100)

goto(loop)

Haha, now this isn't an issue but i love it - because I do the same thing. I see you used excel to create a list of commands. Smart man! Great minds work alike

set       (         D1        , off)
set       (         D2        , off)
set       (         D3        , off)
set       (         D4        , off)
set       (         D5        , off)
set       (         D6        , off)
set       (         D7        , off)
set       (         D8        , off)
set       (         D9        , off)
set       (         D10       , off)
set       (         D11       , off)
set       (         D12       , off)
set       (         D13       , off)
set       (         D14       , off)
set       (         D15       , off)
set       (         D16       , off)
set       (         D17       , off)
set       (         D18       , off)
set       (         D19       , off)
set       (         D20       , off)
set       (         D21       , off)
set       (         D22       , off)
set       (         D23       , off)