Communication strategy with PLC to inform a specific program is completed

I think the easier way would be create some kind of "job done" signals, and set them at the end of each program.

This way PLC would know what program was done inside the sequence, and what isn't.

Most of the time, this is just based on seeing PGNO_REQ going True, which only happens once the production program is complete and the robot is back in CELL waiting for a PGNO (or if the Program Reset has been carried out). If the PLC knows that it's most recent PGNO handshake started Program X, then when it sees PGNO_REQ go True again, it's a fairly safe assumption that Program X just finished (again, barring special cases like a Cancel/Select or Program Reset being carried out).

But, if you need something explicit, you can add code to CELL, like so:

SWITCH PNGO
CASE 1
  P00(#EXT_PGNO, #PGNO_ACKN, DMY[],0)
  Program1()
  WAIT FOR TRUE
  O_CompletedProgram = 1
  WAIT FOR I_CompletedProgram == 1
  O_CompletedProgram = 0
  WAIT FOR I_CompletedProgram == 0

In this case, I'm assuming that O_CompletedProgram is a SIGNAL output of several bits, and I_CompletedProgram is an input of matching size. So when Program1 is completed, this explicit handshake is carried out to confirm that Program1 has been completed, and that all the handshake signals are set to 0 before continuing on to set PGNO_REQ and start the next program-start handshake.

Some code to set O_CompletedProgram to 0 would need to be added to the INI section of Cell, just in case a Program Reset was performed in the middle of Program1

line 5 does not hurt nut it is not needed since following ones are using I/O

I use variable CURR_PROG_NR which is unique for each sequance and is mapped to plc as 8 bits. Whenever plc sends pgno to robot, cell will execute routine assigned to that program nr. When robot interpreter gets inside the routine im assigning same value to that variable and when routine is at the end im resetting that value to 0. That's how i transfer information to plc not only about the sequance was executed but which one was just done as well.

But just for monitoring purposes whether the routine is executed you can monitor existing signal: APPL_RUN, so I don't think there is a need of creating another signal as massula suggests. No harm but why not using something already existing.

Quote from massula

I think the easier way would be create some kind of "job done" signals, and set them at the end of each program.

This way PLC would know what program was done inside the sequence, and what isn't.

Quote

I do this because I have 8 different KUKA programs that are executed at different times by 8 different functions...

where are those functions? PLC?

Quote

BUT there is a problem... sometimes two of these functions are at the same point in life... they both want the robot to do something at the same time.

implement priorities so when there s a competition, pick one with higher priority

on the KRC side there is no need for this since PGNO is a number and each value is unique. you cannot have two values at the same time.

you can have two values changing quickly for example but this is what handshaking takes care of, there is a sequence to it and manual explains it with timing diagram. so the only place where conflict can happen is if the PLC logic is flakey...

at the end you have an SR that latches and keeps output active. get rid of it...

output of last & should drive PGNO_VALID directly. this way as soon as PGNO_REQ is low, also PGNO_VALID goes low.

and if you do need to use "DB".SR8 because of way your code works (maybe "DB".SR6 does not reset after step is completed) then

invert it and AND it with the other logic, something like:

Quote from Koppel

but KUKA complains that it waits for PNGO_VALID to be not true

The beginning of CELL.SRC's main loop waits for PGNO_VALID to be False before it sets PGNO_REQ and starts monitoring PGNO_VALID. This is to protect against situations where the PGNO value gets "stuck", just like what you are experiencing now. The PLC should never be sending PGNO_VALID unless the robot is sending PGNO_REQ.

I Have a similar use case. What works best for me is to queue requests on the PLC and set priority within the queue if needed. I do this but using a single point of entry i.e. all 8 functions talk to the robot through a single interface. Set a busy flag to true when any of the programs starts a robot request and then have the functions wait for the busy flag to be false before selecting a program to run.

It might take a little more work to structure the PLC code, but i think its worth the effort.