Board index FlightGear Development Aircraft Systems

2 Questions: vacuum & electrical  Topic is solved

Modeling aircraft systems, like electrical stuff, hydraulics, pneumatics? Feel free to ask support.

2 Questions: vacuum & electrical

Postby El Flauta » Thu Feb 02, 2012 9:16 am

Hello again. I have 2 questions, about 2 systems:

1.- Vacuum system:
I developed an Attitude Indicator for a two-engine piston aircraft (Cessna 337 Skymaster), and it works nice. However, the instrument only works with the suction of the front engine... while the original one works with suction provided from any engine (front or rear engine).

How can i get suction from any engine?


2.- Electrical system:
The aircraft has an electrical system, taking info from the FlightGear wiki and modifying the generic electrical system. It has all its sources, connections and outputs working... but it has a rare behavior: when I switch the batteries or alternators off, the busses still with current & volts. The same thing happens with the avionic bus: when the switch is turned off, the bus and all its outputs still with volts and current.

How can i to "discharge" the electrial busses and outputs, when i switch OFF the sources?
Vive FlightGear! Have you a Ñ on your keyboard? Spain-LatinAmerica FlightGear community!
--
PZL M18B Dromader
CASA C-101 Aviojet
Cessna 337G Skymaster
User avatar
El Flauta
 
Posts: 426
Joined: Fri Mar 14, 2008 1:09 am
Location: SCVM, Chile
Callsign: CC-FLT
Version: 3
OS: Windows 7 SP1

Re: 2 Questions: vacuum & electrical

Postby jeep » Thu Feb 02, 2012 10:39 am

no answer for question 1

same problem with question 2 : now, i use bukaroo electrical system
jeep
 
Posts: 73
Joined: Mon Feb 14, 2011 10:37 am

Re: 2 Questions: vacuum & electrical  

Postby Torsten » Thu Feb 02, 2012 11:29 am

In your aircraft's system.xml, you need two vaccum systems:
Code: Select all
<vacuum>
  <name>vacuum</name>
  <number>0</number>
  <rpm>engines/engine[0]/rpm</rpm>
  <scale>1.0</scale>
 </vacuum>
 <vacuum>
  <name>vacuum</name>
  <number>1</number>
  <rpm>engines/engine[1]/rpm</rpm>
  <scale>1.0</scale>
 </vacuum>


This creates the properties simulating two vaccum pumps
/systems/vacuum[0]/suction-inhg
/systems/vacuum[1]/suction-inhg

Now you need to combine these two pipes into one system, probably by using the pump with the greater vaccum provided. This should be calculated in each frame and can be done in Nasal or by using a property rule:
Code: Select all
<filter>
  <name>Suction indicator</name>
  <type>gain</type>
  <gain>1</gain>
<input>
  <expression>
  <max>
  <property>/systems/vacuum[0]/suction-inhg</property>
  <property>/systems/vacuum[1]/suction-inhg</property>
  </max>
  </expression>
  </input>
  <output>/instrumentation/vacuum/suction-inhg</output>
  </filter>

Which in plain word does "get the maximum value of the suction of both vaccum systems and write that value to /instrumentation/vacuum/suction-inhg.

The code snippets are from the SenecaII.

Torsten
flightgear.org - where development happens.
User avatar
Torsten
 
Posts: 648
Joined: Fri Feb 01, 2008 10:22 pm
Location: near Hamburg, Germany
Callsign: offline
Version: next
OS: Linux

Re: 2 Questions: vacuum & electrical

Postby El Flauta » Thu Feb 02, 2012 11:34 am

Ok... i have the two vacuum systems. I'll try in afternoon :) Where i should put these <filter> codes?
You told me about Nasal, but your example haven't it... well, i'll search in afternoon. Thanks
Vive FlightGear! Have you a Ñ on your keyboard? Spain-LatinAmerica FlightGear community!
--
PZL M18B Dromader
CASA C-101 Aviojet
Cessna 337G Skymaster
User avatar
El Flauta
 
Posts: 426
Joined: Fri Mar 14, 2008 1:09 am
Location: SCVM, Chile
Callsign: CC-FLT
Version: 3
OS: Windows 7 SP1

Re: 2 Questions: vacuum & electrical

Postby Torsten » Thu Feb 02, 2012 10:08 pm

El Flauta wrote in Thu Feb 02, 2012 11:34 am:You told me about Nasal, but your example haven't it...

Right - because I consider an implementation in Nasal the second best option.
El Flauta wrote in Thu Feb 02, 2012 11:34 am:Where i should put these <filter> codes?

That's a well hidden secret feature called "property rule". These elements used to live within the autopilot configuration files only but they are so powerful, they can be used for computation of property values in many areas of the aircraft. Read more here: http://wiki.flightgear.org/Autopilot_Configuration_Reference and just replace the word "autopilot" by "property rule".

Hope this helps,

Torsten
flightgear.org - where development happens.
User avatar
Torsten
 
Posts: 648
Joined: Fri Feb 01, 2008 10:22 pm
Location: near Hamburg, Germany
Callsign: offline
Version: next
OS: Linux

Property rules

Postby Hooray » Thu Feb 02, 2012 10:29 pm

Right - because I consider an implementation in Nasal the second best option.


The XML autopilot system has probably become one of the most flexible and most powerful property-configurable systems in FlightGear (that is, directly after Nasal scripting) - I guess, it is fairly close to becoming "turing complete" one day ;-)
(that's exactly what happened to the C++ guys who ended up accidentally implementing a turing machine when they added meta-programming capabilities in the form of C++ templates)

The Nasal code for something like this would probably look similar to this (untested pseudo code):

Code: Select all
var max = func(x,y) (x>y)?x:y;
var prop_max = func(p1,p2) max( getprop(x) or 0.00, getprop(y) or 0.00 );

var update_inhg = func {
 var m = prop_max("/systems/vacuum[0]/suction-inhg","/systems/vacuum[1]/suction-inhg");
 setprop("/instrumentation/vacuum/suction-inhg",m);
}

settimer(update_inhg, 0);


I am not really arguing against XML, but obviously it is much more verbose. Without having tested this, I assume the XML code to be faster than the equivalent Nasal code, but Torsten can probably comment on this?

Personally, I could see many uses (beyond autopilots!) for these "property rules", especially if these configurations could be instantiated at run time, i.e. by having a Nasal script dynamically create such a property-driven controller.
That would provide many cool options actually, uses that would not be specific to the main aircraft anymore. We could in fact use XML autopilots to control AI traffic (flug's bombable). But property-driven pattern matching and filtering would also be useful in other scenarios, such as I/O using the generic protocol.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: 2 Questions: vacuum & electrical

Postby Torsten » Thu Feb 02, 2012 11:04 pm

I think, performance of Nasal code and XML based property rules is pretty close. The big advantage of the property rules is that they don't produce garbage that a garbage collector has to clean up. But as nothing in life comes for free (except FlightGear, of course) XML tends to be much more verbose - as you correctly stated.

My personal guideline for using one or the other system is:
  • Computing properties from a well defined set of other properties once per frame: use a property rule.
  • If there is no other way to get it done: use Nasal.

Torsten wrote in Thu Feb 02, 2012 10:08 pm:especially if these configurations could be instantiated at run time

Great minds think alike. I have recently committed some code to allow runtime loading of <strike>autopilots</strike> property rules and have a Nasal binding for that in mind. This _might_ end up in something like
Code: Select all
var myPid = pidController.new();
myPid.Td = 0.0001;
myPid.Ti = 123.4;
myPid.Kp = 0.2;
myPid.input = "/foo";
myPid.reference = "/bar";
myPid.output = "/baz";

etc, etc.

But that's probably a little off topic now.
flightgear.org - where development happens.
User avatar
Torsten
 
Posts: 648
Joined: Fri Feb 01, 2008 10:22 pm
Location: near Hamburg, Germany
Callsign: offline
Version: next
OS: Linux

Re: 2 Questions: vacuum & electrical

Postby Hooray » Thu Feb 02, 2012 11:11 pm

That's great news, but given that the autopilot system is already implementing SGPropertyChangeListener for its various "live" properties, wouldn't it be easier to simply watch the property tree, and directly instantiate the controllers using conventional setprop() calls, rather than implementing a full fledged Nasal interface?
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: 2 Questions: vacuum & electrical

Postby El Flauta » Fri Feb 03, 2012 3:49 am

Torsten wrote in Thu Feb 02, 2012 10:08 pm:That's a well hidden secret feature called "property rule"...

It works!!!

I have it working on Vacuum, Attitude and Heading indicators now. Thanks :)
Vive FlightGear! Have you a Ñ on your keyboard? Spain-LatinAmerica FlightGear community!
--
PZL M18B Dromader
CASA C-101 Aviojet
Cessna 337G Skymaster
User avatar
El Flauta
 
Posts: 426
Joined: Fri Mar 14, 2008 1:09 am
Location: SCVM, Chile
Callsign: CC-FLT
Version: 3
OS: Windows 7 SP1


Return to Systems

Who is online

Users browsing this forum: No registered users and 0 guests