Mathias Fröhlich said: > On Freitag, 2. April 2004 05:47, Jim Wilson wrote: > > Earlier we had a report of a reset issue on the list. It appears that the > > problem only affects a couple JSBSim aircraft...the c172 (all of them) and > > the 737. Everything else seems to trim fine. > Others don't work too. The A320 for example ends upside down too. > > > The issue appears to be due to a difference between how the FDM is > > initialized on startup and how it is initialized on restart. On startup > > the FDM initialization is delayed until a tile is loaded for the startup > > location, giving an accurate ground elevation value (test for gound_elev > > > -9990). This test is not possible during the reinit phase, because we're > > only passing through the reinitialize routine once. > > > > The more I look at the workarounds we have been accumulating for making > > flightgear initialize and reinitialize the more I realize that we may be > > frequently taking the wrong approach to solving such issues. We are > > failing to build self-sufficient and self-protecting subsystems. > :) > > Hmm, I am not very familiar with the way flightgear interfaces with a FDM. > What I can tell now is that JSBSim has a problem with it's timestepping method > during reinitialization. But Jon and me are working on this. > But this is not the whole problem. Doing this right is not sufficient. > > > Which is why I'm calling this a JSBSim bug. If the altitude is < -9990 > > and/or the ground_elelvation is < -9990, would it be possible for JSBSim > > to not ground trim and instead go for a coffee or freeze or whatever it > > needs to do while the scenery system gets wound up? > > > > In other words, rather than try and find another bandaid, what I would > > like to do is remove the elevation test from following code in main.cxx and > > let the fdm take care of itself: > I am not shure what happens here. But it appears to me that either > FGInterface::update(double) or FGInterface::init() is called while the > environment (ground level, etc ...) containes senseless data, true? > > So, for the coffee question, I think that this could be done. > But you told about self-sufficient and self-protecting subsystems. I don't > think that this goal could be achieved when code, which in effect tests > for an error condition of the tile loader, which is something orthogonal to > flightdynamics, is moved into a FDM. > Just call FGInterface::init() when the FDM has *all* data required for > initialization. The same goes for FGInterface::update(double), it should not > be called when the FDM sees screwed up environment data ... > > Or, in other words, why should a FDM need to know that groundlevels below > -9990ft are an error condition of the tile loader? >
My response is that the Init is merely for setting up and initializing data structures. This should happen independent of what is on the bus. The updates should basically noop until all the parts it needs are initialized, although with something like this case it might be fine to merely delay the ground trimming, but go ahead and process non-external data. BTW I'm not sure of your characterization of the relationship between these two subsystems. That was my question, is this more than just ground trimming? Best, Jim _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
