Stats

  • Locked Locked
  • Replies 7
  • Subscribers 143
  • Views 18736
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

load a skill into the terminal

Titi

Hello, i try to load a skill (toto.il) into the terminal wish has launched my icfb.

I try it with an Opusserver but i can't load toto.il directly, i try to load it by using a variable "command" , when i set manualy (into icfb) command to "toto.il", all is ok, the script is launched. But i can'tset the variable command to "toto.il" into the terminal, i think the probleme is due to the string, the return is always "" or nil.

This is my syntax : 

echo "command = "toto.il" " | opusClient (This command always return nil)
echo "(load command)" | opusClient

 Have you a solution instead of my solution with opusServer ??

 Thanks.

Parents

  •  Hi Remi,

    Andrew's suggestion is a good one that I have had success with in the past.  The DFII session is the 'master' which starts the external tcl/wish process using ipcBeginProcess() . At this point you can choose either synchronous or asynchronous communication depending on your needs.

    For example, with synchronous communication, you start the external script, wait for it to complete (effectively blocking the DFII session) and then the user can continue working after the external script is done.

    With asynchronous communication you run the external script and effectively the communications occur in the background. This might be a little more complex but it gives greater flexibility. You define a data handler and an error handler, for example, to handle messages coming from the external process on stdout and stderr respectively. This also means that the DFII session will not be blocked, it can be used for other things while the 'slave' script is processing.

    This method will allow you flexibility to automate things on the DFII side also, for example, when something arrives from the script on the data handler, it can process the data according to what you want to do.  For example, you might have:

     msg: "Missing data, try again"

    cmd: load("toto.il")

    So depending on the first item, the action might be to print a message, or to execute an action. You have control over the format and the communication "protocol" so make it fit your needs, the above is just a suggestion.

     Hope this helps!

    Regards,

    Lawrence.

Reply

  •  Hi Remi,

    Andrew's suggestion is a good one that I have had success with in the past.  The DFII session is the 'master' which starts the external tcl/wish process using ipcBeginProcess() . At this point you can choose either synchronous or asynchronous communication depending on your needs.

    For example, with synchronous communication, you start the external script, wait for it to complete (effectively blocking the DFII session) and then the user can continue working after the external script is done.

    With asynchronous communication you run the external script and effectively the communications occur in the background. This might be a little more complex but it gives greater flexibility. You define a data handler and an error handler, for example, to handle messages coming from the external process on stdout and stderr respectively. This also means that the DFII session will not be blocked, it can be used for other things while the 'slave' script is processing.

    This method will allow you flexibility to automate things on the DFII side also, for example, when something arrives from the script on the data handler, it can process the data according to what you want to do.  For example, you might have:

     msg: "Missing data, try again"

    cmd: load("toto.il")

    So depending on the first item, the action might be to print a message, or to execute an action. You have control over the format and the communication "protocol" so make it fit your needs, the above is just a suggestion.

     Hope this helps!

    Regards,

    Lawrence.

Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.