elfege
USA
Asked
— Edited
Has anyone figured out way to get the goto() function to work with variable so it can goto the last defined loop such as this :
$lastLoop = ""
:loop1
$last = "loop1"
left(200, 0)
sleep(100)
print($last)
goto($last)
this would allow to have the equivalent to calling a function and resuming the current loop after its execution. It would prevent me from using too many scripts and avoid lots of redundancies. My project currently has 50 scripts so I'm trying to find a way to shrink this number. 
I would suspect that you are flooding the communications channel by querying the sensors to rapidly. Increase the sleep command and see if that helps you out.
@wbs, that situation is not possible with ARC. If a script is already running, it will not run again. In a threaded environment, only one instance of a thread can run at once, because it is only a single instance. A thread is a single instance. A thread is not more than one thing, it is only one thing. Each control/script runs in a separate thread. Meaning, it is only one. One thing can not run more than once. You can only have one instance of one thing.
ARC will never crash from that scenario, nor will the communication drop due to that scenario.
Instead, the two previous versions of the EZ-B v4.x/0 and EZ-B v4.x/1 will drop communication if the connection is flooded. This is due to processor limitations of the wifi module and tcp stack buffer size. The most recent EZ-B v4.x/2 (shipping in April) will never drop communication channel because it has enough memory for a much larger buffer and significantly faster processing speed.
With the EZ-B v4.x/2, you can run a loop of getting and setting ports without a sleep(). This, of course, is not to provide an excuse for poor programming structure of excluding sleep()s even with the EZ-B v4.x/2.
However, the current EZ-B v4.x/0 and EZ-B v4.x/1 will drop the connection if too much data is received for the reason stated above.
There is a setting in the Connection Control config menu for data flood prevention for advanced users. There is a question mark which you can hover your cursor over for additional information on how to use it. It varies per CPU and Windows Installation. This data flood prevention value is ignored when used on an EZ-B v4.x/2
PS, look in the Examples folder that is included with ARC for a project called Procedural 4 (Threading). This will give you an example of how threading works.
Hi Guys, Thank you for any advice you can offer.Have uploaded my project file. It may look like a jumbled mess,hence needing advice on proper program organizing as well. Its a start at least. eyeroll
@DJ Are you saying that it is impossible to get a stack overflow? I have been concerned about this.
:DomeLimit If (GetADC(adc2) >2.5 and GetADC(adc3) <2 and GetADC(adc1)<2) Move(D2,"stop") ... goto(DomeLimit)
This will not eventually cause a stack overflow?
@rz90208 You can also pour sugar in your gas tank to see if you can "stuff up" your engine... What's your point? There is always a way to screw something up.. @DJ was just lamenting about the attributes of the new EZB4.1/2. He didn't say it was bullet proof
Correct - that will not cause a stack over flow. For example, this will not cause a stack overflow - ever ever ever ever ever ever ever ever ever (rinse, repeat)
The only issue that would happen from the example you provided was covered in detail in my previous post regarding communication flooding - which is not possible to happen using the EZ-B v4.x/2, available in April. I recommend re-reading my previous post for clarification.
It is impossible to create a stack overflow using the EZ-Script compiler and runtime. This is because the executor has a circular buffer on the stack, which is quite large - it's to the size that it doesn't make sense that any EZ-Script would ever need to recover with "returns" from a depth of over a million levels - or have a million conditions...