Hey all - I'm hoping I'm just overlooking something really simple here. Fanuc allows for multiple asynchronous tasks to be executed using the "RUN" command. This allows for logic handling in the background without interrupting the active robot program. Is there any way to do this with KSS that doesn't involve the SPS? We have an application where we need a background task handler that would include some WAIT statements, so obviously I don't want to call those in the Submit Interpreter. Anybody have any ideas? KRC4s with KSS 8.2.
KSS: running asynchronous modules?
-
Metalikooky -
September 18, 2014 at 2:17 PM -
Thread is marked as Resolved.
-
-
I guess you don't have Multi-submit mode on your KSS8.3
-
There's a multi-Submit option for the KRC4s? WHY DOESN'T ANYONE TELL ME THESE THINGS!?!?!
Kidding aside, you can still do what you need in the SPS, without using WAIT commands. It does require some rather adroit programming, though. I had to do something like this and ended up creating a state machine architecture in the SPS to accomplish what I needed.
-
I found this "KUKA.PLC Multiprog 5-35 uses the ProConOS runtime system to execute PLC applications." in kuka's docs
-
Metalikooky
you can probably use triggers and/or interrupts to do your waits, explain what you are trying to accomplish and somebody should be able to helpSkyeFire
multi submit will be default as of KSS8.4.X , possibly end of Q4 2014
Pressing on "S" display list of current active submits that you can stop/cancel
irobot
SoftPLC is replacement for hardware modules (AB,Siemens, etc...) to control production cell logic.
Multiprog lets you develop PLC type code (leader logic,structure text...) that KRC will execute with dedicated CPU process (ProConOS) -
I found this "KUKA.PLC Multiprog 5-35 uses the ProConOS runtime system to execute PLC applications." in kuka's docsYes, but ProconOS is an option package for the KUKAbot that you have to buy, and it's a pretty substantial one. Serious overkill for something that could be done with the SPS, not to mention needing an entire separate programming language of its own. It's a great package, and I love it, but it's like shooting a mosquito with a shotgun, in many cases.
-
Holy smokes I forgot about this thread! We've been pretty busy with setting up some new cells. Thanks everyone for getting back to me.
Regarding our particular application for this requirement, we don't really have one. I was developing a Fanuc application where we used a Background Task and that got me wondering about how to do it with a Kuka.
The state machine programming in the SPS sounds like the best way to go for us since we don't have any 8.3 robots yet.
Thanks again!
-
Hi Guys!!!
I am developing a Robot application with KSS 8.3.11. I would like to develop an application with multiple background tasks running in parallel i.e. like multiple submits running in background.
I have an application to control the Robotic Cell logic which has a table, safety door and I have some wait conditions so I was wondering to have the logics in separate sub file to avoid these waits.
How could I develop such an app?
Thanks
-
It's entirely possible to do it in a single SPS file -- I've done it. It does require careful programming, usually involving creating a state machine.
Failing that, you might inquire if KUKA has the multi-SPS option available as an add-on for your robot, but you'll have to pay for it.
-
Thanks Skyfire!!!
I may try using state machine. I do not have an add-on of multi-SPS option. I could guess it would be tricky to do it in single SPS. Could you help me with a short example?
Thanks
-
In SPS programming, the key insight is (not hexepodia) that you cannot (well, really really should not) do anything that would stop the program pointer. So, no WAITs, no loops (aside from the SPS's own main LOOP/ENDLOOP). But you still need a way to cause events to happen in sequence, waiting for inputs or certain conditions. The answer is a State Machine, or something similar. Basically, you create a variable that holds the current state of the SM, and that variable only changes state under certain circumstances. As long as those circumstances are not met, the SM remains in one state, while the SPS program pointer continues to run unimpeded. This is a very bare-bones example:
Code
Display More; in SPS.SUB State = 0 ; init state machine on cold boot or SPS restart ... LOOP ; SPS main loop SWITCH State CASE 0 IF $IN[1] THEN ; 'wait' for input from PLC $OUT[1] = TRUE ; signal PLC that input was received State = 1 ; change state ENDIF CASE 1 IF NOT $IN[1] THEN ; 'wait' for PLC to signal it received $OUT[1] $OUT[1] = FALSE ; complete handshake State = 2 ENDIF CASE 2 IF ($ASYNC_STATE == #IDLE) THEN ; 'wait' for async-motion buffer to be empty ASYPTP {E 0} ; move E1 axis to 0 State = 3 ENDIF CASE 3 IF ($ASYNC_STATE == #BUSY) THEN ; 'wait' for E1 motion to begin State = 4 ENDIF CASE 4 IF ($ASYNC_STATE == #IDLE) THEN ; 'wait' for E1 motion to finish State = 0 ; return to initial state ENDIF DEFAULT Sate = 0 ; reset if State value becomes invalid ENDSWITCH ENDLOOP
That's a very crude example, but it conveys the general idea. Finite State Machines can be as insanely complex as you want them to be (loops, branches, etc) -- the trick is that you have to control the transition from state to state, and avoid dead-ends or duplicate states.
-
Thanks Skyfire!!!
In SPS programming, the key insight is (not hexepodia) that you cannot (well, really really should not) do anything that would stop the program pointer. So, no WAITs, no loops (aside from the SPS's own main LOOP/ENDLOOP). But you still need a way to cause events to happen in sequence, waiting for inputs or certain conditions.Can I call a module (.src ) from Program folder in sps to generate some messages. I believe it should not stop the program pointer as it does not have any wait or loop, etc.
The answer is a State Machine, or something similar. Basically, you create a variable that holds the current state of the SM, and that variable only changes state under certain circumstances. As long as those circumstances are not met, the SM remains in one state, while the SPS program pointer continues to run unimpeded.How state machines justify the principle of parallel computing? As you said SM will stay in same state until unless certain conditions would not be fulfilled. Well if I understood correctly the concept of parallel processing then we have simplest example of our PC in which we can work in doc/excel and same time we may listen music as well.
I want to have something like this in background:
1). Reading/Writing data to/for Robot-PLC interface.
2). KRC controlling the peripheral equipments like safety door, tables, etc.
without mutually affecting each other.I this can be achieved by existing solution from KUKA or the answer is to have multiple submits ?
Thanks
-
You can call .SRC modules from the SPS, as long as those .SRC modules do not contain any forbidden instructions (motion commands other than ASYPTP, changes to $TOOL or $BASE, etc). The tricky bit about SPS programming is that commands like WAIT, and 'dead-end' loops, are not explicitly forbidden -- you can put them into the SPS and the SPS will obediently execute them, but that will break the "endless run" concept model of the SPS.
Managing I/O between the robot and PLC, and managing perimeter safety devices, are tasks that are often done with the SPS (with the proviso that the SPS is not a safety-rated system). No multiple-SPS is required, although that would make it easier.
Basically, you can do anything you like with the SPS as long as it does not impinge on robot motion. You simply have to program adroitly.