Interesting to know they will merge KUKA.Sim and WorkVisual in the future. I always wondered when something like this would happen.
Hm! Similar to how ABB has RobotStudio set up? RS has both the robot setup/programming environment (free), and a full simulation engine (with paid license).
Did you already check the release notes for RS 2022.3.2? Maybe there is an issue which is already known.
I didn't even know there were release notes.
Hm... well, after tracking the notes down, the only one that relates to the Watch window is:
QuoteRoutine variables can't be displayed in RAPID Watch with RobotWare 6.12
A limitation in RobotWare 6.12 prevents variables declared in a routine from being displayed in the RAPID Watch window.
But these aren't routine variables, they're global variables. And other VARs declared at the same level don't have this issue, only the Clocks. So I don't think this note is applicable.
Still, it's handy to know those notes exist. Thanks!
I used EthernetKRL_Server.exe file to send data using their own interface and then there wasnt any issue( by directly copy-pasting the xml file).
But while using python the connection issue is popping up.
Same computer/cables/network switch/etc?
Then the problem probably has to be with your Python program. But there are about 5000 different methods to open TCP/IP connections in Python. And since whatever Python library you're using is throwing that error, you need to look into the documentation for that Python library.
always in the same point of the job
Delete that point, delete the associated variables from the .DAT file, and re-create the point from scratch.
Not sure about that at all. Are you assigning the clock value to another variable? That one ought to be visible in the rapid watch, with maybe a minor lag.
Nope, in my usage, I literally just have
ClkReset Clock_StopWatch;
ClkStart Clock_StopWatch;
WHILE di10_ToolAttached=0 AND ClkRead(Clock_StopWatch)<30 DO
WaitTime 0.1;
ENDWHILEBut Clock_Stopwatch only shows Unknown Value in the Watch window. Odd. My first thought was that it was an issue with VARs vs PERSs, but I've found that's not the case. It seems to be unique to Clocks.
I'm having a minor issue with RS 2022.3.2. The Watch Window seems to work for CONSTs, PERSs, and even most VARs. But any of my CLOCK VARs that I add to the Watch shows up as Unknown Value. Even when I have the robot waiting for that Clock to reach a particular value.
All these variables are declared Globally at the top of my RAPID module (no TASK or LOCAL keywords). I have VAR NUMsdeclared the same way, at the same program level, which show up in the Watch perfectly well, but the Clocks simply won't show anything. The Help file doesn't state there's anything unique about Clocks that would prevent them from showing up in the Watch. Is this just a normal RS thing?
VAR num Trax_decision;
VAR clock Clock_StopWatch;Like i said im new to this, it was said to me to upgrade KSS Version so i tried my best but nobody told me all consequences that this may have. So I really thank you all for help.
Kind regards.
I can only conclude that whoever told you that is either incompetent, or was selling illegal copies of KSS.
What you describe is possible. The devil is in the details, of course. But as long as you had a safety-qualified means of ensuring that the Cobot could not reach a human while operating in non-Collaborative mode, you should be able to do this.
Details are important, though. Let's say you use a light curtain to switch the Cobot back to Collaborative mode when it approaches an area it shares with the operator. The placement of that light curtain would have to take the Cobot's non-Collaborative stopping distance into account, so that the operator would be safe even if the Cobot hit the curtain at maximum non-Collaborative speed and got E-Stopped by the curtain.
Likewise, any other fencing or guarding would have to be designed to deal with the robot in non-Collaborative mode.
I wanted to upgrade KSS release from 8.2.6 to 8.5. Firstly i stopped the KRC on the minimized HMI (Windows), then i tried to setup the KSS 8.5 Relase. Then it showed it cant be set up and then i turned the switch off.
Where did you get this KSS release? Many KRC4s that shipped with KSS 8.2 may not be able to run 8.5. Also, what you describe is not the process for updating KSS. You must use a KSS Image from KUKA, deployed using a KSR USB stick. The KSR stick must be configured correctly, then the KRC rebooted with the KSR plugged into one of the KRC's USB ports. The KSR stick will wipe the KRC's hard drive and perform a factory reset, using the new Image.
Obtaining correct KSS image from KUKA, using your KRC4's serial number, is critical, since attempting to install a KSS Image that is not correct for the hardware will likely destroy the KRC at the software level. The only way to recover from this would be to factory-reset the KRC, using KSR with either a KUKA factory Image, or a good Backup Image made with the KSR while the robot was still in good operating condition.
The problem with using the SPS is that, if the SPS is not running for some reason, then the spindle will never be stopped. That's one reason (among several) that this is not a Safety-qualified solution.
One way to protect against SPS halts might be something in the SPS like:
IF bRunSpindle AND NOT $ALARM_STOP THEN
PULSE ($OUT[4], TRUE, 0.1)
ENDIFwhere bRunSpindle is a global BOOL variable. In this usage, every cycle of the SPS (which should execute a full loop several times every 0.012sec) will "pulse" $OUT[4].
But the Pulse command has a hidden trick: If you do something like this:
PULSE ($OUT[4], TRUE, 1.0)
WAIT SEC 0.5
PULSE ($OUT[4], TRUE, 1.0)Then $OUT[4] will stay True for 1.5sec. Basically, repeating a Pulse command before the previous Pulse command expires extends the original Pulse. So, in the upper example, as long as bRunSpindle is True and $ALARM_STOP is False, $OUT[4] will stay True all the time. But, if either BOOL changes state, or the SPS is halted for any reason, 0.1sec later, $OUT[4] will become False.
Glad I could help a bit.
Another thing about Cobots (or, at least, the ones I've used so far), is that to achieve their Collaborative rating, they are very fussy about their payloads. For example, every Cobot I've used, after a collision fault or a reboot, requires an operator to manually acknowledge that the programmed payload is still attached, and that no external forces are acting on the Cobot (ie, no one is touching it). This is b/c the Cobot must perform a degree of recalibration or checking of its internal torque sensors, which are what detects collisions. This means that these sensors are part of the critical safety chain of the Cobot, and as such no quick/easy bypasses are permitted. For some Cobots, doing an axis calibration may require the robot to point straight up ("candlestick pose") in order to separate gravity effects.
Dressing a Cobot has challenges as well. Thick cables, heavy hoses, spring-loaded retractors -- Cobots cannot tell the difference between these forces and a collision. So dressing needs to be light, neat, and you must avoid motions that pull on the dressing, or might wrap it around the wrist. Sticking to the Cobot's internal power/communications lines is strongly recommended, and you need to design your EOAT accordingly.
Another wrinkle of having the robot's internal sensors be part of the safety chain -- Cobots are less maintainable by end users, in general. So far, I've never seen motor replacement on a Cobot performed by anyone but a certified tech from the robot manufacturer, and some maintenance can only be done by shipping the robot back to the factory. In contrast, replacing motors on Big Iron is usually not a big deal.
One Cobot I worked with was used as a demo model, mounted on a cart... and we found that moving that cart across a bumpy floor would throw the contact sensing so badly out of calibration that it had to be sent back to the factory. A smaller Cobot (10kg payload) came from the manufacturer in a high-strenth carboard "carrying frame", with hand-holes, and the instructions were explicit that simply picking the robot up by hand would void the warranty -- instead, the crate and padding had to be broken down in a specific order, then the robot could only be lifted (by hand) using the cardboard carrying frame (which supported all the axes in their shipping positions), and there were all sorts of warnings about how jostling the robot carelessly could render it useless. Once it was bolted down to its permanent stand, it could take more abuse, but between crate and stand, it was vulnerable.
So: read the instructions completely before opening the crate! Cobots are just easier to break than Big Iron, even the small Big Iron.
As Panic says: if this is a safety hazard, then the correct way to handle the problem is to wire the power supply of the spindle in series with the E-Stop circuit in some way.
One possible approach would be to have the spindle power interrupted by a relay closed by the Drives On status outputs at pins 35&36 and 33&34.
whaaaat...?
the way i see it they are the same thing - both are marked external. so i assume they are both inputs, probably connected internally.
...wow, I must be more sleep deprived than I thought. 
I am a little dubious about the user mentioning "cold boot", You don't really want to cold boot, I think that what is meant is power on.
Got it.
Display MoreI keep getting singularity errors whem my J4 and J6 are nowhere near lined up. I'm going between two PRs. I made sure all my position configurations matched. I need help!
J1: 56.889
J2: -12.030
J3: -7.969
J4: 103.653
J5: -.847
J6: -111.444
If J5 is that close to 0, then J4 and J6 should be lined up. What model robot is this? With what wrist type?
Also, post the entire exact error message, especially including the axis number being reported.
So, XG12.1 has two contacts for power output, and two for power input.
Now, the KRC5-Micro is an odd duck, so I can't guarantee this is the right solution. But on the similar connectors on the KRC4 Compact (the most similar controller), the I/O module got its power from the Power Input pins.
This allowed the end user to either connect an external power supply of their own choice, or power the I/O module from the KRC's internal power by running jumpers from the 24V output to the 24V input, and ditto for the 0V pins. So, if the KRC5-Micro follows the same design pattern (which almost every version of KRC I've seen does):
A jumper between 1 and 3, and another between 2 and 4, may be the correct solution. The manual doesn't actually say, from what I've seen.
Panic Mode will probably show up in 5min and bawl me out for getting this all wrong... 
Would it not be possible to just enlarge the array of Workspaces?
No. They are system variables, not user-generated variables.
...well, I've never actually tried it, but I would be amazed if editing those arrays actually worked.
For one thing, multiple arrays in multiple files ($MACHINE.DAT and $CUSTOM.DAT) would have to be edited. The standard set of Workspace-related variables are implicitly linked by KSS, but there's no way to tell KSS to add more linkages. The $WORKSTATE signals are defined in $MACHINE.DAT (which, the last time I tried, could not have lines added or removed, only values could be altered), and $WORKSTATE1 is implicitly linked to $WORKSPACE[1] (which is defined in $CUSTOM.DAT). Not to mention the implicit link to $WORKSPACE_NAME1, which is a CHAR array containing the string name of the Workspace.
It depends on what you're trying to do.
Cobots are really not much different from their "big iron" cousins, except that the safety standards that apply have various caveats. The required Risk Assessments can be more complicated, sometimes.
The big issue is understanding how easy it is to accidentally make your Cobot non-collaborative. Too many people think that just buying a Cobot means they can do without fencing or other safety equipment. But if you put a sharp knife, a pointer screwdriver, a welding torch, or a chainsaw on your Cobot... well, your Cobot isn't a Cobot anymore, and you need to treat it just like Big Iron. The number of people I've seen buy Cobots and think they can just disregard all safety concerns....
Many Cobots have options to turn their Collaborative mode off, temporarily. Doing this safely requires safety-rated interlocks, because a Cobot in non-Collaborative mode is just as dangerous as a Big Iron robot in the same weight class.
Cobots are limited to modest payloads, and low speeds, unless you turn off Collaborative mode. So don't expect high speeds.
Cobots generally program much the same as the Big Iron, although their joints may be arranged somewhat differently (this varies by brand). The main difference tends to be that Cobots can be "jogged" by holding the "deadman" and physically pushing the robot into position before hitting the Record button. Some Cobots are actually stupidly hard to jog accurately from the pendant, making the push&pull programming a necessity rather than a handy option (URs, I'm looking at you here).
See here:
Hm! So, looks like I should try holding down "1" while doing a cold boot.
I may have to wait a week, though -- we're starting a buy-off test run as I type this.
Yes, INVERSE() should have no effect on the ARP. However, it is vulnerable to the ARP -- INVERSE() relies on $BASE and $TOOL, so you need to ensure that when INVERSE() is called, those variables are correct.
So, you might be able to try checking your path points with INVERSE() using a temporary E6POS copy of your start point, trying different S&T combinations until you (hopefully) find one that doesn't return an ERR_STATUS above 0.
