Posts by jay

Smallest valid TP program:

/PROG A
/ATTR

All sections:

/PROG A
/ATTR
/MN
: ! code goes here ;
/POS
/END

I wrote about this recently here.

It may be more reliable to run a KAREL routine that records timestamps on start/stop.

Eric is correct. #EMH indicates a material handling overlay, #ESW for spot welding, #EAW is likely arc welding.

The last digits of the part number indicate the revision and possibly touch screen? Older iPendants have the E-stop towards the middle while the newest revision has it near the top.

It's certainly possible to reinvent the wheel, but it would be much easier to just get the iRVision 2D Visual Tracking option.

Is your goal to simply get the system to work or to gain a very in-depth and academic understanding of how visual tracking works?

If you enjoy the prospect of the academic exercise:

1. Write a background "sensor task" that triggers your 2d single view vision process every so often, either on a time delay, or every X distance of conveyor travel (better).
2. Associate/save the current encoder count with this set of offsets (you'll need it later to figure out how far the parts have traveled along the conveyor)
3. Translate your vision offsets from the camera's calibration frame into your tracking frame.
4. Put these vision offsets into some sort of queue e.g. ( [{ encoder_count: 10000, vision_offset: { x: 0, y: 0, r: 0 }}, { encoder_count: 10000, vision_offset: { x: 10, y: 5, r: 45}}] )
5. Write a routine that receives offsets from the queue when they are within the robot's tracking boundaries, populating a vision register with the offset data
6. Make sure to write a couple maintenance routines that clean up your queue (get rid of parts that pass beyond all boundaries, parts that were seen by the camera twice, etc.)

If VISION GET_NFOUND is not available, I would just call GET_OFFSET repeatedly until it fails (jumps to the label provided).

Hi Steven,

Each call to VISION GET_OFFSET only returns a single offset. You can get more offsets by calling VISION GET_OFFSET multiple times. You may find the VISION GET_NFOUND command useful.

e.g.:

LBL[1] ;
! execute the 'TEST' vision process ;
VISION RUN_FIND TEST ;
;
! get the # found ;
VISION GET_NFOUND TEST R[1] ;
;
! loop through the results ;
FOR R[2]=1 TO R[1] ;

! store the offset in VR[1] ;
VISION GET_OFFSET TEST VR[1] JMP,LBL[1] ;

! do something with the offset ;

ENDFOR ;

Hi Marla,

It looks like you're not terminating your CONDITION[1] with an ENDCONDITION statement.

CONDITION[1]:
WHEN GOUT[2] = 2 DO
tp_call
-- re-enable condition handler
ENABLE CONDITION[1]
ENDCONDITION

-- initially enable condition handler
ENABLE CONDITION[1]

Condition handlers are automatically disabled whenever they are triggered. This is why it's typical to re-enable the condition handler when the handler completes as shown above.

KAREL has many XML-related builtins that are documented in the manual. You could potentially 1) upload a file with XML position data to the robot, 2) provide a signal to the robot that it's ok to read the XML data from a known location.

Hard to say if this is easier or more efficient, but it may be worth a try.

On current controllers you have several options, but I'm not sure if this is applicable to R-J3iB (I would guess that it is the same):

1. System config has an option to allow/disallow simulation while in AUTO ($AUTOMODE_DO)
2. System config has options to define outputs to set when any inputs and/or outputs are simulated
3. You can setup a Production Check to disable production if any I/O is simulated

FANUC has an error code manual that lists them all.

Quote

Jay, would you be able to elaborate further on the difference between CNT0 and FINE termination types and how each may be used more effectively in the programming process?

Generally, I would only use FINE when absolutely necessary. A FINE termination type causes the robot to actually stop at the position before moving on. Any CNT termination allows the robot to decelerate as it reaches the destination, but it does not actually stop unless that's the final position. Think of it as rounding a corner: CNT100 will round the corner at P2 between P1 and P3 the maximum amount will CNT0 will only round the corner slightly. FINE won't round the corner at all.

Quote

So with regard to PAYLOAD settings, would adjusting the PAYLOAD setting to a smaller value allow more freedoms due to the joints and axis' not being concerned with more inertia being moved? I may be misinterpreting this.

Basically, yes. The robot takes its payload into account when planning its motion. Lower payloads allow the robot to be more aggressive.

You can find the payload schedules under Menu > System > Motion. Without setting a payload, the robot assumes its maximum payload, 5kg in your case. If you setup a schedule at say, 1kg or .5kg, you will find the robot accelerates much faster and even rounds corners differently. You can configure the CoG and inertia values as well, but simply changing the mass will help a lot in your case. Use the PAYLOAD instruction in your TP program to set a schedule active.

Hi David,

Another option outside of the password-level lock-down functionality is to put the teach pendant in HMI mode. The iPendant HMI Setup menu allows you to disable the SELECT, EDIT, DATA, and TYPE keys. This is covered in section 2.2.23.4 of the HandlingTool manual.

HMI mode is not protected by a password, so an overly curious operator who likes to push buttons may be able to disable it, but this is a quick way to at least have some level of protection.

The codes returned in the status parameter of many KAREL builtins are of the format:

ffccc (decimal)

where 'ff' represents the facility code and 'ccc' represents the error code within that facility.

Error code 2008 corresponds to facility code 2 (FILE), error 008 (FILE-008): Illegal device name.
Error code 67205 corresponds to facility code 67 (HOST), error 205 (HOST-205): Tag already mounted.

You may want to use DISMOUNT_DEV before calling MOUNT_DEV just in case the device is already mounted. I would guess that MSG_CONNECT should work even after an error 67205 from MOUNT_DEV, but it may not. Hope this helps.

Are you using the MOUNT_DEV procedure to ensure the server tag is ready before moving on to MSG_CONNECT?

If it works fine when you manually start the program, the issue may be that the Autoexec program starts before the rest of the controller is ready. You may want to try using a DELAY statement at the top of your program (or a WAIT FOR statement) before initializing your server.

Hard to say... you may want to add some debug information to your KAREL program to ensure it's in the state you expect before trying to connect with your PC.

You may also want to add the %NOBUSYLAMP translator directive so that busy lamp isn't ON all the time

Yes, you can set it as the Autoexec program from the System Configuration screen. Menu > System > F1 (TYPE) > Config

Yes, it is probably possible, but FANUC will not honor your warranty if you change the internal cableset without approval. You're probably better off running the cable externally.

Hi there,

The differences between each motion type are described pretty well in the HandlingTool manual section 8.4.2, but here's a quick gist:

* Joint moves move all required axes simultaneously to get from point A to point B. This will probably cause the TCP to move in an arc instead of a straight line between points.
* Linear moves move the TCP in a straight line from point A to point B. Depending on your start and end points, a linear move may not be possible due to configuration changes, singularities, etc.
* Circular moves allow you to move in an arc from point A to point B through an intermediate position C.

In general, linear moves are good for when you need the robot to move in a straight line. Joint moves allow the robot to move in the most efficient way from points that may be very different from each other. In either case, the slowest axis of your robot will be the limiting factor. Circular moves are generally only used when necessary.

As far as cycle time goes, here are a couple tips:
1. Use as few points as possible to get the job done
2. Make sure your PAYLOAD settings are accurate
3. Keep your termination types (e.g. CNT100) as high as possible while maintaining accuracy. The difference between FINE and CNT0 is huge.
4. Remove any WAIT statements if you can

Hope this helps. (Also wish I had an LR Mate to play around with in college)

Hey everyone,

Just wanted to quickly share an open source project I've been working on: KUnit, a unit testing framework for KAREL. It provides some simple structures and assertions for writing automated unit tests on the controller.

I wrote a blog post about it here: Introducing KUnit

You can download and view the source code on GitHub: https://github.com/onerobotics/KUnit/

It basically allows you to write small tests/assertions about your KAREL code and then use a web browser to see the test output.

Example:

PROGRAM test_add_int
  -- %NOLOCKGROUP is required to run KAREL from browser
  %NOLOCKGROUP
  -- %INCLUDE the KUnit routines
  %INCLUDE kunit.h


  -- the ROUTINE under test
  ROUTINE add_int(l : INTEGER; r : INTEGER) : INTEGER
  BEGIN
    RETURN(l + r)
  END add_int


  -- 1 + 1 = 2
  ROUTINE test_11 : BOOLEAN
  BEGIN
    RETURN(kunit_eq_int(2, add_int(1,1)))
  END test_11


  -- 2 + 2 = 4
  ROUTINE test_22 : BOOLEAN
  BEGIN
    RETURN(kunit_eq_int(4, add_int(2,2)))
  END test_22


  -- 0 + 0 = 0
  ROUTINE test_00 : BOOLEAN
  BEGIN
    RETURN(kunit_eq_int(0, add_int(0,0)))
  END test_00


  BEGIN
    -- initialize KUnit
    kunit_init


    -- do some tests
    kunit_test('1+1=2', test_11)
    kunit_test('2+2=4', test_22)
    kunit_test('0+0=0', test_00)


    -- output the test suite results
    kunit_output
  END test_add_int

Run the program in the browser via http://robot.ip.address/KAREL/test_add_int and see:

KUnit


...


Finished in 0.002 seconds
1500.0 tests/sec, 1500.0 assertions/sec


3 tests, 3 assertions, 0 failures

Give it a shot and let me know if you have any questions, issues, feedback, feature requests, etc. Pull requests gladly accepted

scotty and bidzej are correct, the two ethernet ports can only be configured on different subnets and have no routing functionality.

Quote

OK, it might be the case that either of the port can not be configured as router or switch (don't know which one is appropriate ). But the next question is why every controller has two ports? Why Fanuc, who is quite cost conscious, would give an additional Ethernet port??

Generally 1 port is used for communication with external devices while the other port can be used for PC access, RIPE, ethernet encoders, etc.