Since the NotebookUI uses a periodic timer to update, we need to introduce the ability to run several simulation steps between updates. I'm thinking that would involve changing update() to check if we're running the model and if so, use a simple incrementing t counter instead of labtime.time. If we then cap the UI update timer at some reasonable value (do we really want to see stuff hapenning at faster than about 5 Hz?) , we add a loop inside update which will run several simulation steps when update is called.
The last thing would be to add a flag to plotter.update which would stop it from updating the historian, which means we can focus on the simulation part (update controller, which updates the TCLabModel, update the Historian to capture the changes) and have plotter update at the UI update rate, perhaps several time steps after it was previously called.
Since the NotebookUI uses a periodic timer to update, we need to introduce the ability to run several simulation steps between updates. I'm thinking that would involve changing
update()
to check if we're running the model and if so, use a simple incrementing t counter instead oflabtime.time
. If we then cap the UI update timer at some reasonable value (do we really want to see stuff hapenning at faster than about 5 Hz?) , we add a loop inside update which will run several simulation steps when update is called.The last thing would be to add a flag to plotter.update which would stop it from updating the historian, which means we can focus on the simulation part (update controller, which updates the
TCLabModel
, update the Historian to capture the changes) and have plotter update at the UI update rate, perhaps several time steps after it was previously called.