FSUIPC5 - LINDA Interface Changes

[Scotfleiger]

Hi Pete

You will know that LINDA is built around FSUIPC4 and I have been doing some compile tests in 64-bit. The only issues/compile errors are in the code and data structures used to interface with FSUIPC. The main issue I have is with the DWORD usage - it does not appear to copy across to 64-bit in Delphi Pascal. 

 

64-bit key types of concern are:

 

Type

  FS6IPC_READSTATEDATA_HDR = packed record

    dwId     : dword;

    dwOffset : dword;

    nBytes   : dword;

    pDest    : pointer;

  end;

  FS6IPC_WRITESTATEDATA_HDR = packed record

    dwId     : dword;

    dwOffset : dword;

    nBytes   : dword;

  end;

 

Are there are changes to the FSUIPC5 external program interface data structure? LINDA will also need the full licenced version of FSUIPC5 once the ordering system is up and running. 

[Pete Dowson]

2 minutes ago, Scotfleiger said:

You will know that LINDA is built around FSUIPC4 and I have been doing some compile tests in 64-bit. The only issues/compile errors are in the code and data structures used to interface with FSUIPC.

Why do you want to convert LINDA to 64 bit? Does it have modules (other than Lua plug-ins) which run inside P3Dv4? External processes can remain 32-bit.

4 minutes ago, Scotfleiger said:

The main issue I have is with the DWORD usage - it does not appear to copy across to 64-bit in Delphi Pascal. 

 

64-bit key types of concern are:

 

Type

  FS6IPC_READSTATEDATA_HDR = packed record

    dwId     : dword;

    dwOffset : dword;

    nBytes   : dword;

    pDest    : pointer;

  end;

  FS6IPC_WRITESTATEDATA_HDR = packed record

    dwId     : dword;

    dwOffset : dword;

    nBytes   : dword;

  end;

 

Are there are changes to the FSUIPC5 external program interface data structure?

No! The external interface has to be the same. DWORDs are 32 bits, and the pointer is used only locally to the calling program so it doean't matter to FSUIPC. It is a pointer for the linked LIB (if this is used) to use to store the data when it is returned. It doesn't feature in the interchange. It would be a 64-bit pointer if you recompile the LIB to 64-bit for a 64-bit program. but why bother?

Try my existing TraficLook and WeatherSet programs, which just use the standard FSUIPC SDK-provided data. There's no 64-bit version of the SDK. I don't think it is needed. There's no reason for most utilities to move to 64 bit.

Pete

[Scotfleiger]

Thank you Pete. If it is not necessary I would prefer to leave LINDA in 32-bit. I won't be able to test it until I can register my copy of FSUIPC5 and get the full functionality. Could you email me a test registration? You should have my email. 

[Scotfleiger]

Hi Pete

After a weekend of fighting with 32-bit and 64-bit pointer to allow LINDA to connect to and communicate with FSUIPC5 5.10, the light is beginning to appear at the end of the tunnel. There appears to be a timing difference between the SDK/Delphi FPUser.pas FSUIPC_Open() function with FSX and P3Dv3.4 (using FSUIPC4) compared to P3Dv4 and FSUIPC5. Using the demo form supplied in the FSUIPC SDK I can now access FSUIPC offsets (sim version, FSUIPC version and time) for P3Dv4/FSUIPC5 with a 32-bit LINDA application.

Once I determine how to overcome the timing issues, I will let you know.

For your ToDo list to update the Offsets PDF. The $3308 offset value for P3Dv4 is 12. P3Dv3.4 is 10. Do you know what happened to 11?

[Pete Dowson]

9 minutes ago, Scotfleiger said:

After a weekend of fighting with 32-bit and 64-bit pointer to allow LINDA to connect to and communicate with FSUIPC5 5.10

I'm not sure I understand. What do you need 64-bit for? Are you converting LINDA EXE to 64-bit? Why?

10 minutes ago, Scotfleiger said:

The $3308 offset value for P3Dv4 is 12. P3Dv3.4 is 10. Do you know what happened to 11?

I think 11 was earmarked for the 64-bit version of FSX-SE, which I suppose is now FSW. But I don't recall offhand. I'm not planning to look at FSW yet, if at all. We'll see how it pans out.

Pete

 

 

[Scotfleiger]

As you rightly stated 32-bit apps will work fine. However, when I could not get LINDA to talk to FSUIPC5 due to the timing differences I did experiment (and stretched my knowledge) with a 64-bit build. I will send you the revised FPUser code when I have a working solution. 

[Pete Dowson]

4 minutes ago, Scotfleiger said:

when I could not get LINDA to talk to FSUIPC5 due to the timing differences

This, I don't understand. Why would timing differences affect talking to FSUIPC? There's always been "timing differences" in the Inter-Process Communications. Different versions of FSUIPC3/4, different loads on FS, different loads on the PC itself. How could "timing differences" stop the interface working for you?

Is it more related to the Lua plug-ins than the IPC interface?

Pete

 

[Scotfleiger]

Pete

I just got the SDK routines to communicate with FSUIPC5 late last night. I will spend time today investigating why. It appears that the interface is taking much longer to initially connect than previously. Unfortunately my development system runs on my Mac/Win10 emulator and my P3Dv4 on my Win10 PC so I can't use the debug tools. I will update you later. 

[Scotfleiger]

Hi Pete

I now have LINDA working with FSUIPC4 and FSUIPC5 as a 32-bit application. I take back my previous comment on timing issues. My problem lay with the renaming of the FSUIPC5 file (fsuipc5.ini, .log and .dll) as these are checked and/or accessed during LINDA operation. The SDK files are essential unchanged.

I am getting a Exception 20 "DATA ERROR" writing or reading to some AP offsets (see linked log). All these offset are 4 bytes long (0804, 0810, 07C8, 07C4, 07DC, 07D0, 07EC & 0800). It is high highly a programming error on my part, but what is an Exception 20 "DATA ERROR"?

Finally, my user community would like to see the VRi serial handling added back as soon as convenient. LINDA was written specifically to handle the VRi Combo MCP panels before it was expanded into a general HID device handler.

Thank you for all your work in generating FSUIPC5.

FSUIPC5.log

[Pete Dowson]

1 hour ago, Scotfleiger said:

I am getting a Exception 20 "DATA ERROR" writing or reading to some AP offsets (see linked log). All these offset are 4 bytes long (0804, 0810, 07C8, 07C4, 07DC, 07D0, 07EC & 0800). It is high highly a programming error on my part, but what is an Exception 20 "DATA ERROR"?

FSUIPC merely relays the error number it receives and the description from the SimConnect SDK. I'm not sure why you are getting those. Are they definitely with an aircraft which features and autopilot with those features?

The more important matter is whether those offsets are actually working for you. Maybe P3D in their infinite wisdom have not enabled those SimVars for writing as they were before. If so I'd have to intercept them and send the approriate Events (controls) instead, aaa much messier proposition.

1 hour ago, Scotfleiger said:

Finally, my user community would like to see the VRi serial handling added back as soon as convenient.

Of ourse. All the missing bits were targetted to be completed before the end of the week, but there has been a deluge of problems which I'd not really expected. I must resolve problems before dealing with facilities. Keep tabs on the release notice. I'd like to get it done.

Pete

 

[Scotfleiger]

Hi Pete

Thank you for the steer on SimConnect SDK error reporting. I am using the normal offsets (writing 4 bytes with 1 or 0 in first byte) to control the default P3Dv4 B58 autopilot using the Saitek Multi Panel. These calls control the aircraft AP until the Exception 20 occurs. After that the AP fails to work and the sequence of 8 Data Error repeat on each button press/offset call. 

I have tested the same operations with P3Dv3.4, FSUIPC4 4.966 and my latest LINDA build and the errors do not occur.

I will investigate what I am sending and report further.

[Pete Dowson]

4 minutes ago, Scotfleiger said:

These calls control the aircraft AP until the Exception 20 occurs.

Are you saying they actually work (i.e. cange the actual AP) till then?

I'm checking. Looks like those have never been directly writeable. Seems a flag s being lost or not tested correctly. It will be fixed.

Pete

 

[Scotfleiger]

Yes. The buttons as programmed control the AP fine until the error occurs. The fault appears to be triggered when I turn the knob to change the alt/hdg/crs but not all the time. Perhaps I am calling too quickly. I am testing further to find the trigger. 

[Scotfleiger]

I have been able to reproduce the fault condition. The fault condition can only be cleared by closing and reopening P3Dv4. Using offset 0x07CC (2 bytes) to change the Heading while monitoring the Offset value using LINDA Tracer, I was able to trigger the Exception 20 DATA ERROR after exactly 19 offset writes. The Pascal function used:

function setHDGvalue(hdg: integer): boolean;
   var
      val: array [0 .. 1] of byte;
      dwResult: DWORD;
      v: single;
   begin
      v := round(hdg * 65536 / 360);
      val[1] := trunc(v / 256);
      val[0] := round(v - (val[1] * 256));
      FSUIPC_Write($07CC, 2, @val, dwResult);
      FSUIPC_Process(dwResult);
      result := true;
   end; // setHDGvalue

You can see the Offset values changing if you search for "[INIT] Ready to go, Captain!" in these log files.

FSUIPC5.log2

FSUIPC5/log3

Sorry to add to you to-do list.

 

[Pete Dowson]

2 hours ago, Scotfleiger said:

Sorry to add to you to-do list.

It's something odd with SimConnect. The easiest solution for me to to mark those values as non-writable. This will automatically make it revert to the Event / control method.

Pete

 

[Scotfleiger]

Thanks Pete. I would not like to lose the ability to write data to offsets. I thought I was write data too fast but in the test I sent I was turning the knob slowly one step at a time. Data is only written when the value changes. Would the speed of reading an offset cause the problem? The code is called at 20Hz (50ms).

[Pete Dowson]

33 minutes ago, Scotfleiger said:

Data is only written when the value changes. Would the speed of reading an offset cause the problem?

No, it is something to do with the classification of which SimVars are writeable. I'm looking at it today. Im currently not sure whether it is an error in my conversion to 64-bit, or a problem in P3d4.

There are several other non-LINDA reports now of similar problems from other programs using the offsets for switches.

Pete

 

[Scotfleiger]

I have isolated the trigger for the reported DATA ERROR report. I was updating the AP values one-after-the-other every 50ms. The offsets are AP 07BC, HDG 07C4, NAV 07DC, SPD 07DC, ALT 07D0, VS 07EC, APR 0800 & REV 0804. Commenting out the offsets writes eliminated the problem.

I will look at reducing the number/frequency of calls and report back.

[Pete Dowson]

1 hour ago, Scotfleiger said:

Commenting out the offsets writes eliminated the problem.

Well, naturally, because no attempts would be made to write the variables if the offsets were not written.

1 hour ago, Scotfleiger said:

The offsets are AP 07BC, HDG 07C4, NAV 07DC, SPD 07DC, ALT 07D0, VS 07EC, APR 0800 & REV 0804.

You have a couple of errors there: the documented ones are AP 07BC, HDG 07C8, NAV  07C4, SPD 07DC, ALT 07D0, VS 07EC, APR 0800 and REV (BC) 0804.

I'm a bit puzzled at present because the code inthis area is the same from FSUIPC3 and FSUIPC4, and those values aren't writeable directly withSimVars in either P3D3 or P3D4. There shouldn't be any DATA ERROR for commands which should not be given -- FSUIPC has to use the Events (Controls) for them, and always has.

I'll get back to you.

Pete

 

[Scotfleiger]

You spotted my typo. The still an issue over time with writing to these offer even when the rate is reduced.

[Pete Dowson]

I've been testing writes to those offsets here. Each one does generate the correct event ("AP_MASTER" etc etc). I'm at a bit of a loss still understanding why it might then be trying to write the SimVars directly. It makes no sense.

Could you repeat a test on one or two of those offsets but first edit the FSUIPC5.INI, adding these lines to the [General] section:

Debug=Please
TestOptions=x10
LogEvents=Yes

and show me the resulting log, please.

Pete

 

 

[Scotfleiger]

I ran the test with the params your gave with a modified test build of LINDA (differs from original logs). I see a large number of Exception 20s before LINDA was up and running. The changes I have been trying delayed the triggering of the fault at the end of the log.

FSUIPC5.log

[Pete Dowson]

22 minutes ago, Scotfleiger said:

I see a large number of Exception 20s before LINDA was up and running.

Yes, this is because the TestOptions parameter added does a write test on all of the variables during FSUIPC initialisatin. Don't worry about those now, the info was for me.

   179406 *** EVENT: Cntrl= 65814 (0x00010116), Param= 0 (0x00000000) AP_APR_HOLD_OFF
   179406 *** EVENT: Cntrl= 65813 (0x00010115), Param= 0 (0x00000000) AP_LOC_HOLD_OFF
   179406 *** EVENT: Cntrl= 65811 (0x00010113), Param= 0 (0x00000000) AP_NAV1_HOLD_ON
   179406 SimWrite[145]: 0804="AUTOPILOT BACKCOURSE HOLD", DDef=00000007, Ref=3880, Size=4 [flt=0.000000, int=0, 0x00000000]
   179406 Exception 20 "DATA_ERROR", Ref 3880, Index param 1 on write SetData for "AUTOPILOT BACKCOURSE HOLD"
   179406 SimWrite[132]: 07D0="AUTOPILOT ALTITUDE LOCK", DDef=00000007, Ref=3881, Size=4 [flt=0.000000, int=0, 0x00000000]
   179406 Exception 20 "DATA_ERROR", Ref 3881, Index param 1 on write SetData for "AUTOPILOT ALTITUDE LOCK"

Something really strange is occurring. It is quite happily sending events for the assorted AP offsets you are writing, and then, suddenly, switches to the SimVar writing -- to non-writeable SimVars (as determined, in fact, by the initialisation test.

I now need to find out why this is occurring. Corruption of the tables in memory?  Nothing actually writes to those decode tables in my code, at least nothing programmed.

I think I'll have to write a Lua plug-in to do something like what you are doing. Writing ot, what, 8 or so AP switches up to 20 times per second? I don't suppose you have a simpe 9not needing LINDA) plug-in which can do that, and which gives the same symptoms on your System, have you? If not, it might speed things up if you could make one, test that it fails, then let me use it do I can debug the issue here.

Thanks,
Pete

 

 

[pcssundahl]

I think I've found the correct thread. If you have an apple device Pete I would be happy to give you a promo code to download any of my apps for free. The server to link the device with the pc is a download on my website. www.flightsimsystemsllc.com 

If it helps you test for a problem. 

[Pete Dowson]

14 minutes ago, pcssundahl said:

If you have an apple device Pete I would be happy to give you a promo code to download any of my apps for free.

Sorry, what sorts of "Apps"? Do you mean for an iPhone or iPad, or an Apple PC?

[LATER]
Thanks for the offer. I've looked at your website. What sort of 'problems' would they help me with? Sorry if I'm not seeing what you mean.

I assume those apps need an interface program on the FS PC. Talking to FSUIPC or SimConnect?

Pete