Paul Henty

Ruediger and others... I've just published 3.1.12 BETA of my DLL. Please use NuGet to update (make sure you tick 'Include prereleases'). Remember you'll also need FSUIPC v5.153b which John kindly posted above. No code changes are required in your project. The Read/Write LVAR methods should now just work with larger LVAR names. I can't test this as I don't have P3D so please let me know how it goes. Thanks, Paul

All understood. Thanks. Paul

Thanks John, Can you please confirm a few things before I implement the changes to my DLL: 1. 0x0D70 is now 128 bytes long, meaning LVARS up to 128 characters can be requested. 2. It is not safe to write 128 bytes here in FSUIPC4 and 3 so I'll need to check the FSUIPC version in my DLL. 3. Normally these strings are Zero terminated. Is a 0 required at the end if the string is the exact length of the offset. e.g. Can I send 40 characters to a 40-long string offset, or is it only 39 because the end 0 is required. Paul

This is referring to a function so I think it is only for setting the switch to the RAD position. I've had a look through the DLL but can't see any way to read the position of the switch. The only reading seems to be reading if LEDs are on or off. Paul

That's good. At least we know the hardware and Skalarki SDK are working. What about the C# project? With the breakpoint on the OnHardwareEvent() method, does it ever get executed or not? Paul

Hi Okan, You will need to find out if the button press is being recognised, and if so, if the key is being sent. In the code, find the OnHardwareEvent and put a breakpoint on the first line: switch (e.Source) Then run the program and press the hardware switch again. If the breakpoint is hit then it means the press is being captured which is good. You can then step through the code (F10) to see what happens after that. It should go to the line that sends the key press. If not, you can probably see where the problem is. If the breakpoint is not hit then if means that the Skalarki SDK is not picking it up. We'll need to look into it further, but first you can check with the Skalarki example application that your key press is being recognised there. You'll need to change the switches it's looking for though: Change the line: // Register an event var totalEvents = Switches.GLARE.All.Concat(Encoders.GLARE.All); To // Register an event var totalEvents = Switches.PEDESTAL.ACP1.All; When you get to the point where it says: you can press your hardware button and it should report that on the screen. Paul

Sorry for the delay - I've been on holiday. The DLL uses 40 characters for the LVAR name (offset 0D70 says 40 bytes in the FSUIPC4 Offsets list). If this offset is now 64 then I can modify the length of my internal offset and it should be okay. If Pete or John can confirm this is correct I'll make the changes and release a new version to NuGet. Paul

The hardware connection status is reported whenever the connection state changes. The event called 'eventClient_ConnectionStateChanged' is fired. The event arguments (e.Connected) tells you if it's connected or not. I suggest you try the c# example included in the SDK. Make a new C# Console Application project add the Skalarki DLLs as references copy the code over from: C:\Program Files (x86)\SkalarkiIO Profiler 5.1\SDK\Samples\Program.cs See if you can get that to connect. Paul

Hi Okan, I have written a C# application which I think does what you want. I can't test it because I don't have the hardware. If you're a beginner at C# this is a very difficult first project. 1. Download and extract the attached C# project. Then open it in Visual Studio. 2. You will need to install my FSUIPC DLL into the project. Go here for instruction on how to do this: http://fsuipc.paulhenty.com/#help Under "Quick Installation Guide" see the instructions for "Installing the Library into an Existing Project". There is a video link if you prefer. 3. You will also need to add a 'reference' to the Skalarki SDK DLLs. In the Solution Explorer pane, right-click the node called 'References' and then select 'Add Reference...' Click the 'Browse' button at the bottom of the form. Navigate to where the Skalarki SDK is installed on your machine and add the two DLLs called: SkalarkiIO.SDK.dll SkalarkiIO.SDK.Telemetry.dll On my machine they are here: C:\Program Files (x86)\SkalarkiIO Profiler 5.1\SDK 4. The project should now compile and run. The status bar will show if the application is connected to FSUIPC and your hardware. When both are connected you should be able to press the INTRAD button and the application will send F12 to the FlightSim. I don't know if I've got the Skalarki DLL code correct. I've no way of testing it and the documentation is quite sparse. You may need to get further help from their support. The FSUIPC part is good though. Let me know how it goes. PaulSkalarkiFSUIPCExample.zip

Hi Okan, I'm away today, but I'll look at this for you tomorrow. Paul

Yes you can. There isn't an easy helper method in the DLL, but it's just a matter of writing a string to 0x0D70. See the offsets list (FSUIPC4/5 Offsets Status.pdf) for the details of what to write. As this is a write-only offset, I recommend declaring the offset as write-only and placing it in it's own group. Then you can process just that group. Something like this: private Offset<string> macroRequest = new Offset<string>("macro", 0x0D70, 40, true); private void fireMacro(string macroRequestString) { this.macroRequest.Value = macroRequestString; FSUIPCConnection.Process("macro"); } Paul

The full COM1 frequency is available at offset 0x05C4 in FSUIPC5 (see the documentation for the details). Only 2 decimals are available in FSUIPC4 and earlier (0x034E). If you are using my .NET Client DLL and using the FsFrequencyCOM helper class, this is only applicable to the older BCD offsets (e.g. 0x034E). Just use 0x05C4 instead by declaring a normal <int> offset. Paul

Hi Frans, You'll need to repost this in the main FSUIPC support forum. This is a subforum for programming issues. Your post might not be seen here by anyone who can help you. Main FSUIPC Support Forum is here: https://forum.simflight.com/forum/30-fsuipc-support-pete-dowson-modules/ Paul

Which timer are you using? Is it System.Timers.Timer? If so then I think the problem is that by running this code every 10ms you'll end up with multiple copies of FSUIPCProcess() being run in parallel on different threads. This is the only thing I can think of that will cause this problem. On my machine Open() takes over 100ms to run. So your timer will be starting about 10 threads all calling Open() before the first one finishes. Each thread will be creating, processing and then deleting the ~systemoffsets~ group. So one thread will be trying to process this group but another has just deleted it. If this is the case then here are some solutions: 1. Use a different timer when the connection is not open that uses a more realistic interval (e.g. 250ms) - or modify the tick interval of your existing timer. 2. If you are using WinForms and don't need your FSUIPCProcess() method running on a background thread you can use the Forms timer which will block each tick until the code on the previous tick has run completely. This will also block your UI though. 3. If you don't mind the timer not ticking at exactly 10ms you can set the timer to 'one-shot' mode with: MyTimer.AutoReset = False when you create it. Then at the end of your FSUIPCProcess() method you can restart the timer and get another tick: MyTimer.Start() I hope one of those helps... Paul

Thanks for the report. I've checked here on version 3.1.11 and I can't see this exception being thrown. If you have any more info e.g. how/when you see this exception, full stack trace, I can look into it a bit more if you like. Paul

Hi, Here's what I can tell you from the stack trace: The main error is that FSUIPCConnection.Process() has been called for the default group (no group name), however at the time it was called, no offsets have been created yet (at least not in the default group) so that group does not exist. The origin of the call is an event being fired called InputChangeStateEvent on the SkalarkiIOProfiler.Profile class. This calls JEEHELLAirbus.JLFMGS.ExecuteFunction() which calls your FSUIPC wrapper. If this problem only occurs on one PC then it's likely a timing issue (especially likely if your application is multi-threaded). Something on that machine is causing the _InputChangeStateEvent event to be fired before the offsets are created. You'll need to think about what triggers the InputChangeStateEvent and why it might be firing early on that machine. However, it could just be a tread timing issue (is the bad PC super fast or super slow?) in which case you'll need some kind of synchronisation/delay code that guarantees things are created in the correct and started order. Hopefully that points you in the right direction. If you need more help I'll need to see the relevant parts of the code. Paul

Hi Ruediger, I assume you are using the FSUIPCConnection.ReadLVar() method. Unfortunately this doesn't work over WideFS. WideClient is sending your application a cached value, without waiting for the real value to arrive from FSUIPC. This is because of the way this feature is implemented in FSUIPC. There is a workaround I can try but it will make each LVAR read at least three times slower. They are not fast at the moment so I suspect slowing them down by three will make it unusable. If you're only reading a few LVARs and not very frequently then I can add a new method for reading LVARs over WideFS if you want to try it. Paul

Hi George, Apologies for the delay in replying. The reason it won't show after the first time is that the values of the offsets have not changed since the first time Process() was called. The DLL will not write normal offsets unless their values change. To solution is to mark the offsets as 'Write-Only'. These type of offsets will be written every time Process() is called, even if the offsets values have not been changed. The messaging offsets are a good example of write-only offsets. You would never have to read value from them. Because they are written on every process, you should also put them in their own group so that you can control exactly when they are written. (You process that group only). Here are the offset declarations, placing them in their own group called 'message' and marking them as write-only: (Last parameter is set to true). private Offset<string> messageWrite = new Offset<string>("message", 0x3380, 128, true); private Offset<short> messageDuration = new Offset<short>("message", 0x32FA, true); Here is the code for writing. It's the same except we are now processing the specific group. string Message = "my message test"; this.messageWrite.Value = Message; this.messageDuration.Value = 2; FSUIPCConnection.Process("message"); Paul

Hi MR, Lua questions should really be posted in the main support forum. This sub-forum is for programming with .NET languages. However, looking at the documentation, event.sim doesn't fire when the sim loads. Only on CLOSE, FLIGHTLOAD, FLIGHTSAVE and AIRCRAFTCHANGE. You can run a LUA script when the sim has finished loading and is ready to fly by naming your LUA file 'ipcready.lua'. That might be useful to you. I'm not an expert on LUA so if you need more help please ask in the main forum. Kind Regards, Paul

Hi Emerson, The C# code looks fine and it sound like you are getting sensible values from FSUIPC. (I think you made a mistake here though (in red) as the the number should change from 2 to 5 degrees) >> When I set flaps 2, flaps value == 4096 and servo moves 90 degrees approximately. Then I set flpas == 5 and and txt.flaps value == 4096 a Yes possibly. I don't know what values your servos need to make them move. At the moment you are just sending the raw flaps values. It would be a lucky coincidence if those were the same values the servo needs. It's likely that you will need to do some maths to translate the flaps value into the correct range for the servo. If you can explain to me what values are needed to make the servo move I can help with that. Paul

As Pete suspected, my DLL only implements the external FSUIPC interface, not the internal (gauge) one. The DLL is aimed at people who want to use .NET instead of C or C++. Since a gauge can only be written in C/C++, I didn't see any point in implementing the internal interface for .NET. Paul

Yes, the checking for changing values has also changed. Before it was sometimes writing when it shouldn't and causing problems for some users. Now it compares the current and previous values so you can't write the same value twice with a read/write offset. If you need to do that you should be using a write-only offset in a named group. The SendControlToFS() is easier to use than manually writing to those offsets. The DLL uses those offsets behind the scenes anyway so it's not really any different. I've no plans to publish the source code at the moment. Paul

Hi Sebastian, The main change was that offsets marked as write-only now write every time you process them, even if you haven't set a new value. It sounds like your offsets for sending the events/controls were marked as Write-Only. I had to change this because for some offsets you need to set the same value as before. The DLL didn't see this as a change in value so the offset didn't get written the second time. There were also problems if you wanted to write a 0 as the first value. Because the initial value is 0 you couldn't write a 0 as the first value. With the new behaviour, you need to put write-only offsets into a named group and only process them when you need to send the new values to the sim. Offsets the are not marked as Write-Only work the same as before. They read unless you've set a new value; then they will write. Paul

Those new offsets in FSUIPC5 won't work with the FsFrequencyCOM class. The documentation says that the new offsets store the frequency in Hz rather than the old BCD format. So you just need to read the offset as a normal Int and divide by 1,000,000 to get the frequency in the more common Mhz units. The frequency helper classes was added to help people with encoding and decoding to/from the old BCD format. Because the new offsets are not in BCD I can't really add support for them in the same class in a way that makes sense. The new format is very easy to use now so there really isn't a need for the helper class any more. Paul

Further to Pete's reply, the DLL facility is just a wrapper over the joystick scanning facility in FSUIPC provided at offset 0x2910. As Pete says, this can only read real Joysticks 0-15. I can see offset 0x3340 deals with Virtual joysticks but there is no wrapper in the DLL for this. You'll need to access this offset directly. I recommend declaring an offset of type BitArray (4 bytes) for each Joystick. Then you can directly access each bit (button) as being 'true' or 'false' without needing to do bitwise masking. Each joystick will be at increments of 4 from the base offset of 3340. e.g. 3340, 3344, 3348, 334C etc... Paul