This thread may be helpful: Best practice to calibrate real world to roboguide
Posts by TitusLepic
-
-
Relevant post: General conversion between different coordinate system types (KUKA, Fanuc, ABB, etc)
More detailed explanation: https://www.mecademic.com/academic_artic…n-euler-angles/
Off the top of my head I don't know the conversions, but you should be able to figure it out with this information.
-
-
You don't have to do a wait. Just a fine termination for the previous point.
-
This method is way easier, and you can do it yourself:
Do yourselves a favor and create a TP program, chose an open register (in this case Register 1 was open) and put in the following code:
R[1] = $DCS_CODE
Run that line and look up the value in your Data Registers. -
Userframe, or UFrame. There's a bunch of information on this forum; it's the reference frame that all of your points are taught relative to.
Menu > setup> frames > F3[other] > user frames
-
Dropping the collision detect to 50% increases the disturbance threshold. I would monitor that look for spikes. A lot of things can cause this.....cables, motors , bad RV gear and even a servo amp. When these things suddenly start happening I look for cable damage first especially if the RCC are laying on the floor. I've found metal shavings pierced through the insulation from people stepping on cables.
Thanks. I should have mentioned, I put the collision detect back at 100% after sending it home and it's run fine since then. Will inspect the cables today if I get a chance.
-
Is it set to inverse polarity? (next > detail)
-
From the mechanical maintenance manual:
-
You should take your backup from a known position, but that doesn't have to be the mastering position. I always take mine from our home position.
-
One of my robots (R2000iA/165F RJ3iB) just started throwing collision detect alarms on two axes (2 and 3) simultaneously. Looking at the error log, it looks like axis 2 triggered twice by itself earlier this afternoon, then axis 3 alarmed twice, and since then they've been occurring together.
The operators don't know if it's been occurring in the same place or not. When I got called down to the robot I could jog it fine, but when trying to send it home (auto-homing routine) it seemed to be releasing the brakes then immediately erroring out. I dropped the collision detect sensitivity to 50%, the go-home routine worked, and it's run fine since then (all of about 10 minutes so far).
What can cause collision detects simultaneously? Like I said, I could jog it fine and I saw the tool drop when the brakes released, so I'm thinking more likely to be reducer or servo amp or something like that that the motor or brake - but I'm far from being an expert which is why I'm asking here. It's 103°F (39°C) in the plant right now so I'm also wondering if something could be overheating.
-
I don't have time for a full reply right now, but the following two threads may help you out:
1st, programmatically cutting circles - your application will be slightly different since you're moving in a different plane but this should give you ideas: Re: Problem with simple circles, is there direct input method for programming them
2nd, calling a program in a loop - again slightly different application but same concept: RE: FANUC arc mate 120. How to weld with fragments.
The other thing you'll have to do is in your programmatic arc / spray program you'll have to reverse direction every pass. You can use your loop index mod 2 *(-2) +1 to give you a register that will alternate between -1 and 1 every pass. You can multiply your offsets by this to reverse direction every pass.
Hope that makes enough sense to get you pointed in the right direction.
-
I wouldn't know about 8.10. My weld robot is Arctool 6.40. I didn't say anything about weld external output in my previous reply.
-
I'm not in front of a weld robot right now, but go to menu > i/o > weld. Look for arc detect. That's the input you're looking for.
-
To answer TitusLepic, need to post the software application and version. Posting the summary.dg file from your 'All Above' backup will answer a lot questions regarding this and setup at the robot end.
If my suspicion is correct (that RPT was the integrator), summary.dg will show HandlingTool as the software application/version but they replaced the shell so the TP will show that Routerware is the software application
-
Do you know who the original integrator for your robot was? And when you start it up, does it show that you're running routerware instead of handlingtool?
-
I've also noticed that digital inputs related to the spindle, namely two that define if the spindle is clamped or if the spindle is unclamped, do not update accordingly when it clamps or unclamps.
My guess is that this is your problem. I'm guessing (and this is just a guess) that you have a karel program running in the background that's turning off the DOs because the spindle shouldn't be running without a tool clamped.
The clamp/unclamp sensors should be a pair of prox sensors reading the back of the drawbar. Probably under a cover. Check them and see why they aren't reading.
-
Thanks! So if the robot has not moved for the time set in $SV_OFF_TIME, servo motors are shut down wherever is the robot?
Yes
-
BGlogic runs continuously in the background. No need to call it from your program. However, not all RJ3iB controllers have BGlogic as an option.
-
I am not sure how to do this. Is rack 36 specific to a certain register or set of registers?
Go to Menu > I/O > Digital
IN/OUT (F3) CONFIG (F2)
This is where you assign Racks to I/O signals. For example, in the attached screenshot I have mapped DI 17-24 to CPCs 1-8