$PRO_NAME[], $PRO_NAME1[], How to use with extended submit interpreters?

i think you are doing it all wrong... read the manual... read pinned topic READ FIRST...use tools to find what you are looking for so you don't have to read everything. whatever software you use to open PDF files, it will have a search function. use it...!

1. you stated your KSS is 8.7... so first manual to check is system integrator manual for your guessed it ... KSS_87_SI_en.pdf

2. open the file and use CTRL+F to search for CWRITE for example. and in no time you should find "12.4.7 CWRITE: changes in relation to Single Submit mode" which explains everything you asked - both for single and multi submit, along with examples...

3. when asking for help, provide info... something that clearly describes steps taken, and responses observed. "i tried command out but got an error..." is useless. i cannot read minds... you need to at least say what error. or better yet, make a small example program that reproduces problem so others can try it out on their robot or OfficeLite.

Btw if some KRL program is running you cannot simply "cancel it" (deselect it)... when program is running, first you need to stop it... and once it is stopped, then you can deselect it.

back to your question "is it possible..."

of course it is possible to have multiple submits running side by side, starting and stopping each other etc. and i have done it many times. but one need to be careful, organized and check things. it is wrong to just fire command and hope for the best. this is something one does while exploring the functionality but this is not robust enough to be used in production....

lets say you want to start S3P0.SUB as extended submit 3 using

CWRITE ($CMD, STAT, MODE, "RUN/R1/S3P0() > 3")

while that line is needed - it is not enough.

first you may want to check if multisubmit is even available, so you need an IF statement where you decide what to do result is not what you expected. and you definitely want to check if extended submit interpreter #3 is free to use because it may be already running ... and you may want to check to verify that that 'something' is really what you expected... and what about spelling? what if it is a different case or extra characters like "/R1' etc?

I make my own libraries that make this easier. this way each routine handles what it is supposed to along with error checking etc. then main program becomes much shorter, clearer, and easier to manipulate.

Quote from spencmi

If not, i'm just gonna have to combine all of my sps programs into one giant sps...

that is very different from my mantra.... i write routines that can be called in any interpreter. debugging and testing is much better and quicker in robot interpreter. and each routine is created to evaluate, handle and report everything. then my submit is only handful of self descriptive lines. i dislike things like

$OUT[14]=TRUE

it need to be in form that everyone can understand... (people that are not programmers).

Quote from spencmi

.. If not, i'm just gonna have to combine all of my sps programs into one giant sps...

This would be my first choice in any case.

With using the process of panic_mode

Quote from panic mode

.... i write routines that can be called in any interpreter. debugging and testing is much better and quicker in robot interpreter.....

I personally hate stopping/starting background processes by background processes. Makes things unnecessarily complicated and prone to errors.

Quote from hermann

This would be my first choice in any case.

With using the process of panic_mode

I personally hate stopping/starting background processes by background processes. Makes things unnecessarily complicated and prone to errors.

maybe i was not very clear.... i too recommend avoiding of stopping/starting background processes by background processes. very few people are capable of making this robust, and long term maintenance is always an issue. what i meant is that my preference is compact and readable submit code (utilizing modular architecture).

i hate to see things there that are ambiguous or require interpretation. that includes names of the signals... and logic... i like that all logic is tucked away into some suitably named module, tha is only called from Submit...

calls are easy to manage, comment out...

for testing/debugging they can be run in robot interpreter...

i do NOT like to see 10000 lines submit... i would rather see something like this that ANYONE can interpret ... without any programming knowledge

DEF SUBMIT_X()

LOOP

  IF PB_Reset_All THEN
     Initialize_All()
  ENDIF
  
  Logger()
  Gripper_Control()
  Conveyor_Control()
  Access_Control()
  ;Monitor_Drawers()

ENDLOOP 

END