Paul Henty

Hi Andrew, What version of the DLL are you using? (You can check the properties of the DLL in the windows explorer). Also can you confirm you are declaring the Offset variables at the Form (class) level and not in updateInfoTimerTick(). Paul

Thanks for the comments. I've decided that my DLL should really be getting global weather using 'GLOB' from the CC00 area. Even if C400 worked it would probably be the wrong thing as this is just the last weather written, not the current weather. Since CC00 is returning the correct values my user is happy now. Paul

Hi Pete, Here are the lines from the log with the weather logging turned on. This is my set global weather request with the three wind layers. 362953 WX Received in (0 mSecs), WX request type 1, ICAO=GLOB 363422 NW_GLOBAL command, setting weather to global mode 363687 NW_SET weather command received, ICAO=GLOB 363687 >NewSet: **** New Weather being set: ICAO=GLOB (Dyn=0) 363687 >NewSet: Pressure=1013.0, Drift=2.0 363687 >NewSet: Visibility[0]: range=62.1sm (100005m), from=-1460ft, to=8530ft 363687 >NewSet: Temperature[0]: alt=0ft, Day=14 C, NightVar=3 C, DewPt=4 C 363687 >NewSet: Surface wind: to alt=3280ft AMSL, dir=0T, vel=10.00, gust=0.0, turb=0, shear=0, var=0.0 363687 >NewSet: Wind layer 1: to alt=6560ft AMSL, dir=270T, vel=20.0, gust=0.0, turb=0, shear=0, var=0.0 363687 >NewSet: Wind layer 2: to alt=9840ft AMSL, dir=0T, vel=30.0, gust=0.0, turb=0, shear=0, var=0.0 363687 >NewSet: Cloud[0]: type=9, from 5700ft to 15700ft (+/- 400ft), cover=2, turb=2, topshape=0 363687 >NewSet: Precip=0, base=0ft, rate=0, icing=0 363687 >NewSet: Cloud[1]: type=1, from 39300ft to 40940ft (+/- 20ft), cover=6, turb=0, topshape=0 363687 >NewSet: Precip=0, base=0ft, rate=0, icing=0 363687 >NewSet: **** End of New Weather details for ICAO=GLOB 363687 Setting Weather: "GLOB 051136Z 00010KT&D1000NG 27020KT&A1000NG 00030KT&A2000NG 100KM&B-448&D3048 2CU057&CU100FMVN000N 6CI393&CI016FNVN000N 14/04&A0 Q1013 " 364094 >Change: Wind layer 1: to alt=6560ft, dir=270T, vel=20.0, gust=0.0, turb=0, shear=0, var=0.0 364094 >Change: Wind layer 2: to alt=9560ft, dir=0T, vel=30.0, gust=0.0, turb=0, shear=0, var=0.0 364094 Results: FS98 Wind1: 3280ft to 6560ft AMSL, dir=270T, vel 20, gust 0, turb 0 364094 Results: FS98 Wind2: 6560ft to 9560ft AMSL, dir=0T, vel 30, gust 0, turb 0 After that I get these two blocks repeating in the log until it's closed: (The plane is parked at EGJJ). 364094 Weather Received (type 5 request, Nearest): "EGJJ&A84 051134Z 00010KT&D1000NG 27030KT&A1916NG 00020KT&A2833NG 100KM&B-532&D3048 2CU054&CU004FMVN000N 6CI390&CI000FNVN000N 14/04 Q1013 @@@ 66 14 270 30 | 96 14 0 20 | " 364094 WX Received in (0 mSecs), WX request type 5, Lat=49.2070, Lon=-2.2066, Alt=0.0m 365109 Weather Read request (Global set) to area 1: ICAO="GLOB", Req=0 365109 Weather Received (type 1 request, (null)): "GLOB&A0 051136Z 00010KT&D1000NG 27020KT&A1000NG 00030KT&A2000NG 100KM&B-448&D3048 2CU057&CU010FMVN000N 6CI393&CI001FNVN000N 14/04 Q1013 @@@ 33 14 270 20 | 66 14 0 30 | " 365109 WX Received in (0 mSecs), WX request type 1, ICAO=GLOB For completeness, here are the results of the IPC Reads from the two weather areas: (Just up to the wind layers where you can see the problem in the second one from C400) 281641 0 ReadLocal: Offset=C000, Size=0400 00 00 00 00 00 00 00 00 47 4C 4F 42 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 51 00 C9 07 50 3F 00 00 28 0A 40 FE 46 18 00 00 01 00 00 00 00 00 0E 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 E8 03 0A 00 <- Layer 0 00 00 00 00 00 00 00 00 00 00 00 00 D0 07 14 00 <- Layer 1 00 00 00 C0 00 00 00 00 00 00 00 00 62 0B 1E 00 < - Layer 2 263937 0 ReadLocal: Offset=C400, Size=0400 00 00 00 00 00 00 00 00 47 4C 4F 42 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2C BD C8 07 50 3F 20 00 28 0A 40 FE 46 18 00 00 01 00 00 00 00 00 0E 00 03 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 E8 03 0A 00 <- Layer 0 - OK 00 00 00 00 00 00 00 00 00 00 00 00 E8 03 14 00 <- Layer 1 - Duplicate E8 03 00 00 00 C0 00 00 00 00 00 00 00 00 D0 07 1E 00 <- Layer 2 - Altitude from Layer 1 not 2 Paul

Reading the docs again I saw that you can get global weather from 0xCC00 using "GLOB" as the ICAO. This works fine. I could change my DLL to use this method for getting the global weather rather than 0xC400. Is the difference that C400 is what was last written and CC00 is the current state of the global weather which could be different because of dynamic weather? If that's the case I'm probably wrong to be using C400 in any case. Paul

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