Jump to content
The simFlight Network Forums

Recommended Posts

Posted

Hi,

Tying to send two consecutive events to the PMDB74x.  The events process, but the desired result in Sim is far from what I expect.

Code - processes the events from a FIFO queue (EventID & MouseID is Integers)

        Private Shared ReadOnly mySimEvent As New Offset(Of Integer)("SendControl", &H3110, True)
        Private Shared ReadOnly mySimParams As New Offset(Of Integer)("SendControl", &H3114, True)
        Private Shared ReadOnly myEventQueue As New Concurrent.ConcurrentQueue(Of SimEvents)
        Private Structure SimEvents
            Public EventID As Integer
            Public MouseID As Integer
        End Structure

<snip>
  
                    Do Until myEventQueue.IsEmpty ' no other Process() call is made elsewhere when this loop is called
                        Dim myEvent As SimEvents
                        myEventQueue.TryDequeue(myEvent)
                        mySimEvent.SetValue(myEvent.EventID)
                        mySimParams.SetValue(myEvent.MouseID)
                        SimLogger.Trace("Sending Control {0} with parameter {1}", myEvent.EventID, myEvent.MouseID)
                        FSUIPCConnection.Process("SendControl")
                        Thread.Sleep(1000) ' <- Time delay seems to be of no consequence
                    Loop


Debug Log:

2023-08-29 21:41:12.3958 TRACE FSInterfaces.FSServer.FSUIPCRunnerElapsed, Sending Control 79873 with parameter 536870912
2023-08-29 21:41:13.4351 TRACE FSInterfaces.FSServer.FSUIPCRunnerElapsed, Sending Control 69873 with parameter 536870912

 

Control 79873 (0x79873) is defined as EVT_OH_ELEC_GND_TESTS_GUARD in the PMDG_747QOTSII_SDK.h file (Mouse parameter is MOUSE_FLAG_LEFTSINGLE 0x20000000)

Control 69873 (0x110F1) is defined as EVT_OH_ELEC_GND_TESTS_SWITCH in the PMDG_747QOTSII_SDK.h file (Mouse parameter is MOUSE_FLAG_LEFTSINGLE 0x20000000)

I expect, the Guard to open on the switch, and the switch to be toggled.  However, the Guard seems to open and then close again.

I can call both of these controls independently (outside of the loop) successfully.

Is there something that needs to happen here to 'reset' the Send Controls?

Posted
Quote
        Private Shared ReadOnly mySimEvent As New Offset(Of Integer)("SendControl", &H3110, True)
        Private Shared ReadOnly mySimParams As New Offset(Of Integer)("SendControl", &H3114, True)

The order of these offsets matters. FSUIPC sends the control to the sim as soon as you write 3110. So that's before you've written the new parameter - the offsets are written in the order they are declared.

If you reverse the order of these two lines (declare 3114 first, then 3110) it should work as expected.

Paul

Posted
36 minutes ago, Paul Henty said:

The order of these offsets matters. FSUIPC sends the control to the sim as soon as you write 3110. So that's before you've written the new parameter - the offsets are written in the order they are declared.

If you reverse the order of these two lines (declare 3114 first, then 3110) it should work as expected.

Paul

Very useful to know, but it doesn't solve the issues.

Loop currently reads (simplified for debugging purposes):

                    ' Process any queued events
                    Do Until myEventQueue.IsEmpty
                        Dim mySimEvent As New Offset(Of Integer)("SendControl", &H3110, True)
                        Dim mySimEventParams As New Offset(Of Integer)("SendControl", &H3114, True)
                        Dim myEvent As SimEvents
                        myEventQueue.TryDequeue(myEvent)
                        mySimEventParams.SetValue(myEvent.MouseID)
                        mySimEvent.SetValue(myEvent.EventID)
                        SimLogger.Trace("Sending Control {0} with parameter {1}", myEvent.EventID, myEvent.MouseID)
                        FSUIPCConnection.Process("SendControl")
                        FSUIPCConnection.DeleteGroup("SendControl")
                        Thread.Sleep(1000)
                    Loop
2023-08-29 22:38:55.7787 TRACE FSInterfaces.FSServer.FSUIPCRunnerElapsed, Sending Control 70481 with parameter 536870912
2023-08-29 22:38:56.7829 TRACE FSInterfaces.FSServer.FSUIPCRunnerElapsed, Sending Control 70482 with parameter 536870912
2023-08-29 22:39:10.7899 TRACE FSInterfaces.FSServer.FSUIPCRunnerElapsed, Sending Control 79873 with parameter 536870912
2023-08-29 22:39:11.8007 TRACE FSInterfaces.FSServer.FSUIPCRunnerElapsed, Sending Control 69873 with parameter 536870912

First two controls send EVT_CDU_L_A, and EVT_CDU_L_B.  As expected, 1 second apart from each other an "A" and "B" character shows up on CDU-L.

Second two controls send EVT_OH_ELEC_GND_TESTS_GUARD and EVT_OH_ELEC_GND_TESTS_SWITCH.  It seems that the Guard opens the switch toggles, but then the guard closes again (and disables the switch).  This is not how it performs on the aircraft, the guard should stay open.

Tried with a few other switches with guards:

Battery Guard / Battery Press.  Works as expected.

2023-08-29 22:46:08.2810 TRACE FSInterfaces.FSServer.FSUIPCRunnerElapsed, Sending Control 79650 with parameter 536870912
2023-08-29 22:46:09.3245 TRACE FSInterfaces.FSServer.FSUIPCRunnerElapsed, Sending Control 69650 with parameter 536870912
2023-08-29 22:46:10.3910 TRACE FSInterfaces.PMDGB74x.PowerMonitor, Battery Disconnected. ELEC_Battery_SW: 0
2023-08-29 22:46:10.3910 TRACE FSInterfaces.PMDGB74x.PowerMonitor, BUS B Off. ELEC_StanbyPowerSw: 1, ELEC_Battery_Sw_ON: 0

EMER Lights Guard  Switch.  Works as expected.

2023-08-29 22:51:14.7136 TRACE FSInterfaces.FSServer.FSUIPCRunnerElapsed, Sending Control 79693 with parameter 536870912
2023-08-29 22:51:15.7592 TRACE FSInterfaces.FSServer.FSUIPCRunnerElapsed, Sending Control 69693 with parameter 536870912


Guess I will have to test and verify each and every single one, but from what I can see yes - the code works fine after swapping the two requests around.  There still are some switches with guards though, that doesn't want to play ball.

 

 

 

Posted

In the code you've posted you're still declaring the offsets in the wrong order. You need to declare 3114 then 3110.

I noticed you have swapped the order you set the values, but that doesn't matter. It should be this:

                   Do Until myEventQueue.IsEmpty
                        Dim mySimEventParams As New Offset(Of Integer)("SendControl", &H3114, True)
                        Dim mySimEvent As New Offset(Of Integer)("SendControl", &H3110, True)
                        Dim myEvent As SimEvents
                        myEventQueue.TryDequeue(myEvent)
                        mySimEventParams.SetValue(myEvent.MouseID)
                        mySimEvent.SetValue(myEvent.EventID)
                        SimLogger.Trace("Sending Control {0} with parameter {1}", myEvent.EventID, myEvent.MouseID)
                        FSUIPCConnection.Process("SendControl")
                        FSUIPCConnection.DeleteGroup("SendControl")
                        Thread.Sleep(1000)
                    Loop

However, this might not solve the problem since your examples are always sending the same parameter value. It would only make a difference on the first ever call. But, you should fix the order in case you ever need to send a different parameter value.

Other things you might try:

  1. Turn on the Event (control) logging in FSUIPC and output to the console. Check that FSUIPC is receiving what you think the code is sending. And you'll be able to see if anything else is writing that control.
  2. Try with a non-mouse parameter. I think some of the PMDG controls can also take direct values like 0/1 for open/close.

Paul

Posted
10 hours ago, Paul Henty said:

The order of these offsets matters. FSUIPC sends the control to the sim as soon as you write 3110. So that's before you've written the new parameter - the offsets are written in the order they are declared.

 

9 hours ago, Paul Henty said:

Turn on the Event (control) logging in FSUIPC and output to the console. Check that FSUIPC is receiving what you think the code is sending. And you'll be able to see if anything else is writing that control.

 

After a night's sleep... Those two statements solved it in a few seconds.

FSUIPC log window showed that it got the events twice, and that made me think.  You said offsets are sent as soon as they are written to 3110.  So I removed the Process() call, and then things started working correctly as the event is only sent once to the simulator.  However, now it doesn't matter what I sent, the simulator keeps getting the same Event

 

For example, I sent via FSUIPCClient:

2023-08-30 08:37:11.0297 TRACE FSInterfaces.FSServer.FSUIPCRunnerElapsed, Sending Control 79693 with parameter 536870912
2023-08-30 08:37:11.0297 TRACE FSInterfaces.FSServer.FSUIPCRunnerElapsed, Sending Control 69693 with parameter 536870912

FSUIPC Log window reports

36825016 *** EVENT: Cntrl= 79873 (0x00013801), Param= 536870912 (0x20000000)  <79873>
36825016 *** EVENT: Cntrl= 69873 (0x000110f1), Param= 536870912 (0x20000000)  <69873>

Not sure what is going on here, but the Client DDL isn't doing what it is supposed to be doing.

1) If I don't call Process() the same event is sent over and over, irrespective of what the value of the Event Offsets are (so they don't update)

2) If I do call Process(), everything is sent twice to the simulator (and no, I am not calling Process() elsewhere) - which explains the unexpected results with the switch Guards as the guard is triggered twice

 

Posted

Found some other debugging code that interfered with this.

For the loop, this seems to work

                    Do Until myEventQueue.IsEmpty
                        Dim mySimEvent As New Offset(Of Integer)("SendControl", &H3110, True)
                        Dim mySimEventParams As New Offset(Of Integer)("SendControl", &H3114, True)
                        Dim myEvent As SimEvents
                        myEventQueue.TryDequeue(myEvent)
                        mySimEventParams.SetValue(myEvent.MouseID)
                        mySimEvent.SetValue(myEvent.EventID)
                        SimLogger.Trace("Sending Control {0} with parameter {1}", myEvent.EventID, myEvent.MouseID)
                        FSUIPCConnection.Process("SendControl")
                        mySimEvent.Disconnect()
                        mySimEventParams.Disconnect()
                        FSUIPCConnection.DeleteGroup("SendControl")
                    Loop

Don't think I need the Disconnect() and DeleteGroup() call, but I can't use the Offsets declared globally (threaded application).  I must declare them at each use (which is strange).

Posted

You've still got the declarations the wrong way round. 3114 must be declared first, then 3110. Please see the code I pasted in my last reply.

Quote

Don't think I need the Disconnect() and DeleteGroup() call,

You don't need the Disconnect(), but you definitely need to delete the group if you declare (recreate) the offsets each time you send them.

Quote

but I can't use the Offsets declared globally (threaded application).  I must declare them at each use (which is strange).

The DLL is thread-safe and (by default) offsets can be declared on one thread and set/processed on another.

Quote

 If I don't call Process() the same event is sent over and over, irrespective of what the value of the Event Offsets are (so they don't update)

If this is the case then either:

1. Another application is sending these events.

2. Your application is sending these events from elsewhere in the code. Make sure you haven't declared these offsets somewhere else in another group (or in the default, empty group).

Also, if you are using a version of my DLL before 3.1.6 you'll need to update as the write-only offsets were buggy before that.

Paul

 

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • 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.