Seems familiar.............Yamaha?
Posts by TygerDawg
-
-
I am North American reseller of RobotWorks software, an Add-On program for SolidWorks. RobotWorks will do this for you also.
-
In general, I would not expect the systems integrator to be qualified to make these measurements. The job of the system integrator is to assemble the different components together into a machine.
I suggest you contact robot manufacturer's Applications Engineering departments and discuss your needs. They may have data already created for these performance criteria. They may be willing to work with you to design tests and gather data (but usually for an engineering fee).
Nothing but actual live tests with real tools, fixtures, environmental conditions, and workpieces will determine if any of the robots are suitable for your adaptive deburring application.
-
I might be able to help you out.
Send me an email with valid contact information to " bt <dot> info <at symbol> bluetechnik <dot> com "
(blind contacts will be ignored)Cheers,
-
Sorry, never used any of those.
-
I think use of GOTO is lazy programming style and is difficult to understand program flow. Use of GOTO can produce very complicated program flow if not careful. Just try flow charting your code and you will see.
In your case I would use nested CASE structures.
done_flag=FALSE
DO
CASE i OF ;1st case loop
VALUE 1:
CASE counta OF ;2nd case loop
VALUE 1:
<something>
done_flag=TRUE
BREAK
VALUE 2:
et cetera
ENDCASE
VALUE 2:
et cetera
ENDCASEUNTIL (done_flag==TRUE) OR (<other condition>)
..or something similar. It is more modular code design, easier to follow by someone else.
I'd also use subroutines for separate motion & calculation statements. In the subroutines I suspect that you could implement error recovery routines you wanted earlier.
-
I don't know AS, but do know V+ which is similar. Some suggestions:
Improve structure with a CASE or SWITCH structure or whatever is AS equivalent (don't use GOTO...yuck).
In rough pseudo-code, here is my idea:
.PROGRAM pg0()
...blah blahDO ; infinite loop
CASE of pg.no
VALUE 1
CALL two_box()
BREAK
VALUE 2
CALL three_box()
BREAK
...
VALUE any
; do nothing
BREAK
ENDCASEUNTIL false (or other end condition)
In each called program, then you must set up error trapping routine. In V+, there were functions REACTE (react on error) and REACTI (react on input). These were set up to catch errors, interrupt programs, and allow the programmer to design a reaction to the error. Does AS have something similar?
-
Unfortunately that seems to be the nature of the beast. From my skeptical, burned-out experience, the reasons for the constant recruitment ads for programmers:
Robots aren't deployed on the system integrator's floor, they are deployed at the customer factory site. Travel required.
All other parts of the machine / system are done FIRST, and THEN the RobotGuys are sent to finish up. Usually by this time the schedule is way behind and time must be made up by the programmers. Long hours required.
Too many places are still run very badly and a "throw it over the wall" mentality masquerades as "team work". A lotta BS. By the time the programmer gets it, all the supporting "team" members are deployed on other projects and can't be bothered to fix all the mistakes. Long hours & pressure to patch it all up on the customer floor. I've been "stranded" at customer sites on several occasions by miserable management teams who think their job is to deploy a warm body to the customer floor. I once had to beg the plant manager for a weekend off to go back home for my wife's birthday.
If your job is Manufacturing Engineering, then robot programming is only a small portion of the work done. Production Managers are only concerned with getting their parts out the door, on THEIR schedule. Robot breakdowns, repairs, upgrades, and programming changes occur at 230AM on Sunday night. Oh, and they only give you 1-1/2 hours time slot, so you had better get it done.
Robot programming is a lot like crack cocaine (or so I've heard). You get hooked on it.
Consider going freelance. I have friends who do that , and it is quite lucrative. It requires travel, though, but you are more in control. Regarding job liability & task responsibility, many of the freelancers I know adopt the mentality of "I sell programming HOURS, not SOLUTIONS" as a way of not getting stranded forever a badly concepted system job.
-
I may have to develop a similar course in the near future and have given it some thought, applying wa-a-a-ay too many years of shop floor experience to the task.
#1: Safety issues.
Not a recitation of RIA/ISO standards, but realistic stuff. "No persons in workspace while robot in auto mode. No exceptions. Walk off the job is Boss says do it anyway." Safety circuit strategies & devices, so that students are aware & can recognize the correct equipment when they see it. Examples of robot safety stupidity that gets folks killed (e.g., that youtube video a few years back where some chowderheads strapped a chair to a large Fanuc arm and went for joyrides...almost clunking his head on the floor. What isn't recognized is that the accelerations of that motion are nearly neck-snapping like the Earnhardt crash.)Robot morphologies. 6-axis, 3-axis, 4-axis, articulated, cylindrical, etc.
Robot location theory. {X, Y, Z, RX, RY, RZ}, frames, tools, coordinate transformations.
Essential programming constructs for never-programmed-before students. IF-THEN-ELSE, DO loops, WHILE loops, FOR-TO loops.
Motion programming constructs. Show various types because all robots seem to do it differently. Linear, circular, continuous paths.
Workcell design. Optimal placement of robots, fixtures, EOAT.
Speed issues. Accels, Decels, speeds of motion segments. How to optimize speeds.
Tool design & tool transformations.
Use of relative transformations...the theory & utility of such, at least.
Programming excercises. Simple pick place, path apps, multiple tools, matrix apps, palletizing apps.
Basic system integration. Signals, PLCs, sensors.
Accuracy versus repeatability discussion.That should be enough to blow any newbie's head off.
-
If I recall correctly, there are two V+ commands for teaching from the command prompt ("the dot prompt").
HERE <location_name>
TEACH <location_series_name>
Your description appears to be a response from a custom program used for teaching application-specific locations.
Use the TASK command to see which program is running in which task, then you can look into the function of the program. Or you could ABORT or CONTROL-Z the program to discover which one it is for editing.
-
You do not give much for design requirements. Do you have surface finish issues, inside / outside gripping, mass of part....
If your system design would allow it, I would use some variety of tool steel for the gripper "fingernails." This will last the longest.
If you cannot use tool steel, then some type of softer metal (brass, aluminum, mild steel) for touch surface inserts, but expect to replace the insert regularly as a maintenance item.
Ground or polished touch surfaces.
Correct pneumatic pressure to avoid touch damage.
If two-finger gripper on external grip, I have used fingernails designed like machinist's v-block locators to capture the cylindrical object at the centerline axis.
If two-finger gripper on internal grip, I have used fingernails with matching radii to internal diameter.
Similar construction for three-finger grippers.
I have designed in shoulder features to the fingernails that allow me to positively align and locate the workpiece repeatably.
For 90C hot environment, I would either try to cool the gripper between picks/places, or make the fingernails long in order to attempt some bit of "cooling fin" heat transfer effect. If you do not cool, then you will lose the gripper mechanism and / or the heat will be transmitted to the robot wrist joint. That's bad news. -
Experience gained from many years of shipping robots:
Be sure to collapse and tuck the arm, then block the joints with foam blocks, wood blocks, stacked cardboard, bubble wrap, down pillows, whatever. It's never a good idea to try to use the motor brakes and geartrains to counteract the bouncy-bouncy action of shipping robots on a truck trying to make the arm links remain stationary. -
Re-iterating my advice on another post somewhere in the forums:
Another strategy to avoid singularities is slight modifications of how the tool and workpiece is mounted. Most tool designers are not RobotGuys. So the designers typically design EOAT mounts and workpiece fixtures that are all square and orthogonal designs and aligned with the Robot World axes.............terrible. Add small offsets (5- 15 degrees) to your tooling to offset the axis alignments slightly. As stated before, this won't eliminate singularities, but will certainly reduce the likelihood of them occurring. And it is an inexpensive solution. I've done this many, many times over the years with great success.
-
Case 1: compact, complicated workcell with actions & functions arrayed 360 degrees around the floor-mounted robot. It was very useful to have this capability. The fastest path from a point in front to a point in the rear was a "Great Circle" path over the top of the robot.
Case 2: Inverted robot: can utilize all of the available work volume of the arm.
Case 3: Some deployments for machine tending or injection molding machine tending. Pick from the front, perform secondary operations to either side, place to the rear.
-
I'm not an expert in AS language, but know V+ which is similar. Does AS have a "DRIVE" command? In V+, this command is used to move an individual axis a desired amount.
-
A simple way to do this that I have seen used many times is to position a simple limit switch in the workcell. When the robot is at "home", then the robot's EOAT actuates the limit switch in some manner. This provides redundant confirmation of tool location, arm configuration, and no motion.
-
Clean room arms will have features like this:
- buffed / polished arm element surfaces, smoother than the typical industrial variety
- special coatings & paints that minimize outgassing, or that may survive a caustic washdown environment
- special plumbing arrangements to eliminate or control pneumatic exhausts to specific ports, keeping it out of the controlled environment
- perhaps special bearings and / or seals at the joints to control outgassing of seal materials and to keep the robot's internal cavities hermetically separated from the controlled environment
- special electrical connection arrangements (e.g., down through the mounting base) to maintain the controlled environment
Take a look at what Staubli offers in this area. They've been selling into the clean room environment for years.
-
Even better:
"Repeatability Specs" are made for full-speed, full-payload. I've found it better to attach a EOAT of significant mass to bias the gear mesh. Since a repeatability spec defines a spherical tolerance zone around a point in space, I also believe you're going to get more useful data if you use your dial indicator to check on three planes. Use a cube or inside of a box or whatever...you get the idea I hope. Further, move to same point but in different orientations. And repeat the test a significant number of times, at different times of day that accomodates temperature changes.
This is not hard to do, but is semi-rigorous with respect to mathematics and statistics.
-
I wouldn't know if this would be useful to you or not since your positions are vision-system driven, but...
Many of us gray-haired grumpy old robot guys learned to add some slight angles to the tooling to reduce the probability of encountering a singularity. Pallets, trays, robot mounting bases, EOATs, everything is usually designed by machine designers, not robotics guys. So they build it in nice, square, orthogonal arrangements because it's easy to do so in the CAD systems. I've found that's one of the worst things one can do in robot systems. If you add some tilts, twists, and angles to the tooling elements, you are less likely to create the situation that develops into a singularity. Still could happen, though.
Other than that, I could imagine you set up a separate task (if possible in your operating system) to monitor rates of change of joint links. Then react accordingly if the joints start to spin too fast (indicating an imminent singularity).
-
Just a quick thought and this comment may not apply: is your tool a simple pointer co-linear with Tool Flange Z-Axis? If so, no need to teach that, just plug in the number for the tool transform definition {0, 0, <number>, 0, 0, 0}.
The math behind the 4-point teaching method makes me think there could be some calculation weirdness for just such a condition, but would work well for offset arbitrary tools.