CURRENTMODE Confusion...

[DDoutel]

Does the CURRENTMODE variable always reflect the hardware state on the Pro Throttle? If not, how do I get it in sync? I'm trying to program an autorepeating command to raise and lower the gear manually in FB. I've got autorepeat working nicely for elevator trim on a CMS control, and would like to use mode 2 of the same control for the manual gear.

Thanks in advance,
Duane

[Bob Church]

No. It reflects the mode that the CM thinks that it's running in. It would reflect the Pro Throttle mode if the Pro Throttle is set as the Mode Control on the Program Settings Tab with a few caveats. First, when you first activate the map, either via download or by hittine "Mapped Mode" the Control Manager is in Mode 1 regardless of the state of the LEDs on the throttle (or the FighterStick). The CM doesn't get notified of the Mode Light state until the mode changes, so if they're not in sync at the beginning you have to click the button and change the LEDs once and then the CM will know where they are.

If you're using the FighterStick for Mode Control, the same rules apply and the Pro Throttle LED state doesn't mean anything to the CM. If you use CMS for Mode Control, then it controls things and neither the Pro Throttle or the FighterStick LEDs matter.

You might want to look at PROTHRMODE and FTRSTKMODE and hang on to those rather than mode itself. They reflect the mode of the individual devices regardless of the current mode in the Control Manager, though the same problem with initial synchronization still exists. You have to click them once to ensure they're lined up unless the LEDs are in Mode 1 at map activation time.

- Bob

The StickWorks
http://www.stickworks.com

[DDoutel]

Thanks, Bob; this is what I needed to know.

Regards,
Duane

[DDoutel]

Geez; I'm finding that the script facility is defying 20 years worth of development experience in assembly, C, and C++; anyone got a bit of sample script that demonstrates how to actually USE the PROTHRMODE variable? I'm finding I can't even get multiple statements within a IF-THEN-ELSE or SELECT case....

I gather it's not possible to do something like:



If ( [A1 == 1] ) Then
ÂÂ*Select ( ) Of
ÂÂ*EndSelect
Endif

or

If ( [A1 == 1] ) Then
ÂÂ*Sequence
Â* Â*...
ÂÂ*EndSequence
Endif

[Bob Church]

Putting the conditional around the select block is illegal. Putting one around the sequence can create problems, but it does seem to compile okay. It's a problematic construct though. If A1 is "1" the sequence will start, but as soon as A1 comes off "1" the whole sequence starts getting skipped. For example (not tested, just for illustration):

if( [ a1 == 1 ] ) then
sequence
a1 = 2;
delay( 10);
a1 = 1;
endSequence
endif

When A1 hits 1, the if/then is satisfied and it will run as far as the delay( 10 ). As soon as it does the sequence will get suspended so the delay can run. Next time the loop comes 'round, a1 will be "2" and the sequence will never be entered because of the conditional, the delay( 10 ) will never finish unless something outside the if/then block sets A1 to 1 again, and the sequence will never complete. You need to do it like this:

sequence
wait( [ a1 == 1 ] );
a1 = 2;
delay( 10 );
a1 = 1;
endSequence

The wait instruction doesn't skip the sequence, it just puts it into suspension if it's not satisfied, so the sequence will get reentered on the next loop. The if/then actually stops the sequence from being reentered and so it stalls.

What are you trying to get it to do?

- Bob

The StickWorks
http://www.stickworks.com

[Bob Church]

>> ... anyone got a bit of sample script that demonstrates how to actually USE the PROTHRMODE variable? <<

Here&#39;s a couple that work here. The first is probably the more straightforward. It just does three compares on the PROTHRMODE variable and sets/clears bits depending on the result:

>>
script

cms.b1 = [ PROTHRMODE == 0 ]; // CMS.B1 is ON in Mode 1
cms.b2 = [ PROTHRMODE == 1 ]; // CMS.B2 is ON in Mode 2
cms.b3 = [ PROTHRMODE == 2 ]; // CMS.B3 is ON in Mode 3

endScript
<<

The Select block also works, but it has to be at global scope. This next does essentially the same function as the above, sets the bit when you come into the matching value, clears it when you leave:

>>
script

select( PROTHRMODE, position ) of

case 0: cms.b1 = TRUE;
exitCase: cms.b1 = FALSE;
break;

case 1: cms.b2 = TRUE;
exitCase: cms.b2 = FALSE;
break;

case 2: cms.b3 = TRUE;
exitCase: cms.b3 = FALSE;
break;

endSelect;
endScript;
<<

You can&#39;t put an if/then around the Select, but you could proably put one around whatever you&#39;re doing with the bits and handle it that way. Another somtimes useful thing to keep in mind is that the Select block only actually does something when you change zones. You can put an if/then around the value that feeds the select block and stop it from changing state that way, e.g.:

if( WeWantThingsToChange ) then
A1 = PROTHRMODE;
endIf

then feed A1 to the Select block. Unless WeWantThingsToChange is TRUE, A1 won&#39;t track PROTHRMODE and the Select block won&#39;t move.

Anyway, maybe one of those will help you get to where you want to go. If not, let me know what you&#39;re trying to do. There&#39;s probably a way....

- Bob

The StickWorks
http://www.stickworks.com

[DDoutel]

Bob, you&#39;re a god! I&#39;ll give all this a shot shortly; many, many thanks!

Best regards,
Duane

[Bob Church]

You&#39;re welcome, Duane! If you have any trouble getting it to do what you want, let me know.

- Bob

The StickWorks
http://www.stickworks.com

[DDoutel]

Originally posted by Bob Church@May 30 2004, 06:47 PM
You&#39;re welcome, Duane! If you have any trouble getting it to do what you want, let me know.

- Bob

Well, OK... here I am! Bob, sorry to bug you with this.

I am using Hat 1 and cms controls on the ProThrottle for increase and decrease elevator trim respectively. I want to program it so that MODE1, as indicated by the red light on the throttle, will, if held, "crank" the gear up or down manually.

I should be able to simply check PROTHRMODE for MODE1 in an IF statement, and, within the IF, create a SEQUENCE/ENDSEQUENCE block as a compound statement within the IF statement.

Why must this be so painful? As a developer of fairly extensive experience, I&#39;m finding the scripting facility within the Control Manager to be only half there, and my frustration with it is growing fast! I&#39;ve now spent at least 48 hours (literally, not figuratively) trying to accomplish this. The driver itself is a work of art; I know, because I&#39;ve written enough drivers to appreciate such things.

[Bob Church]

Hi Duane,

I know it can get a bit frustrating sometimes, I get into things that don&#39;t make sense at first, too. Generally when I get it working, I can see where I went astray, but at the time it just looks like the thing has gone brain dead. I&#39;m working on a generic "DoWhatIMeant()" instruction, but it&#39;s still in the planning stages. :)

Discounting the IF/THEN part, can you get the sequence to work? IOW, if you didn&#39;t have to deal with the modes, can you make the sequence do what you want it to? So far, I&#39;m not at all sure what&#39;s going wrong or what it is you&#39;re trying to do. You mentioned manually cranking up the landing gear in an earlier post, but I don&#39;t have the sim so I don&#39;t really know what that entails. Can you post the sequence here so I can have a look? One possibility is that you&#39;ve just run into a bug that nobody else has encountered yet.

Anyway, I&#39;m here and more than happy to help you work it out, and if there&#39;s a bug I&#39;d certainly like to find it so I can fix it before the Throttle Quad update. If you could post the sequence and a description of what needs to happen (which keys need to get sent, etc.), it would be a big help. I can take a look and maybe sort out what&#39;s gone wrong.

- Bob

The StickWorks
http://www.stickworks.com

[DDoutel]

Bob, this is what&#39;s on MODE0, and it works without flaw:



%define ThrottleMode cms.a1

// MODE1 == 0
// MODE2 == 1
// MODE3 == 2
// MODE4 == 3

ThrottleMode = PROTHRMODE;
...

// Elevator Trim Positive
Sequence
Â*while ( JS1.B7 );
Â*CMS.B7 = TRUE;
Â*delay(REPEAT_DELAY);
Â*CMS.B7 = FALSE;
Â*delay(REPEAT_DELAY);
EndSequence

// Elevator Trim Negative
Sequence
Â*while ( JS1.B5 );
Â*CMS.B5 = TRUE;
Â*delay(REPEAT_DELAY);
Â*CMS.B5 = FALSE;
Â*delay(REPEAT_DELAY);
EndSequence


What I need to do here, is find out if the throttle is in MODE1, and set, say, CMS.B19 to TRUE (mapping this in FB would, if held, lower the landing gear), and in the case of the first block, set CMS.B21 to TRUE (this, if held, would crank UP the gear).

I&#39;ve tried this a crapload of different ways, and logically, it just doesn&#39;t make sense that I can&#39;t get there from here...

[Bob Church]

Hi Duane,

So basically all you want to do is to shift the toggling output from CMS.B5 and CMS.B7 to CMS.B19 and CMS.21 if the Mode is 0? If I&#39;ve got that right, then just stay away from the "If/Then" and put a little logic in the blocks you&#39;ve got:

script

%define ThrottleMode cms.a1
%define REPEAT_DELAY 10

ThrottleMode = PROTHRMODE;

// Elevator Trim Positive
//
Sequence
while ( JS1.B7 );
CMS.B7 = [ ThrottleMode != 0 ];
CMS.B21 = NOT CMS.B7;
delay(REPEAT_DELAY);
CMS.B7 = FALSE;
CMS.B21 = FALSE;
delay(REPEAT_DELAY);
EndSequence

// Elevator Trim Negative
//
Sequence
while ( JS1.B5 );
CMS.B5 = [ ThrottleMode != 0 ];
CMS.B19 = NOT CMS.B5;
delay(REPEAT_DELAY);
CMS.B5 = FALSE;
CMS.B19 = FALSE;
delay(REPEAT_DELAY);
EndSequence

endScript

Which seems to work fine here for doing what I described. If you just need a slow toggle though, the interval timer is a little simpler to use:

script

// Generate a pulser on either direction
//
timer( INTERVAL, d1, REPEAT_DELAY, REPEAT_DELAY ) = js1.b5 OR js1.b7;

// Now just use that and PROTHRMODE to generate the toggling outputs
//
CMS.B5 = d1 and js1.b5 and [ PROTHRMODE == 0 ];
CMS.B19 = d1 and js1.b5 and [ PROTHRMODE != 0 ];
CMS.B7 = d1 and js1.b7 and [ PROTHRMODE == 0 ];
CMS.B21 = d1 and js1.b7 and [ PROTHRMODE != 0 ];

endScript

That does the same thing. I&#39;m not sure I&#39;ve quite got the B5/7/19/21 things exactly where you want them, but you&#39;ve got two pairs of flashing outputs, one on js1.b5 and one on js1.b7 and the output they flash will change with PROTHRMODE.

There are probably a lot of ways to pull it off. I think your problem was probably an interaction between the If/Then and the Sequence, those errors can be hard to pin down sometimes.

Anyway, that does what I think you want. If it&#39;s still not quite there, let me know where I missed it and I&#39;ll work somethinge else out.

- Bob

The StickWorks
http://www.stickworks.com

[DDoutel]

Bob, I think this is close to what I need; one further question if you&#39;ve still got the patience? I actually want MODE0 (green light) to pulse CMS.B7j, and MODE1 to pulse CMS.B21 (I&#39;ll assign this as directX button 21 in FB). What happens when I want to put some function on MODE2? The code below wouldn&#39;t discriminiate, would it?



CMS.B7 = [ ThrottleMode != 0 ];
CMS.B21 = NOT CMS.B7;


Would the above have to change to something like:



Sequence
CMS.B7 = [ThrottleMode != MODE1 AND ThrottleMode != MODE2];
CMS.B21 = [ThrottleMode != MODE0 AND ThrottleMode != MODE2];
// future whatever...
CMS.Bxx = [ThrottleMode != MODE0 AND ThrottleMode != MODE1];
delay(REPEAT_DELAY);
CMS.B7 = FALSE;
CMS.B21 = FALSE;
CMS.Bxx = FALSE;
delay(REPEAT_DELAY);
EndSequence


Am I starting to get the idea here, or am I all wet? :)

[DDoutel]

Hi Bob,

I found out the above stuff I posted didn&#39;t work; cms doesn&#39;t like AND in []&#39;s. I had to do it like this:



// Elevator Trim Positive
Sequence
Â*Â*Â*Â*while ( JS1.B7 );
Â*Â*Â*Â*CMS.B7 = [ThrottleMode == 0];
Â*Â*Â*Â*CMS.B21 = [ThrottleMode == 1];
Â*Â*Â*Â*delay(REPEAT_DELAY);
Â*Â*Â*Â*CMS.B7 = FALSE;
Â*Â*Â*Â*CMS.B21 = FALSE;
Â*Â*Â*Â*delay(REPEAT_DELAY);
EndSequence

// Elevator Trim Negative
Sequence
Â*Â*Â*Â*while ( JS1.B5 );
Â*Â*Â*Â*CMS.B5 = [ThrottleMode == 0];
Â*Â*Â*Â*CMS.B19 = [ThrottleMode == 1];
Â*Â*Â*Â*delay(REPEAT_DELAY);
Â*Â*Â*Â*CMS.B5 = FALSE;
Â*Â*Â*Â*CMS.B19 = FALSE;
Â*Â*Â*Â*delay(REPEAT_DELAY);
EndSequence


Now I have another dumb question:

Why do I have to set an entirely separate button, i.e. cms.b19 or cms.b21, rather than using the mode 2 tab for buttons cms.b5 and cms.b7 to send those DX codes?

Doesn&#39;t this kinda say that the mode tabs in mapped mode actually don&#39;t respect the throttle mode at all?

[Bob Church]

Hi Duane,

>> I found out the above stuff I posted didn&#39;t work; cms doesn&#39;t like AND in []&#39;s. I had to do it like this: <<

No, it doesn&#39;t like that. The square brackets are used around an arithmetic comparisone to turn it into its&#39; bit value result. You want to do it like this:

>> CMS.B7 = [ThrottleMode != MODE1 ] AND [ ThrottleMode != MODE2]; <<

Which is two analog comparisons AND&#39;ed together.

>> Why do I have to set an entirely separate button, i.e. cms.b19 or cms.b21, rather than using the mode 2 tab for buttons cms.b5 and cms.b7 to send those DX codes? <<

Well, mainly because you asked how to use PROTHRMODE. :) If you let the Pro Throttle control the Control Manager modes, then the tab functions will track. What we&#39;ve been doing here is independent of the Mode tabs, it&#39;s just logic based on the current state of the Pro Throttle mode switch, not the Control Manager mode itself.

If you want to use the tabs, then select the Program Settings tab and set the Mode Control box to ProThrottle. Then the three tabs will come active and the ProThottle will switch between them. Have a script run a single CMS bit for each function rather than the two that it&#39;s using now, then set the functions on the Mode tabs to send the single CMS output to one of two (or three) DirectX inputs. CM Device 1, Buttons 17, 18, 19 for example. The difference in doing it that way is that the split in functions happens in the GUI assignments rather than down in the script.

>> Doesn&#39;t this kinda say that the mode tabs in mapped mode actually don&#39;t respect the throttle mode at all? <<

It just depends on what you&#39;ve got set on the Program Settings tab. When I added PROTHRMODE and FTRSTKMODE, it was to allow those LEDs to be used for smaller functions without having them set the mode for the whole program. You can include functions that track PROTHRMODE and functions that track FTRSTKMODE by writing them into the script and have the script itself control the main CURRENTMODE variable and so which set of tabs is active, then switch through the three groups of functions independently. I thought the LEDs and using PROTHRMODE or FTRSTKMODE would be hande for cycling through weapons modes, things like that, since you could look at the LEDs and tell where you were.

So - is it working okay now?

- Bob

The StickWorks
http://www.stickworks.com

[DDoutel]

Yup; it&#39;s working ok now, Bob. Your help very much appreciated.

I think the reason for my confusion (perhaps even initially) is that I HAVE set the mode control to ProThrottle, so I HAVE the three tabs available. I guess that&#39;s why it didn&#39;t make sense to me that switching modes at the throttle didn&#39;t do what I needed.

I don&#39;t know where you are with CM in terms of further work, so I hope you won&#39;t mind if I make a suggestion for your consideration.

You&#39;re probably aware of the Windows Script Host, which is, as it says, the mechanism for implementing various script languages capable of controlling much of windows from simple scripts. One of the little-known things about the Script Host is that it&#39;s actually a component available for embedding in one&#39;s own apps for the purpose of implementing a scripting facility, and is highly customizable in terms of behavior. You can even implement your own language, if you choose.

I guess what I&#39;m gettng at here is that you can get pretty nearly a full-blown scripting environment, customized to your needs, complete with parser, etc. (particularly if you go with already-implemented flavors like JavaScript/JScript/VBScript/Python) for a lot less effort than it takes to implement a language and compiler on your own. you can even support scripting in multiple languages.

Just something you might want to consider, if you&#39;re looking at future enhancements to CM.

Thanks again, Bob!

Duane

[DDoutel]

One last thing (I promise...)

Where we have Script/EndScript statements, would it be efficatious to have something like: Script Mode = X/EndScript, or perhaps a Mode=X/EndMode directive around blocks of script which would be "activated" depending on the state of the hardware switch, and thus track with the lights on the device? This would make scripting these guys a good bit more intuitive...

Just another thought... :)

Best,
Duane

[JNOV]

Duane:

I find the three- (four-) hard modes too limiting, so I don&#39;t normally use them. In fact, in a typical complex script, I may define three or four sets of independent or partially overlapping "soft" modes, in addition to a few shift states. Of course, that renders the GUI almost useless, so I typically generate all of my outputs via CMS buttons. One loses the benefit of one of the two sets of hardwired LEDs as mode indicators (although substitute indicators are possible), but that seems a small price to pay for the flexibility.

- JNOV

[DDoutel]

Originally posted by JNOV@May 31 2004, 11:09 PM
Duane:

I find the three- (four-) hard modes too limiting, so I don&#39;t normally use them. In fact, in a typical complex script, I may define three or four sets of independent or partially overlapping "soft" modes, in addition to a few shift states. Of course, that renders the GUI almost useless, so I typically generate all of my outputs via CMS buttons. One loses the benefit of one of the two sets of hardwired LEDs as mode indicators (although substitute indicators are possible), but that seems a small price to pay for the flexibility.

- JNOV
I think you can have both flexibility AND ease of use.

[DDoutel]

Bob,

I just wanted to let you know that my comments about what I view as the only rough edge in an otherwise brilliant driver implementation in any way reflect an unappreciative attitude on my part; they don&#39;t. I spent many years writing drivers under Windows, so no one has a better appreciation for what it takes to build one as stable and versatile as this one than I do.

Many thanks for your work on them, and your patience with my questions along the way.

Most Sincerely,
DDoutel

[Bob Church]

Hi DDoutel,

Thanks for the kind comments! There was no offense taken on my part, I recall the thread and thought I&#39;d replied but sometimes I get sidetracked. I&#39;ll have a think about the mode thing and see what it would take to implement. It might be easier to break things up that way. I&#39;ll also have to think about how to explain it. :) Something to look at for CM4.

Anyway, my apologies for not replying to you originally.

Best regards,

- Bob

The StickWorks
http://www.stickworks.com