My occurrences of this are substantially lower than a few months ago but I am still seeing it.
Generally extended delays (more than a few minutes) are on the Toolbox side, not the processor side because PuTTY can connect and get a prompt when Toolbox refuses to.
If I can't get the processor to stop the program cleanly I delete the DLL (*.DLL) files from the app folder on the processor and then stopprog.
Either the program stops cleanly or it doesn't and when whatever process protection timer in the background gets irritated and tried to restart the program it fails because it can't load the DLL files.?
At that point if Toolbox is playing game and I'm not too aggravated the program can be loaded normally, otherwise FileZilla and progload command here I come...
Get
toggle quoted message
Show quoted text
What's the current best practice on stopping the program (so you can load new code)?
?
I've been using...?
PROGREG -p:1 -u
KILLPROG -p:1
?
But I see an old post where Dave H recommended...
STOPPROG -P:#
PROGREGISTER -P:# -U
DEL \SIMPL\App##\*.*
?
And someone else recommended just...
KILLPROG -p:1
?
The first method usually works for me, but occasionally things still get locked up for 20-30 minutes before I can get a prompt to do an INITIALIZE and get it back. I haven't tried getting web access to the processor when that happens (will try that next
time). I wonder if Dave H's third line (deleting the app folder contents) would keep me from having to do an INITIALIZE. I've also been using the Toolbox transfer dialog to send the new code, so maybe I need to switch to transferring via FileZilla and then
sending PROGRESET -p:1. I'm also using Toolbox Text Console for the most part, so should I switch to PuTTY or something like that?
?
--
Josh Winn
The LiquidPixel Group
