MobiFlight Community Support

Welcome to the forum for MobiFlight! Feel free to reach out to the community in case you have questions, issues or just want to share great ideas or details about your latest home cockpit project.

You like MobiFlight? Donate via PayPal and support the MobiFlight development. Thanks! 

icon
Avatar
anthonym
Posts: 5
Greetings fellow panel builders.
I have searched the forum to see if anyone has encountered this issue before but I could not find any reference to this particular issue.

I have built a panel setup that includes the major systems for the PMDG B747, ie Bleeds, Packs, Fuel Pumps etc, on one half and the other contains the same systems for the PMDG B737ngxu.
I have included the annunciator test switch for testing the operation of the LED annunciators on the B737 and also the led's I have installed in the home-built Korry switches used on the B747.
I have configured the 737ngxu Event ID and it works well, so when the switch is toggled, the FSUIP Offsets for the led's are set to 1 (on) and the led's operate along with the sim.

However when I config the B747 Event ID to test the lights, MobiFlight does not set the led FSUIP offsets to on. The lights on the overhead panel within the sim operate as intended but not the external led's on my panel. All led's have been verified as working and they operate as intended when run in the sim environment. (except for the test function of course)
The Event ID I am using is: 69867. It also makes no difference if I toggle my switch or I toggle the sim switch.

If there is something I have missed or any suggestions I would be most grateful. I could do an electrical workaround but would prefer it to be handled via the MobiFlight Software.

Thanks in advance.
2020-07-06 08:28
Avatar
waelsalh
Posts: 7
I have the same problem with 747 and 777
2020-07-06 09:35
Avatar
pizman82
Moderator
From: ETSI, Germany
Posts: 3522
Supporter
Hi guys.

You did nothing wrong..... This is a issue/missing feature of PMDG.

Only the newest product PMDG B737 NGX"u" (for P3Dv4.5 and above) support THIS system.
In all other prior PMDG´s thats missing.

Means a Output in the older PMDG will always show the status of the function. All Offsets NOT act to things like Lighttest and/or Battery status.
For example the Green Gear Status LED will light if Gear is DOWN ( and Offset is 1) . If you disable Master Battery switch the virtual LED is OFF..... BUT the Offset is still "1" cause the gear is basicly down already..... So Mobiflight light already the LED.
Same with Lighttest.... If Gear is UP then the Green LED is OFF ( Offset is 0) . If you press the Lighttest switch then virtual LED is ON but the Offset is still "0" . So Mobiflight can not light it.

Solution:

To solve this you must use the same system we work with since years....
Make Precondiitons ( So each LED got 3 Configs) or work with Placeholders ( i recommend so)

Example for Placeholder and Lighttest.
You read one time at beginning of your mcc file the Lighttest Swtich Offset .... ( lets say it´s "1" aslong Lighttest is in progress)
You define in each Output Config a Placeholder to this Lighttest Config and say e.g. its symbol "a"
In each Output config you use transform: if(a=1,1,$)
Means If value of "a" ( The lighttestswitch) IS 1 then Set LED Output to always "1" (on) .... ELSE ( So if Lighttestswitch is not 1) set Output value to "$" ( Means current value of function)

Same can be done with Battery switch.... Here you say... Aslong Battery switch is OFF then set to "0" ..... Else set to "$" .
And sure you can also combine both things.... Here you need TWO Placeholders and a little more advanced formula !
Good Luck !
2020-07-06 14:21
Avatar
anthonym
Posts: 5
Hey
Thank you for your reply and solution.

I have tried a few led's with the new config you suggested and so far they appear to be working perfectly.

I had read posts regarding preconditions and config references before but could not get my head around how it all went together. Your examples really helped. Now I think I have an understanding of the process I can sort out some other issues using the same technique.

I will config the rest of the led's and post on the results.

Many thanks
2020-07-07 09:18
Avatar
pizman82
Moderator
From: ETSI, Germany
Posts: 3522
Supporter
Wonderfull that it helps you ! ;)
Just a little note to protect you from a problem:

Precondition System have a big difference to placeholder/Config Reference System.... Thats why i recommend the placeholders!

A Precondition not change the Value of a Config.... It just Enable or Disable the Config. BUT it NOT directly controll the Device like a LED.


For example again the Battery Switch and Gear Down Green LED.

With Precondition Logic you again need a Global Config at beginning of MCC File that read the Battery Switch. Lets call it for example "Battery"
Your "Gear Down LED Config" Read the Offset from the GearLED..... And you now use a Precondition that say "Only work if Config "Battery" = 1
Now Gear is Down.... LED is light ..... And you now move the switch of Battery to OFF.
This let the precondition going into FALSE ( Cause now the "Battery" Config is no longer 1) . It will DISABLE the Whole Config.
BUT
The LED is still ON..... Cause it was ON before and "nobody" told it to go off. It is just no longer controlled by the Config so it stay in LAST status !

That means in Precondition Logics we always need two ( or more) Configs to handle a situation.
Target is.... If a Config get Disabled in case of Precondition ( Like our "Only work if battery is On) then we need a other config that work that time with a Precondition like "Only work if battery is OFF"

In easy words.... With Precondition we must create multiple configs ( one for each posible precondition situation) .... With Placeholder 1 Config is enough cause here we direclty change the value itself and NOT just the Enebale/Disable status.
Summary: Complex things are better with placeholders.... Easy things can be done with Preconditions whatever you already need multiple configs and more work to build !
Good Luck !
2020-07-07 14:28
Avatar
anthonym
Posts: 5
Hey pizman82
Just an update to the config issue I was having.
I completed the configs for the remaining led's and all seemed to be working well until the next time I loaded the aircraft and Mobiflight.
Mobiflight did not want to run and would display the following message in the debug window.

(12/07/2020 12:05:48 PM(851): Error on config execution. An error occured on parsing your value formula. Please review and correct any errors.)

I then unchecked the output led entries with the new config and Mobiflight would then run.

During this process I noticed that Mobiflight would stop and not display a value in the FSUIP value and Offset value windows past the first led entry. My question is, does Mobiflight read the first entry line first and work its way down the list one at a time, so it does not get to the placeholder definition until the end. If so maybe the led config entries do not have a defined variable to reference and stops Mobiflight from running? Do I need to move the placeholder entry to the top of the list in the mcc file?
Similar to the way the Mobiflight test function starts from the top and works its way to the bottom in sequence. Or is there any other reason why this is happening.

ps, the transform code I am using is if(a=0,1,$) where 'a' is the light test offset placeholder.

Your thoughts are much appreciated.
2020-07-12 04:47
Avatar
pizman82
Moderator
From: ETSI, Germany
Posts: 3522
Supporter
Your 100% right ! :thumbup:
MF work a Config always from Up to Down

That why i said....
iconpizman82:


Example for Placeholder and Lighttest.
You read one time at beginning of your mcc file the Lighttest Swtich Offset .... ( lets say it´s "1" aslong Lighttest is in progress)
......



Mobiflight can ( at the moment) NOT use the placeholder in a formula aslong the "Value" is not readed already.

I report this to Sebastian.... maybe in the next hotfix he can include a little code that e.g. all placeholders are simply set to "zero" at beginning.... So the Value is not correct in first loop ( until it get realy read first time) BUT this will prevent us from the error warning.

Solution:
Please create the "Read Config" you use for the placeholder on TOP of your MCC file ( or better said above the configs that will use them)

You can copy paste it within the code ( by editing the mcc file with a text editor) OR you can simply duplicate a Config on Top .... this create a new config dirctly behind ( e.g. on second position from Top) Then rework this config so it will be the "read config" you will use for placeholders..... Finaly delete the current used config that is in lower section.

Badly we can not simply drag and drop a config in Mobiflight.... So you must go one of this uncomfortable ways.
Good Luck !
2020-07-12 15:21
Avatar
anthonym
Posts: 5
Hey pizman82
Ah now I see. I did not fully understand what you meant in your explanation and what exactly what goes where at the beginning of the mcc file.

I am still very much a novice when it comes to computer code. I feel much more at home with the physical side of the build, and rely on searching volumes of forum entries for answers and information. But this issue has given me a good idea on how things work together and actually I am quite happy I was able to correctly identify what was happening. Thank you for your confirmation and patience.
I can't wait to take the panel for a flight. Question is now what? Maybe an A2A piston aircraft panel. Hummmmm.

Many Thanks.
2020-07-14 08:10
Avatar
pizman82
Moderator
From: ETSI, Germany
Posts: 3522
Supporter
iconanthonym:


I am still very much a novice when it comes to computer code. I feel much more at home with the physical side of the build, and rely on searching volumes of forum entries for answers and information.



For me it´s inverted. I feel much more comfortable with a calculator, a pen and a piece of Paper with hundrets numbers on it.... As with a driller or a solder iron.

Thats the bad factor in cockpitbuilding i said hundrets of times in the past. If you build it alone you must fit a lot of different areas.... All technical are jobs with a edjecation time of 2-5 Years.
For a perfect Cockpit a group of people would be much more profitable.
- A licensed Pilot who basicly know everything about the Systems and how they must look like.
- A Designer with CAD knowledge to build all the plans for 3D Printing , CNC work and so on.
- A construcktor for WOOD, METAL and PLASTIC .... So technical 3 industry workers to have a professional man for all needed parts. ( with access to professional hardware, too)
- A electronic Pro for all the solder and wirework
- A Programmer for the Code
- A "Think-tank" who figure out the logics and tell the programmer what he should do !
Good Luck !
2020-07-14 09:51
Avatar
anthonym
Posts: 5
I agree. Not many people would have ALL the skills and knowledge needed to build a perfect cockpit, but I am learning more each step of the way, so, maybe in a few years and a few more builds.....who knows. :)

Having the forum available with knowledgeable people really helps builders like me who sometimes just needs to 'fill in the gaps'. Definitely helped me!

Many Thanks again.:thumbup:
2020-07-15 14:11
icon