Welcome, Guest. Please login or register.
Did you miss your activation email?
May 24, 2012, 09:25:20 AM
Home Help Login Register
News: Any Problems or Experience with Industrial Robots ?
Register and place your Question / Answer to worldwide Robotexperts right here !

+  Robotforum | Support for Robotprogrammer and Users
|-+  Industrial Robot Help and Discussion Center
| |-+  Stäubli & Bosch Robot Forum (Moderators: Werner Hampel, Jim Tyrer, Martin H, Fabian Munoz)
| | |-+  [help]synchronous task not run in specified period in CS8C for TX60
0 Members and 1 Guest are viewing this topic. « previous next »
Pages: [1] Print
Author Topic: [help]synchronous task not run in specified period in CS8C for TX60  (Read 1248 times)
superql
Newbie
*
Offline Offline

Posts: 6


« on: November 24, 2011, 11:01:15 AM »

hi, guys:

i use val3 for programming, and the robot controller is CS8C. i set the cs8c as client, and another PC(OS/windows) in which force sensor installed acts as a server. cs8c sends request every 4ms to the PC via ethernet(TCP/ip), and PC reads from the force sensor and sends the data back to the cs8c.

in the client side:

program start():
        taskCreateSync "readForce",0.004,bOverRun,readForce(nStatus,nForce,nMonitor,bZero,bClear)

which creates a task called "readForce" running every 4ms

program readForce(nStatus,nForce,nMonitor,bZero,bClear):
   do
           send request to socket(tcp/ip)
           receive data from socket(tcp/ip)
           delay(0)
        until false

i've made sure that cs8c and PC locate in the same local LAN network with netmask 255.255.255.0.

the data transfer is ok, however when i measured the time interval of requests sent by the Cs8C in the PC side, i found

that the time interval of request is about 2 senconds further slower than the expected 4ms.

the network payload is very low, thus it seems that the task "readForce" was blocked or delayed, how could this happen??

how to solved this problems.

thx a lot!
Logged
Spielkind
Newbie
*
Offline Offline

Posts: 7


« Reply #1 on: November 24, 2011, 09:15:27 PM »

Hi superql,

which instructions are you using for sending and receive?
Did you set the timeout to 0 seconds (means 'off')?
Do you use sioGet and sioSet instructions?
Did you disable the Nagle-Algorithm?

Good luck

Spielkind
Logged
superql
Newbie
*
Offline Offline

Posts: 6


« Reply #2 on: November 25, 2011, 04:22:02 AM »

dear Spielkind:

thanks for your reply!

i used the sioGet and sioSet to receive and send the datas to Ethernet.

i used the ioCtrl to set the timeout to 0.

but i don't know how to disable the Nagle-Algorithm, it was not menthioned in the Val3 manual, have you tried that and did that take effect?? could you please tell me how to disable the Nagle Algorithm.

thx and greeting.
Logged
Spielkind
Newbie
*
Offline Offline

Posts: 7


« Reply #3 on: November 25, 2011, 06:37:39 PM »

Hi superql,

to configure the Nagle-Algorithm you need the sioCtrl() instruction. It depends on the VAL3-Version, if it is supported in the standard VAL3 or as an AddOn.
If your VAL3 manual do not describe Nagle in the sioCtrl() instruction chapter, you need an AddOn.
To get that, you need to ask your Stäubli Hotline. It is qithout any costs but you need to detail the VAL3 version you use.

Just to clarify:
Nagle is an optimization algorithm in the TCP/IP world. It collects small payload on TCP/IP and package it to bigger payload to avoid high traffic with much more Overhead than payload. It´s principle indeed causes a time delay, but I don´t think it is responsible for your 2 seconds delay.

You wrote, that you have a delay of 2 seconds, you disabled the timeout and you do Read and write sequential each after the other.
If the system doesn´t receive the data fast enough, surely it will take time until data is received ...
So first of all I would check, where you loose the time.
There are several possible changes in your application which causes less time consuming:
1. You could separate reading and writing into separate tasks - this makes your communication more reliable.
2. I´m not sure, how you use the sioGet and sioSet. You can send byte by byte but this takes a lot of time.
Another possibility is, to use a num array as Parameter in sioGet and sioSet. In that case, sioSet will send the complete contents of the array at once, sioGet will read all data which is in the incoming buffer and put it into the array until the array is full or the buffer is empty.

If my comments are not helpfull, please post your problematic code.

Spielkind
Logged
superql
Newbie
*
Offline Offline

Posts: 6


« Reply #4 on: November 26, 2011, 07:41:52 AM »

the original code is from the library atiForceSenEn downloaded from Staubli website:

-->start program:

begin
  call initialize("io:sAtiFs",l_n)
  taskCreateSync "readForce",0.004,bOverRun,readForce(nStatus,nForce,nMonitor,bZero,bClear)
  taskCreate "user",100,user()
end

-->initialize program(setting the socket):

begin
  nPort=49151
  nSioTimeOut=5
  x_nLink=getData(x_sSocket,sFs)
  if x_nLink>0
    sioCtrl(sFs,"port",nPort)
    sioCtrl(sFs,"timeout",nSioTimeOut)
  endIf
end

-->readforce program(scheduled every 4ms, sending request to the server for data sampling, and receiving response from the server via the socket):

begin
  //Header begin
  //Description of Program
  // Reads ATI Force Sensor values
  // Usually ran in a synchronous task
  //
  //Input parameters
  // none
  //
  //Output parameters
  // num    x_nStatus : Returns status of sensor
  // num    x_nForce  : Array of 6 num that returns force and moment values
  // num    x_nMonitor: Array of 2 num that sets monitor bits
  // bool   x_bZero   : Set to zero (tare) sensor, reset when request is sent
  // bool   x_bClear  ; set to clear monitor conditions, reset when reguest is sent
  //
  //Examples
  // taskCreateSync "readForce",0.004,bOverRun,readForce(nStatus,nForce,nMonitor,bZero,bClear)
  //
  //History
  // Creation: 10-Jul-2009, J Cook
  // Modification: dd-mmm-yyyy, name, description
  //  description continued
  //
  //Header end
  do
    nSend[16]=round(limit(x_nMonitor[1],0,255))
    nSend[17]=round(limit(x_nMonitor[0],0,255))
    if x_bZero==true
      nSend[19]=bOr(nSend[19],1)
    endIf
    if x_bClear==true
      nSend[19]=bOr(nSend[19],2)
    endIf
    nSent=sioSet(sFs,nSend)
    if nSent!=size(nSend)
      x_nStatus=-1
    else
      nSend[19]=0
    endIf
    nReceived=sioGet(sFs,nRec)
    if nReceived!=16
      x_nStatus=-2
    endIf
    if nRec[0]==nHeader[0] and nRec[1]==nHeader[1]
      x_nStatus=(nRec[3]+nRec[2]*256)
      for l_n=0 to 5
        x_nForce[l_n]=(nRec[(l_n*2)+5]+nRec[(l_n*2)+4]*256)
        if x_nForce[l_n]>power(2,15)
          x_nForce[l_n]=x_nForce[l_n]-power(2,16)
        endIf
        if l_n<2
          x_nForce[l_n]=x_nForce[l_n]/nForceCounts
        elseIf l_n==2
          x_nForce[l_n]=2*x_nForce[l_n]/nForceCounts
        else
          x_nForce[l_n]=x_nForce[l_n]/nTorqueCounts
        endIf
      endFor
    else
      x_nStatus=-3
    endIf
    delay(0)
  until false
end

-->user program (for displaying the state of the sensor and data from the server):

begin
  userPage()
  do
    cls()
    put("status: ")
    putln(nStatus)
    put("fX: ")
    putln(nForce[0])
    put("fY: ")
    putln(nForce[1])
    put("fZ: ")
    putln(nForce[2])
    put("mX: ")
    putln(nForce[3])
    put("mY: ")
    putln(nForce[4])
    put("mZ: ")
    putln(nForce[5])
    gotoxy(0,13)
    put("ZERO")
    l_nKey=getKey()
    switch l_nKey
      case 271
        bZero=true
      break
    endSwitch
    delay(0)
  until false
end

The codes above seem to make sense, i even have commented the receiving part in the "readforce" program for only testing the sending request.Then, in the server side, i use the TCP/IP capture tool to capture the request package, and the measured interval is 100ms still much longer than the expected 4ms.

this totally made me confused.

     
     

     
Logged
Spielkind
Newbie
*
Offline Offline

Posts: 7


« Reply #5 on: November 27, 2011, 08:36:53 PM »

According to Wikipedia (http://en.wikipedia.org/wiki/Nagle%27s_algorithm) the Nagle could cause up to 500ms delay...

Another thing I didn´t realized:
You wrote, the TCP/IP server is a Windows PC. I´m quite sure, that you can´t get 4ms response with a normal WinPC.

--> Maybe your problem is the sum of
  • Nagle between CS8C and PC,
  • Windows related non realtime
  • communication delay between WinPC and your force sensor

This all would explain, why you measured a delay of 100ms...

As already mentioned, I would investigate in, where you loose the time ...
Logged
superql
Newbie
*
Offline Offline

Posts: 6


« Reply #6 on: November 29, 2011, 09:56:32 AM »

your analysis is very helpful and clear,then how to disable the Nagle's Algorithm? could you tell how to do that as your experiences? needs more extra addons?

The VAL3 i used is 6.6.5 with some addons, i've inquiry to the Staubli hotline , but got no response yet.

regards
Logged
Jim C
Guest
« Reply #7 on: November 29, 2011, 02:26:01 PM »

With version 6.6.5 you will need the expansion add on. Use the instruction $sioCtrl

$sioCtrl(sFs, "nagle", false)



num $sioCtrl(sio siPort, string sAttribute, void attributeValue)

This instruction is replaced with instruction sioCtrl() with VAL3 s7+. sioCtrl() can be used with VAL3 s6.4+.
This instruction modifies the attributes of a sio data. Supported attributes are:

- "port" num value defining the TCP port for TCP socket servers and clients
- "endOfString" num value defining the ASCII code for end of string delimiter, for TCP socket servers and clients
- "timeout" num value defining the timeout (in seconds) for TCP socket servers and clients
- "clients" num value defining the maximum number of clients for TCP socket servers
- "target" string value in the format "www.xxx.yyy.zzz" (e.g. "10.10.90.1") defining the address of the TCP server, for TCP socket clients.
- "nagle" (s6.5.5) bool value to enable (default) or disable the nagle TCP optimization, for TCP socket servers and clients. See http://en.wikipedia.org/wiki/Nagle%27s_algorithm
- "arpTimeout" (s6.7.1) bool value to enable (default) or disable the arp table timeout for TCP socket servers and clients.

The instruction return an error code:

0 no error, attribute is modified with success
-1 unknown attribute
-2 invalid type for the attribute value
-3 invalid value for the attribute value
-4 attribute value could not be modified (not ready)
Logged
superql
Newbie
*
Offline Offline

Posts: 6


« Reply #8 on: December 06, 2011, 09:11:17 AM »

hi, Jim:

Thanks for your reply!

the VAL3 version in our controller is s6.6.5, the installed expansion addon version is s6.6.5 ( the version info is copied from the MCP of the CS8C controller).

i set the $sioCtrl(sFs,"nagle",false) in my program, however the return code is -4 meaning the modification failed. and the long transmitting delay is as before.

any suggestion??

greeting
Logged
superql
Newbie
*
Offline Offline

Posts: 6


« Reply #9 on: December 11, 2011, 07:08:20 AM »

hi,Spielkind and Jim:

thanks for your suggestions!

i think i found what the problem is. after several tests, i found that there may be the problem caused by the c++ program in the PC side though i even didn't know why,  i just changed to an universal server code from www.codeproject.com.

however, i found that if the timeout is too low, the program of val3 will not work fine, such as losing package. if the timeout>=0.002s, the program will work stable.

secondly, the synch task scheduled every 4ms seems impossible, but scheduled by every 16ms or 20ms seems ok.

finally, the sioCtrl will not changed the "nagle" option under Val3 s6.6.5 and expansion addons s6.6.5.

hopes these will help for others.
Logged
Pages: [1] Print 
« previous next »
Jump to:  


Login with username, password and session length

Powered by MySQL Powered by PHP Powered by SMF 1.1.16 | SMF © 2011, Simple Machines Valid XHTML 1.0! Valid CSS!