Posts by SkyeFire

You have to include a means to "undo" the changes when you start a new part. You'll note that in my example, I set $BASE (a dynamic variable) to BASE_DATA[1] (a static variable), and then perform all my changes to $BASE. BASE_DATA[1] is never tampered with, and as such always serves as the initial start point for a fresh part.

The underlying concept is "Scope." https://en.wikipedia.org/wiki/Scope_(computer_science)

In the SRC file, a variable declared inside a subroutine (or function) only exists for that subroutine. As soon as that subroutine is no longer in the call stack, that variable is lost.

In the .DAT file, any variable declared has a "module-wide" scope -- any subroutine in that .DAT file's associate SRC file can access them. But the variables are only kept in memory as long as one of the subroutines in that SRC file are in the caller stack.

If a .DAT variable is declared with an initial value (eg, DECL INT Counter=0), then the values of that variable are remembered forever, even if the program is reset or the robot is rebooted. An Archive of the robot will show a "snapshot" of all these values as they were the moment the Archive was made.

Any variable declared with GLOBAL, in any DAT file, has global scope -- any subroutine, in any module, can access it. The file $CONFIG.DAT is a special case -- anything declared in $CONFIG.DAT is automatically global, without need a GLOBAL in the DECL line. This is because before GLOBAL DECL was added to KRL, $CONFIG.DAT was the only way to create global variables.

Easiest way to do this is to create a Base that has one axis (say, Z) perfectly aligned with the "layering" effect you want to create, then manipulate the Base inside your FOR loop. Something like:

DECL FRAME Shift
DECL INT Index
$BASE = BASE_DATA[1] ; nominal Base
FOR Index = 0 TO 50
  Shift = $NULLFRAME
  Shift.Z = Index
  $BASE = BASE_DATA[1] : Shift ; raise Base by (Index * 1mm) in Z
  LIN StartPoint
  ; torch on
  LIN EndPoint
  ; torch off
  LIN Escape ; move clear of weld
ENDFOR

Easy enough. You need to manipulate $BASE or BASE_DATA, depending on how your program is structured.

Let's say that your "original" base, representing one corner of the pallet, is stored in BASE_DATA[1]. Keep this safe, and don't mess with it. Instead, program all your pallet-pattern points in BASE 2. Then, in your program, use counters to represent each dimension of the layer pattern X,Y,Z. A very crude example:

FOR XCount = 0 TO 9 ; 10 rows
  FOR YCount = 0 TO 7 ; 8 columns
    FOR ZCount = 1 TO 4 ; 5 layers
      ; insert Pickup motions here, programmed in some base [b]other than[/b] Base 1 or 2
      BaseShift = $NULLFRAME
      BaseShift.X = XCount * XShift ; shift over by XShift for every XCount row
      BaseShift.Y = YCount * YShift ; shift for columns
      BaseShift.Z = ZCount * ZShift ; shift for layers
      BASE_DATA[2] = BASE_DATA[1] : BaseShift ; Create Base 2 from Base 1, shifted by the rows/columns/layers of the Counts
      ; program palletizing moves in Base 2 here
    ENDFOR
  ENDFOR
ENDFOR

SYN OUT is simply menu-driven means of using very basic TRIGGER commands when programming on the teach pendant, rather than writing "raw" KRL. OrangeEdit attempts to duplicate the teach pendant programming environment to the greatest degree possible.

If the message window turns red and shows a question, then you need to answer the question using the softkeys along the bottom of the screen. This isn't an error, it's an operator dialog message.

Well, this is a nasty one. But I've seen it happen twice in the past few months, under both KSS 8.3.14, and 8.3.20. So I thought I'd pass the warning around.

Basically, this seems to happen when the KRC4 has a botched reboot, either after a change to the SafeOp configuration, or possibly after suffering a serious fault during an RSI activity (my sample size is pretty small). Something about this sequence of events apparently corrupts the file MOTIONDRV.INI. Most of the file appears to be overwritten with ASCII "null" values.

The really nasty part about this problem is that it shows no symptoms, until someone tries running an RSI_MOVECORR, at which point Error 2848 pops up. But since this happens on a robot that was working perfectly well immediately before the failed reboot, it can leave you chasing your tail. My team only eventually found it by performing a brute force comparison of an entire archive against the robot, directory by directory, until we found differences in files that should not have existed.

The driver entries that "go missing" from MOTIONDRV.INI are:
RSI_MOVECORR, mdrStandStill.o, OLDC, loadDataDevice.o

So, I assume that any attempt to use SafeOp Standstill mode while MOTIONDRV.INI is corrupted will also produce Error 2848, but I haven't tested that. The last two drivers I'm not familiar with.

A cold boot with "Reload Files" will not recover this situation. Only fixing the file from an archive, or doing an all-out restore, appears to fix it. No other files appear to be affected.

If you use 32 bits, you can write a function to encode a REAL variable using IEEE 754: http://steve.hollasch.net/cgindex/coding/ieeefloat.html Most PLCs will interpret this correctly without issue.

No, they are part of the operating system. Safety messages, illegal-variable messages, program halts -- these messages need to work regardless of what program is running, or if it is running.

I may be a bit sensitive on the topic. Models like the LWR absolutely require precise gravity vectors -- even very tiny errors can make them behave unpredictably. And for larger robots, well... I once got assigned to a project where the designers planned to mount the robots to 10m tall, curved tracks, that would have tilted the robot through >30deg across the height of the linear axis, and didn't understand why I had an issue with this (did I mention that it had accuracy requirements around 0.1mm?).
And then there was the time someone wanted to commision a ceiling-mount robot, without bothering to mount it to the ceiling. Sitting upright on the shipping pallet, plugged it in, engaged drives... SMASH.

Controller model?
KSS version?
Error message and number?
What line inside the INI fold generates the error?

That's a very good idea (better than mine) -- rather than try to combine "permissive" spaces into a complex shape, line the interior of the fence with "prohibit" spaces. You just need to keep in mind that, in T1, the robot will only be halted as it crosses the border -- once the operator acknowledges the error message, they will be free to continue on and jog into the fence. So it's not a "hard" protection, but it will give the operator a warning when they get too close.

I'll pause to point out that using non-SafeOperation work spaces to protect a fence line almost certainly fails OSHA and RIA safety requirements.

Beyond that, I don't think you can use the workspaces this way, internally to the robot -- the zones are all individual, they don't "combine" with each other. My first thought is that you could simply set the workspaces up to set certain outputs, and use an external controller to combine those signals using Boolean OR logic to control the robot's $MOVE_ENABLE signal.

No, tilting the robot relative to gravity is not a good practice. For very small tilts, you might get away with it, but as the angle increases, the strain induced on A1 and A2 will increase. At the extremes, a 90deg tilt would probably render the robot mostly inoperable, and a 180deg inversion would cause the robot to smash itself into the floor or ceiling (I have seen this happen).
Even at tilts small enough to avoid such mechanical issues, the robot's accuracy will suffer, as the positional corrections applied for payload effects will be calculated incorrectly. This would be more obvious on a robot operating close to its payload limit, and would probably render an Absolute Accuracy robot... well, non-Accurate.

The Configuration manual. It's there. Look for the Automatic External setup chapter.

Sounds like the ArcTech I/O config is incorrect. Or, the wire feed device your are using is not the same make/model that ArcTech was designed for.

AUT probably blocks minimizing the HMI. Generally this is only possible in T1, with a User level of Expert or higher. Also, switching in AUT or EXT automatically reduces your login level to Operator (the lowest level), by factory default. Factory default also logs you out to Operator level after more than 5 minutes of idle time.

The error message indicates that the robot is never achieving communications with the gripper device. Is your Device IP&subnet compatible with your robot/PLC IP&subnet? Have you used the WorkVisual Profinet diagnostic tools?

A properly defended and segregated network helps prevent this. Also, one generally does not make the C: drive accessible from the network, or if it is accessible, only in read-only mode. Any write-access network shares are limited to non-system areas. And all shares, of course, must be password-protected.

With a physically widespread set of robots, while trying to maintain common application software across them, the USB-stick "sneakernet" method quickly becomes impractical.

Any robot depends on a fixed vector relationship to gravity in order to function properly. Tilting the mount plate of a robot is, at best, a bad idea, and at worst can cause the robot to destroy itself.