Posts by gpunkt

Quote from ssaul

in start instead of 91,92,93 and 94 put only 1

But that would map the signals to another place in the I/O-area specified by Rack/Slot....

Or Maybe you just menat to say that he could map DO[91-94] on one line?

DO[91-94] RACK:67 SLOT:1 START:91

In R-30iB (system software v8.xxp/yy) you're not able to use a "ceiling speed" for the DCS Cartesian Speed Check (CSC). You can set a threshold such that IF the robot moves faster, it will stop.

Basically this is a safety-reated monitoring function, that will stop the robot if the monitored speed is greater than specified.
The only way of CONTROLLING the speed safely is to use the OVERRIDE function within the CSC.

Example: You want the robot to move at maximum 250mm/s. You then have to take into account the max speed of the robot. Let's say that this robot can be programmed with motions up to 4000mm/s. To make sure that no motion is faster than 250mm/s (because then it will stop, and we don't want unnecessary stops now, do we? ) you need to set an appropriate override value in the CSC.

250/4000 = 6,25% override. So let's make it 6%.

The problem is that override affects ALL motions, regardless of motion type (J, L, C or A) and programmed speed. This means that all of you already slow motions that maybe already is programmed with speeds <250mm/s will be performed at only 6% of their programmed speed. Not very nice either.

Enter: the possibility to control speed with the CSC!
From v9.40p/36 it's possible to select a cartesian limit for the speed control, not just an override value. This will then work as an upper limit, much like the T1 mode will cap motions programmed with speed >250mm/s to 250mm/s, but motions programmed with slower speeds will run at the programmed speed.
You do need also the Constant Path option for this to work.

When in T1/T2 you're not able to perform hand guidance. In order for this to work, the controller must be in AUTO mode.

Since this is a COLLABORATIVE robot, I guess FANUC didn't bother to add the keyswitch since most customers will use it in collaborative mode and will want to use the hand guidance.

Quote from DS186

You could also ask your local FANUC sales rep. for a ROBOGUIDE V10 Trial license. I assume that these kind of problems are fixed with V10.

Bear in mind that installing V10 will void your existing licenses on your computer!

Good thing though is that V10 is backwards compatible and also offers the "RG Classic" (same as RG V9) interface along with the new GUI.

Quote from Rbz

Are those J P[x] at the end needed just to store the points, even if they are not used?

What happens if the instruction J P[1] is deleted? Is the point deleted as well?

Yes

Quote from edimmy

I'm currently trying to setup I/O on a R-30iB mini plus controller and want to clarify a few things I'm confused about. I attached what is my understanding of the setup, yellow is the pre-existing connections, blue goes to a terminal block for 0V, and red goes to a terminal block for 24V.

For CRMC24, is this correct that I should put 1-6 to an external 24V and 18-23 to an external 0V? I'm just trying to wire a button in before getting to anything more complicated.

Also, am I correct in my understanding of the configuration: range DI[101 - 108] (for DI01 - DI08), rack 48, slot 1, start 1?

Any help would be very much appreciated.

Display More

24V-2 is 24V coming from the controller itself. If you are providing external 24V, then only have 24V-EXT connected to your terminal block for 24V.

Otherwise it looks good.

DI01 corresponds to the bit at Rack 48, slot 1, start 1. In your I/O-menu, you can choose to map this (and the following digital inputs) to what ever DI[x] you whish.

Maybe not the cutest solution but you might be able to accomplish your task by doing something like this:

1. Make a single view VP which looks for the same things as the first cam view in your multi-view VP (let's call this "VP_1")

2. Go to Cam view 1 position and snap a picture and store it in image register 1

3. Run VP_1 using the recently snapped picture that's now in image register 1

4. Check PASS/FAIL on VP_1

5. If FAIL, redo step 2 through 4

6. If PASS, Run your multi-view VP with the picture in image register 1

7. Move to Cam view 2 position and run find for that cam view

8. Run Get_Offset on multi-view VP

9. If it fails, then you know that it failed at Cam view 2.

You need to use KAREL-programs for this, look in the iRVision Reference Manual (B-83914EN_09) for more info. The KAREL-programs are IRVSNAP and IRVFIND for executing the VPs and storing the pictures in img register as well as using a stored img to execute a VP.

If it's safety-related, then you should have a relay inbetween the RO[x] and the actuator, where the relay is energized by a safe output monitored by a safety controller (either the robot itself, using Safe I/O connect, or using a safety relay or safety PLC).

An unsafe way of doing it would be to make logic in Safe I/O connect where an NSI is modified according to your logic, then usie that NSI in your BG Logic. But as I said: it's an UNSAFE way of doing it. So nothing I would recommend.

I don't think Coordinated motion is correct for this application. Maybe Multi-Group Motion would be better? Then you can make programs with both motion groups included.

Quote from Sivakumar119502

CRMA16

Thank you for your invaluable support to this thread!

Not good to load sysvars.sv from another robot, especially not if it's from another model and generation.

What this program (sw_check) does, I don't know. What values are in the R-registers (and why)?

I assume that the program stops because it reaches line 18 (ABORT).

SYST-034 means that the HOLD signal that the remote control system (usually a PLC) sends to the robot was not received. Either hardware malfunction or program in the PLC.

Quote from venkata1988

Thank you for the response , i have a question i was able to use the skip command to get the pick position , of the end of arm . Using the LPOS i was able to get the pick location then i moved it to a position register PR[22].

The thickness of the material is 2mm .

Based on the above program , during the first cycle R[7[ will be moved to the PR[10,3] , is R[7] the Z position of the first pick ?

May i know what mistake i am making ?

Display More

Yes, in my example, R[7] is the Z position of the top layer, or first pick if you like. This information was given by input of operator in my example.

Your program seems to make a search using SKIP for the first pick. Then it seems like you save the result of that search/SKIP to PR[22]. My suggestion is to perform the first pick right then and there.

After each pick, you should update PR[22,3] to itself minus the 2mm thickness of each layer.
Or you keep using the SKIP motion to get the exact Z for each pick (and then update PR[22] each time).

So get rid of PR[10,3](?????) and the thing with subtracting 50mm??

To speed things up, you could do something like this:

!First cycle
F[1]=ON

LBL[1]
!Move to above stack
..
!If not first cycle, start the search from 100mm above last pick
IF F[1]=OFF THEN
	!Add 100mm to the last search result
	PR[22,3]=(PR[22,3]+100)
	L PR[22] 1000000000mm/s CNT100
ENDIF

!Perform search towards bottom of stack
L PR[4:bottom of stack] 50mm/s FINE, SKIP LBL[100]
!If successful, save current pos
PR[22]=LPOS

!Pick
..

!No more first cycle =)
F[1]=OFF

!Place
...

!Go home between cycles?
...

!Eat, sleep, repeat
IF (Continue with cycle) THEN
	JMP LBL[1]
ENDIF
END

Quote from muhammedsuhail1997

I am new to Fanuc so does that mean all the L motions (like, L P[1] 200 mm/sec FINE) would be fine but the J motions (J P[2: Home] 200 mm/sec FINE) would need to be retaught.

L- or J-motion instructions has nothing to do with how the target position is expressed (Cartesian or Joint values).

L motion instruction moves the TCP linearly towards the target position.
J-motion instruction moves the robots axes in the easiest/fastest/most comfortable way towards the target position.

Assuming you're working in a User Frame with Z+ being upwards:
You need to find the correct Z-coordinate for the top layer, and then you also need to know the height of each layer.

To find the correct Z-coordinate for the top layer, there are a few ways of doing so:
*Tell it directly to the robot (type in the value in a R-register, send it through Group signal from a PLC etc.)
*Use a distance sensor on the robot to measure it
*(if your using a vacuum gripper) use the vacuum OK-signal as a trigger (using SKIP condition) to know that you found the correct height

Either way, you will need to read out the robot TCP's Z-value at some point. It is a Register instruction with a syntax something like this: PR[i]=LPOS
What this will do is that it will read out the currently active TCP's coordinates and store them in a Position Register (PR).
The Z-value can then be read from the PR and written to an R[]-register for further arithmetics: R[5]=PR[10,3] <---- will read out the third ("3") element of Position Register 10 ("10"), which is the Z-coordinate (X = 1, Y = 2, Z = 3, W = 4, P = 5 and R = 6).

Example (you get the Z-value of the top layer by some sort of input from operator)

!First cycle
F[10:first cycle]=ON

!Main Loop
LBL[1]
!Write correct Z-value to pick position
IF F[10:first cycle] THEN
	PR[10,3:Pick pos]=R[7:Top layer Z-val]
	F[10:first cycle]=OFF
ELSE
	PR[10,3:Pick pos]=(R[42:Last pick Z]-R[79:Layer height]
ENDIF

!Move to Pick pos
L PR[10] 50mm/S FINE
!Pick
...
!Keep track of last used Z-value for picking
R[42:Last pick Z]=PR[10,3]
...
!Place
...
!More picks needed? If so, JMP to LBL[1]
IF (condition for continue picking) THEN
	JMP LBL[1]
ENDIF
END

The "MESSAGE[]"-instruction will only display the characters as text.

You're looking for something like the "Status Menu" from the Menu Utility-option.
With it, you can define your own status messages together with R[]-values and much more.

I think it's a free option. Have a look in the Handling Tool manual for more info about it.

You can access them on the CRF8-connector on the 6-axis amplifier:

No, I haven't tried it myself, but I know of others who has done it with good outcome.
In terms of communication speed, I have no info.

I would propose one of two solutions:

1. Equip the robot with Profinet, set it up as an I/O-device with the PLC as I/O-Controller.

2. Equip the robot with Ethernet IP and use Siemens' own FBs for Ethernet IP communication (they have both EIP Scanner and EIP Adapter). See https://support.industry.siemens.com/cs/document/10…?dti=0&lc=en-DK

Get in touch with your local rep and ask for the plugin developer kit.
For Tablets, iPendant Controls is not very good. Instead, you're better off with developing your HMI as a plugin.

Quote from Hubert_Bonisseur

Hello, i have the same issue with a welding cobot (CRX 10iAL). The welding cable increase the payload and i have de SYST 321 error.

It's the main issue i have with this robot.

Update the system software, it will allow for more external forces nowadays.
Also, make sure that the cables/hoses are lifted by balance blocks to minimize their impact on the robot.
Then there are payload compensation instructions you could use (see the Tablet TP manual for further reference).
And, of course, make sure that the payload setting is correct!