Force control?

[yzhao334]

Question here: any possibility to use DPM for force control? Will the communication frequency and delay suitable to run an impedance or admittance controller?

[gavanderhoorn]

I believe that's actually one of the use-cases of DPM -- although Fanuc won't call it "force control" or even "admittance control", as they have other products for that.

Net performance will probably be mostly limited by two things (ignoring anything in the controller and DPM itself, as we can't change that):

1. latency
2. jitter

Using Karel and TCP/IP is not going to help either of these. The Karel VM runs at ITP period, which on recent controllers is 125 Hz (or 250 Hz with a special option). This limits how low you can get the latency. Using UDP probably helps, but is only supported on newer controllers / system software versions.

Another contributing factor to jitter would be the fact there is no real way to be notified when new offsets have been read from the system variables by the motion controller process. The (primitive) demo in this repository does it by looking at:

fanuc_dpm_mouse_demo/fdpm_mdemo.kl

Lines 325 to 341 in e3dc606

	ROUTINE is_dpm_mpty_
	VAR
	stat__ : INTEGER
	temp0__ : REAL
	temp1__ : REAL
	temp2__ : REAL
	BEGIN
	stat__ = 0
	GET_VAR(0, '*SYSTEM*', '$DPM_SCH[1].$GRP[1].$OFS[1].$INI_OFS', temp0__, stat__)
	IF (stat__ <> 0) THEN POST_ERR(stat__, '', 0, SEV_ABORT); ENDIF
	GET_VAR(0, '*SYSTEM*', '$DPM_SCH[1].$GRP[1].$OFS[2].$INI_OFS', temp1__, stat__)
	IF (stat__ <> 0) THEN POST_ERR(stat__, '', 0, SEV_ABORT); ENDIF
	GET_VAR(0, '*SYSTEM*', '$DPM_SCH[1].$GRP[1].$OFS[3].$INI_OFS', temp2__, stat__)
	IF (stat__ <> 0) THEN POST_ERR(stat__, '', 0, SEV_ABORT); ENDIF
	RETURN ((temp0__ = 0.0) AND (temp1__ = 0.0) AND (temp2__ = 0.0))
	END is_dpm_mpty_

which is basically polling, which is not the most efficient + is sensitive to scheduling of the task.

I could go on, but to summarise: if I were going to do this, I'd probably use either a fieldbus (using group io) or direct analog connections (as in: physical ones), then configure DPM to get its input from either of these. The external device would then update registers (through the fieldbus) or supply voltages which would correspond to the desired offsets.

While it won't make the controller magically run at a higher control frequency, it will most likely lead to lower jitter and more predicable performance.

Whether 125 Hz is going to be sufficient in terms of bandwidth I can't say, as it would also depend on your application.

Fanuc will most likely suggest to 'simply' use their F/T control options, but from your question I get the impression you're looking to do something other than simple force-controlled contouring (or deburring, or ..). Afaik there's no way to influence force control schedules in an on-line/real-time way, so I don't believe using the OEM provided options would work.

But again: this depends on your application.

[gavanderhoorn]

Oh and I haven't performed any benchmarks wrt latency or jitter, comparing the various supported forms of input to DPM.

My response was based on my experience with the various interfaces into the controller I'm aware of.

It could be effective performance is bottlenecked somewhere else in DPM or the controller itself, which could make latency and jitter incurred by the use of TCP or UDP sockets, fieldbus or direct physical connections to not matter at all.

[gavanderhoorn]

I actually tried to use UDP (the stream motion)

I didn't mean J519, I meant using UDP sockets with Karel to receive DPM offsets over a socket.

experienced latency issue [..]

Latency is always an issue when controlling a robot externally. All large OEMs have this issue, some less than others.

and high requirement of 'real time' processing requirement.

If you're going to control industrial robots with a real-time external interface, you indeed need to do that using a real-time capable system yourself.

There are ways around this, but they typically introduce time delay or deviation from the trajectory.

If you want low delay and jitter, you're going to have to provide setpoints on time, and real-time systems are just about the only way to do that.

It seems DPM could have similar issue but less requirement about communication, however may cause jitter issue.

Yes, so as I wrote above: either you provide setpoints in a timely fashion, or you are too late and then your control will suffer.

Probably Fanuc has not got good external motion interfaces for now.

They have a few, but they may not be on-par with offerings from KUKA, ABB or Yaskawa.

[gavanderhoorn]

I've selected my own answer as the answer to close the discussion.

Feel free to keep commenting of course.

[gavanderhoorn]

Oh and you probably already have a Fanuc, and that's why you're asking this, but if you have the option to use a different brand, you may want to look at either KUKA or ABB. They both have low-latency, real-time, high bandwidth external motion interfaces which may be easier to use.

[gavanderhoorn]

Just an FYI for future readers: the OP has deleted all his comments except the first one.

This is why it looks like I'm only replying / talking to myself in this thread.