Activation of weld guns from MotoROS

[Noraboke]

Hi,
We have been using MotoROS with our GP25-12 successfully for general movement control, but would also like to move on to welding. Is there any proper way to achieve this through MotoROS?

So far, we have been looking into writing various user output groups on/off, however, it seems like the only relevant addresses signalize that we are ready for the welding and not actual activation of the ARCON function.

Controller: YRC1000
Robot: GP25-12
Welding equipment: Fronius

[gavanderhoorn]

Could you clarify whether you're also using motoman_driver?

From the way you phrase your question I have the feeling you're not.

[Noraboke]

My bad. Yes, we are also using the motoman_driver.

[ted-miller]

Hi Noraboke.
Unfortunately, the ROS interface does not have any direct connection to the robot's standard "process" controls (welding, painting, cutting, etc). So, there is no way to directly call a normal ARCON/ARCOF command. But there are a couple work arounds.
(FWIW, this is on the development planning roadmap for sometime in the future. But, there's no schedule for it yet.)

Options:

1. The best option is to directly control the welder from your application on the PC. I'm not particularly familiar with the Fronius communication protocol, but I know that the Yaskawa interface is based on Modbus TCP. I'm fairly sure that Fronius supports other communication options as well, depending on which features you need from the welder. For instance, if you're doing a basic job-mode routine where the weld settings are pre-programmed on the power source, I think there's a simple I/O interface for basic on/off and job selection.

I know there are users who have had success controlling welders directly from their ROS application. Though, there applications are proprietary and closed-source.

If your choice of power source is flexible, I know for certain that Miller, SKS, and OTC have basic I/O interfaces using Ethernet/IP. There are open source implementations of E/IP available.

2. I've never actually attempted this... but I think you could play some games with the INIT_ROS job and control the execution flow with I/O signals (which are supported in motoman_driver). (I've been curious to see someone try this.)

Example modified INIT_ROS job:

NOP
'INIT SIGNALS
'INTERNAL MOTION SIGNALS
DOUT OT#(890) OFF
DOUT OT#(889) OFF
' 
*LOOP
TIMER T=0.05
' 
JUMP *STARTARC IF IN#(1)=ON
JUMP *ENDARC IF IN#(2)=ON
JUMP *MOTION IF IN#(3)=ON
JUMP *LOOP
' 
*STARTARC
ARCON
WAIT IN#(1)=OFF
JUMP *LOOP
' 
*ENDARC
ARCOF
WAIT IN#(2)=OFF
JUMP *LOOP
' 
*MOTION
'READY FOR MOTION
DOUT OT#(889) ON
'MOV UNTIL 890=ON
WAIT OT#(890)=ON
DOUT OT#(890) OFF
WAIT IN#(3)=OFF
JUMP *LOOP
END

In this example, you use OT 1-3 to determine which 'action' the robot should perform.

• Turn on OT#3 to enable robot motion.
• Send a trajectory to move the robot to the start of the weld seam.
• Turn off OT 890 and OT 3 to disable motion-mode.
• Turn on OT 1 to invoke the ARCON command.
• Turn off OT 1, turn on OT 3 to enable motion again.
• Send a trajectory for motion while the welder is on.

3. Lastly, you could develop an interface to generate INFORM jobs instead of using motoman_driver. After you generate a trajectory and build an INFORM job, you can send the job to the robot using Yaskawa's High Speed Ethernet Server protocol.
   I imagine this would be a lot of work.

[gavanderhoorn]

Seeing as you're not using the standard motoman_driver nodes to interface with MotoROS, I'd recommend making your scripts available.

Right now we can only guess what you're doing by looking at the wireshark traces and from your descriptions.

[gavanderhoorn]

And how are you "turn[ing] on" and "turn[ing] off" those IOs?

I see some reads and writes, but the writes go to addresses 15080, 15081 and 15082. And as @ted-miller wrote:

And I don't see any links in the CIO between the profinet board and #15080-15082.

[gavanderhoorn]

Do you do that for a specific reason? motoman_driver doesn't do this. I'm curious why you decided to implement that in ra-mtp-ntnu/moto.

I think my intention was to disconnect from everything before starting a new case, so the connection events would be registered (from scratch) and same for all of them (Wireshark logs). It was an implementation in my own code. Although, probably not good or necessary.

As you can see here:

motoman/motoman_driver/MotoPlus/MotionServer.c

Lines 703 to 716 in bd4bdbd

	case ROS_CMD_STOP_TRAJ_MODE:
	case ROS_CMD_DISCONNECT:
	{
	BOOL bRet = Ros_MotionServer_StopTrajMode(controller);
	if(bRet)
	{
	Ros_SimpleMsg_MotionReply(receiveMsg, ROS_RESULT_SUCCESS, 0, replyMsg, receiveMsg->body.motionCtrl.groupNo);
	if(motionCtrl->command == ROS_CMD_DISCONNECT)
	return 1;
	}
	else
	Ros_SimpleMsg_MotionReply(receiveMsg, ROS_RESULT_FAILURE, 0, replyMsg, receiveMsg->body.motionCtrl.groupNo);
	break;
	}

stopping trajectory mode and 'disconnect' do the same thing.

Shutting down the servos separately is probably also not necessary.

[Noraboke]

Seeing as you're not using the standard motoman_driver nodes to interface with MotoROS, I'd recommend making your scripts available.

True! I have made my experimentation code available here now.

And how are you "turn[ing] on" and "turn[ing] off" those IOs?

For us, #15080-15082 corresponds with OT#4057-4059 on the controller (I think). At least it seems to work when these are activated. I just selected some arbitrary addresses that didn't seem occupied by any other service.

[Noraboke]

As you can see here:

Ahh, I see! Thank you.

[ted-miller]

@Noraboke
I just concluded a test and was able to invoke motion after an ARCON command. However, to fully automate this, it will require additional changes to the robot job and CIO.

Additionally, as I think about this more, I have some safety concerns about potentially leaving the welder energized when it shouldn't be. I need to discuss with a colleague to ensure that we can make the proper CIO modifications to disable the welder when in an error state.

[Noraboke]

That is wonderful news! To know that it is possible.

Additionally, as I think about this more, I have some safety concerns about potentially leaving the welder energized when it shouldn't be. I need to discuss with a colleague to ensure that we can make the proper CIO modifications to disable the welder when in an error state.

Understandably.

I would love for you to share more about how to achieve this after the discussions/implementations.

[ted-miller]

Turns out that I was wrong about the job needing changes. The process is just clunky, given all the WAIT commands in the job.

Your sequence above looks ok; this should work. Please double check that you are using the R1+S1 job. You can check this at the top of the job:

(This example is R1+R2.)

---

But having just said that... I think we're going about this wrong. My original assumption was that your robot would be communicating using the WeldCom (modbus-based) protocol. This is what is used in the Americas and Asia. But, I vaguely recall hearing that the EU likes to use a simpler I/O based communication method with Fronius. And as I look at your python and CIO some more, I'm pretty certain that this is how your welder is being controlled via the Profinet interface.

So, you can control the welder directly without using the INFORM arc commands. Your py script already has addresses for stuff like purging gas and inching wire. I'll cc you on a message to a colleague at Yaskawa Europe to get the I/O mapping. (I'm speculating that #10063 is used to start the weld.)

In that case, you would use the standard R1+S1 INIT_ROS job. You don't need any of the jumping that is in the job above.

There are still safety concerns with this approach. If communication between your PC and the robot is lost while the arc is active, then there will be nothing to turn the welder off. For this, I highly recommend implementing a heartbeat signal from the PC to the robot. You should modify the CIO to disable the welder if the heartbeat signal is not does not change state within some timeout.

Additionally, you should ensure that all external safety interlocks (light curtains, gate latches, etc) are either hard wired to the welder or connected to the CIO control bits.

[Noraboke]

Your sequence above looks ok; this should work. Please double check that you are using the R1+S1 job. You can check this at the top of the job:

Hmm.. We seem to be using the R1+S1 job, but somehow the robot still won't move during ARCON. But then again, I am only giving it around 1-2 seconds tops (of ARCON in the same position) before pushing the stop button. The OT#(4057) signal is also kept on during MOTION "mode" in my implementation and not turned off until switches to other modes are made. Or should it be switched off?

Regarding the I/O approach, this is something we have attempted before. However, I was not able to find the correct address or write to them back then. I did get in touch with Fronius, which suggested 87090 or 70143 based on their documentation. It does not seem to be 87090, which can be accessed from the pendant. I don't know how to test 70143, as it does not seem to be listed in our pendant or writable from our computer.

Do you know of any way to activate #70143?

(Side note information for anyone else who might be looking)
In our pendant, "Welding start" seems to be assigned to 10050, but this does not seem to lead anywhere as far as I know. In fact all the addresses mapped here ("Welding start", "Robot ready", and "WorkingMode0-4") does not seem to correspond with the Fronius I/O interface. The figure below just shows signal values not turning on/off when activated through the pendant. The other addresses such as "Gas on" etc. seem to be mapped according to their naming however. Oddly enough, 10051 "Robot ready" does not seem to correspond either, despite being mapped to #10051 in the documentation.

[Noraboke]

The I/O signal method seems to work!

We use the 70143 signal to activate the welding for our setup, which seems to work fine with motion. To make this address writable, a modified CIOPRG.LST had to be used linking 70143 to a writable one.

There are as Ted mentioned safety concerns with this approach.