Jump to content
The simFlight Network Forums

kiek

Members
  • Posts

    72
  • Joined

  • Last visited

Posts posted by kiek

  1. I'm trying to compile the UIPCHello.c that is on the FSUIPC C SDK, and after adding the library I get this error:

    LINK : fatal error LNK1104: cannot open file 'LIBC.lib'

    It looks like you forgot to add /NODEFAULTLIB:LIBC.lib to the Command Line options of the Linker in the Configuration Properties of your project...

    I don't think you need to compile a new .lib, at least I did not.

  2. Hi Lasse,

    I can see that you are not a SIOC programmer yet ;-)

    Here example SIOC code to display the GS needle and Localiser needle values -if alive- at four digit displays (most left digit blank or minus and then 3 digit value):

    You have to update the digit numbers to your hardware.

    Have not tested it but this is how you should do it in SIOC.



    Var 1 name gs_alive Link FSUIPC_IN Offset $0C4C Length 1
    {
    CALL &OUTGS
    }

    Var 2 name gs Link FSUIPC_IN Offset $0C49 Length 1
    {
    CALL &OUTGS
    }

    Var 3 name OUTGS LINK SUBRUTINE
    {
    IF &gs_alive = 1
    {
    &D_gs = &gs
    IF &gs < 0
    {
    D_gss = -999998 // minus sign
    }
    ELSE
    {
    D_gss = -999999 // blank
    }
    }
    ELSE
    {
    &D_gs = -999999 // blank
    &D_gss = -999999 // blank
    }
    }

    Var 4 name D_gs Link IOCARD_DISPLAY Digit 1 Numbers 3
    Var 5 name D_gss Link IOCARD_DISPLAY Digit 4 Numbers 1





    Var 10 name loc_tuned Link FSUIPC_IN Offset $0C4A Length 1
    {
    &loc_tuned_in = TESTBIT &loc_tuned 1
    }

    Var 11 name loc_tuned_in
    {
    CALL &OUTLOC

    }

    Var 12 name loc Link FSUIPC_IN Offset $0C48 Length 1
    {
    CALL &OUTLOC
    }

    Var 13 name OUTLOC LINK SUBRUTINE
    {
    IF &loc_tuned_in = 1
    {
    &D_LOC = &loc
    IF &loc < 0
    {
    D_locs = -999998 // minus sign
    }
    ELSE
    {
    D_locs = -999999 // blank
    }
    }
    ELSE
    {
    &D_loc = -999999 // blank
    &D_locs = -999999 // blank
    }
    }

    Var 14 name D_loc Link IOCARD_DISPLAY Digit 5 Numbers 3
    Var 15 name D_locs Link IOCARD_DISPLAY Digit 8 Numbers 1
    [/CODE]

    regards,

    Nico

  3. at the same time I'm more and more believing that a solution based on FSUIPC4 offsets and LUA scripting will be much

    easer to implement, but then I need the NGX SDK variables to be connected to FSUIPC4 offsets.

    I don't think so Roar. The best way forward for SIOC users would be a lekseecon like solution, meaning a direct connection between the SIOC Server and the SDK. No involvement of FSUIPC. With the lekseecon solution the user only has to deal with SIOC variables, not with FSUIPC offsets and not with lua scripts.

  4. extradition from the UK to the USA to sit in a prison for two years awaiting trial, as happened recently to another poor old man like me, just isn't something I would look forward to!

    You are right Pete. I've seen that poor man on television, arriving at Heathrow airport, leaving his wife behind...

    I hope these lawyers understand what FSUIPC is all about, it's rather technical stuff ... ;-)

  5. I have been visiting the support site and checking whether there's a reply yet regularly. I didn't know whether to expect an email or not. I have a short-cut taking me straight there, so I check it as often as i check my email.

    Still no joy.

    Regards

    Pete

    Pete,

    I guess that they have to consult their lawyers. This may take weeks ;-)

  6. Hi Dario,

    I know nothing of lua (not using it), but let me tell you (just for information) how my lekseecon (a C++ program) reads data from the NGX SDK via SimConnect.

    The simconnect interface is abstracted by a SimConnectClient object.That object takes care of opening and closing the connection to FSX, initialisation, and mapping the needed client events to simobjects (however, that part is out of scope her, I only detail reading now).

    Five times per second an object abstracting the SDK, calls a read on the SimconnectClient object. That object calls the simconnect callback procedure and it checks whether the NGX datastructure has changed. If so, it copies the whole structure to the same strucure into my lekseecon C++ program.

    Also 5 times per second a check operation on objects representing annunciators, values (like heading, altitude, course) in the end-user application is called. Every object has a 'const reference' (set at compile time) to that part in the NGX datastructure, within lekseecon, to which it needs to be checked. If there is a change in value it will send the new value to the end users application via an object abstracting the SIOC interface or an object abstracting the FSUIPC interface.

    In my lekseecon program for the Level-D 767 I do exactly the same (with the Level-D SDK). I have about 400 objects that poll the datastructure (within lekseecon!) 5 times per sond, but with the powerful cpu's we have these days that is no problem at all. Lekseecon is always below 0,00 % in the Task Manager.

  7. Sorry, I don't know Nico Kaan's interface?

    My lekseecon program http://www.lekseecon.nl/lekseecon.html. provides almost every control and state of the Level-D 767 via FSUIPC offsets (and, although out of scope here, SIOC variables).

    Use lekseecon_f.exe. The leksecon variables for controlling the Left and Right Fuel Switches (as ON/OFF switches) are 505 and 506, provided via FSUIPC offsets $91F9 and $91FA (1 byte each).

  8. Hi Gibbon ,

    Here some tutorials how to read, write and read/write from/to FSUIPC offsets from SIOC:

    http://www.lekseecon...html#readFSUIPC

    http://www.lekseecon...tml#writeFSUIPC

    http://www.lekseecon...readwriteFSUIPC

    And study the list of FSUIPC offsets (inthe FSUIPC SDK) carefully...

    And do note that you cannot be sure that an aircraft add-on supports the published FSUIPC offsets.

  9. Hi Pete/Rob,

    Here are the definitions of the lekseecon read/write variables for the Level-D MCP. These variables are available at the 4 bytes offsets posted before.

    Note that these variables are not only used to send rotarie values to the Level-D but they also receive information from the Level-D, for instance in case you change a heading or altitude with the mouse in the panel, or to give the Speed a value when a speed window "opens" or the VS a value when the VS window "opens" (with opens I mean that it goes from blank to a value).

    So these variables can also be used to drive 7-segment displays in an MCP.

    296 Vrw MCP IAS/Mach, range 100 to 950 Note: Mach values are given x 1000, so .802=802

    297 Vrw MCP Heading in degrees, range 0 to 359

    298 Vrw MCP VS, range -9900 to 9900

    299 Vrw MCP Altitude in feet x100, range 0 to 640

    Using word controls in stead of dword controls might work for ALT, HDG and SPD. Maybe you have to make sure that the upper 16 bit of the offsets are 0 by changing these values in the panel with your mouse, before you start using your rotaries, then lekseecon will initialize these values.

    For VS it will not work i'm afraid. Lekseecon treats the 32 bit value as signed, not the 16 bit lower part.

    regards,

    Nico

  10. Hi Pete,

    I see, that's indeed the way forward, not via FSConfig, but with your powerful FSUIPC Offset controls.

    The lekseecon offsets can be found in the Lekseecon Manual, 0x8b18 for the IAS, 0x8b1c for the Hdg, 0x8b20 for the VS, and 0x8b24 for the Alt, all 4 bytes.

    (and do not forget to 'activate' lekseecon variables 296, 297, 298 and 299 in the CONFIG_FILE for lekseecon in FSUIPC Mode)

  11. Hi Pete (and Rob),

    Rob has to check the Manual of the GoFlights FSConfig software to find out how he can assign FSUIPC offsets to his rotaries. I do not know the RP48 but I doubt it will be possible to let the rotaries generate values between 0 and 359 for the MCP HDG offset. That's what my leksecon FSUIPC offset for MCP HDG requires...

    best regards,

    Nico Kaan

  12. Hi Fouad,

    ipc.clearbitsUB(0x905F, 0xFF) -- Clear the Lekseecon offset corresponding to AUTO

    And since this is my first 2 scripts please do comment on them as I believe there is alot of room for improvement.

    Good to read lekseecon 8.0 is useful.

    I know nothing of lua but i'd assume that it also has a clear byte command, or a setbyte to value 0? so you do not have to use clearbits.

    And also setting the value 1 in a byte should be possible with a command other than setting bit 1.. ipc.setByte(0x905f, 1) ?

    regards,

    Nico Kaan

  13. Hi,

    FYI, from one of the developers in the Level-D FSX Forum (only for licenced members):

    "The 767 for FSX has been reprogrammed to take advantage of the new SimConnect features. FSUIPC is now only used for the advanced fuel logic (fuel dump, scavenger pumps, apu fuel flow). It is likely that this logic will be also converted to SimConnect in our future products. In the meantime, if you want to desinstall FSUIPC you will only loose what is mentionned above."

  14. About GE, I think I saw Nico Kaan using Ground Enviroment with WideFS, that's why I asked.

    But surely it's a scenery enhancer. How is it going to enhance scenery from a different PC? I really don't know how it can be used with WideFS -- if you know more please let me know.

    Indeed. It does so via shared directories over the LAN directly, and not via WideFS ...

  15. I hope this hasn't been answered before, I tried searching, but couldn't find it...

    I am building a cockpit and using fsuipc to control my switches. As far as i can tell, there is only a toggle for the fuel pump switches. Is this corrrect?

    No, that depends on the aircraft.

    For the Level-D 767 there are on/off commands for the Fuel Pumps as offstes in FSUIPC (at 0x8B22). They are provided by the Level-D SDK and my FSCONV program (for free).

  16. Meaning you use all 121 bytes, every one is important?

    Yes! These offsets are FSCONV offsets. They represent hardware switches. Note I'm only using your offsets as mailboxes, they are not 'real FSUIPC offsets' in the sense that they represent something in FS9. So what you're saying about differences in processing needed to obtain values is not relevant here.

    I don't know how else to say the same thing each time! ;-)

    Much appreciated, but I want to be as precise as possible. We are both talking within our own 'mind sets'.

  17. Hi Pete,

    Thanks. Splitting up Reads is no option. I only read once and process (16 times a second).

    So I understand that calling after every 60 msec

    FSUIPC_Read(dwoffset, 128, pDest, &Res);

    FSUIPC_Process();

    is not faster then

    calling every 60 msec:

    FSUIPC_Read(dwoffset, 121, pDest, &Res);

    FSUIPC_Process();

    So it makes no sense enlarging my blocksize with dummies from 121 to 128.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.