Paul Henty

Hi Pete, A user of my DLL is having a problem reading back wind layers from 0xC400. I'm getting it too and think it could be a bug in FSUIPC4. If I create three wind layers and write as Global Weather: Layer: UpperAlt (metres): Knots 0 : 1000 : 10 1 : 2000 : 20 2 : 3000 : 30 Then read back weather using offset 0xC000 then it comes back fine. Exactly as I've written it. However if I read back using offset 0xC400 then is comes back like this: Layer: UpperAlt (metres): Knots 0 : 1000 : 10 1 : 1000 : 20 2 : 2000 : 30 That is, the wind speeds of the layers are correct, but the reported upper altitude is wrong. Layer 0 altitude is duplicated and then the subsequent altitudes are one layer behind. I've examined the raw bytes from the reads using the FSUIPC Logging and they are different. I can see the duplication in the 0xC400 (LastGlobal) read which makes me think it could be a bug in FSUIPC. Would you be able to take a look please? Thanks, Paul

It looks like that DLL was built against the 4.5 framework instead of 4.0. Correction attached. FSUIPCClient3.0_RC1.zip

Hi Ruediger, My apologies for this problem, there was a bug in some of the new 3.0 code. I've attached a new version of the DLL. The BitArrays should be working again. Paul

Hi Ruediger, The DLL decides whether to read or write an offset based on the value. If the current value is different than the previous value that was read, the DLL writes the new value. This error is generated when the DLL detects a change, but, that offset has never had a value read. I think this is the first time you are calling Process(), but before that you have set the value of some offsets. Make sure your first process() call is before you've changed any values. Maybe do this right after you call FSUIPCConnection.Open(). If you have offsets that you only want to write to, mark them as write-only. If you can't track it down I can give you a modified DLL that will tell you which offset is causing the problem. Just let me know what Framework version you want it built against. (2.0, 4.0, 4.5 etc). Paul

I attached the Beta instead of the RC1 version. I have to swap it. Should be there now - make sure you have the RC1 version. Paul

Hi Nuno, The connection handling in Version 2.4 isn't the best. If you attempt to connect but it fails, the DLL still thinks the connection is open. So when you try to open it again you get the error. The best way around this is to always close the connection if there are any errors during the open: try { FSUIPCConnection.Open(); } Catch (FSUIPCException ex) { FSUIPCConnection.Close(); MessageBox.Show(ex.Message); } Or a more ugly way is just to force a close() before open(): try { FSUIPCConnection.Close(); FSUIPCConnection.Open(); } Catch (FSUIPCException ex) { MessageBox.Show(ex.Message); } Calling Close() isn't a problem if the connection isn't open. This problem has been fixed for the next release 3.0. If the connection fails, the connection is not left 'open'. The connection is automatically closed if the connection is lost during Process(). There is also a new property FSUIPCConnection.IsConnectionOpen so your program can ask if the connection is good or not. I've attached the latest V3.0 RC1 here (built against the 4.5 framework) in case you want to try it. But, aggressive closing will work around the problems in 2.4. Paul FSUIPCClient3.0_RC1.zip

It was found that offset 0x0BFC (Flaps Handle Index) doesn't have the same filtering as 0x0DBC. This can be used to control the flaps instead. Paul

Thanks Pete, I've just tried this using the Flaps Handle offset at 0x0BFC instead and that doesn't have this problem. Maybe it's better to use that offset rather than disturbing your code for 0xODBC. I suggest that Paul (OP) swtiches to 0x0BFC. As far as I can tell he's just looking to raise the flaps so this would be sufficient. Dim flaps As Offset(Of Byte) = New FSUIPC.Offset(Of Byte)("FlapsControl", &H0BFC, True) 'Flaps Control Private Sub btnFlapsUp_Click(sender As Object, e As EventArgs) Handles btnFlapsUp.Click flaps.Value = 0 FSUIPCConnection.Process("FlapsControl") End Sub Private Sub btnFlapsDown_Click(sender As Object, e As EventArgs) Handles btnFlapsDown.Click flaps.Value = 1 FSUIPCConnection.Process("FlapsControl") End Sub Paul

Hi Pete, You may have seen one of my DLL users having problems sending values to 0BDC when the value written is same as the previous one. In his scenario his program is raising the flaps (sending 0) after the flaps have been put down via the keyboard/mouse. Because he's previously written 0 here to raise the flaps on a separate occasion FSUIPC seems to be ignoring the second 0 that he's sending. I've used the logging to confirm my DLL is sending the 'duplicate' 0. Is this the way that offset is designed to work? Thanks, Paul

Thomas: The dll doesn't check for changed values if the offset is write-only, it writes on every process. The problem does look like the DLL isn't writing when the value is the same, but it seems FSUIPC is doing this filtering. Paul: I've done some testing here and I get the same results as you. I've used the logging in FSUIPC to check the 0 is getting written by the DLL and it is. It seems that FSUIPC is ignoring values here where they are the same as the last value written. I don't know if that's be design or an oversight. I'll clarify with Pete in the main support forum. Currently you can work around this by sending two writes with close values so that FSUIPC sees changing values: Private Sub btnFlapsUp_Click(sender As System.Object, e As System.EventArgs) Handles btnFlapsUp.Click flaps.Value = 1 FSUIPCConnection.Process("FlapsControl") flaps.Value = 0 FSUIPCConnection.Process("FlapsControl") End Sub Private Sub btnFlapsDown_Click(sender As System.Object, e As System.EventArgs) Handles btnFlapsDown.Click flaps.Value = 8191 FSUIPCConnection.Process("FlapsControl") flaps.Value = 8192 FSUIPCConnection.Process("FlapsControl") End Sub Paul

The FSUIPC docs suggests that the reading of values from offset 0BDC is not always accurate. I suggest only using this offset for writing (declare it as Write-Only and in it's own group so you can control exactly when it gets sent): Dim flaps As Offset(Of Integer) = New FSUIPC.Offset(Of Integer)("FlapsControl", &HBDC, True) 'Flaps Control Then use another offset to determine the position of the flaps. Maybe 0BE0 or 0BFC (see docs). e.g. Dim flapsPos As Offset(Of Integer) = New FSUIPC.Offset(Of Integer)(&H0BE0) FSUIPCConnection.Process() If flapsPos.Value > 0 Then flaps.Value = 0 FSUIPCConnection.Process("FlapsControl") End If If you still have problems I'll probably need to see a bit more of your code; especially where your Process() calls are. Paul

No, the PMDG offsets are read-only, If you want to control the PMDG 737 from C# you need to send 'controls'. The available control numbers are listed in the PMDG SDK. Specifically, the C header file (it ends with .h). To send a control via FSUIPC see the FSUIPC documentation for offset 3110. In C# declare 2 write-only offsets in a group called "sendControl": private Offset<int> controlParam = new Offset<int>("sendControl", 0x3114, true); private Offset<int> sendControl = new Offset<int>("sendControl", 0x3110, true); // Must be declared AFTER 3114. Make a method you can call to send a control and parameter value: private static void SendControlToFS(int controlNumber, int parameterValue) { this.sendControl.Value = controlNumber; this.controlParam.Value = parameterValue; FSUIPCConnection.Process("sendControl"); } I don't have any PMDG aircraft so I can't really help with anything specific to the 737. From memory, I think some controls need a parameter value that represents a mouse button (e.g. Left, Right). These values are also in the .h file. You may have to experiment or ask on a PMDG forum. Paul

The encoding for this offset is Binary Coded Decimal which means you need to get the ToString() in hexadecimal, not decimal. If your transponder is showing 2406 then this offset will contain the value 9222. If you convert 9222 in to hexadecimal you get 0x2406 which is what you want. I've no idea why you are getting 4608. This is 0x1200. It might be that the aircraft you are testing on doesn't use the normal FSX transponder. Is it a 3rd party add-on? If so, try with a default FSX plane. This conversion should work: string Transponder = TransponderReq.Value.ToString("X4"); // X4 = Hex format padded to 4 characters Paul

As cknipe rightly says, using DecimalDegrees will let you format it however you like. Alternatively, you can also use the ToString() method. This will keep the padded three-digit degree number, and for longitude will also do E/W if you like. lat.ToString("d", 6) Where "d" means decimals only and 6 is the number of decimal places. lon.ToString(True, "d", 6) The "True" here means show E and W. If you set it to False you just get the plain number with - for west values. Paul

It does mention the order in the FSUIPC Offset Status pdf: For 3380: For 32FA: However, what isn't documented anywhere is that the DLL sends the requests in the order the offsets are declared. Most of the time the offset order doesn't matter so I didn't think to include it in my User Guide. Paul

I think there are two problems: 1. You've declared the message text offset (3380) after the control offset (32FA). This means the control will be sent before any text has been set. 2. You're declaring offsets inside the main timer loop. Offsets must only be declared at the class or form level. The way you have it now, you are creating two new offsets each time this code runs. You app will eventually crash when the FSUIPC memory file gets full. To solve these problems I suggest moving the declarations to the form or class level (see my sample application for where they should go if you're not sure), and reverse the order so the control offset is sent after the text is set: ' At the form/class level... Dim SimulationMessage As Offset(Of String) = New Offset(Of String)("SendMessage", &H3380, 128, True) ' Simulation Message Dim fsuipc_TextDelay As Offset(Of Short) = New FSUIPC.Offset(Of Short)("SendMessage", &H32FA, True) ' Inside my timer loop If SIMRate <> 256 Then Console.WriteLine("WARNING: SIM RATE IS AT " & SIMRate.ToString) SimulationRate.Value = 256 SimulationMessage.Value = "SimRate is locked to 1X speeds" fsuipc_TextDelay.Value = 5 FSUIPCConnection.Process("SendMessage") End If The order that you assign values to the offsets doesn't matter. You can set the text after setting the delay value. It's the order you declare (Dim) them that's important. If you declare any other offsets in the timer loop, or any other method, you must move them up to the form/class level as well. Paul

Hi Ruediger, There was a deliberate delay of 200ms built into the SendControlToFS() method. I don't remember why I added it and I can't see any reason for it to be there now. I've attached a new version with the delay removed. That should speed things up a bit :smile: Thanks for reporting this. Paul FSUIPCClient3.0_BETA.zip

Hi Noah, Error #15 means the FSUIPC memory file is full. The reason it's full is that you're declaring the offsets in the method body. Each time you run the method a new offset is declared. This will quickly fill up the FSUIPC memory file. All offsets should be declared only once during the lifetime of your program. The best way of doing this is to declare offsets at the class or form level. e.g. private Offset<long> altitudereq = new Offset<long>(0x0570); private Offset<short> FPMreq = new Offset<short>(0x0842); private Offset<double> headingreq = new Offset<double>(0x0580); private Offset<int> airspeedreq = new Offset<int>(0x02B8); public double getAltitude() { try { FSUIPCConnection.Process(); } catch (FSUIPCException ex) { } double altitude = (double)altitudereq.Value * 3.28084D / (65536D * 65536D); altitude = Math.Round(altitude); return altitude; } public double getAirspeed() { try { FSUIPCConnection.Process(); } catch (FSUIPCException ex) { } double airspeed = (double)airspeedreq.Value / 128; airspeed = Math.Round(airspeed); return airspeed; } public double getHeading() { try { FSUIPCConnection.Process(); } catch (FSUIPCException ex) { } double heading = (double)headingreq.Value * 360 / (65536D * 65536D); heading = Math.Round(heading); return heading; } public double getFPM() { try { FSUIPCConnection.Process(); } catch (FSUIPCException ex) { } double FPM = (double)FPMreq.Value * 3.28084; FPM = Math.Round(FPM * -1); return FPM; } Paul

Hi Bodo, Reading the protocol it seems that the reference number at 4204 is also required: Try writing a number there as well (before 0x4200 of course). Paul

If you look at the top of this page, under the tabs, you can see a 'breadcrumb trail' of the forum hierarchy. At the end is the one you're in now: 'FSUIPC Client DLL for .NET'. The main support forum for FSUIPC is the one before that called 'FSUIPC Support Pete Dowson Modules'. Just click that and it'll take you to the correct place. You could repost there and someone might be able to help before Pete's return on 7th Feb. it's unlikely that anyone reading this sub forum will be able to help. Paul

You've posted in a sub-forum for .NET programming. In future please post general FSUIPC support questions to main forum. Pete will probably see it here when he gets back and move it. Or maybe a moderator could move it in the mean time if one happens to pass by... Paul

You've posted in a sub-forum for .NET programming. In future please post general FSUIPC support questions to main forum. Pete will probably see it here when he gets back and move it. Or maybe a moderator could move it in the mean time if one happens to pass by... Paul

You've posted in a sub-forum for .NET programming. In future please post general FSUIPC support questions to main forum. Pete will probably see it here when he gets back and move it. Or maybe a moderator could move it in the mean time if one happens to pass by... Paul

Great! Thanks for the feedback. Paul

I think this is probably a rounding error. The value is stored in the Flight Sim as Metres * 65536. Converting from feet may leave a tiny rounding error if there is not enough precision. So for example if you convert 800 feet to metres * 65536 (using your feet conversion above) you get: 15980298.24 But the .24 will be ignored as the offset is an integer. So converting back the integer part (15980298) you get 799.999988 not 800. You could mess with rounding functions but an easier trick is just to add 1 to the converted value to push the metre value up to the next 1/65536 of a metre. This should be enough to tip the rounding error to the 'other side'. For example adding one to 15980298.24 = 15980299.24, which is written as 15980299 to Flight Sim. Converting this back gives 800.000038 which is basically the value you are looking for. TL;DR - Probably a rounding issue: Try this: current = ((state*65536)/foot*100)+1 ipc.writeUD(0x07d4, current ) If that still gives some glitches when you test you can safely add 2 instead. BTW - You'll need to use the proper Feet conversion value in and out. Don't use 3! Paul