Posts by SkyeFire

Quote from RoboMan3000

Thank you SkyeFire - I think that works!! Do you work for Kuka or something??

No, I just did a lot of KRL programming for about 20 years.

Quote from RoboMan3000

When I get to the CWRITE - "krl_fgets" process, I get an error message number -11, "At least one function parameters have an invalid value."

Hm... it's been a long time. The module I've attached is the most advanced one using FGETS I ever wrote. I do recall that FGETS has some fiddly requirements the docs don't explain very well.

Quote from RoboMan3000

I initialize my buffer Buff[256] to be all zeros, and Offset = 0 and READ = 0, here is the line

Hmm... I looked at my old module, and I always did an STRCLEAR on the buffer, then set _chBuffer[1]="x" before calling FGETS. I vaguely recall a long, painful learning process that lead to that. And I think setting all the buffer to be 0s actually doesn't work, it needs to be some valie alphanumeric char:

      WAIT FOR STRCLEAR (_chBuffer[])
      _chBuffer[1] = "x"

      CWRITE ($FCT_CALL, _FgetsState, _Mode, "krl_fgets", _nFileHandle, _chBuffer[], _nFGetsLength, _nCharsRead)
      CWRITE ($FCT_CALL, _EOFState, _Mode, "krl_feof", _nFileHandle, _bEOF)

Long old thread here: Re: CWRITE

KRL uses CHAR arrays as ersatz strings. Which usually works. For example, I had this in a .DAT file:

CONST CHAR chRFMasterFile[200]
chRFMasterFile[]="RFMaster.txt"

And in the SRC:

FileOpen (chRFMasterFile[], _chMode[], _nFileHandle)

FileOpen is just my library subrouting that call the KRL_FOPEN command:

GLOBAL DEF FileOpen(FI_chFileName[] :IN, FI_chMode[] :IN, FO_nFileHandle :OUT, FI_BufferMode :IN)

CWRITE($FCT_CALL, _OPSTATE, _MODE, "krl_fopen", FI_chFileName[], FI_chMode[], FO_nFileHandle, FI_BufferMode)

Your problem is that you want to create an array of strings, which isn't possible to do directly in KRL. I don't think you can work around it using 2D arrays, at least not without resorting to loops with single character copying. What I've done in the past is to create a STRUC, which includes a CHAR array "string" variable, then create an array of the STRUC type.

GLOBAL STRUC ROBOT_DATA CHAR Name[24],V7KName[24],INT Context,RobotTypeEnum Type,BOOL HasToolchanger,Reg_Coop RegistrationCoOp,BOOL ResidualCorrection,GuidanceTypes GuidanceOption
DECL GLOBAL ROBOT_DATA Robot[10]
Robot[1]={Name[] "rnd-kr210-642486",V7KName[] "Cell1-Spirit",Context 1,Type #V7OML,HasToolchanger TRUE,RegistrationCoOp #Master,ResidualCorrection TRUE}
Robot[2]={Name[] "xxx",V7KName[] "Cell1-Spirit",Context 2,Type #V7IML,HasToolchanger FALSE,RegistrationCoOp #Slave,ResidualCorrection TRUE}
Robot[3]={Name[] "xxx",V7KName[] "Cell2-Spirit",Context 1,Type #V7OML,HasToolchanger TRUE,RegistrationCoOp #Master,ResidualCorrection TRUE}
Robot[4]={Name[] "xxx",V7KName[] "Cell2-Spirit",Context 2,Type #V7IML,HasToolchanger FALSE,RegistrationCoOp #Slave,ResidualCorrection TRUE}
Robot[5]={Name[] "xxx",V7KName[] "Cell3-Spirit",Context 1,Type #V7OML,HasToolchanger TRUE,RegistrationCoOp #Master,ResidualCorrection TRUE}
Robot[6]={Name[] "xxx",V7KName[] "Cell3-Spirit",Context 2,Type #V7IML,HasToolchanger FALSE,RegistrationCoOp #Slave,ResidualCorrection TRUE}
Robot[7]={Name[] "xxx",V7KName[] "Cell4-Spirit",Context 1,Type #V7OML,HasToolchanger TRUE,RegistrationCoOp #Master,ResidualCorrection TRUE}
Robot[8]={Name[] "xxx",V7KName[] "Cell4-Spirit",Context 2,Type #V7IML,HasToolchanger FALSE,RegistrationCoOp #Slave,ResidualCorrection TRUE}

It's a bit kludgy, but I can confirm it works. Just pass something like Robot[7].V7KName[] to FOPEN (those empty braces are vital, it's how you tell KRL you're passing the entire array), and FOPEN will try to open the file named Cell4-Spirit.

Here's an example of a Logging function that uses SWRITE to create the file names on the fly. It's using date/time values instead of an array, but the same SWRITE principle will work:

GLOBAL DEFFCT INT LogFileOpen(FI_chMountPath[]:IN, FI_chFileNamePrefix[]:IN,FI_chFileNameSuffix[]:IN,FO_FileColumnHeaderArray[]:OUT)
  ;FOLD HEADER
  ; Creates Log file using date, time, and received arguments
  ; Also writes initial "Column Header" line if defined
  ; Column header array needs to use #Terminator for .Usage value in final row
  ; Array needs to be complete and contiguous
  ; Routine will exit on undefined array index
  ; Should work on KSS 8.3 and above
  ;ENDFOLD (HEADER)
  ;FOLD DECLARATIONS
  DECL LOGCOLUMnHEADERSTRUC FO_FileColumnHeaderArray[]
  DECL CHAR FI_chMountPath[]
  DECL CHAR FI_chFileNamePrefix[]
  DECL CHAR FI_chFileNameSuffix[]
  DECL CHAR _chLogFileName[256]
  DECL CHAR    _chLogString[1024]
  DECL STATE_T _State
  ;DECL INT     I
  DECL INT _nOffset
  DECL INT _nIndex
  DECL INT _nLogFileHandle
  DECL LOGCOLUMNHEADERSTRUC _LogColumnHeaderLine
  DECL BOOL _bReturn
  ;
  ; ENDFOLD (DECLARATIONS)
  ;FOLD EXECUTABLE
  
  ; Initialize
  _nIndex = 0
  _nLogFileHandle = 0
  
  ; create log file "RobotName_FI_chFileNamePrefix_Year_Month_Day_Min_FI_chFileNameSuffix.LOG"
  _bReturn = StrClear (_chLogFileName[])
  _nOffset = 0
  IF VARSTATE("FI_chFileNamePrefix[]") == #INITIALIZED THEN
    SWRITE (_chLogFileName[], _State, _nOffset, "%s_", FI_chFileNamePrefix[])
  ENDIF
  SWRITE (_chLogFileName[], _State, _nOffset, "%s_%04d_%02d_%02d_%02d_%02d", $ROBNAME[], $DATE.YEAR, $Date.Month, $Date.Day, $DATE.HOUR, $DATE.MIN)
  IF (VARSTATE ("FI_chFileNameSuffix[]") == #INITIALIZED) THEN
    SWRITE (_chLogFileName[], _State, _nOffset, "_%s", FI_chFileNameSuffix[])
  ENDIF
  SWRITE (_chLogFileName[], _State, _nOffset, ".LOG", FI_chFileNameSuffix[]) ; extension
  
  ; create/open file in Append Mode
  ; Buffer Mode left undefined
  ; Handle>=1 if successful, otherwise <1
  FileOpen(_chLogFileName[], "a" ,_nLogFileHandle, ) 
  
  IF (_nLogFileHandle > 0) THEN
    ; Write Header data to log file
    _bReturn = STRCLEAR (_chLogString[])
    _nOffset = 0
    _nIndex = 1
    
    ; Build top Label row for array output to log file
    LOOP
      ON_ERROR_PROCEED ; trap for premature array end
      _LogColumnHeaderLine = FO_FileColumnHeaderArray[_nIndex]
      IF $ERR.NUMBER==0 THEN ; end of array not reached
        SWITCH _LogColumnHeaderLine.Usage
        CASE #Valid ; Entry marked for use
          ; Append label to top line of log file
          SWRITE (_chLogString[], _State, _nOffset, "%s,",_LogColumnHeaderLine.chColumnLabel[])
        CASE #Terminator
          EXIT ; hit marked end of array
        DEFAULT
          ; Do nothing
        ENDSWITCH
      ELSE ; previous array Index was empty (array was badly formatted)
        MsgNotify ("Array INDEX %1 invalid -- Missing #Terminator?", "LogFileOpen",_nIndex)
        EXIT ; exit loop
      ENDIF
      Increment (_nIndex)
    ENDLOOP
    
    ; Trap in case string end up empty
    IF (STRLEN (_chLogString[]) == 0) THEN
      _chLogString[] = "   "
      MsgNotify ("No top-row string!", "LogFileOpen")
    ENDIF
    
    ; End-of-line ASCII characters
    _chLogString[STRLEN(_chLogString[]) + 0] = 'H0D' ; append CR (overwrite trailing comma)
    _chLogString[STRLEN(_chLogString[]) + 1] = 'H0A' ; append LF
    FileAppend(_nLogFileHandle, _chLogString[])
  ENDIF
  
  ; Clear array stored data values
  LogDataClear (FO_FileColumnHeaderArray[])
  
  RETURN _nLogFileHandle ; return handle integer
  
  ;ENDFOLD (EXECUTABLE)
ENDFCT

Quote from Chang21

No messages are showing on the KCP, robots simply come to gradual stop before moving on.

When the program is paused at a WAIT command, a Status message related to that WAIT will appear. No message means it's not the WAIT I242 causing this behavior.

How long does the robot remain stationary? This sounds like it could just be a case of a "fine" motion occurring.

There's also the Advance Run Pointer to consider. If the Input is not True a sufficient number of motion commands prior to the loop, this could also cause a "fine" type move for whatever is the final motion in the loop.

Is that final motion a CONT or not?

Quote from Chang21

At the top of my program we use the Wait for as shown below,

[WAIT FOR EnableJob50_I242]

once process has finished we have a second wait for to allow us to go back home post work.

[WAIT FOR EnableReturnJob50_I346]

Quote from Chang21

I am more familiar with ABB so am not sure why the KUKA robot is still monitoring the [WAIT FOR EnableJob50_I242] when at the bottom of the program, and if so how to stop it monitoring the input.

From your own description, the program does not wait for I242 at the bottom of the program, it waits for I346. Are you seeing a "Waiting for I242" message on the SmartPad?

I vaguely recall that the I/O mapping for KSS 8 is distributed among a number of XML files. But I don't think I ever tested that.

One quick way to check would be to make an Archive, then make a small I/O mapping change, and make another Archive. Then run the two Archives through a comparator like KDIFF or Beyond Compare. The files that show differences would be the places to dig in further.

Hmm. If this were a memory issue (how many MB do your programs take up?), I would expect everything in the user interface to bog down, not just the cursor response.

My first test would be to plug in a monitor, mouse, and keyboard, and see if the UI suffers similar issues. If not, I don't think it's a memory thing.

The SmartPad is actually a separate computer of its own, communicating with the KRC using RDP. The programs take up memory in the KRC, not the SP, so if your issue is "too many/too large programs", the issue should show up on the KRC.

You could also try just deleting all your programs (MAKE A BACKUP FIRST!), and see if that solves the problem.

If the problem is limited to the SP, it could be hardware or software. Unfortunately the SP is pretty much a black box, so there's not a lot of troubleshooting to do on it. I would suggest contacting KUKA and asking if there are any KSS updates available for your KRC -- it's just possible that there's a bug that a later revision fixed. And a KSS update should also update the firmware on the SP.

(Note: KSS versions numbers are X.Y.Z -- updates in Z are usually free from KUKA, but Y would be a paid upgrade)

Quote from Rayid

By multitasking, I mean a robot with three workstations, with start buttons on each one, calling different programs to execute different tasks.

That's simple enough. There are many different ways to accomplish this, but the simplest might be to use the CELL program, which comes with a lot of support infrastructure on every KRC. CELL runs in a continuous loop, monitoring a set of inputs, and will call a specific program based on those inputs (or wait at Home position for the inputs to change). You will need to edit CELL to call your programs, and set up the various Auto External I/O to the signals you are using, but this is all well documented.

Quote from Rayid

- I know Kuka and ABB are two different brands. I wanted to ask if there are any similarities in the way Kuka programs work.

Eh... Of the major brands, the KRL and RAPID languages are probably more similar to each other than either is to, say, Fanuc TP. But that's about the limit of the similarity. The languages have quite different syntax and structure.

Quote from dardo

I'm looking for an offline programming software, but I face a major problem: our cell layout is constantly changing (2~3 times a day). Is there any software that allows me to create a program based on position variables instead of fixed coordinates? I know I'd lose a lot in terms of precision, but this is not an issue for our processes.

Changing how? By how much? Are there just new obstacles the robot needs to avoid, or do the process points the robot much reach move about?

If you want to program offline, your virtual model has to match your real world condition in order to achieve anything. It sounds almost as if you want to make changes to the final program output without changing the virtual world? That's not going to work.

What are you actually trying to accomplish? In some circumstances, it might actually be easier to make the on-the-fly changes on the real robot, rather than in whatever offline software you're using. This does, however, require you to structure your program properly to support that from the beginning.

It would also be helpful to know what brand of robot you're using, as they all handle this rather differently.

Quote from Rayid

How do I make a copy of the disk correctly?

Clonezilla always worked well for me on KRC2s. Norton Ghost also worked pretty well. I've heard Acronis TrueImage also works, but I've enver tried it.

Quote from Rayid

Topic 3: What is the purpose of the .SUB file? I know it runs in the background. Information? Examples?

A .SUB file is simply an .SRC file that can be run from the SPS (background) interpreter. The SPS has certain limitations that must be followed, such as no motion commands or commands that can change motions (like writing $BASE or $TOOL). Otherwise, the language is the same KRL.

Quote from Rayid

Topic 4: How to use a Kuka in multitasking?

What kind of multitasking? KRC2 supports 1 Robot Interpreter, and 1 SPS interpreter, running in parallel. That's all you have.

Quote from Rayid

Topic 5: Is .src used in Kuka as an ABB (main) type?

What? KUKA and ABB are completely different brands, they have nothing to do with each other. This question makes no sense.

Quote from Rayid

If you can direct me to any bibliography or explain something to me, I would appreciate it in advance.
The manuals I read talk about syntax, declarations, etc., but they don't address my concerns.
I've already read the programming manual by the expert.

This question is far too broad to answer. Programming on the KCP via the menus used Inline Forms (ILF) for "easy mode" programming. Each ILF contains multiple lines of "hidden" KRL. Examining a typical SRC file in the KUKA Editor and in a text editor offline will show the difference.

More avanced programming requires writing "raw" KRL code. It's possible to mix ILFs and "raw" KRL in the same program, but usually it works better to keep them separated.

Quote from massula

Just a note: I'm not sure if a KSS 8.2.x controller would accept any KOPs.

If I recall correctly, KOPs were introduced with KSS 8.3.

Whups! That's what I get for not reading closely enough.

I think ABB uses ZYX sequence for Euler, rather than XYZ. That could be part of the problem.

ABB RAPID includes OrientZYX() and EulerZYX() to convert between Euler and Quaternions the way that ABB does it.

Did you create a new project after installing ArcTech? I would suggest installing the ArcTech KOP into WorkVisual, uploading the active project from the KRC, making a small change, then deploying the project back to the KRC under a new name.

It should go without saying that you should make at least an Archive All backup before this. And should have made a KSR backup before installing ArcTech.

Quote from lekanoje

It is the First Linear motion LIN on step 53 that I had the error.

That would be this one?

LIN {X 270.474,Y 2.649,Z 459.371,A 95.000,B 0.000,C 180.000,E1 0.00000}

With the $BASE and $TOOL values that program has, that point doesn't seem outrageous. I recommend trying the other points until you find one that works. Then compare the Axis angles and XYZABC position of the real robot to the simulated robot for the same command.

Also make sure you do not skip over the $BASE= and $TOOL= lines, or else your program will not behave anything like the sim. The PTP commands to {A1...} will probably work the same, but any command to XYZABC coordinates will be unpredictable.

That's another thing to check when this error occurs: Check the actual values of $BASE and $TOOL in the robot and ensure they match what the program is setting them to.

Quote from lekanoje

I guess the Robot program disregarded the comments. That is why the error is showing up on step 31 on the smartpad.

No, it's the FOLDs. The KUKA HMI on the Smart "folds" any code located between a ;FOLD and ;ENDFOLD into a single line. The code still executes, but the Folding enables Inline Forms and allows you to reduce visual clutter.

Thus, this:

;FOLD ---- GO HOME ----
 PTP {A1 100.000, A2 -100.560, A3 150.910, A4 0.000, A5 47.750, A6 -120.400, E1 0, E2 0, E3 0, E4 0, E5 0, E6 0}
;ENDFOLD

appears that way in a text editor, but on the SmartPad will usually appear as simply ---- GO HOME ----

Quote from lekanoje

I just physically checked the XYZ positions on the real Robot, they are way out of range. I do not know where to pinpoint the situation. Funny enough, the Simulation is 100% perfect..

What positions did you check? The LIN commands, or the Monitor>Position>Cartesian display?

Quote from lekanoje

I activated the PTP $AXIS_ACT on the program line when i first had the Start key error. I got stuck on Line 31(Motion) for programmed path reached (BCO).

As i try toinitiate the start key(Green Button), the robot arm keeps moving out of range. And i stopped the program. The safety stop then got triggered.

Wait, what? In Post #1, you said Line 20 was the problem. Now it's line 31? And is it that line on the SmartPad (as shown #20 in your photograph), or the line number in the .SRC file as it displays in a text editor?

Line 30 in your posted file is a commented out BAS(#FRAMES) command, so that's no help.

If you want effective help, be specific. That file has over 2000 PTP/LIN motions in it, saying "line 31" does not help find the problem at all.

Your file sets $BASE and $TOOL as follows:

Those appear to be reasonable numbers. But do they match what the simulated robot is set up for?

Quote from lekanoje

Output?. Can you please offer some explanation. The simulation ran successfully and I was able to generate a program from the simulation.

If the real robot behaves differently from the simulated robot, there are only a few possibilities:

1. The program in the real robot does not match the program generated by the simulation postprocessor.
2. The program generated by the postprocessor does not match the program in the real robot.
3. There is a configuration difference between the real robot and the simulated robot (different model, different $BASE/$TOOL settings, etc).

In this case, #3 should not be the issue, since your screenshot of the SmartPad shows you are moving the robot to an E6AXIS position, which is unaffected by $BASE and $TOOL settings.

Your screenshot of the SmartPad shows a date&time that matches perfectly with that in the .SRC file you attached.

Therefore, that .SRC file does not match what is in the simulation. Either you posted the wrong file to this forum, or your postprocessor is not generating a .SRC file that matches your simulation.

Quote from lekanoje

No error message came up. Everything was fine.

Then it would appear the problem is in your output from RoboDK.

Quote from lekanoje

I also, created and saved a HOME position with its axis on the simulation. I discovered the saved Home positions on the simulation is not transfrred to the real program. The default HOME position is still coming up as i try to RUN the program.

Please find attached code for review. I would appreciate any input to get this solved in this Forum.

Is the program you attached the direct output of RoboDK, or is it saved from the robot? B/c the .SRC file appears to match the display on the SmartPad 100%.

When you copy&paste the program from the USB using the SmartPad, are there any error messages generated?

The input to the Geometric Operator can be FRAME, POS, or E6POS, but the output is only ever FRAME -- XYZABC, no S, T, or Ex.

So applying an offset to Ex as you are with TOffset won't have any effect.

Quote from glowny_automatyk

But currently I have an additional linear axis

And this axis is... where? Going by the rest of your post, I'm guessing that the robot is mounted on E1, which is probably a rail?

Regardless: it's possible for the robot to reach a given XYZABC position in space from multiple different positions on the rail. Too many for the KRC to simply guess at. As such, it's up to the programmer to positively control all 7 DsOF.

For a PTP move, an out-of-reach condition would be predicted before the motion began. But any LIN-stype motion consists of many, many tiny PTP motions daisy-chained together, and that reach prediction only looks one PTP motion ahead. So a LIN motion with a destination 5km distant will try to make that move, right up until it hits a joint or reach limit. This is something inherited from the original version of KRL/KSS back in the 1980s, and KUKA has probably never had any strong motive to change it.

The FORWARD and REVERSE functions can be used in your program to try and pre-calculate this kind of problem.

So, $CONF_MESS needs a pulse (specifically, the False-True transition edge) to clear any messages. If $STOPMESS remains True after you pulse $CONF_MESS, then you need to look at what messages on the KRC are not being cleared.

You also need to check your timing. Each signal should be a send, wait for response, then execute the next signal. If you fire the various signals too quickly, you can cause a lockup. For instance, pulsing $DRIVES_ON followed to $CONF_MESS too quickly can result in the messages not clearing, since the Drives need some time to engage before their blocking status clears.