Meadville Space Center
Welcome, Guest. Please login or register.
August 04, 2020, 03:35:09 AM

Login with username, password and session length
Search:     Advanced search
Project Apollo - NASSP 6.4.3 released!
http://nassp.sf.net
25068 Posts in 2094 Topics by 2266 Members
Latest Member: twa517
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Apollo - NASSP
| |-+  Project Apollo - NASSP Development
| | |-+  Programming (Moderators: movieman, dseagrav, Swatch, lassombra)
| | | |-+  Checklist MFD
« previous next »
Pages: 1 ... 9 10 [11] 12 13 ... 22 Print
Author Topic: Checklist MFD  (Read 100001 times)
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #150 on: February 20, 2008, 07:45:20 AM »

By the way, is it already possible to control the DSKY with the checklists? I ask because as far as I know the DSKY isn't using standard switches, but is quite often used in checklists, of course.

Cheers
Tschachim
Logged

movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #151 on: February 20, 2008, 09:53:12 AM »

I think you'll need to special case the DSKY: there are already functions to call on it for each keypress, so that shouldn't be hard to do. Detecting when it's been done could be hard, since the state isn't easily readable.... you might just have to say 'Enter V99E on the DSKY then press continue on the MFD' or something.
Logged
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #152 on: February 20, 2008, 03:47:30 PM »

Well, in automatic checklists, there isn't anything I know of that requires the dsky.  In manual checklists, the DSKY would obviously not be able to report it's state.  As of yet, I hadn't thought about what to do with it, but I think for now, we need to just cause it to suspend any auto-completion until the user says the step is done.
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #153 on: February 21, 2008, 01:25:49 PM »

Thinking about it, we could read back things like the verb, noun and major mode display from the DSKY, which should be enough for many types of checklist.
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #154 on: March 12, 2008, 11:05:19 AM »

Well, in automatic checklists, there isn't anything I know of that requires the dsky.

That's right, but that's only because I didn't implement something like this.  Happy

In manual checklists, the DSKY would obviously not be able to report it's state.  As of yet, I hadn't thought about what to do with it, but I think for now, we need to just cause it to suspend any auto-completion until the user says the step is done.

Well, I'm just thinking about the DSKY buttons as pushbuttons. I know that they are no PushSwitch objects, but I suppose that the current code can be enhanced in a way so that they behave like that, i.e. if the checklist says "Press Verb" or "Press 5", the controller presses or highlights the "Verb" or the "5" button, whether it makes sense or not. No "high level" feedback like the current major mode or something like this. The "checklist syntax" in the excel should be enhanced for that to be able to enter one or more keypresses in a line, like "DKSY V 3 7 N 0 0 E" or similar.

A feature like this would be very useful, especially to further decouple Quickstart/Standard and Standard/Virtual AGC mode, i.e. it would be possible to better automate Virtual AGC missions with the final goal to be able to fly both Simple and Virtual AGC missions automatically (Quickstart) or manually.  Two Cents

Cheers
Tschachim
Logged

lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #155 on: March 12, 2008, 11:58:46 AM »

Looks like it's time for me to start digging into the dsky.

I remember somewhere someone mentioned the idea of turning all our switch listener from a case based operation to a simple callback into the switch itself (Or some other method we have set up to receive the event of that switch).  That might be necessary to then remove the mouse interaction from the dsky and overlay it with panel switches that then call into the dsky when pressed.  Speaking of which, I don't know if anyone noticed but in the past, the push button switch was implemented with special logic and I modified it to be implemented as a simple springloaded two pos switch (thus allowing the logic to remain in one switch).  It probably wasn't noticed because it didn't change a thing action wise but it made things easier for the checklist controller to operate push button switches.

Anyways.  Perhaps we want to look at switching the panel listener system to a callback system?  As that's the only way I see operating the DSKY from the checklists as being reasonably doable.
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #156 on: March 12, 2008, 02:31:08 PM »

I already experimented with callbacks in my local copy, since I can't commit that yet, I'll try to explain it, then we can discuss it here. I basically followed the "functor pattern" explained here: http://www.newty.de/fpt/functor.html

I added the following interface and template class to toggleswitch.h/cpp:

class PanelSwitchCallbackInterface {

public:
   virtual void Call(PanelSwitchItem *s) = 0;
};

// derived template class
template <class T> class PanelSwitchCallback : public PanelSwitchCallbackInterface {

public:
   // constructor - takes pointer to an object and pointer to a member and stores
   // them in two private variables
   PanelSwitchCallback(T *o, void(T::*f)(PanelSwitchItem *)) {
      object = o;
      function = f;
   };

   void Call(PanelSwitchItem *s) {
      (object->*function)(s);
   };

private:
   void (T::*function)(PanelSwitchItem *); // pointer to member function
   T *object;                        // pointer to object
};


Then I added a pointer to the interface to PanelSwitchItem, together with a set method:

class PanelSwitchItem: public e_object {
...
public:
   virtual void SetCallback(PanelSwitchCallbackInterface *c);
protected:
   PanelSwitchCallbackInterface *callback;
...


The set method (and a new destructor) deletes a previously set callback and sets the new one. Then I added the following to the SwitchTo functions, same place where the listeners are called:

if (callback) {
    callback->Call(this);
}


For example the SM RCS switches are now working like this: After the register call the callback is set:

SMRCSHelium1ASwitch.SetCallback(new PanelSwitchCallback<SMRCSHeliumValve>(SMQuadARCS.GetHeliumValve1(), &SMRCSHeliumValve::SwitchToggled));

That means the SMRCSHeliumValve has a SwitchToggled function, which is called when the SMRCSHelium1ASwitch is toggled:

void SMRCSHeliumValve::SwitchToggled(PanelSwitchItem *s) {
   ...
}


What do you think?

Cheers
Tschachim
Logged

movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #157 on: March 13, 2008, 09:47:31 AM »

Looks OK to me.
Logged
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #158 on: March 13, 2008, 12:16:04 PM »

Looks good to me.  So the callback is implemented as a functor in the switch class correct?  If we have that taken care of then why don't I put that template stuff in the Toggleswitch.h and commit it and then I'll work on turning the dsky keys into true switches that will call into the dsky.  Btw, Tschachim, congrats on a truly elegant implementation.
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #159 on: March 13, 2008, 01:17:07 PM »

So the callback is implemented as a functor in the switch class correct?

Yes, PanelSwitchItem has a pointer to PanelSwitchCallbackInterface called "callback" and in every SwitchTo function of every switch subclass I inserted

if (callback) {
    callback->Call(this);
}


directly after the listener is called, I hope I explained it properly. I didn't remove the listener stuff, but if we do the callbacks that way, I'm going to replace the stuff currently done in Saturn's listeners with callbacks step by step and then we can remove the listener stuff, kinda "laborious task".

If we have that taken care of then why don't I put that template stuff in the Toggleswitch.h and commit it and then I'll work on turning the dsky keys into true switches that will call into the dsky.

Yes, for me it's fine if you put that in and go ahead and I'll solve any CVS merging conflicts or other problems on my side if there will be any at all.

Btw, Tschachim, congrats on a truly elegant implementation.

Thanks, but it's not my effort, I just adapted the stuff I found in the internet: http://www.newty.de/fpt/functor.html  Happy

Cheers
Tschachim
Logged

lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #160 on: March 13, 2008, 05:00:15 PM »

Yes, PanelSwitchItem has a pointer to PanelSwitchCallbackInterface called "callback" and in every SwitchTo function of every switch subclass I inserted

if (callback) {
    callback->Call(this);
}


directly after the listener is called, I hope I explained it properly. I didn't remove the listener stuff, but if we do the callbacks that way, I'm going to replace the stuff currently done in Saturn's listeners with callbacks step by step and then we can remove the listener stuff, kinda "laborious task".

Ok, so if I understand you correctly, you are just slipping it in where we WERE calling the panel listener (which will eventually cease to exist in favor of a clean callback system).

Yes, for me it's fine if you put that in and go ahead and I'll solve any CVS merging conflicts or other problems on my side if there will be any at all.
There will be some, I can almost guarantee it...  Though if you remove the same from your version and do an update it should auto-merge most of it.

I'll go ahead and put that in tonight and work on the DSKY.  I have a couple ideas on the syntax for the excel sheet for the dsky but I need to figure out how people want to do highlighting for it.  Do we want to highlight the entire dsky or do we want to just highlight the button that should be pressed?
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #161 on: March 13, 2008, 05:41:03 PM »

Ok, so if I understand you correctly, you are just slipping it in where we WERE calling the panel listener (which will eventually cease to exist in favor of a clean callback system).

Now I have problems to understand (I'm no native speaker, sorry), I'd say I'm slipping it in where we are calling the listener, I don't want to remove anything yet. Anyway, here is my version of the SwitchTo function of the ToggleSwitch:

bool ToggleSwitch::SwitchTo(int newState, bool dontspring) {

   // Switch only with REALISM 0
//   if (switchRow) {
//      if (switchRow->panelSwitches->Realism)
//         return false;
//   }

   if (Active)
   {
      if (state != newState)
      {
         state = newState;
         SwitchToggled = true;
         if (switchRow)
         {
            if (switchRow->panelSwitches->listener)
               switchRow->panelSwitches->listener->PanelSwitchToggled(this);
         }
         if (callback)
         {
            callback->Call(this);
         }


         //
         // Reset the switch if it's spring-loaded and not held.
         //
         if (IsSpringLoaded() && !IsHeld() && !dontspring)
         {
            if (springLoaded == SPRINGLOADEDSWITCH_DOWN)   SwitchTo(TOGGLESWITCH_DOWN,true);
            if (springLoaded == SPRINGLOADEDSWITCH_UP)     SwitchTo(TOGGLESWITCH_UP,true);
         }
         return true;
      }
      if (IsSpringLoaded() && !IsHeld() && !dontspring)
      {
         if (springLoaded == SPRINGLOADEDSWITCH_DOWN)   return SwitchTo(TOGGLESWITCH_DOWN,true);
         if (springLoaded == SPRINGLOADEDSWITCH_UP)     return SwitchTo(TOGGLESWITCH_UP,true);
      }
   }
   return false;
}


I attached my versions of the files, so you can see for yourself. But please don't use the files directly, I removed the "operator=" stuff of the switches as discussed, but that requires a couple of changes in other files.

Cheers
Tschachim

* ToggleSwitch.zip (29.06 KB - downloaded 68 times.)
Logged

movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #162 on: March 13, 2008, 06:04:15 PM »

Do we want to highlight the entire dsky or do we want to just highlight the button that should be pressed?

I would think the entire DSKY would do.
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #163 on: March 13, 2008, 06:12:48 PM »

Well, I'd prefer the button, but I could live with the entire DSKY, too.  Happy

Cheers
Tschachim
Logged

lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #164 on: March 13, 2008, 06:52:22 PM »

The button is doable, it's just a question of which would be best.  I suppose the button makes most sense so I'll set it up for that.  The challenge of course with the button is that the MFD needs to be able to understand it and select the right button.

Question for VC 6 users...  Is it acceptable to use _ in identifiers in VC6?  If so I would like to use some on the dsky keys, if not, no big.  It's the difference between DSKY1_1 and DSKY1Button1 for the button object names.
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
Pages: 1 ... 9 10 [11] 12 13 ... 22 Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!