Posts by TygerDawg

First things first: decide what it is you wish to teach your students.

• fundamental exposure to robot technology
• simple programming via Teach Pendant Programming TPP
• more complex programming with structured language
• simple pick & place or more complex path applications
• systems integration (sensors, grippers, vision systems...)

Simple: less time, effort, cost. Students get less learning and skills.

Complex: more time, effort, cost. Students get more skills (but is more needed for High School?)

Do your students already have some programming experience? Many do not. Nor have patience to read, study, and learn.

My University / Engineering Technology labs use small Kawasaki units. Selected because of TPP +AND+ a very powerful & easy structured language together. Not terrible. But I only use TPP because my students are iPhone generation and don't know, and don't care, about structured language programming.

I use RoboDK extensively in my course. I want students to know what is offline programming and also to help visualize 6DOF motion. Education license is what I have, minimal or no charge. Full function, six months. RDK is a very good package once you get over the learning curve. Can integrate Python programs for exotic actions, so can do "programming" with that.

I wanted to evaluate an interesting new small lab scale 6-axis cobot from IGUS. But these products are new release this past Spring and I have not been able to get my hands on one yet. I ***think*** I got budgetary pricing of ~USD$9K (?) each at one time. They also have other types like gantry units.

Skyefire mentioned Automation Studio. Fabulous product, insanely expensive for Academic use. I discovered a much less expensive alternative that I use in my classes, AUTOSIM PREMIUM from IRAI France. Less polished than AutoStudio or the equivalent FESTO software package, but very powerful anyway. I use it to teach students fundamentals of pneumatic circuits. My colleague uses it for hydraulics technology. It can also be used for PLC and industrial control circuit simulation.

IRAI France also has an interesting "robot" simulator package for HighSchool or less called MIRANDA. You may find this interesting. Find link to it on their website.

Many, many options available for this. Some may even be inexpensive.

Search strings:

• Cartesian robot or Cartesian actuator
• XYZ Gantry or XYZ Gantry robot

You need to define your maximum Z-axis height.

Resolution is usually very high, but you need to define your needs.

Motors used to drive the axes may cause noise problems depending upon your required traverse speeds.

Concur.

Staubli, Kuka, etc., have +World_X axis pointing forward from the robot.

Kawa is rotated, +World_Y points forward from the robot.

The Kawa World coord sys is like most milling machine tools: standing at a mill, +Z is UP, +X points to RIGHT, and +Y points FORWARD.

Why they choose to do this and be inconsistent with the rest of the robot market is one of this life's great mysteries.

On my small teaching robots, the Tool Flange coord sys is also a bit different. -Tool_Y points through the dowel pin. So +Tool_Y points opposite the dowel pin.

Kawa makes a nice robot system, but it has its quirks. Perhaps my assumption/assertion that Kawa is essentially a captive company for Toyota (and, to a lesser extent, Ford) is true. So they don't need be market-consistent or friendly.

As a rule, I ***NEVER*** change the BASE of a robot. In my particular world, there are just too many problems that doing this could create. Especially if I change the BASE on an application and leave it for some other poor goombah to discover by accident. Most robot users/programmers do not understand transformations, so why leave these boobytraps out there for others to find?

It's been many years, so please forgive if my transformation math is not exactly correct.

If I remember correctly, SHIFT only applies to points in the BASE coordinate system.

So the problem statement is:

GIVEN:

• arbitrary FRAME (call it: frame1) out in robot space taught in the default BASE robot coordinate system
• an X-Y-Z pattern of points relative to frame1 (call them pt1 = frame1+TRANS(X1, Y1, Z1), pt2 = frame1+TRANS(X2, Y2, Z2), etc)

FIND: I desire to move the points pt1, pt2, etc. to my dimensional specification within frame1 (sort of like using SHIFT inside frame1)

SOLUTION:

• OPTION1: Use TRANS function to calculate transformations within the frame1 coordinate system
  • command: pt1_new = frame1+TRANS(X1+X1_shift, X2+X2_shift, etc)
• OPTION2: inverse the frame1 back to BASE and then use SHIFT within the BASE coordinate system
  • command: pt1_new = SHIFT(-frame1+pt1 BY X1, Y1, Z1)
    • ASSUMPTION: all of the various coordinate systems are aligned suitably. Else it may be necessary to change the order of the X, Y, Z components to get the desired changes

Like I said, it has been many years and my command might be incorrect. I'd have to find a machine and test this and prove the correct trans math order. But I hope that you are understanding my intention.

You may not ever resolve this. Reasons:

• robots are repeatable, not accurate
• path accuracy is a tubular tolerance zone around a mathematically perfect path definition and is dynamic based on arm configuration (varies all over the work volume)
• a robot arm ain't a rigid CNC machine tool
• servo parameters for individual motors may need tweaking to smooth out those bumps...not recommended
• some arms are meant for carrying heavy loads point-to-point, not to follow a path

Servo-tweaking:

Years ago I was engaged in a project to resolve an out of tolerance condition on a Staubli robot path doing high-precision cutting. The application was analyzed. It showed that the path segment containing the tolerance deviation occurred when the J2 and J3 links went through an inflection point. The arm extended, paused, and then retracted. J2 & J3 opened, paused, then closed. Poof: consistent path tolerance deviation at the inflection point.

How resolved: some really clever French servo programmer engineers "super-tuned" the servo parameters and sent to us a new servo parameter setting. Problem was corrected. But I hate solutions like that: implementing a "special" in the field and leaving it for the next poor b@st@ard to find.

Wrong arm use:

I was tasked with a dispensing job using a refurb BigYella spot welding beast. Dispensing path tolerance is very forgiving. Except this big arm had to move its J5 & J6 in wild gyrations as the dispensing gun traversed around a sharp corner. Angular accelerations were high for J5 & J6. Result: squiggly dispensing lines that could not be programmed out. Cause: big J5 & J6 gears made for carrying heavy payloads, not doing finesse work.

Quote

What is your budget?

Cwany: We know the price range of this size of cobot and are prepared to commit the funds to it if it is the right choice for the organization. Why do you ask? Any Educational Discount that might be offereed doesn't really add up to much. None of the cobot manufacturers are cutting any substantive deals for Academia. I guess it is too early in the market cycle.

Skye: thanks for the good insight. Familiar with UR arms, have seen the Fanuc CRX arms webpages. Was curious what BigYella had to offer that would discriminate their product from the herd. We already make the students sweat over another well-known industrial arm.

Thank you for your replies.

Anyone else have any insights to offer?

It is not my intention to create a firestorm of opinions with this question.

I have a situation that requires fast resolution.

We have an opportunity to move on the purchase of ONE collaborative robot.

It will be used for academic student teaching, student projects, and so on.

Given the evolution of the cobot market so far (October 2021), which brand of robot would you purchase (5-10Kg-ish payload range) ?

Brief reasons why would be nice.

North American market only.

You may be lucky enough to find some descriptive VAL3 language programming documentation available for no cost. Check the Staubli Customer Support site. Those are reference documents and not useful without training. Useful knowledge of programming VAL3 applications comes with a Staubli training course.

Many thanks, that's a very clarifying assertion. I'll have to investigate more and ponder next steps.

Very interesting insight in this discussion. I know very little about Fanuc arms & programming. I'm looking to expand and as popular and pervasive as Fanuc robots are, I'm not sure now they would be a good fit for me.

Quote

Edge case, general industry, fancy programming is all I do.

Would be cool if Fanuc developed a proper IDE.

I've done plenty of that also. Just curious: what is your favorite choice of robot brand for this level of work?

Quote from hermann

Don't know when VAL was introduced, but I used BOSCH robots (nowadays they don't exist anymore) in early 80's. They had a complete language with variables, structures lke "if then else" "switch case" and so on....<snip>...They had multitasking, and they where able to control multiple mechanics with one controller. What a pity that they didn't survive.

You would very much like the Staubli VAL3 language and the integrated & powerful IDE Staubli Robotics Studio SRS. VAL3 does all of that. I haven't punched keys on SRS in years, but it was awesome for complex programming tasks.

In the early 2000's I was approached by a large company for just this. The task was repair of turbine blades. The problem:

• blades are very expensive so repair is preferable to new
• blades undergo high-temperature loading during service. Blades demonstrate creep after being in service, and the distorted shape does not agree with the CAD model.
• blade leading edges and tips erode during service. This produces random "scallops" and reduces surfaces that must be rebuilt by welding new material, then manually finishing (machining & grinding) to an aerodynamic profile.
• The skilled crafts employees used to do this repair task were all approaching retirement age.

My client wanted a magical software package capable of developing a repair strategy for a blade and create robot welding paths based on the repair requirement. I researched vision systems, scanning, CMM measurements, point clouds, and so on. I did not find any useful solution. As far as I knew at the time, the technological level of software was not sufficient to perform this adaptive/generative CAD task.

Almost 20 years later, the technology level is probably suitable for this. Massive amounts of programming would probably be required. My guess is that it still does not exist on the market. Therefore it is still probably less costly to simply hire & train a new generation of craftspeople.

Staubli is a "programmer's robot" and the language is much more sophisticated than most robot programming languages. It would help if you had a C++ programmer's mindset.

It's been a while since I used the Staubli VAL3 language. I checked my old VAL3 Language Reference to confirm. I don't see that the VAL3 language supports simplistic JMP-LBL or GOTO language constructs. The language was developed to perform highly complex actions beyond simple technician-level programming. In large, complex programs JMP-LBL & GOTO commands will make the code unsupportable because it will be difficult to follow the logic and program flow for diagnostics.

In addition to the constructs provided by Psyril, you also have available the CALL-RETURN constructs. For me, that is what takes the place of JMP-LBL & GOTO constructs. My programs would have many subroutines.

You might consider a trick we used years ago for trade shows. We fabricated a steel box, maybe 5 ft x 5 ft x 1 ft. Bottom plate + four sides. On the underside were added channels for fork lift forks. Inside the box were added four mounting bosses with tapped holes. On top of the box was a 3/4-inch thick tooling plate secured to the internal mounting bosses. The box was filled with landscaping crushed rock for ballast. It weighed a million pounds. But we mounted large, fast robots on it used to do a lot of flashy zip & spin high-inertia moves for the trade show audience. I do not recall that beast ever moved a hair.

If 1 of 10 parts is slipping, then that is a 10% failure rate.

If 1 of 20 parts is slipping, then that is a 5% failure rate.

Both cases are utterly unacceptable because of damaged work pieces, equipment, and disrupted operations.

The design issue is to provide enough grip force and enough coefficient of friction to hold the work piece. It appears there is an opportunity for improvement that will provide a robust solution.

Any of the soft stuff applied to gripper fingernails will become a maintenance issue, disrupting continuous production and uptime. As you have discovered.

The toothed inserts will certainly provide more friction if your work pieces. But it will involve surface disruption.

You might consider going back to the beginning with (1) properly designed fingernails (not trivial) and (2) properly sized gripper mechanisms (again, not trivial).

Every gripper manufacturer I have ever encountered provides rigorous engineering guide for proper application of their gripper. Defining the fingernail geometry to grip multiple parts is usually a fun challenge. An expensive alternative for multiple incompatible work piece geometries is multiple grippers and tool changers. But that requires extra programming to be effective.

Things to consider:

• put this question in the Staubli robotics discussion forum, not the General.
• arm is not calibrated
• arm is badly calibrated
• battery to backup the calibration is low-voltage or dead
• you have a EOAT transform that may be badly calculated, and you are commanding the TCP to move to a location that the arm cannot reach
• regardless of EOAT transform invoked, you are commanding the arm to move to a location it cannot reach

Concur with Skye & Rob.

Whenever someone tells me Awww, that'll be good enough without calculations for verification, I go into Stupid Spasms.

Manufacturers will supply a figure of loads applied BY the robot TO any device/surface to which the robot is mounted.

It is required to take those force and moment values and design a mounting system that will absorb those applied loads.

This design task will involve static load and structural analysis, floor anchor specification (style, diameter, engagement, pull-out force), and so forth.

If you or your team doesn't know how to perform these mechanical engineering calculations, hire a consultant.

Good enough and they say it's fine may get someone injured or worse.

For a calculation, you'd have to estimate the change in momentum of the water exiting the nozzle. This could produce a force value.

However, water jets are usually very small diameter. Lots of pressure, but how much mass is being expelled per unit time? Water jet manufacturer could give guidance on volumetric flowrate of water+abrasive (and THAT gives mass flow rate for momentum calculation).

I suspect that this is a lot of unnecessary calculation. Arms large enough to perform large waterjet cuts will usually be large payload also. They might not ever notice the waterjet reaction force. Small arms may be more susceptible to those forces.

Unsure of the capabilities of your specific robot brand. We installed a Staubli arm once upon a time in a similar tough situation. Staubli showed us how to change the mastering pose to something more useful. We simply had to put our own scribe marks on the joint in question. It was also deemed critical to sufficiently document the non-standard condition for others who came after.

RESOLVED.

There had been at one time a previous AS tool transform definition invoked.

But all AS tool defs were deleted.

The invoked tool transform was retentive, and I was too fatigued & distracted to remember / recognize that.

Kawasaki guy mentioned this as a possibility, and this condition was verifed by using the Teach Pendant Keyboard to enter the TOOL command, which displayed the current active tool transform. It matched the motion I was seeing.

But, my question remains: if switch QTOOL was set to OFF, then why was the previously-set AS tool definition still active when Tool Mode Interpolation was selected for manual movement?

The comment at the bottom of the QTOOL selection states the tool def will be used for teaching if ON, and not active if OFF.

I suppose that it is a mystery of Japanese logic and design.

I teach a Robotics course with four Kawa RS03N arms with E76 controllers. No student damage, fresh batteries and re-zeroed. We use a simple Tool-Z axis pointer tool for most exercises.

One robot started recently (after good behavior) to exhibit Tool Mode motion that is not oriented correctly. Wither NULL Tool or Aux Function T1 = {0, 0, 128, 0, 0, 0} invoked I get this motion on pressing the TP buttons:

• Press +X: TCP moves +Tool-Z
• Press +Y: TCP moves -Tool-X
• Press +Z: TCP moves -Tool-Y

Behavior is like the Tool Coord Sys has a RX(+90) and then a RZ'(+90) rotations.

This occurs with any Tool transform invoked.

Base Mode motion moves correctly in all axes.

I've checked various things:

• QTOOL = OFF
• no other tool definitions active
• BASE Coordinate System has not been modified

I have requested help in diagnosing this directly from Kawasaki and have not gained any traction with those guys.

Can anyone suggest a diagnostic path to figure this out?