Monitoring Alarm in sps program

Whats your your "Alarm" exactly?

• Emergency Stop?
• Some message that needs to be acknowledged?
• Loss of drives?
• ...

Fubini

if by "alarm" you mean message, look for message number then for example add in your submit something like

$OUT[whatever]=ISMESSAGESET(message_number)

Quote from mcasa0802

The application is for a polishing tool on the EOAT, rotary motor that I MUST stop if the robot stops moving. If Robot Errors, Alarms, Motion stops all axis, then turn on Digital Output. Need to monitor continuously so was thinking of placing this code in the sps.

Doesn't necessarily need to be the SPS. Depending on your system configuration, you might be able to use $ALARM_STOP (program stopped by some error), or $PROC_ACT (program running), or $PRO_MOVE (robot physically in motion).

Any signal or variable that starts with $ is a System Signal or Variable. Many of these are constantly updated by the operating system, regardless of what the robot program or SPS are doing.

For example, if you use an SPS program to monitor a state and set an output, it can still be possible for the robot to run even with the SPS halted. But the System Signals like $PRO_ACT are always being updated, no matter what -- the only way to stop them is to crash the operating system or turn the robot off entirely.

Which leads to another item: do you want to set an output when an error happens? Because using the SPS, if someone stops the SPS, or just turns off the robot, that output obviously will not get set. Usual practice is to use a System Signal that is set when there is no error, and is reset when an error is present.

$ALARM_STOP, for example, is always True unless an E-Stop occurs, at which point it becomes False. OTOH, $STOPMESS is False when no errors are active, and becomes True when an error is active.

In your case, you want to ensure the polisher stops whenever something goes wrong with the robot. I would suggest using $PRO_ACT, and tie that signal into the power circuit for the polisher. $PRO_ACT is always True when the program in the Robot Interpreter is running. Anything that stops the program will turn $PRO_ACT off. And if the robot is turned off, $PRO_ACT will also go False then, too.

OTOH, $PRO_ACT will not go False if the program simply gets stuck at a WAIT statement. So $PRO_MOVE, which goes True when the robot is physically moving, might be a better choice.

But $PRO_MOVE will not go False if the robot speed is reduced to 0. So you begin to see some of the complexity.

A different approach might be to use a PULSE command with a short time duration in the SPS. Firing a PULSE before the previous PULSE expires keeps the signal high. So something like

PULSE ($OUT[1], TRUE, 0.1) would keep output 1 True until 100ms after the SPS was stopped. So that would detect the SPS being stopped, with a short time delay.

You could do combination logic as well:

bMyBooleanVariable = $PRO_ACT AND $PRO_MOVE AND NOT $STOPMESS

PULSE ($OUT[1], bMyBooleanVariable, 0.1)

in decently fresh kss versions you also have $ROB_STOPPED which could be of use to monitor, this variable is true whenever the robot is standing still. Observe i might have misstyped the variable as this is of the top of my head.

Another useful feature would be ir_stopm(). Check ini section of a program. There you can do certain stuff if it is triggered. E.g. stop the polisher or similar.

When an alarm occurs, I want to be able to retrieve the error code from an external device. Are there any system variables that I can read to achieve this? For example, when the E_Stop is pressed, I want to read a variable that will give me the error code = KSS01200.

I have looked through the manual and found the variable $ERR. The $ERR.NUMBER should be able to accomplish this, but no matter how I try, this variable always remains at 0 and does not update. I would appreciate any suggestions or solutions. Thank you very much.

that is not it... that is a KRL version of error handling similar purpose as TRY/CATCH... this can be used to find problem that you anticipate , for example if goal is to suppress some message.

but this does not give you any info on messages that are already shown.

displayed messages are stored in a message buffer which is an array that can hold up to 100 messages. what you want is code that reads this buffer. note, this will get you message info but not texts (unless message is user type). system messages are actually stored in some sort of a database. in the past this was an MDB file. nowadays it is a collection of KXR files (or KXZ files if ZIP-ed). they are really an XML files kept in C:\KRC\DATA\

to see if any messages are present use function GET_MSGBUFFER

so if you are interested in English messages, you may want to extract and look inside file CrossMeld_M_en.kxr. you can export this in suitable format (*.CSV or whatever) and use it on your KRC/PLC/HMI as needed.

Thank you for your response. Since I currently do not have a robot to test with, I can only refer to the manual for explanations regarding GET_MSGBUFFER. From what I understand, the message buffer corresponds to the various contents of the top bar messages on the smartPad, and it does not only include error messages. Therefore, if I want to specifically identify error messages that cause the robot to stop, I should use the type in MsgBuf_T to determine this and then read the error code using nr. Is my understanding correct?

no... you can also look at the example code that was shared... originally i was sharing this on German forum so i used "meld" for message array (in German 'Meldung' ='message')

.type element should be an ENUM that tells message type (notify, ack, waiting... they all got different icons)

.no element is an integer, as used in screenshot i shared (line 6 displays message that KSS00127 is one of displayed messages). that is the KSS message number.

if you are generating message yourself, note that this just places message into suitable buffer but this does not handle other things like stop the robot. if you are making own messages, you need to add code that loops and check if message is still in buffer before allowing rest of the program to continue. if you use functions that are part of the MsgLib, they already have such check.

as stated there are different ways messages are handled - this message buffer only has capacity of 100 messages. notification messages do not get stored there. they are handled differently so for them there is practically no limit... you can have hundreds or thousands of them. bit all other messages types (including dialog) are managed in this buffer which only holds up to 100.

I see, thank you for your patient explanation. No wonder I couldn't find much information when I used "meld" as a keyword. I will try it directly with the robot next week. Thank you very much for your response.

normally i use MBX or similar for that.... it is just temporary variable to get snapshot of what is in the message buffer. you can declare it in DAT file too but note that it does not get cleared.

for example if you have 7 messages, then first 7 elements of the array will get data. once the messages are gone, data will still stay in your array.

so if you get 2 new messages, this will replace 1 and 2 in your array, and you will get message count =2 .... but if you look beyond that, you will still see data from old messages 3,4,5,6,7 which of course now can be ignored. just process data based on actual number of current messages in the buffer....

MBX... When I was searching for information related to $STOPMB_ID, I also came across this function. I did some searching on it but couldn't find much detail or tutorials on how to use it. However, I did find its format on the forum as follows:

EXTFCTP INT MBX_REC(INT MBX_ID : IN, STOPMESS MESS : OUT)

If I want to use this function in the future, are there any things I need to pay attention to? Or where can I find relevant information about it in the manuals?

watch for data types, correct parameters and syntax.

the best info is usually inside manuals... sometimes you have to go through many of them. which is why it is important to know how to enlist help of a computer.

i collect info, store it in a good place for later reference. some call it hoarding. but that is how you get access to information. and if there is a lot to sift through, use correct tool to quickly find what you are looking for.

if i have an idea what manual may be called, is use Everything. Few clicks and i get things narrowed down to a file i want.

if i have no idea what file name to look for i just use Agent Ransack (or whatever GREP like tool you prefer). few seconds later i can preview results and open individual manuals for a closer look...

another way to use computer is to search online. learning some German can go long way too since online translation tools are not able to spot programming and translation mistakes.

here is an example from good old KRL-Reference-Guide-v4_1.pdf

but now you should know what this 'MLD' is supposed to be.

Wow, Agent Ransack looks so useful. If I had known about this tool when I first started using KUKA, it would have been incredibly helpful. I also searched all the manuals I have using MBX and MLD as keywords and found a similar example in the System Software 4.1 manual. However, in my version, MLD is declared in the DECL section, so the meaning of MLD is very clear.

i tried to make a list of some of more useful tools in READ FIRST topic. agent ransack etc are mentioned there.

yes MLD is abbreviated 'Meldung'. the screenshot i posted was an attempt to translate it into English which obviously failed - they changed the variable name to MESSAGE in some but not all places even though example was just few lines long.

things like this would easily be noticed if example was run on KRC or in OfficeLite. all programs need to be tested. and this is one of the reasons i expect forum members to share short program samples (a real code) to demonstrate the problem. nobody has time to waste on 10 pages of non-functional code or something they typed in as they recollect it...