ESP8266 Community Forum

If a running script is causing problems I don't know how else to stop it other than a reboot.
Might it be worth including a [Stop] somewhere on the Edit page to stop a script from continually running (even when it's being edited in the browser)?

More...
I've noticed that some errors may be flagged, but despite seeing an error the parser still continues parsing (as mentioned about the new serialinput example 'turkey' problem in latest News.
This even happens after flagging up an unknown branch error, so it's anyones guess where program flow could end up after that. I don't know anything about what's under the hood, but would it not be better for the parser stop on all errors if it was possible?

But that aside, it seems the parser keeps parsing indefinitely unless it comes to END or crashes and reboots. The ability to continually loop may be what is wanted - perhaps for continually monitoring an input pin etc - but it does pose a bit of a problem during development.

Lets say I want a continual loop to monitor an input pin (eg: gpio00 button).
I Save it, and Run it. But let's say something isn't right, so I click Back in the browser to return to the Edit screen and make changes... but the edits can't be Saved, because the ESP is still busy continually looping the parser rather be interested in listening to the browser Save command (or anything else for that matter). So I'm not sure that having a Stop or Halt button in the browser would be effective in such a loop situation, unless the parser can be made to periodically check for browser commands even when it's busy.

The only way I know of stopping the free-running parser at the moment is by doing a reboot and quickly saving the edits after reconnection before the program gets autorun into another endless loop again - it's certainly possible... but it's a less than ideal situation for unconfident newbies to find themselves in.
So is there a better way?

I suppose a quick-fix could be to monitor the gpio00 button, so it could be used to stop the parser when running as well as break out of autorun to prevent the parser even starting.
But that would prevent gpio00 being able to be used for anything else, which would be a shame. Perhaps a relatively simple? solution to that might be a gpio00 behaviour Dropdown on the Edit page which might allow users to assign required behaviour to the gpio00 button as needed, perhaps with options of Ignore, No autorun, Halt parser, No autorun and Halt parser - so the parser would check any appropriate behaviour flags that were set and adjust it's use of gpio00 accordingly.

Just some thoughts and ideas in case anything is helpful.

you could add an end button or routine that you could use any time.

button "Stop" [Stop]
[Stop]
end

simply add this to your code for a stop button
or you could hook up a button to an unused gpio if you want and when that button is pressed have it go to the Stop routine through the use of an interrupt.

There is a reboot button.

In order to interrupt your code the stop button needs to be within your code unless espbasic editor just adds this for you automatically as the first lines of code and uses a 1px x 1px button so that it is hidden somewhat from the user. But if someone acceidently clicks on the pixel it will stop the code so maybe an alternate method would just be listing the routine and somehow having the button from the editor page access the routine through msg branch possibly or something similar.

This would mean that every code would have injected stop code in it there are some reasons possibly or people who may not want this IDK you may want to stick to implementing such a thing yourself possibly.

A stop button or stop message branch just because it is there does not need to be used.

this code would allow easy stopping

msgbranch [mybranch]
wait
[mybranch]
MyReturnMsg = "Not a valid msg received"
msgget "stop"
if stop == 1 then gosub [endpgm]
[endpgm]
cls
MyReturnMsg = ".............:::::PROGRAM IS HALTED!!!"
delay 3000
end

to call this it would simply require you to type the following in the web browser

http://192.168.x.x/msg?stop=1
or AP mode
192.168.4.1/msg?stop=1

This would stop your program dead in its tracks

I'm afraid you totally got hold of the wrong end of the stick, forlotto.
The problem I was drawing attention to was the fact that the parser has an ON control but no OFF control.
And at the time of writing, the Alpha release was suffering mental instability problems and blundering blindly on regardless of mental ill-health, even after suffering terminal program errors... it was a mindless rampaging zombie without a an OFF control!

I had already mentioned tough self-defence measures of reboot and gpio button for stopping the program, but such weapons should only be considered desperation last-resort for use by asylum staff, not standard issue for the general public.

I have since seen mmiscool state that the parser is stopped when Run is pressed... but that's not really a Stop cos it's a certain re Run - or when Save is pressed... but sometimes (more often than not with my bloatware program) the parser is too busy doing it's own thing to even notice the Save being pressed (or doesn't respond to it anyway). This was more apparent in pre A17 when any Save that didn't return the ok acknowledgement inevitably required a reformat and reflash. In A19, ignored Saves can be re-clicked repeatedly and perhaps may eventually do a save and return an acknowledgement, but that can hide corruption which would only show up if clicking Edit first - and why would you be doing Edit if still trying to Save your previous Edits.

That same percentage of 'iffy' absent-minded Saves also seems to affect the running program, cos half the time some things that just worked don't work next time, but may work again the time after that. This is particularly noticable after viewing any of the ? doc pages.

The lack of consistency means there is nothing apparent to debug and no may to progress, so has forced me to abandon the udp network demonstrator program I was working on. I have included it below for you to try and see for yourself if you like, particularly as you mentioned the lack of udp examples elsewhere. There are web buttons that cause the node to BlinkIP it's IP address, Blinks blue led for node location purposes, toggle a relay, etc. All these functions can be triggered locally by web buttons, or remotely via udp instructions, or locally via udp instructions. Each works most of the time, but if a hiccup bug occurs somewhere it may not show up, and then the zombie parser thereafter stumbles blindly on regardless of errors, and can corrupt the flash memory which is not apparent just by doing a Save or Run, it only shows up by doing Edit, and then only fixable by doing an inevitable full reformat and reflash. I got to the point of trying to test the Ping Pong network interaction between to 2 network nodes, but was spending too much time constantly reformatting and reflashing, so I decided to call timeout and start writing a book!
Speaking of which, if you do try the script, click on the top left ? button for all the info you should need regarding the program. As I said, I don't know if interactive Ping Pong works between nodes yet, but the idea is that you send NAME SERVE (name can be a specific node name or ALL) in the msg window, and a receiving node would reply with BALL, and the 2 nodes then keep batting BALL between themselves, toggling the onboard blue led each type. ALL DELAY 1000 would add 1 sec delay between responses, and ALL STOP should end the interaction.

So it's not a matter of issuing public Stop weapons to take the rampaging zombie down, it's a matter of keeping the zombie contained and controlled to prevent it rampaging on the public. And I suspect that would be more a matter of making the zombie parser Stop itself on all errors, rather than stumbling blindly on past them. I also suspect it's only a noticable problem in a larger program with many alternative branch paths, but the present consequences mean that although examples are ok, any larger 'real-world' programs are currently impractical.