The code for the &quot;Create offset curve&quot; command has some problems.  <br><br>The following:<br><br>    cylinder radius 1 z 1 <br>    create curve offset curve 1 distance 0.5<br><br>raises in an exception because the direction vector passed through a series of calls is (0 0 0). The actual code raising the exception is gp_Dir.lxx, lines 41-42:<br>
<br>  Standard_Real D = sqrt (Xv * Xv + Yv * Yv + Zv * Zv);<br>  Standard_ConstructionError_Raise_if (D &lt;= gp::Resolution(), &quot;&quot;);<br><br>  I am told by the Cubit experts here that a zero value direction vector  for this command should assume the offset is to be planar so in this case a direction vector of (0 0 1) should be used.  This is indeed how the current version of Cubit behaves.  When the option &quot;direction 0 0 1&quot; is added to the command the OCC code works properly. At least the first time.  If the exact command is entered a second time, the resultant curve is offset by an additional 0.5 making the total offset 1.0.  Each time the command is repeated, the offset is incremented by another 0.5 which is incorrect behavior.  <br>
<br>After the create offset command with direction is entered, a &quot;reset&quot; command yields the following:<br><br>   Traceback (most recent call last):<br>     File &quot;&lt;string&gt;&quot;, line 1, in &lt;module&gt;<br>
     File &quot;C:\Cubit_Open_Cascade\cubit_build_OC\claro\bin\Debug\cubit.py&quot;, line 2278, in cmd<br>       return _cubit.cmd(*args)<br>   RuntimeError: Access violation - no RTTI data!<br><br>Cursory debug reveals the failure occurs when attempting to destroy the existing geometry.<br>
<br>Also, when the magnitude of the direction vector is increased to any value other than 1 (such as 0 0 3), strange no-planar behavior results when, in fact, the magnitude should have no affect on how the command behaves.<br>
<br>Thank you for looking at this.  Sorry it is so long but I thought the detail would help.<br><br>  - Boyd<br><br>