Pretty sure it is $SCR.$ITP_TIME.
Posts by Nation
-
-
This is probably not the case, but I was on a job where the previous integrator muted every zone the moment the robot was switched to T1 mode. Are the zones getting muted?
-
INC (incremental) motion option on a move could work as well.
-
Yeah, this is kinda nuts. I'm teaching a class, and was confident if the students had the wrong frame selected when running the program, the robot would fault. Then we did the classic move the paper they made their path on, and one student had accidently touched up everything in world, even though at the top of their program they had the UFRAME= and UTOOL= commands.
I've been able to recreate it on 2 real V9.30P robots, and one virtual V9.30P, and one virtual V8.30.
Its been eye opening what they've been able to find that I've missed over the years.
-
I'm running into an odd issue. When a point is taught in world, and you run to it in a different userframe, instead of generating a frame mismatch error, the robot just simply runs there with no errors. Active frame doesn't change.
If the point has a user frame number other than 0, and you run to it with a mismatched frame number, you get an alarm, as expected.
Is there a system variable besides FRM_CHKTYP that governs this behavior? I want the robot to fault if you run to a point taught in world, and you have the a frame that is not world active.
-
Be prepared for the cost of a new harness if you decide to go that route. Last time I did one, it was $11k.
-
-
Note that I said I've never used it.
Did you try using dosbox to run it? Was your windows 7 virtual machine set in 32 bit mode?
-
Animation commands don't show up in the TP program. Moves will, which your program doesn't have.
Also, if it is a simulation program, don't edit it on the TP. Stuff will get out of sync.
-
Here you go. Version 3.07.
Granted I have never used this. You will likely have to run this in a virtual machine, or in DOSbox to get it to run in on modern os.
-
What version of OS is your robot running? I have translators dating back to v1.5.
-
Agree with ND Auto. I've done an application like this before, although it was with a Vizumatic driver.
All you should have to do is program the point and tell the screw runner you are in position.
That arm should be more than capable for a screw driving application.
-
Depending on what is in your robot, you will/may need the following:
Hardware:
Another servo amp.
Additional Axis card.
Software:
Extended axis control.
Coordinated motion.
Unfortunately, the software side of these will require talking to Fanuc. Once they find out you are not the original owner, they will want a "software relicensing fee" before they sell you any additional options. I've heard various numbers, but the fee is at least a few thousand dollars.
-
I think the robot will fault out with a system level fault once it hits the RUN_FIND and the camera fails to take an image. I recommend testing this of course.
Depending on the PLC you are connected to, you could watch for specific faults from the robot.
As for doing it from the robot without Karel, it will be difficult. I'm thinking of a background task to watch the active error, run as a middle man to the UOPs, and then abort the main motion task and restart.
-
Okay... so what we need is a way to set a digital output if we attempt to take an image and do not get a valid response from the camera. (We force the condition by simply disconnecting the camera). Can you give me an example of how to do that with VISION RUN_FIND, or some other method?
I'm an old ABB guy, and the FANUC code is just not very intuitive for me yet.Hmm. This is a bit harder. Normally vision errors are handled by the "GET OFFSET" jump label, but if you want to handle the "RUN FIND" itself erroring out, that will be quite a bit more involved. The hardest part will be preserving the program stack. I have a feeling you will get stuck on the "RUN FIND" command indefinitely.
You might be able to fire the vision camera from Karel, then examine the status the "V_RUN_FIND" returns, and set your DO that way.
I don't believe it is possible in TP though.
-
Why doesn't the TP accept your changes? Is the program write protected? Is the password protection option present on the controller, and you are not logged in at an appropriate level? Is the TP turned on when you try to make the edits?
If you are trying to add a jump label to the end of "VISION RUN FIND", that is not possible. "GET OFFSET" causes the program to jump if there is no offset to return.
Easiest way to cause a camera failure would be to just block what is looking for. Put the lens cap on, don't fire the lights, or cover the object with a rag.
-
Try deleting the .pc and .vr file from the controller, and recompile.
-
Can you break up the program and run it in chunks?
-
Try reserializing the robot and adding in an option you won't use (enhanced mirror image comes to mind).
That might make roboguide "redo" the robot tree.
-
This is easy to do in Karel. I can't share the code, but I wrote something like this for a client to pull and delete programs from a remote FTP server.
The key is to setup a client tag under setup, connections, and then use the copy command in Karel to copy from the client tag (C1:) to the MD: device.