FRI quality and Latency

Hello hsedaghian,

well, the answer for the "poor" rating is "(not real time) Ubuntu or Windows".
"However, in torque mode it sounds unstable"

This is the consequence.

Background: On the FRI Channel, the Timing is computed w.r.t of the exchanged telegrams.
If the Timing of the datastream does not keep the realtime-requirements (e.g. equidistancy), the Connection is derated.

Note: The Problem with common "all-purpose" OSes (Non realtime OS), like Windows or Linux is, that they provide tremendous bulk Transfer and dataexchange capabilities for Mainstream usage (e.g. Transfer 1Gig of Pictures in low/Zero time).
But this requirement does not care about a few milliseconds sooner or later...

Therfore: If you want to do realtime control (e.g. for torque control - faster than 5msec), you must make shure to keep the realtime condition, that means: Keep the effective answerrate below 5msec (each telegram must reach the controllerbox within this timeslot).
This will become difficult with a Standard Mainstream OS, like Windows or Ubuntu.
You might try, but the Connection will remain unstable (as already reported).
You could try to ease the pain, as you could try:

• Check the Firewall Settings,


• check the OSses Network-Configuration for the FRI-Ethernet Port (e.g. prioritize the port, if possible),


• check the network-Driver.

I personally would strongly advice: Switch to an RTOS -> e.g. if you are already using linux, you could try to use the Linux Realtime patch, AND get the FRI Application into realtime mode AND make shure, that the Linux Ethernet-device-Driver is realtime able (has no further delays) (AND btw make shure, that the PCs Hardware is realtime-able, e.g. by making shure, that no hidden BIOS events kill the realtime...).

hope that helped,
DrG

Hello hsedaghian,
"Latency"...
could you describe your Network-Topoloty in a bit more Detail..

What is the desired Timing rate (cycle time)?
Is the Ethernet Connection between the KUKA Controller box and the FRI Client PC Point to Point with a direct cable?
(Or is there some additional Network Hardware in between - like Switches?)

Is the Ethernet Connection shared with additional stuff?
You also could try to use the KONI Option of FRI (-> Refer to the Manual for Details) to reserve a dedicated direct Connection.

DrG

Hello hsedaghian,

Quote from hsadeghian

I am connecting the remote computer Lan port directly to the KONI port by cross cable...
Thus I feel that the command latency issues the whole send and receive time in between two computers.

Cool - KONI, direct Connection...
... in this case, you have to Focus on the Client side Computer and its application.

Latency: Yes, this is the roundtrip Timing
ControllerboxFRIServer -> TransmissionToClientComputer -> NetworkstackClientComputer -> FRIClientApplicationProcessTime -> NetworkStackClientcomputer -> TransmissionToControllerbox -> ControllerboxFRIServer

Quote from hsadeghian

Thus, if I am right, the delay between two computer in is only 1 ms. isn't it ?

I don't understand this number "1msec". From the FRI Hostside, the only thing one can measure is the total time, an Information was in the Loop (Time spent between send and receive).

Quote

The sampling rate set in the java program is 5 ms. when I set the sampling rate to 2 ms the latency is 5ms by the above command.

But I am not really surprised about the 5msec total latency, if you run a 2msec cycle rate.

DrG

Hello Hseadeghian,

Quote from hsadeghian

How much the latency is supposed to be if I install a real time OS on client?

You should focus on the jitter statistics, (friSession.getFRIChannelInformation().getJitter();)

since especially the jitter has a huge influence on the grading "poor" "good" "perfect" .
And especially in the jitter will be the essential difference between an RTOS and an all purpose OS.

DrG