The function RunInstruction (or RunCodeCustom which is the old naming) allows you to generate a program call at a given point in your program.
This will provoke a new line in your generated code.
You should make sure that the name of your program matches the specific function that drives your gripper. For example, if you use the Universal_Robots_RobotiQ post processor, it includes the functions to drive a 2 finger gripper. In that case, you need to call RQ_2FG_Close and RQ_2FG_Open. Example:
10-24-2018, 01:56 AM (This post was last modified: 10-24-2018, 02:46 AM by mattmct.)
I'm using the 2F 140 gripper on a UR5e series arm.
I'm not too sure I understand what you're explaining. Sorry, my understanding is quite new when it comes to comms between RoboDK and the UR controller.
I played around with that you described but couldn't get any response from the program. However, I did try creating a program which executes a Program Call Instruction named RQ_2FG_Close. When right-clicking and attempting to run on the robot, a pop-up message appears on the UR teach pendant saying MODBUS Signal Gripper_Status1 has been deleted. So I guess I'm on the right track.
However when loading the .installation file suggested here, I get a checksum error. These files are 5 years old now so I guess these are no longer appropriate for the UR5e series.
How would you suggest to proceed?
Just an update:
I've created 2 separate scripts using the UR teach pendant both opening and closing the gripper. I've exported this to my PC and I can send the raw script file via sockets and port 30002 using a seperate python script and this works. However, every time I run this, it disconnects RoboDK from the robot. Is there a way I can just incorperate this script in RoboDK with my existing project?
I slowly learned that robot.RunInstruction('FunctionName', INSTRUCTION_CALL_PROGRAM), actually loads a program on the UR and executes. What I found however that this doesn't always work for some strange reason. The program loads, but nothing happens. Not only this, there was about a 5-second delay between the command being sent and then actually being executed.
I ended up disconnecting the RQ-2F from the UR controller and I'm now controlling it from the PC and execution is great, no delays at all. As I couldn't really find anything existing I created my own class using the pymodbus library. On top of that, I've also created a socket server that you can connect to via TCP so I now have two methods for controlling the gripper.
This has allowed me to control the gripper through my custom GUI as well as through RoboDK.
After a few requests privately, I thought I'd share the latest:
Since posting this, I've found Robotiq actually has a GitHub repository for exactly this only that it's geared towards ROS. Nonetheless, the gripper still communicates via Modbus serial so, it will work on any application as long as you can run python.
Do note on line 86 they mention a TODO to add a Try/Except block around line 88. I've found on occasion line 88 response can be None so you need to test for it's type before proceeding and parsing data from it.
rr = self.client.read_holding_registers(INPUT_REG, 3, unit=self.id,timeout=2)
retries = 50
# To get around spuratic - object has no attribute 'registers'
while not isinstance(rr, ReadHoldingRegistersResponse):
rr = self.client.read_holding_registers(INPUT_REG, 3, unit=self.id)
retries -= 1
if retries <= 0: raise TypeError("Failed to get status after 50 tries")
except TypeError as e:
We are currently testing out a new method and if approved we will have a section in the documentation in the very near futur.
Here's the procedure:
Run on robot option (using the driver): On the other hand, the driver allows you to run programs step by step from RoboDK and see the pointer being run anytime from RoboDK. It is important to first be able to connect to the robot to use this feature. Otherwise, the option Send program to Robot should still work with less headaches (Windows Firewall, antivirus, etc).
To properly run custom programs using the driver (for example, opening/closing the gripper), you should use program calls instead of "Insert Code" . This should have no impact when you generate programs or send them to the robot in one shot, but it is important to have an effect with the driver. See attached image and RDK file.
Furthermore, I would like to add the following correction from what I said in previous emails: You should make sure the number 255 or 0 is separated by a space before and after the brackets. Example: rq_move_and_wait( 0 ) // instead of rq_move_and_wait(0) This is required so the driver received the correct ID. We'll remove this requirement in future versions of RoboDK.
Important: For the RobotiQ gripper to work using the driver as described in this email, make sure to use the same file I sent on May 25th: