FYI, to finish up the story, RacerMike got with me and he put a backup into Robot Studio. It was causing the same issues on the virtual controller as well. When re-serializing the controller with a newer version of LRMate Handling Tool, the problems went away. So have gotten a newer HT version from Fanuc and will be updating the robot when I get back to the site.
Posts by Jaycephus
-
-
Yeah, something is wrong, but I'm not sure what. Here is the 'detailed' reply I've gotten from Fanuc so far:
Quote"The error is: ** Core crashed ** Program exception occurred at PXNN(5) on PPC Zero divide exception ** HD ** ** Register dump ** ERR:5 SUB:7 TSK:5 TIM:17-DEC-28 04:08.04 ** OEA ** Somewhere in the position register routines. There is likely something not configured correctly when they added the 7th axis..."
No other recommendation or procedure from them.
But I followed the current Fanuc documentation for v8.13P from CRC when I added the axis. However, there were discrepancies between the manual and the current version of the Ext. Axis dialog. There are several options that are not documented, so I left them at defaults.
I replied:
QuoteI can only assume it is an internal configuration issue.
As I originally outlined, it is only at the execution of that one particular line, assignment of JPOS, that it hard crashes. Assignment of LPOS also causes a fault. I do believe there is something not right about the Extended Axis, and that this is the cause. Specifically, there are times where internally, Axis 7 position is considered to be undefined, null, or zero. I'm repeating myself, but I saw this with assignment of UTool or UFrame to a PR. The 7th axis will be undefined, the whole PR is considered to be undefined at that point, and so I added a line of code, PR[i,7]=0 ; and that fixes the PR and permits the PR to be assigned to another UTool or UFrame.
Other than this 7th axis related problem, all other aspects of the Robot work, and I have a fully functional 'robot-on-rail' cell that picks and places perfectly fine with good accuracy. I just can't use assignment of JPOS and LPOS.
I need to fix this by some means, whether that is re-installation or something else.
It might be that when I got the install media for the Extended Axis, I did a full software installation, and there was something I needed to do differently there. The Software Installation Guide listed no particular prerequisites, such as clearing off software or some kind of factory reset, but that might be necessary, or a different procedure should be used when there is already v8.13/12 on the robot, and I am going to install v8.13/15. (The Guide I followed came with the v8.13/15 key I got with the Extended Axis option for this robot.)
Thanks for your help,
I'm posting this to see if it will prompt some advice from the community.
-
Could be incorrect payload and inertia settings. Or payload-creep (initial settings now wrong due to increased payload mass, or EE mass due to replacing aluminum parts with steel, added equipment, etc.) The bigger the payload (and inertia settings), the slower the robot will be commanded to go by the motion profiler, and the more tolerant it will be to the load it is carrying with respect to Collision Guard. Setting Collision Guard sensitivity down to 80 or 90 for the moves with full payload might work, too. Both of these things should definitely be checked and tried first.
-
Yes, the Single-Axis-Master page shows (2) in the ST column for all 7 axes. The zero position is at one end of the axis, with positive World-X of the robot align to the positive direction of the 7th axis (set to X).
I have a working program and the robot picks accurately. Robot's World X origin is now set to the origin of my 7th axis, 7th axis jogs with coordinated motion in Tool mode, and makes coordinated moves with the 7th axis.
I just have these faults and lock-ups if I try to use LPOS or JPOS.
-
The default (Normal speed) rate might be mentioned at the top of the BG Logic page. Not sure how that looks on a R30iA. It might be 8ms. If so, then 125 counts should, approximately, equal a second. If your timing is actually 16ms, then 63 counts would be about 1 second. Or you might be able to run in High speed mode on a given program like yours, and your timing would be 250 counts per second.
I use a line like:
IF(DI[1]),R[1:DwellTimeCnt1]=R[1:DwellTimeCnt1]+1 ; (increment R[1] while DI[1] is on)
IF (!DI[1:MonitoredInput]),R[1:DwellTimeCnt1]=0 ; (reset R[1] when DI[1] is off)Then check for dwell being done:
IF (R[1:DwellTimeCnt1]>R[2:DwellDuration]),F[1]=(ON) ; (trigger something when dwell or de-bounce is done)Then once some event happens, F[1] needs to be reset. The event could be another dwell timer acting as a conveyor-move watchdog timer, or a timer for retracting a pneumatic cylinder that doesn't have a retract sensor, etc. Or DI[1] goes low. Depends on the system.
IF (<monitored event>),F[1]=(OFF) ;
Now you can tweak R[2] value on the fly to get your de-bounce timer tweaked in.
-
For a workaround until Fanuc can help me fix the base problem, I can read from $SCR_GRP[1].$MCH_POS_X through _Z, and .$MCH_ANG to duplicate the functionality. It looks like $MCH_ANG gets updated in real time when the servo is on, and the cartesian positions get updated during a programmed move, so it would need to grab the current joint positions from $MCH_ANG, make a tiny move, and then can use the $MCH_POS cartesian position data to check my current position in my UFrame.
If there are better system vars to use, I'd be happy to know about them.
-
Robot is wall mounted, basically, mounted to the axis at 90 degrees off of vertical, so user frames are -90 degrees rotated on X axis.
It is oriented in the robot's X, and the rail's 0 is the robot's world origin in X.
Not sure what this option number is, but I can do XYXWPR+Ext1 moves and jogs, such as moving to my UFrame[1] 0,0 as long as I command my 7th axis to move within range for the robot to reach that UFrame position. Since that frame is about 500mm down the rail, I would need to move to 350 or 400mm on the 7th axis or the position will be unreachable, since I would basically be commanded the base to be in one place and the EE to reach beyond the robots physical capabilities.
-
-
Not sure what you are asking.
My program is set to group mask 1, the default. My extended axis is in group 1. All of my programmed moves work without issue, as long as the XYZWPR is within the reach of the robot for the given 7th axis position value. (i.e. going to 0,0 in a UFrame might require that the 7th axis be in the range of 250mm to 550mm.) World X origin is at the origin of the 7th axis.
-
Yes, now I am using BG Logic, but I'm getting a intp-443. The website says "There is an operator or data that cannot be used in Mixed Logic. Mixed Logic statements are those that have parentheses." The only thing I have with parentheses is F[1] = (on). Can I not use "on" ?That error, INTP-443 is referring to the fact that you don't have parenthesis in the IF statement. It is not referring to the Flags.
I believe your version (or no version so far) permits any IF statement that is not "Mixed Logic" meaning you HAVE to use the parentheses with the IF statement, like:
IF (DI[17]), F[1]=(ON)
or something more complex like
IF (!(DI[17] AND DI[18]) OR (DI[19] AND !DI[20])),JMP LBL[10]
or
IF (GI[1]>0 AND !(DI[1] OR DI[2])), DO[1]=ON ;So, HawkME's code is the only IF statement syntax that is permissible in a Background Logic program. (Even though regular TP will use either Mixed Logic, or the plain IF DI[17]=ON,JMP LBL[1] )
Well, the newest systems permit the new IF () THEN ; ELSE ; ENDIF ;, but R30iA wouldn't have that.
Like HawkME said, Background Logic automatically loops, so you treat it like writing ladder or structured text programs in a PLC. You can have a single IF (logic) statement, and that's all. It will loop as fast as it can, which is 4ms at best, or 8ms by default, I think on newish robots. Not sure if R30iA is that fast, or double those timings. If you have too much code in a program, or maybe certain instructions as well, you will not be able to go to the higher rate.
The rate matters if you are doing anything complex because the only way to do timing for on-delay or similar is to have a Register act as a counter with a line that increments it every pass through the code. If you know that 250 counts is 1 second, then you can check if the register exceeds your desired timing value. But if the Background Logic rate changes from 4ms to 8ms due to adding code or someone setting the rate to Normal, then your timings will suddenly be twice as long.
Anyway, there are some gotchas for BG Logic, like non-Mixed Logic IF statements, TIMER, and JMP up, etc.
-
The line
PR[1]=LPOS ;
gives me an INTP-311 "Uninitialized data is used" fault.
(PR[1] is initialized, and it wouldn't be the source of the error in this case, anyway.)I believe LPOS is considered "uninitialized" in this case due to this robot having an extended axis added as an integrated (rail) 7th axis in Group 1.
Internally, I think the 7th axis is sometimes seen as empty data, and results in an issue like this. Prior to adding the 7th axis, this was not a problem on this robot.I also had the same problem when running:
PR[1]=UFRAME[1]PR[1] would start initialized, and then become uninitialized after running this code, because while XYZWPR all had the correct data in them, the 7th axis went undefined (***) AFTER running the above line of code.
A subsequent UFRAME[2]=PR[1] ; would fail due to PR[1] being considered to be uninitialized immediately after running PR[1]=UFRAME[1].
Stabbing '0' into the 7th axis of PR[1] would fix it, and then I could use it to copy UF[1] data to UF[2], for example with "UFRAME[2]=PR[1] ;"Anyone know if there is something to tweak to get LPOS to work in this situation?
Thanks,
-
Hello,I have a LRMate 200iD with a R30iB controller, that has the collision guard pack installed. My boss wants to know the specifications of the collision guard pack (i.e. at what torque sets it of) i have looked in the documentation from Fanuc but i am not able to find anything relevant.
Can anybody provide me with something (documentation, specs sheet, etc) that i can show my boss?
There's not a 'spec sheet' like your boss is probably wanting. Torque at the motors, or force at some point of the EE are all robot and system-dependent. Your robot likely has only a 7Kg payload max capability, depending on options (could be down at 5Kg), but may only be carrying 1Kg or less in your actual application. At 7Kg payload, (and whatever inertia parameters your EE has), which you should be setting for this robot at that mass, your robot will move considerably slower than it would at minimal payload.
I'm pretty sure that Fanuc changes the servo tuning based on your payload and inertia settings, and the motion processor uses significantly different accelerations and top speeds as the payload and moment-arms increase. So, I would expect that Collision Guard base-'sensitivity' changes as well between a light load and a heavy payload. The manual DOES say that sensitivity is automatically altered internally when jogging to be more sensitive during jogging. They provide a way to link the collision guard sensitivity to a register so that your program can adjust it on the fly with a special TP command when running in auto. Be aware that when running the program in manual, the jog-mode higher sensitivity may be overriding your programmed settings.
Also, there is no one 'torque limit,' either. You're dealing with a six axis robot that may be wall or overhead-mounted. One or more axes may be compensating for gravity to keep the payload in position, and a given collision isn't just a matter of exceeding a torque limit. FYI, The manual does say that at the moment of collision, the robot is permitted to rebound or 'relax' away from the collision, and warns that this necessarily also includes a motion relative to gravity, too (falling), for 200 milliseconds.
So, I assume it works off joint position error? Maybe something more sophisticated, but definitely not a simplistic joint-torque limit.
AFAIK, if you need to know precisely what force is involved at a certain point on your EE at a likely collision point, you would have to determine this experimentally once you have your EE mounted with the payload present, and the payload/inertia settings adjusted to match, and a Collision Guard Sensitivity that is not set too-high to self-trigger (default is usually fine for basic use).
Because of the dependency on the application specifics, which can change drastically between when your EE is empty and when it is full, they provide the sensitivity setting you can change in the program to get maximum responsiveness between having an empty end-effector and a full one. I was using CG with a heavy end-effector and a ~300lb load.
-
According to secret documentation to which only a select few have access (the manuals), R30iA has a JRL6 main-board connector, or a controller 'may' have the optional multiplexer board that splits JRL6 out to JRL6A, -B, -C, and -D.
The documented pinout is similar, with possibly nomenclature-only changes OR at least the difference being for the use as a camera-to-multiplexer board cable. Directly connected to JRL7 on a newer system will probably work. My JRL6 cable does, directly connected. Not using the multiplexer board (though I do have one for sale).
Small screen-grab included, showing JRL6 R30iA pinout.
-
Yeah, that's on the table if I don't have a mapping method.
Thanks -
Is it possible to map GO to DO, directly?
My electrical guy didn't arrange my LRMate Outputs in a contiguous group.I mapped them to DO in a contiguous manner, but I'd like to turn them on based on value in a GI or GO. If the outputs had been contiguous, I could directly map the GO to the IO themselves, but that isn't currently an option.
So I have DO mapped to rack 38 (LRMate IO).
DO[21-26] Rack 48, Slot 1, Start 1 (six points)
DO[27-42] Rack 48, Slot 1, Start 9 (skip two, map next 16 points)I am only using the first 13 points, so I would take an incoming value on a GI and apply that to a GO mapped to this range of DO (21-33).
The value in the GO would operate the DO based on the bit value. Right now, the only way I know how to do this for sure is Map Flags to a GO using Rack 34, and then copy the Flag state to the DO in a Background Logic program.
I was wondering if there was a direct way to do it.
Thanks,
-
Another thing to look for is having an app treat your collection of files as a project or treat a folder as a project, etc, so that everything can be opened at once. Then, either as a project-wide feature, or as a search-all-open-files feature, be able to search for a given item across your whole project. Critical for learning someone-else's code, or just figuring out if a Register was already used somewhere, or a named Register is no longer being used anywhere.
UltraEdit does this. Not sure if Notepad++ does this, but otherwise, it is a nice editor.
-
Thanks, yes App Frame should normally be set to zero.
The major thing I forgot to do was the auto-generation for the Vision frame. I did a auto-generated Camera tool (robot mounted camera) only. -
I've done this before, but I must have held my mouth just right when I did it. Or the fact that this HT and Vision version is a little older is messing with me.
I have a pick UFrame and am finding an object in a robot-mounted camera. I calibrated the camera and chose my Pick UFrame as the Application UFrame. I've set it to return results as "Found Position." But when it returns results, the Found Position contains coordinates relative to what appears to be the camera calibration frame, i.e. millimeters from the center of the camera, rather than the coordinate within the Pick UFrame.
Any hints on what I'm doing wrong here?
-
FANUC Robot controllers have a very large list of system variables, many of which are dangerous to change, and may not be documented. Many are for internal use and are read only, but some dramatically affect performance and are writable, at the least during a Controlled Start, if not normal Start. Some may require a Cold Start to take affect.
System Variables that affect performance:
- $Group[1].$USEMAXACCEL - enables 'fast acceleration' feature
- $Group[1].$MAX_SPEED - Not described in manual.
- $Group[1].$CNT_SPEEDUP - Also enables maxaccel? Not clear from manual. Enabled in Alere robots.
- $Group[1].$CNSTNT_PATH - The robot will take the same path for cartesian moves regardless of speed, limits speed override to 5% as the minimum. (COLD start required for changes to take affect.)
- $PARAM_GROUP[1].$CP_CUTOFFOV=5 (default), sets min override speed, only active when $Group[1].$CNSTNT_PATH = TRUE, 5% is the minimum allowed.
- $Group[1].$CNSTNTPTHJT - The robot will take the same path for joint moves regardless of speed
- $MCR_GRP[1].$fjog_enb - Fast Jogging Mode Enable
System Variables for Status
- $MCR.$GENOVERRIDE: This is the system variable that changes when you hit the +% and -% buttons.
- $MOR.$safety_stat
The value must be decoded, according to the software reference manual, it is bit coded as follows:
1 MFS_EMGOP
2 MFS_EMGTP
4 MFS_DEADMAN
8 MFS_FENCE
16 MFS_ROT
32 MFS_HBK
64 MFS_EMGEX
128 MFS_PPABN
256 MFS_BELTBREAK
512 MFS_ENABLE
1024 MFS_FALM
System Variables for Speed Override (+/- keys, used with and without shifting)
Be aware that if $Group[1].$CNSTNT_PATH=TRUE, then $PARAM_GROUP[1].$CP_CUTOFFOV (default is 5) becomes active and limits speed override to a minimum of 5%.
$OVRD_RATE=5 (default). Set to higher number to increase the change in value in when pressing the un-shifted +/- override keys. (10 is probably more friendly for most cases.)
$SHFTOV_ENB=1 (default). Set to 0 to make shifted +/- override keys work the same as un-shifted.
Or customize the shifted +/- override keys:
$OVRD_SETUP.$OVRD_NUM_S: Set to number of shifted jumps desired, such as 6 or 7.
$OVRD_SETUP.$OVRD_NUM: Set to number of un-shifted jumps desired, or leave as is for default un-shifted behavior.
(When $OVRD_NUM is set to non-zero, $OVRD_RATE will have no effect.)
Example:
$OVRD_SETUP.$OVRD_NUM_S = 7
- Under the details of $OVERRIDE_S, set the values from [1] to [10] to the following: -1, 0, 5, 25, 50, 75, 100, -2, -2, -2
- This will give you the shifted increments of VFINE, FINE, 5%, 25%, 50%, 75%, 100%. Un-shifted will remain unchanged if $OVRD_SETUP.$OVRD_NUM=0.
Other System Variables (some of these can be set from System:Config, or other places in the interface.)
$ALM_IF.ENABLE = TRUE ($ALM_IF.LAST_ALM and $ALM_IF.LAST_UALM)
$CR_AUTO_DO - set for DO to indicate robot is in Auto, integer in the range of configured DO
$CR_T1_DO - set for DO to indicate robot is in Teach mode, integer in the range of configured DO
$DMAURST = TRUE - Auto Deadman reset. Teach pendant resets robot faults, enables servos as soon as deadman switch pressed when in Teach mode (T1).
$GENOV_ENB = TRUE - Speed override enabled.
$SCR.$RUNOVLIM: will control the speed globally in any program during T1 non-step mode and i believe fully automatic. So even if you set an override in a TP program higher than this system variable, the system variable will override it.
$SCR.$JOGLIM: The percentage of system maximum speed you can jog the robot. maximum of 250mm/sec. (applies for T1 non-step and step)
$SCR.$JOGOVLIM: The global override for non-step mode T1 speed. Careful with this one as if you turn it to 100 you may see a fault occasionally because it reaches over 250mm/sec.
$SCR.$COLDOVRD: Default speed set when you reboot the robot.
$MCR_GRP[1].$PRGOVERRIDE: - this is a programmable/secret scaling factor for override, affects programs to make them run slower even though the General Override is set to 100%. (default=100=100%, full speed)
$PARAM_GROUP[1].$SV_OFF_TIME - allow setting timeout for brake activation, per axis, as in after jogging and holding deadman. By default, brakes activate after 20 seconds.These are only writeable when the SFSPD signal is OFF. (Either change in Control Start mode, or set SFSPD off.)
$SCR.$SFJOGOVLIM: SAFETY JOG SPEED LIMIT
$SCR.$SFRUNOVLIM: PROGRAM RUN OVERRIDE LIMIT (in T1 mode, use to allow 100% manual Run mode)*Though these manual-mode jog and run speed changes can greatly speed up your development time, I recommend setting them back to original settings when putting the robot into service. Inexperienced or average users could crash the robot much more easily.
DCS:
- $DCS_CFG.$SYS_PARAM: If you set this to 1, it will disable almost all of DCS. If you go to the DCS menu, it will only show your SAFE I/O connect and device, the code number setup, and the signature. Every other option will be gone. Also you will have to reapply the DCS for it to take.
-
Of course, swapping the link the other way is no different than setting the Negative flag in properties, so that didn't work. Still wondering if there is a way to swap my Joint 7 polarity in the sim. I
But I'm just going to swap my real-world plans around to match what the sim is giving me.