Well now I'm curious. What kind of application are you doing?
I'm not sure if it is possible or not.
Well now I'm curious. What kind of application are you doing?
I'm not sure if it is possible or not.
I cannot imagine why you would want to do that.
Fanuc Basic Process Axis has only speed control, no position control.
You have to use the mixed logic if statement in BG logic. That is the one with parentheses.
"IF (...)"
Sent from my SM-G930V using Tapatalk
Reapplying the hold signal alone will not resume automatically. You have to give it another start signal.
Sent from my SM-G930V using Tapatalk
1. How do you change PR outside of the program? Go to the Data screen, press type, and select Position registers. Highlight the one you want and press the 'position' soft-key (F4). Then edit the values.
2. You couldn't find the equals sign. While editing your program press the 'Inst', Registers, ...=...
3. Line 5 of your code is: 5 J P[2]100% Fine Offset, PR(1,2). This is a syntax error. you cannot use just 1 element of a position register in a motion instruction, you use the whole thing. If you only want the Y value then you have to zero out all other elements.
4. Line 6 of your code has two issues. It is also a syntax error, as mentioned above. Also, it is not an incremental move. you will literally be moving to PR[2] as if it were a regular position.
5. You say "If I continue to call out P[2] I would need to double my PR value each time", yes that is how it will work. You will change the value of your PR each time you loop through the program. Your points P stay the same and are taught at your base location. Your PR offset is the only thing that changes. You need to make a loop using either the For Loop instruction or Jump Labels, then modify your PR value each time.
Yes, UI 1,2,3 & 8 all need to be on in order to allow the robot to run when UI signals are enabled. You can read about this in the manual by searching for UOP Input Signals.
I would first determine if you really need it to be a condition handler, and not just a logical branch in your program. The condition handler can interrupt the program at any time, but do you really need that? Instead, could you have when the robot is finished with it's current job, jump back to a label at the top of the program, then check for those conditions, and if they are true call your safe position program?
A program called by a condition handler cannot have motion. Of course there is a secret workaround for this, but before we go down that rabbit hole, can you tell us what you are trying to do?
Sent from my SM-G930V using Tapatalk
In my opinion embedding the plate in concrete is way overkill for an M710, and in practice have never seen it done.
If you have good quality existing concrete and use adhesive/chemical anchors you will be fine with the plate size shown in the manual.
I would highly recommend you read the manual. I think you may not have a correct understanding of position registers. The PR stores a position that can be used by itself just like a point or be added as an offset to a point.
So say that P[1] is taught as a starting point and you want to move 100 mm in the x direction using an offset set in PR[1]. You could go to the Position register screen and directly modify PR[1] to be X=100, Y,Z,W,P,&R = 0.
Your code would then just be the 2 motions, notice you are not setting the PR value in the program:
:L P[1] 500 mm/s Fine ;
:L P[1] 500 mm/s Fine Offset, PR[1];
If you want to modify the X value of PR[1] to be 100 in the program then you would do this:
: PR[1,1]=100;
To move your robot along a row you would just need to then create a loop where the x value increments each time. You can construct the loop using a For Loop or Jump Labels.
Also keep in mind that Points and Positions registers can be in Cartesian or Joint coordinates, you must make sure it is set correctly.
There is a system variable for this. I would make sure that no program is setting this variable to a 1. You can use the search tool on the robot webpage to find out.
: $SCR_GRP[1].$HBK_ENBL=0;
Here is how I think of the part rack. Fanuc needed a way to show a list of parts that have been imported and are ready for use in RoboGuide. Instead of showing a simple list, they came up with a wacky floating rack of parts that serves no purpose.
Just turn the visibility of the part rack off and forget that it exists. Hiding it does not delete anything. After that just add the parts to each fixture that you want to see it on. You can adjust the location and orientation of the parts on each fixture to get the position you want.
If you have experience using any 3D CAD system you will find out that RoboGuide is exceedingly poor with CAD. There is no concept of constraints besides locking a part into position, and the file format is sub-par. However, RoboGuide does a great job of accurately representing the robot motion and software.
Is the Teach Pendant enabled?
I'm not sure if that actually makes a difference. I would check that there aren't any programs that are writing a position register to your UTOOL and maybe overwriting your changes.
Well if your DI's are already mapped, then all you have to do is look at the mapping for that DI and copy the same mapping to UI[5], i.e., make UI[5] the same rack/slot/start point as the DI that you want it to match.
You say the "PLC rack in the controller". That sentence doesn't make very much sense. The robot controller is not a PLC. It may or may not have a rack of I/O cards. A PLC would be a separate device unrelated to the robot, that may or may not have its own I/O cards.
So which is it? Do you have a 3rd party PLC with a rack of I/O cards or do you have Fanuc I/O cards?
You can map multiple inputs to the same rack/slot/start point. When that physical input comes on, then anything mapped to it will be on. So in your config below, you have DI's and UI's that are both controlled by the same physical input. I have personally never had a reason to do so, but it doesn't hurt anything.
You need to use Position registers for your circular movements. Calculate the 4 points of the circle using a center point and adding the radius in x+,x-,y+,y- for each of the 4 positions respectively. I would suggest putting that calculation into its own little program so that you can re-use the code with different radii and center points as parameters.
In your comment you state "all four PNS inputs are used".
PNS inputs are a binary code, so 4 inputs gives you 2^4 combinations, or 16 different programs. (In addition to that PNS can have a base number added to give you thousands of different program calls, but you shouldn't need that.)
By "simple allocation" and that fact that you mention 4 PNS inputs, I assume you are using the hardwired CRMA15 connection with Auto assignment. In reality there is a possibility of up to 8 PNS inputs, but the way you have it wired gives you default access to only 4, which is still more than you need.
If you have the cad files all together in an assembly in your cad program then they will come in correctly relative to each other. If not then you will have to drag or direct enter their location based of your physical measurements. As far as accuracy, that is what user frames are for, so the exact placement doesn't have to be perfectly accurate in the virtual world. But still I would try to get each object to the nearest inch so that you don't have a potential reach issue. If you wanted to make them perfect then you could use your User Frames to position each object by moving the robot to the origin points then moving the objects into place.
If you don't have a user frame for an object then you may choose to use the actual robot to pin-point its location.
Your question is too vague to answer. Have you tried anything? Are you having a specific issue?
Please put some thought into formulating your question.
Sent from my SM-G930V using Tapatalk