SPS crashes because $PRONAME[] invalid

well.... first identify line of code that causes problem.

there are different ways to do that:

one of them is to use Single Variable Monitor and change $INTERPRETER to 0 (when no MultiSubmit is installed) or 2 (when Multisubmit is installed) and select some robot program (anything) so you can look at the SPS code as it runs and stops. This will reveal line wihere instruction pointer in the SPS and htis is where the fault is. when done, change $INTERPRETER back to 1.

another is to monitor system variable and find where instruction pointer is

another is to comment out blocks of code until problem stops appearing. this is a brute force method and therefore it is least preferred.

Using VARSTATE for something like this is not reliable, due to the asynchronous relationship between the Level 0 and Level 1 interpreters.

My guess is that the error is happening on Line 2. I would put an ON_ERROR_PROCEED immediately before this line, and then fence in the following code with an IF statement checking the value of $ERR.

first find the line of code that produces error. no point in stumbling in the dark.

i

Probably a typo in the Message database, that hasn't gotten any attention because it's not actually breaking functionality -- the dev team probably has higher-priority items on their task list.

well... can't say much without seeing whole code and screenshot at the moment of crash and values....

but i would avoid temptation to copy a string in KRL like that. it is bound to have problems...

KRL does not have a string type so KRL strings are really character arrays. consider this example:

DECL CHAR pr1[24], pr2[24]

pr1[]="hello world"

pr2[]="bye"

pr1[]=pr2[] ; problem..... pr1[] value is "byelo world" since previous content was not erased.

even KSS included string functions have ... issues. and i mean a lot of issues...

for example i had experienced where they corrupt memory (kill drives, crush HMI etc.) and require restart plus all kind of weird messages.

also they don't work across arrays of different dimensions etc. (or at least not correctly)

for that reason, i hesitate to use them and prefer to stick to my own functions.

fortunately array manipulation is simple though it adds to program code length.

Panic is correct. For a good example of string/char-array manipulation, with bulletproofing against errors, I'd suggest looking at MSGLIB.SRC, which comes in every KRC4, located (usually) in /R1/System/.

Did you solve this problem? We are having exactly the same problem. This error message comes sometimes when we are checking out whether the specified program name is selected.

The biggest problem is when after the "proname[] " error our own multi submit program stops to run in the background.

i do tons of string manipulation, use multi-submits all the time constantly starting/stopping one task from another, using code to evaluate and log what is running etc. and don't have a problem...

so problem is clearly with trying to use that kind of code.

as mentioned KRL does not have STRING data type. that's it. so stop treating it as a string, treat it as a character array that it really is.

strings will show anything that is before first null character. and if first character is not null then string is initialised. everything after first null is ignored. a common way to "erase" string is to put zero in first char, without overwriting every single char.

arrays on the other hand are different animals. if at least one element (in this case char) is initialised, then array variable as a whole is deemed initialised.

so do not check if $PRO_NAME1[] is initialised to see what is happening with task, use $PRO_STATE1.