GiD forum

I have a tcl script that I would like to run on GiD. I go to Data>ProblemType>Debugger and then open my tcl file in RamDebugger. Then I click on begin/continue execution (the "play" symbol) but nothing happens.

I have a workaround by using -np- source {File.tcl}, but I would really like to start writing and launching my scripts from within the debugger in GiD.

Why does begin/continue execution not work in the RamDebugger?

When you click on begin/continue execution (or press the <F5> key) the status toobar must show the word 'debug' then you can set/unset breakpoints (<F9> key) and when the flow reach these lines the debugger will stop and allow you to see variable values
Move the mouse cursor over the variable name), or right-click and select in the contextual menu "Expressions" (<F12>)
you can write names of variables, or Tcl expressions to be evaluated on this context.

you can continue the execution flow whit <F10> (next step), <F11> (go inside the procedure, if it is in an instrumented file, previously opened in ramdebugger), <F5> to continue

Is there a way to launch my tcl script from within the debugger instead of doing -np- source {mytclfile.tcl} every time? It is cumbersome if I have to go and browse for the path of the tcl file I want to run every time?

1- Ramdebugger could be used inside GiD or without any relation with GiD, in this second case you simply open your file in ramdebugger and start debugging with <F5>, but then is your Tcl file the 'main file' that do all the work.

2- I think that your question must be which are the ways to load your "mytclfile.tcl" in the GiD interpreter (with or without using ramdebugger).
Really there is only the Tcl command you know:
source {mytclfile.tcl}
but depending on the use this load could (and probably must) be automatized.


a) If your code belong to a problemtype then usually is loaded in the InitGIDProject event raised by GiD
(your procedure can source the files you want of your problemtype, based on the relative location. Do not use absolute paths)

b) If your code is a generic tool of interest for all users and for all problemtypes, then you can set it as a plugin
(inside the \plugins folder the appropriated files are automatically sourced when starting GiD)

c) If your code is a tool of interest only for you, but to be used frequently, you can add a button to the macros toolbar, and put inside the code (it will be saved/sourced in a file inside your user folder)

d) for a punctual test you can do what your are doing, write -np- in the lower command line, followed by the source Tcl command.

Once sourced in GiD you can open the file in ramdebugger, start debugging, and modify it.
You can change it and automatically is redefined for GiD with your modifications (you can force its re instrumentation with <Shift><Ctrl>-R in Ramdebugger, or pressing the contextual menu and selecting 'Reinstrument')

another detail, once you have written in the lower command line
-np- source {mytclfile.tcl}
it is very fast and easy to reload it (if you are editing) simply pressing the <Up> arrow key to recover previously written commands
and pressing <Return> to evaluate the line

Ok then. It is clear that scripts cannot be run directly from the debbugger. They must be run from the GiD command line. Thanks for the information.

I have a follow up question. Is it possible to test tcl commands using an interpreter type interface? For instance I would like to run somthing like:

GiD_Process Mescape Meshing EditMesh CreateNode 0.0 5.0

But without writing a whole script to test it. Is this possible?

you can run it in the lower command entry:
-np- GiD_Process Mescape Meshing EditMesh CreateNode 0.0 5.0 0.0 escape
or don't go from process to tcl with -np- to go again to process with GiD_Process, you can directly write
Mescape Meshing EditMesh CreateNode 0.0 5.0 0.0 escape

or you can also use the Tcl GiD-Command GiD_Mesh (without process words)
-np- GiD_Mesh create node append {0.0 5.0 0.0}