Better still;XRC=old
MRC=really old
ERC=older than dirt
If ERC is older than dirt, what would the RX be?
Better still;XRC=old
MRC=really old
ERC=older than dirt
If ERC is older than dirt, what would the RX be?
Do you have a VR speed that is set low? What are the moments of inertia values (kg*m^2) in your Tool definition?
Ah ha! Looks like that is my solution - mapping a Flag to the UI[6] Start input and then twiddling the Flag from the BG program.
I didn't realize you could map a flag to an input. I'm sorta new to Fanuc.
Got it working how...
Thanks HawkME!
Yes, it is in Aborted mode. No foreground program is running when the background program sets $cust_start to true (on).
I am not turning on UI[18]. I shouldn't have to. When I make the UI[6] input for Start, the program starts running. It just won't do the same when I try to do it from the background program.
I am using a CR-7iA/L collaborative robot on an R-30iB Mate Plus controller.
I am trying to issue a Start from a background program. I do not have a PLC attached.
In the background program I am monitoring a push button and then setting $shell_wrk.$cust_start = ON.
But nothing happens. I have $shell_wrk.$cust_name set to "main", the program that I want to run. Main does not run.
I have UI signals enabled in System/Config. I have tried having $shell_wrk.$shell_start on as well as off - no effect.
Is there something else I have to do to enable using $shell_wrk.$cust_start? Ideas?
Has anybody used the Indexing Conveyor (606-2) option before? I've been asking ABB questions directly, but they don't seem to know much about this option in the U.S. and are unable to answers or give advise.
Instead of generating your points with an rX of -180 (or +180), it is better to make points with an rX of zero. Then set an rX of 180 in your Tool 0 definition.
What are the dimensions of tool 0? If you have rX set to 0 (zero), try setting this to 180.
You are wanting to count how many times a job runs?
Add this instruction to the bottom of the job:
INC I001
Each time the job completes, the variable I001 will be incremented. You will of course have to reset this counter at some time, most likely in the job that is doing the calling. for example:
JUMP *GO IF I001 < 1000
SET I001 0
*GO
The above will reset the I001 counter back to zero upon reaching 1000.
Without more information on exactly what you are trying to do, that is all I can offer. Hope it helps.
Hold down the AUX and AREA keys while you power on the controller. After the pendant beeps, you can release the keys. This activates the screen capture feature.
Put a USB drive in the port on the back of the pendant. When you want to make a screen capture, press the AUX and AREA keys. You will get a small confirmation message on the pendant screen. The screen image JPG is saved to the USB drive with the current time stamp as the filename.
- David
I don't have access to a DX200, but I would guess that all controllers that use the smart pendants can do screen shots.
Thanks, I would have never guess that one. Now, W=rZ, P=rY, R=rX? If so, then I wonder why they are reversed. Shouldn't they be RPW?
This may sound like a dumb question, but I've searched and can't find the answer.
What do the letters WPR stand for? XYZ is obvious, not so much with the other.
Be aware, you can SFTON P022 on ANY frame, not just tool. User, world work as well.
If I am understanding what you want...
Set your offset amount into another P-var, e.g. P022, as an XYZ-type with all elements zero, except for Z=200
Then in your job, do this:
SFTON P022
MOVL P021
SFTOFF
This will move to P021, offset by the value in P022
You could try removing the PL altogether, but that may not help.
The issue as I see it is that the controller is not able to see the next step until you've incremented the byte variable and looped back up in the job.
Because of this, the next step isn't known until the current step is completed.
You could try reformatting a larger sized CF card to 64 Meg. You will have to use a 3rd party software, since MS can't do it. This works on another brand robot that has similar limitations on memory cards.
That is a good idea. It will work if I know the frame of the XYZ-type P-var.
Thanks.
Let me clarify: I need to determine if an already existing p-var is a pulse type or an XYZ type. I don't need to grab the current location into a p-var.
I have a job that can accept a p-var index as a parameter and it will do some manipulation of the referenced p-var; but does different things depending of if it is a pulse or xyz type.
Right now, I'm passing in an extra parameter to signal whether it is a pulse or xyz, but it would be cleaner if the job could tell the difference by examining the p-var to be worked on.
Does anybody know of a way to programmatically (via INFORM) determine the type of a P-Var?
I'm using an FS100 controller and need to tell if a P-var is a pulse or XYZ type.