Jump to content
The simFlight Network Forums

Paul Henty

Members
  • Content Count

    1,014
  • Joined

  • Days Won

    34

Paul Henty last won the day on June 3 2019

Paul Henty had the most liked content!

Community Reputation

52 Excellent

3 Followers

About Paul Henty

  • Rank
    Advanced Member
  • Birthday 01/01/1970

Profile Information

  • Gender
    Male
  • Location
    Gloucestershire, UK

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. Dear Expert,

    we are working on a 6 DOF motion simulator for FSX/ P3D. Actually we are new in this field so we are confuse in the selection of 6 offset values for our 6 stepper motors. We are using the paulhenty code to get the data from the FSX game and done it successfully. But the main confusion is which offset we will use to assign the rotation of motion for motion simulator? We were thinking to use " 3060, 3068, 3070" values for x y and z axis? but not sure on that. Can anyone of you help us in this regard. Your earlier response will be highly appreciable.

  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
×
×
  • 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.