Thank you panic mode , so the advance run is not stopped regardless of the statement called by TRIGGER.
Posts by aknezevi.proton
-
-
Hello,
I am unable to find the answer anywhere in the documentation, but I may be missing something.
We are using KRC4 controller KSS 8.3.17, and we need to set up Torque Limits right before the gripper touches part. For that we want to use SET_TORQUE_LIMITS with TRIGGER WHEN PATH statement to achieve the desired result.
However, right after SLIN command we also set an output to let the PLC know that the command had been processed in order to initiate gripper logic.
That is why I am wondering, does the fact that SET_TORQUE_LIMITS triggers advance run stop change this? That is, if we have lines such as:
CodeTRIGGER WHEN PATH=-2.0 DELAY=0.0 DO SET_TORQUE_LIMITS(6, {...}) PRIO=-1 SLIN POS_At_Part CONTINUE Initiate_Gripper = TRUE ; Initiate_Gripper is SIGNAL
will the line Initiate_Gripper=TRUE be processed before the position POS_At_Part is reached?
Does TRIGGER WHEN statement prevent Advance Run Stop?
Thank you all!
-
Hello,
I have a question that is probably very simple, but I am unable to find anything through the documentation.
In my program I use Submit Interpreter to set certain $OUT signals. Setting of the signals triggers advance run stop in Robot Interpreter.
My question is, does it also do advance run stop in Submit Interpreter? I.e. does a code like $OUT[1] = TRUE stop Submit interpreter from running until the robot has completed its current motion?
Thank you all!
-
Hello,
We have 2 CS8C controllers with 2 TX60 arms. Both of the arms come from the exact same place and were ordered at the exact same time, but they are not ours, they are pre-owned.
We don't know what the owners did to the robots, but the arm.cfx files on the robots have different tuning. One has tuning set to "R2", while the other one has tuning set to "".
How big of a deal is this, and how can we know arm tuning to correct it?
Thanks you!
-
Firstly, if you really want REAL-TIME robot position, use $POS_ACT_MES, as $POS_ACT is only the setpoint.
Secondly, there are two solutions to your problem. The first one is, as hermann mentioned, to use ON_ERROR_PROCEED.
The second one is to not use $POS_ACT unless both $ACT_TOOL and $ACT_BASE are set.
So instead of...
you can use...
Lastly, WAIT SEC 0 also prevents code pre-reading. As does WAIT FOR TRUE. This is called advance run stop.
-
Hello,
We have a CS8C controller with a TX60 arm. On the controller it is written that the arm is floor mount, but we are mounting it on the ceiling.
Is it only necessary to change the 'floor' to 'ceiling' on the Controller->Control Panel->Controller Configuration->Versions->Arm? Or is there something else that needs to be done?
Thank you!
-
-
Hello,
I would like to update the Starc and VAL versions on my controllers in order to have access to the newest features, but I am looking at compatibility tables and I don't know exactly how to find out which of the hardware components are available on my CS8C controllers.
Are there any easy ways to find out which hardware is installed on my controllers?
Thank you!
-
Quote
I have the WMS in the hand position, i understood that I need to select the working mode on the WMS, to power up the arm, for testing. But from my understanding the status for the working mode lights on the teach pendant should corespondingly light up with what's selected on the WMS box. But in my case the status leds of the working mode on the teach pendant are not glowing at all, no matter what working mode I select on the WMS box.
In my experience this just means that the WMS is not wired properly. If that is not the case you unfortunately have to contact Staubli. Good luck!
-
From KUKA manual:
Quote11.8.1 CONTINUE: preventing an advance run stop
Description CONTINUE can be used to prevent an advance run stop that would otherwise
occur in the following program line
CONTINUE always applies to the following line, even if this is a blank line! Exception:
If the following line contains the statement ON_ERROR_PROCEED,
CONTINUE applies to the line after.
-
Quote
Also after a start up there's an error message: Internall error on fieldbus Board=1 Equipment=0 Channel=0 Status=33
This really could be anything, depending on the fieldbus card that is present on the controller. If it is for example profibus it could simply mean that the peripherals are not connected or not configured properly/equally on both ends.
QuoteArm power enable request refused: cabinet working mode is remote or invalid.
Well, since you have Working Mode Selector (WMS), check if it is in a proper position. It needs to be in a position where it is showing a human hand if you want to power up arm for test.
-
Quote
I missunderstood the usage of this kind of signals
I am assuming you meant that you thought 1 means safety stop?
That is not how industrial automation works. What if PLC suddenly loses power, and since it is a profisafe device it runs all safety. If 1 meant that safety was breached (for example 1 meaning safety stop), then if PLC controller (which runs ALL safety!) lost power there would be no way for robot controller to know that there has been a safety hazard, it would not be told that.
And, yes, KRC would know that communication broke, but imagine it was just one wire breaking. That is why mostly in all industrial automation 1 means good to go, and 0 means something is broken. Because if there is no power, by default you send that something is broken, which is just good practice.But, you can always fake signal and just see what controller tells you, to make sure what is 1 and what is 0.
-
Quote
Are the AUT EXT predefined signals ($USER_SAF, $STOP_MESS,…) always required for the AUTO EXT communication and operation?
To move the robot in AUT EXT mode the AUT EXT signals need to be correctly configured and run (meaning timed correctly etc.) To move the robot arm at all outside of Startup Mode the Profisafe Inputs need to be correctly configured and run (meaning safety needs to be sent to robot, for example SHS1 signal needs to be 1 because 0 means safety stop).
QuoteWhich is the purpose of the safe signals then? Can I get to the AUT EXT with them?
Safe signals are for safety purposes. As per above, to move the robot in AUT EXT both the safety needs to be correct (or faked) (because the arm will not move otherwise) and AUT EXT signals need to be correct (otherwise no AUT EXT mode).
QuoteCan I get the AUTO EXT to work, without physical safety components installed (I know it’s not recommendable and dangerous), but forcing both safe and non-safe outputs from the PLC (inputs in the KRC, like USER_SAF or Byte0_bit2_BS)?
Of course! How would the robot controller know that there is no estop button if you sent it that ESTOP button is pressed using the PLC? It wouldn't and it doesn't. You can force all safety outputs on the PLC.
QuoteIf the SafeOperation package is installed, is it mandatory to set all the reserved bits to 1? Are there any bits that, if not used, should be set to 1?
SafeOperation has nothing to do with those signals, it is ProfiNet option package which configures that. SafeOperation configures other things, like brake testing, mastering test, safety zones, safety tools etc. In ProfiNet manual you will find that it says that it is best to set reserved signals to 1, that is in case of upgrades in the future, but also best practice.
-
You should probably do a full system restore. Since it is not just a simple icon missing but all the buttons working who knows what else could be wrong.
-
Thank you panic mode
Quotesuch signals should be already declared in controller MADA (KRC:\STEU\MADA\$Machine.DAT)
I understand that, but they are not declared in MADA. Only in $OPERATE.dat
Quotefor anything else feel free to declare unique name variables (do not create duplicate names).
Thanks, that is as I expected it to be.
Quotewhy would submit not be running? if it is not running something is wrong.
That is in fact a very reasonable thing. If the SUBMIT somehow stops running there could be all kinds of problems, which is why I have an interrupt in robot program in case the SUBMIT stops running.
I was just looking for ways to maybe run several different SUBMITS and looking for a way to not have the same code in every single one of them. -
UPDATE #1:
After uploading the WorkVisual project to the controller there is a 0x8000FFFF (E_UNEXPECTED) exception from HRESULT, "Catastrophic failure" and I am unable to activate the project.
This is because of the conflict of definitions for SIGNALs $MASTERINGTEST_REQ_INT, $MASTERINGTEST_SWITCH_OK and $MASTERINGTEST_ACTIVE in $machine.dat, and the same-named variables in $OPERATE.dat.
So there is a need to create new-named SIGNAL variables and somehow link those to the $OPERATE.dat ones.
Any help is appreciated!
-
KUKA Xpert should have manuals with at least some of the relevant information.
What you should do is look for MA_ manuals for the specified arm's family.
For example, for KR 90 R2700 pro arm the family is QUANTEC so the manual is MA_KR_QUANTEC_pro_en manual, also known as "Robots KR QUANTEC pro Assembly Instructions". It should have all the relevant Maintenance information for the robot arm.
-
Hello,
I am programming a KRC4 (KSS 8.3.17) with KR 90 R2700 pro arm.
I use a profisafe PLC for all safety.
Because of SafeOperation 3.2 which we use there is a need for Mastering Test.
To do the Mastering Test adequately there is a need for the signals $MASTERINGTEST_REQ_INT, $MASTERINGTEST_SWITCH_OK and $MASTERINGTEST_ACTIVE to be sent to the PLC. Unfortunately, these variables are defined inside the Write-protected file $OPERATE.dat and are not SIGNALS, but BOOL variables.
When I attempt to define SIGNAL's with those names and assign them to relevant $OUT[]'s WorkVisual throws exception because a variable with that name is already defined.
My question is, is this WorkVisual exception relevant? Will the controller compiler throw exceptions?
If it will not, will those variables be useful to the PLC, i.e. will they have the same value as the same-named variables in the $OPERATE.dat?
Lastly, if that won't do it, my question is is there a way to define a new SIGNAL and somehow attach it to an existing variable. I would like to do this regardless of if the SUBMIT interpreter is running.
The obvious way to do it using the SUBMIT is to simply have SIGNAL_VARIABLE = $OPERATEdat_VARIABLE, but that depends on the SUBMIT interpreter running.
Thanks very much!
-
Depends on what you want to do, but just putting a GSDML in TIA portal and configuring relevant inputs in KRC should be enough for PROFINET. (PROFINET is what is being talked about here)
I have not worked with KRC5, but KRC4 is straightforward. If your S7-1200 is ProfiSafe you will also get the benefit of ProfiSafe. The GSDML comes with the ProfiSafe already configured.
Then, in WorkVisual you map ProfiNet inputs and outputs to the KSS $IN and $OUT and in the $config.dat (and elsewhere, $machine.dat and $custom.dat) you configure relevant signals that you want to $IN[...] and $OUT[...]
Then you can use these signals in TIA portal as if they were PLC's own signals. In tag library define relevant I/O tags.
For example, you want to use $T1 signal to let your S7-1200 know that the controller is in T1 mode, for whatever reasons you might have, disabling safety or whatever.
Then you need to configure, in $machine.dat, SIGNAL $T1 $OUT[xyzt], where xyzt is some number between 1 and 4069.
Then you need to map that signal in WorkVisual to a ProfiNet output. For example map $OUT[xyzt] to abc.d where abc is a number between 16 and 269 and d is a number between 0 and 7.
Then you see which %Iefg.h that particular input is in your Hardware Configuration in TIA portal and boom, you got yourself a tag $T1 %Iefg.h. (efg and h are numbers)
A more detailed explanation would require you already have a knowledge of TIA portal and so on, but I hope this sets you on a way, maybe not the best and simplest, but a way.
-
This is still unresolved (the part with RAMDISK), but if RoboDK is your problem Sface then it was solved for me by getting MotoCom SDK dongle.