Opened 14 years ago

Closed 11 years ago

Last modified 11 years ago

#1261 closed defect (fixed)

Modelica.Blocks.Sources.TimeTable does not work (bug in event-handling)

Reported by: asodja Owned by: Lennart Ochel
Priority: high Milestone:
Component: Simulation Code Generation Version: 1.6.0
Keywords: Cc: asodja, Willi Braun

Description (last modified by Martin Sjölund)

In attachment is a test model consisting of only one block of the Modelica.Blocks.Sources.TimeTable component.

The output (TimeTable.y) is zero all the time.

The problem is that the {{initial()}} and {{time >= pre(nextEvent)}} (nextEvent is initalized to 0) never happens, e.g., {{functionDAE_output2()}} is not called at appropriate time so the if-statment is never evaluated to true:

int functionDAE_output2()
{
  /* ... */
  tmp0 = initial();
  tmp1 = pre($PtimeTable$PnextEvent);
  RELATIONGREATEREQ(tmp2, time, tmp1);
  localData->helpVars[0] = tmp2;
  localData->helpVars[1] = tmp0;
  if (edge(localData->helpVars[0]) || edge(localData->helpVars[1])) {
    real_array_create(&tmp3, &$PtimeTable$Ptable, 2, 7, 2);
    tmp4 = _Modelica_Blocks_Sources_TimeTable_getInterpolationCoefficients(tmp3, $PtimeTable$Poffset, $PtimeTable$PstartTime, time, (modelica_integer)$PtimeTable$Plast, 1e-13);
    $PtimeTable$Pa = tmp4.targ1;
    $PtimeTable$Pb = tmp4.targ2;
    $PtimeTable$PnextEvent = tmp4.targ3;
    $PtimeTable$Plast = tmp4.targ4;
  }

Attachments (2)

ttTest.mo (3.7 KB ) - added by asodja 14 years ago.
ttTest2.mo (8.5 KB ) - added by asodja 14 years ago.
Bug in event-handling is also evident when {{CombiTimeTable}} is used instead of {{TimeTable}}. In that case, parameter {{t_min}} and {{t_max}} never get initialized properly. They are initialized in initial-equation section: {{{initial equation t_min = tableTimeTmin(tableID); t_max = tableTimeTmax(tableID); But equations from inital-equation section get evaluated before the initial() event is handeled. In this case, in initial() event {{tableTimeInit()}} is called which return valid value of variable {{tableID}}.

Download all attachments as: .zip

Change History (7)

by asodja, 14 years ago

Attachment: ttTest.mo added

comment:1 by asodja, 14 years ago

An important note is also that if {{_Modelica_Blocks_Sources_TimeTable_getInterpolationCoefficients()}} would get called, it would result in a segmentation fault. See bug #1262.

by asodja, 14 years ago

Attachment: ttTest2.mo added

Bug in event-handling is also evident when {{CombiTimeTable}} is used instead of {{TimeTable}}.
In that case, parameter {{t_min}} and {{t_max}} never get initialized properly.
They are initialized in initial-equation section:
{{{initial equation

t_min = tableTimeTmin(tableID);
t_max = tableTimeTmax(tableID);

}}}
But equations from inital-equation section get evaluated before the initial() event is handeled.
In this case, in initial() event {{tableTimeInit()}} is called which return valid value of variable {{tableID}}.

comment:2 by Martin Sjölund, 11 years ago

Cc: asodja, → asodja
Description: modified (diff)

comment:3 by Martin Sjölund, 11 years ago

Cc: Willi Braun added
Owner: changed from asodja to Lennart Ochel
Status: newassigned

These models still do not seem to be working. And we use the MA implementation of the external functions, so it is probably initialisation or event handling that is causing problems.

model ttTest
  Modelica.Blocks.Sources.TimeTable timeTable(table=[0,0; 1,0; 1,10; 2,10; 2,5; 3,0; 4,0]);
end ttTest;
model ttTest2
  Modelica.Blocks.Sources.CombiTimeTable combiTimeTable(table=[0,0; 1,0; 1,2; 2, 2; 2,1; 3,0]);
end ttTest2;

comment:4 by Lennart Ochel, 11 years ago

Resolution: fixed
Status: assignedclosed

Both models are working as expected. You have to simulate more than just one time unit before y is getting different to zero.

comment:5 by Martin Sjölund, 11 years ago

Ah yes, silly examples to not have StopTime in them ;)

Note: See TracTickets for help on using tickets.