曝光台 注意防骗
网曝天猫店富美金盛家居专营店坑蒙拐骗欺诈消费者
the EPIC USB internal connectors in the same order you have them connected
physically. This simply means that the switch assigned to module 0, row 0, bit 0, is
assigned to a device/connector first and then the switch assigned to module 0, row
0, bit 1 is assigned. If you do this for your entire project, your physical and internal
EPIC USB connections will both be the same. On the other hand, if you assign your
physical devices to internal EPIC USB connectors in a random order, your final
EPIC module, row, bits values may not match your actual physical module, row, bits
values since they will all be relative.
4.3.2.4.4 For the advanced EPL users, here's another thought on connectors.
Different connectors can have the same analogs and module/row definitions as
other connectors; however, the end definition (the device level) of the actual switch
(Mod, row, bit) must be unique. This makes it easy to just use the same modrow
and analog definition for all of your connectors and not try and keep track of which
modrows are used with which connectors. Again, you just need to make sure you
only assign 8 devices per modrow across your connectors.
connector(Mod1)
{
30
analog(0);
modrow(0,1);
modrow(0,2);
modrow(0,3);
}
connector(Mod2)
{
analog(0);
modrow(0,1);
modrow(0,2);
modrow(0,3);
}
device(first)//
{
connector(Mod1);
button(1,6,Handoff);//assigned to Mod1 modrowbit (0,1,0)
}
device(second)//
{
connector(Mod2);
button(2,3,Handon); //assigned to Mod2 modrowbit (0,1,1)
In this example two connectors use the same definitions for the analogs and
modrows. Also shown are two device definitions using the connectors I defined.
Notice that the button definitions use the same modrow (0,1) because they are the
first ones defined and therefore are assigned to the first modrow in the connector
definition (0,1). The button definitions however use different connectors (Mod1 and
Mod2) and have different button row bit values. In the end, “Handoff” is assigned
internally to module 0, row 1, bit 0, while “Handon” is assigned internally to module
0, row 1, bit 1.
4.3.2.5 Assignment of hardware devices: devices.hpl
Rather than placing all of my EPL code in one file, I break it up into multiple files. I
use the “devices.hpl” file for all of my hardware device definitions. In this file I’ll
keep all of the definitions for all types of hardware on a given panel together.
Therefore, switches, lights, buzzers, motion control, etc. will all be defined together
so I know exactly where to go if something fails or doesn’t work properly. I also
separate these files by region of my cockpit, so I have a frontdevices.hpl,
leftdevices.hpl, and rightdevices.hpl. Here’s the example I used earlier showing
part of my Threat Warning Prime panel device definitions, this code appears in my
frontdevices.hpl file.
device(Threat_Warn_Prime)
{
connector(Mod1); // Switches on the Threat Warning Prime
button(4,6,Handoff);
31
button(4,5,Msl_Launch);
//the rest of my button definitions
output(Leds1,0,1) // Lights on the Threat Warning Prime
{
Handoff_Led = 0b00000001;
Msl_Launch_Led = 0b00000010;
Pri_Mode_Open_Led = 0b00000100;
// the rest of my output definitions
};
//Other devices could be added with the appropriate code
};
4.3.2.5 Assignment of procedures to hardware devices: procedures.hpl
I use the procedures.hpl file as a companion to the devices.hpl file; therefore, I have
a frontprocedures.hpl, leftprocedures.hpl and rightprocedures.hpl file in my EPIC
project. The procedures file is where I have the actual functions for EPIC to
execute based on a button action. Again, like my devices file, segmentation makes
it easier to manage my project. Below is an excerpt from my frontprocedures.hpl
file for the Threat Warning Prime panel.
//---------------Procedures for Threat Warning Prime----------
void Threat_Warn_Prime.Handoff.On(void){shifthit(PGDN);}
void Threat_Warn_Prime.Msl_Launch.On(void){keyhit(INS);}
void Threat_Warn_Prime.Pri_Mode_Open.On(void){shifthit(PGUP);}
4.3.2.6 Special procedures: Rotaries
In some software simulators not written to support a product like EPIC, virtual
switches may not behave like they would in the real world. In the Falcon4 virtual
aircraft, some 3-position switches will follow this sequence: position 1 to 2, to 3, to
1, to 2 and so on (i.e. it rolls over). In the real world, this switch would go from:
position 1 to 2, to 3, to 2, to 1 and so on (i.e. must reverse direction). To keep your
中国航空网 www.aero.cn
航空翻译 www.aviation.cn
本文链接地址：
航空资料18(9)
