[Lua] Proper use of events

[Matthew Twomey]

This is more of a learning exercise than a problem. I realize there are events specifically for buttons, however in my experimentation today - I became curious why this code is firing so slowly:

dev, rd, wrf, wr, init = com.openhid(0x1234, 0xBEAD, 0, 0);

previousButtonState = false; -- Track this to prevent repeatedly firing
function processButton(handle, data)
    local buttonState = com.testhidbutton(handle, 2, data);

    if ((buttonState == true) and (previousButtonState == false)) then
        previousButtonState = true;
        ipc.control(66300, 0); -- Toggle engine 1 switch
    end
    if ((buttonState == false) and (previousButtonState == true)) then
        previousButtonState = false;
    end
end

event.com(dev, rd, rd, "processButton");

ipc.log("Started up");

When I assign this button directly in the UI, it fires basically immediately. When I instead  monitor for the button press with this script, it has nearly a 1 second delay before it fires. I'm just getting my feet wet with FSUIPC, so I'm in learning mode - so I'm curious if I'm misunderstanding something here about how to efficiently process inputs via Lua.

Thanks,

-Matt
 

[Pete Dowson]

7 hours ago, Matthew Twomey said:

When I assign this button directly in the UI, it fires basically immediately. When I instead  monitor for the button press with this script, it has nearly a 1 second delay before it fires.

Really?  Not sure I understand. Which version of FSUIPC are you using? And why are you using the plug-in instead of assigning directly, if the device is recognised as a joystick? Is it because you are going to extend this to more than 32 buttons?

I don't see anything wrong with your Lua code, though it would be more efficient just to have this in the function:

function processButton(handle, data)
    local buttonState = com.testhidbutton(handle, 2, data);

    if ((buttonState == true) and (previousButtonState == false)) then
        ipc.control(66300, 0); -- Toggle engine 1 switch
    end
    previousButtonState = buttonstate;
    end
end

How are you starting the plug-in running?  via an [Auto]?

One possible problem occurs to me, which may well be the cause of your delay. The event.com function will trigger when ANY data is received from the device, whether it is about buttons or whatever. Maybe your function is actually being alled very often but just doesn't have anything to do most of the time. You can check by using the Lua debug trace facility in the FSUIPC Logging options.

There is a Lua example of reading and acting on buttons from a HID device, one which works well. See HIDDEMO.Lua, in the Examples plug-ins ZIP file. That certainly doesn't use event.com but does it by polling using event.timer -- by default it is currently set to check 25 times per second.

Pete

 

 

[Matthew Twomey]

Hi there and thanks. Yes - I'm starting the plugin via [Auto]. I am new to FSUIPC so I don't have any past experiences to compare with. I am using the beta version against MSFS2020. I'm both a developer and a microelectronics hobbyist - so I'm really just learning the ropes with FSUIPC at this point. I've started working on some hardware projects and have various ideas I'd like to experiment around working with "chorded" controls and combinations of switches + axis values and the processing of these. I was in experimentation mode yesterday and that is how this question came up. I'm more trying to understand what possibilities and / or limitations I might face using the Lua interface.

So I've done a little more testing with this. I've included 4 small (but complete) examples below. The only one that responds "quickly" is the event.button based solution (however, I'd really like to get a solution that can act quickly and be constantly monitoring the input data - like the event solution or the timer solution).

Each example was loaded (only one at a given time) via the [Auto] section of the ini.

Example #1 - event.com approach (Slow)

handle, rd, wrf, wr, init = com.openhid(0x1234, 0xBEAD, 0, 0);

function processButton(handle, data)
    local buttonState = com.testhidbutton(handle, 2, data);
    if ((buttonState == true) and (previousButtonState == false)) then
        ipc.control(66300, 0); -- Toggle engine 1 switch
    end
    previousButtonState = buttonState;
end

event.com(handle, rd, rd, "processButton");

ipc.log("Started up");

Example #2 - event.timer approach (Slow)

handle, rd, wrf, wr, init = com.openhid(0x1234, 0xBEAD, 0, 0);

function processButton()
    local data, n = com.readlast(handle, rd);
    if (n > 0) then
        local buttonState = com.testhidbutton(handle, 2, data);
        if ((buttonState == true) and (previousButtonState == false)) then
            ipc.control(66300, 0); -- Toggle engine 1 switch
        end
        previousButtonState = buttonState;
    end
end

event.timer(25, "processButton");

ipc.log("Started up");

Example #3 - Hard Loop approach (Slow) Impractical, but just as a test (it's still slow) (I was quite surprised this one was slow)

handle, rd, wrf, wr, init = com.openhid(0x1234, 0xBEAD, 0, 0);

function processButton()
    local data, n = com.readlast(handle, rd);
    if (n > 0) then
        local buttonState = com.testhidbutton(handle, 2, data);
        if ((buttonState == true) and (previousButtonState == false)) then
            ipc.control(66300, 0); -- Toggle engine 1 switch
        end
        previousButtonState = buttonState;
    end
end

ipc.log("Started up");

while (true) do
    processButton();
end

Example #4 - event.button approach (Fast) This is the only one that acts quickly

handle, rd, wrf, wr, init = com.openhid(0x1234, 0xBEAD, 0, 0);

function processButton()
    -- ### Leaving this code in here to execute just to test if there is anything in here slowing things down ###
    local data, n = com.readlast(handle, rd);
    if (n > 0) then
        local buttonState = com.testhidbutton(handle, 2, data);
        if ((buttonState == true) and (previousButtonState == false)) then
            --ipc.control(66300, 0); -- Toggle engine 1 switch
        end
        previousButtonState = buttonState;
    end
    -- ### End test code
    ipc.control(66300, 0);
end

event.button("A", 2, "processButton");

ipc.log("Started up");

As suggested, I also fired up and tested HidDemo.lua with the only modification being to the Vendor and Product IDs (to match mine). This behaved the same as tests 1 - 3, about a one second delay before acting on anything.

So I'm both curious what's happening here and willing to do any tests or debugging (I'm happy to go quite deep into it if needed), if that can help or if I can be of any use on this.

Thanks,

-Matt

[Matthew Twomey]

Incidentally, using the HidDemo.lua the delay is also evident in the FSUIPC UI. If I go in to assign an axis on Joy#16 (which HidDemo maps to), each time I physically push the axis there is about a one second delay before it responds in the FSUIPC axis assignment display:

[Pete Dowson]

I wish you had mentioned MSFS earlier. You should be posting in the FSUIPC Beta subForum above.

FSUIPC7 is a Beta release whilst being developed. Additionally MSFS is in development(and is also effectively a Beta release.

I am not in a position to support this. I use Prepar3D and any of you suggested solutions work fine for me -- but then the Lua plugin along with FSUIPC run as part of the SIM process. It's a lot different.

 Maybe John or Thomas will know what is so different, enough for such an enormous  delay.

Did you bother trying tracing to see what is going on?

Pete

 

 

 

 

 

Pete

[Matthew Twomey]

My apologies about the forums misplacement (will go there going forward), I'm a little new to the FSUIPC ecosystem. I didn't realize that parts of FSUIPC were fundamentally different in the V7 Beta (although I suppose I might have guessed that because I had read somewhere that it is "new" that this V7 version runs "stand alone").

Yes, I've done extensive tracing to the extent that I can do so through FSUIPC's logging capabilities as well as logging and timing within my own code and the examples above. I have not attempted to do any tracing of FSUIPC itself, e.g. windows process level snooping and debugging (although I suspect that's not what you mean).

As best I can tell, it appears to me that data is delayed on its way to the buffer that services com.read* (or even earlier). In the case of the event.com solution, I'm not even calling com.read - so that leads me to believe that the data is delayed on its way to wherever the implementation of event.com is getting it from (sorry, I don't know the internal architecture of the FSUIPC lua libs).

[Pete Dowson]

3 hours ago, Matthew Twomey said:

I've done extensive tracing to the extent that I can do so through FSUIPC's logging capabilities

It might have helped providing us with an FSUIPC log file, with Button, Event and Lua tracing enabled. You can ZIP up the Log file and attach it to a reply here.

3 hours ago, Matthew Twomey said:

As best I can tell, it appears to me that data is delayed on its way to the buffer that services com.read* (or even earlier). In the case of the event.com solution, I'm not even calling com.read - so that leads me to believe that the data is delayed on its way to wherever the implementation of event.com is getting it from (sorry, I don't know the internal architecture of the FSUIPC lua libs).

HID com part reads are just effectively doing the same as the normal driver for joystick devices, it just reaches the user program through a different, dedicated interface.

When you run your Lua program, is FSUIPC also scanning the device as a normal joystick? If so I wonder if that is causing some sort of problem at a lower level. Try de-assigning anything you have assigned to it in FSUIPC. It already should be unassigned in MSFS if you planned on using FSUIPC in any case.

I really can't think of any other reason for the problem, but lets see logs. It's getting late here now, and I'm not really working tomorrow 9lots of more normal home things to do), but i might be able to try something on Monday -- just not with the same sort of device, I suspect. What is Vendor 0x1234 and device 0xBEAD?  They don't seem to be officially issued values.

Pete

 

[Matthew Twomey]

First - I'm in no rush, so please enjoy your weekend and time. When you do look back on this, I think I've got the info you mentioned in this post as well as some additional analysis of my own.

So I am running a pretty clean / cleared out setup while testing here. I have nothing at all mapped or assigned except a single button to kill Lua. I've attached my ini file here (FSUIPC7.ini). Vendor 0x1234 and device 0xBEAD are the default identifiers for a vJoy virtual joystick.

I've also attached a log with your suggested tracing enabled (Example-Event-Timer_Slow.log). This is a log running Example #2 - event.timer approach (Slow) listed in my post above. Timestamp 17922 in this log shows the first time the event is captured. I've also noticed this event.timer is only firing about 9 times per second, but it's unclear to me if it's the debug logging that's slowing it down.

I did a second experiment which I find more interesting:

Example #5 - event.time AND event.button

handle, rd, wrf, wr, init = com.openhid(0x1234, 0xBEAD, 0, 0);

function processButton()
    local data, n = com.readlast(handle, rd);
    if (n > 0) then
        local buttonState = com.testhidbutton(handle, 2, data);
        if ((buttonState == true) and (previousButtonState == false)) then
            ipc.log("##### Timer Trigger: Button 2");
            ipc.control(66300, 0); -- Toggle engine 1 switch
        end
        previousButtonState = buttonState;
    end
end

function processButton2()
    ipc.log("##### Button Event Trigger: Button2");
end

event.timer(25, "processButton");
event.button("A", 2, "processButton2");

ipc.log("Started up");

I've left the timer functioning as it was from Example #2. I added an ipc.log line to make it even more obvious when it registered button 2 being pressed via event.timer. In addition, I added a button event which triggers on the same button. Button events work as I would expect them to - they process very quickly, with no perceivable delay. I also added a log line for event.button being fired. With this setup, I see the following in the log:

In this experiment, I see the first highlighted line in that image is the log message indicating when the event.button was fired. However, we see 5 more full cycles (of event.timer) and 578ms go by before the second highlighted line, which is when event.timer caught the exact same button press. I also attached the full log from this experiment to this post (Example5.log) - this log is a little messy though, there are some other things in it. I can create a clean one if you'd like me to.

Also I tried disabling debug logging completely (in case that was affecting it). The significant delay between these two is still present (each pair of entries in this screenshot represent a single button press):

Thanks,

-Matt

 

[Pete Dowson]

I see that the delay you mention if in the region of 450-550 mSecs, rather than a full second. however, that isn't food.

I found a little time this morning to do some tests here. This was on my development PC (not a Sim PC), with loads of other things also running.

Using exactly your later test, and with the latest FSUIPC7 but without  MSFS running yet I see a delay of around 30-35 mSecs, which is probably commensurate with the logging I have on screen (the console).

With an up to date MSFS loaded ready to fly with the Cessna 152, I measure a delay, certainly -- but nowhere near yours (my Button 1 is assigned to SLEW_TOGGLE in FSUIPC). More like 140-160 mSecs as shown here:

  4660813 Button changed: bRef=0, Joy=0 (B), Btn=1, Pressed
  4660813 [Buttons] 2=PB,1,C65557,0
  4660813 FS Control Sent: Ctrl=65557, Param=0 SLEW_TOGGLE
  4660828 LUA.14: ##### Button Event Trigger: Button1
  4660953 LUA.14: Data Read= 00 00 80 FF 7F 00 80 FF 7F 00 80 02 00 00 00
  4660969 LUA.14: ##### Timer Trigger: Button 1
  4660985 FS Control Sent: Ctrl=66300, Param=0 TOGGLE_STARTER1

Here's my test Lua:

handle, rd, wrf, wr, init = com.openhid(0x045E, 0x028E, 0, 0);
prevdata = 0

function logdata(data)
  if data ~= prevdata then
	prevdata = data	
	logstr = "Data Read="
	i = 1
	while string.byte(data,i) do
		logstr = logstr .. string.format(" %02X", string.byte(data,i))
		i = i+1
	end
	ipc.log(logstr)
  end
end
  
function processButton()
    local data, n = com.readlast(handle, rd)
	if (n > 0) then
		logdata(data, prevdata)
        local buttonState = com.testhidbutton(handle, 1, data);
        if ((buttonState == true) and (previousButtonState == false)) then
            ipc.log("##### Timer Trigger: Button 1");
            ipc.control(66300, 0); -- Toggle engine 1 switch
        end
        previousButtonState = buttonState;
		x = com.gethidbuttons(handle, data)
		if x ~= 0 then ipc.log("Buttons=" .. x) end
    end
end

function processButton1()
    ipc.log("##### Button Event Trigger: Button1");
end

event.timer(25, "processButton");
event.button("B", 1, "processButton1");

ipc.log("Started up");

I'll compare this with FSUIPC6 + P3D later.

Pete

[Matthew Twomey]

Oh that's a good find / thought about testing without MSFS running. It took me a minute to figure out I could assign a key to start the script instead of relying on [Auto], which won't spin up until it detects a plane. I did this same test - a couple of observations:

1. The event.button event isn't firing at all for me without MSFS running, but the event.timer does fire. This means I can't measure the exact delta between the two. However - I can visually see that event.timer is responding in a similar slow fashion -  which does not match your observation.

2. The first time I tried this, I had copied your lua script from your last post and I forgot to change the HID device. So I ran it with an invalid HID device. In this circumstance, it responded quickly with no perceivable delay. However once I put my HID values in there, it returned to responding slowly.

--

Important new find! I did some tests with some different devices and this issue appears to present only with the vJoy device. I'm doing further testing here on versions of things, vJoy settings, ...etc. This still doesn't explain why event.button catches a button press (on vJoy) immediately, but event.timer does not...

More to come....

[Matthew Twomey]

Ok - here are my findings with vJoy so far. I've narrowed the difference down to specifically what is feeding vJoy. Take a look at this analysis:

As with the earlier tests, a single button press is listened for by both an event.button and an event.timer (firing every 25ms). Something different happens when I feed vJoy with some external programs I'm working with. When I use the demo feeder for vJoy, the issue does not occur.

This, I can work around by writing my own feeder. This leaves one open question though: In the case of the external feeder for vJoy, Why is event.button able to pick up and process the button press quickly, while event.timer is not (as shown in the first three pairs in that chart)?

More a curiosity than anything else at this point and perhaps just something for all to be aware of going forward if they use vJoy. I am more than happy to continue exchanging notes and troubleshooting on this (I kind of enjoy mysteries like this). However, it's starting to look like more of a niche issue at this point. So if you want to move past it, I totally understand. I really appreciate you working with me and sharing your findings as well as we went along :-)

-Matt

[Pete Dowson]

10 hours ago, Matthew Twomey said:

The event.button event isn't firing at all for me without MSFS running

No, it won't. I had to use more devious internal means to record the time.

10 hours ago, Matthew Twomey said:

Important new find! I did some tests with some different devices and this issue appears to present only with the vJoy device

Aha! I'm using a cheap Game Controller. I used to have vJoy installed on this PC but it got lost when I changed from Win10 1903 to 2004 version. 

So, I'm left wondering how the vJoy software might affect the timings. Perhaps a good test would be to remove all assignments to the device from your FSUIPC7.INI, so that FSUIPC is not scanning the device, just in case two entities trying to read the same software interface is slowing that down. As another step, make sure you create an empty profile for the joystick in MSFS so that it isn't scanning it either.

Of course you won't have a log entry showing when to press the button then, so you'd need to time it some other way. But your > half second is probably noticeable without measurement in any case.

I'm just about to check timings on P3Dv5 with FSUIPC6. Not that it is really relevant now, without vJoy.

Pete

 

[Pete Dowson]

Okay. FSUIPC6 + P3Dv5. Same device, same Lua plug-in.

   411328 Button changed: bRef=0, Joy=0 (B), Btn=1, Pressed
   411328 [Buttons] 1=PB,1,C65557,0
   411328 FS Control Sent: Ctrl=65557, Param=0 SLEW_TOGGLE
   411328 *** EVENT: Cntrl= 65557 (0x00010015), Param= 0 (0x00000000) SLEW_TOGGLE
   411328 ### Mode: SLEW on
   411328 *** EVENT: Cntrl= 65549 (0x0001000d), Param= 0 (0x00000000) PLUS
   411328 *** EVENT: Cntrl= 65719 (0x000100b7), Param= 0 (0x00000000) ZOOM_PLUS
   411437 Button changed: bRef=0, Joy=0 (B), Btn=1, Released
   411453 LUA.3: Data Read= 00 00 80 FF 7F 00 80 FF 7F 00 80 02 00 00 00
   411453 LUA.3: ##### Timer Trigger: Button 1
   411468 FS Control Sent: Ctrl=66300, Param=0 TOGGLE_STARTER1
   411468 LUA.3: Buttons=2
   411468 *** EVENT: Cntrl= 66300 (0x000102fc), Param= 0 (0x00000000) TOGGLE_STARTER1

So, from the time the button is detected pressed in FSUIPC to when the Lua plug-in has sent the TOGGLE STARTER1 control is 140 mSecs. That's an overall time. Of course with the event.timer set to 25 mSecs, that could contribute to that between 0-25 mSecs. It should be more consistent using your original method of even.com.

Also the first thing my Lua does is log the data (the "Data Read= line above).  There's another 15 msecs before sending the control. So at the best, and without logging (especially to screen as i was) even the fastest looks like being of the order 80-100 mSecs.

As far as I can see the higher timings for MSFS with FSUIPC7 are commensurate with them being separate processes.

10 hours ago, Matthew Twomey said:

However, it's starting to look like more of a niche issue at this point. So if you want to move past it, I totally understand.

Yes, I think i'll have to 'move on' as you say. I don't see there's a lot more I can do.

Incidentally, if you want to get deeper into using vJoy with FSUIPC you might want to take a look at my freeware "vjoyOffsets" program, which you can find on FSUIPC.com. If allows direct access into the FSUIPC offsets from vJoy axes, buttons and POVs. The offsets are documented in the offsets list, part of the main FSUIPC documentation package. (Of course not all yet apply to MSFS -- the document with FSUIPC7 lists their status).

Pete

 

[Matthew Twomey]

18 hours ago, Pete Dowson said:

So, I'm left wondering how the vJoy software might affect the timings. Perhaps a good test would be to remove all assignments to the device from your FSUIPC7.INI, so that FSUIPC is not scanning the device, just in case two entities trying to read the same software interface is slowing that down. As another step, make sure you create an empty profile for the joystick in MSFS so that it isn't scanning it either.

I went ahead and did this test. In my case, I only needed to clear one thing out of MSFS. I had actually already created a completely empty (zero assignments) controller profile in MSFS, so I switched back to that and completely wiped my FSUIPC ini and let it recreate fresh and free of any entries. I then just added the start and kill lua keyboard mappings and re-tested. Same results - when fed with my external feeder (UCR in this case) - event.timer+com.readlast picks up the event 350 - 500ms after event.button does. When fed with the vJoy example feeder they both pick up the event nearly immediately.

18 hours ago, Pete Dowson said:

just in case two entities trying to read the same software interface is slowing that down

So - yeah, it could be that the feeder I'm using isn't acting in a courteous manner. I don't really know much about the vJoy driver / interface - but maybe this feeder is opening it in some kind of exclusive mode or something along those lines. Or maybe it holds something open too long or neglects to signal something is complete. There must also be some difference in how FSUIPC is implementing event.button compared to what's happening with event.timer+com.readlast (e.g. why event.button is always fast). I probably will end up writing my own feeder for my project anyhow and I'm sure I'll learn plenty abut vJoy at that point.

Thanks for the pointer on vjoyOffsets, I had no idea that existed and that should come in very handy.

18 hours ago, Pete Dowson said:

Yes, I think i'll have to 'move on' as you say. I don't see there's a lot more I can do.

Yep - thank you for your time, I enjoyed our conversation.

-Mat

[Pete Dowson]

6 hours ago, Matthew Twomey said:

There must also be some difference in how FSUIPC is implementing event.button compared to what's happening with event.timer+com.readlast (e.g. why event.button is always fast).

The event.button facility is actually derived from FSUIPC's joystick scanning, so it's part of the mechanism using the regular interface.  Using it causes FSUIPC to scan the device just as if you'd assigned to it in FSUIPC.

The com library functions are, however, treating the device as a normal serial device, with some special decoding functions added for regular HID devices which have defined data formats. 

So the difference is in the interface being used. Why the lower level HID interface gets so delayed by the vJoy software I don't know. That's a good question for the author.

Pete

 

[Matthew Twomey]

4 hours ago, Pete Dowson said:

The event.button facility is actually derived from FSUIPC's joystick scanning, so it's part of the mechanism using the regular interface.  Using it causes FSUIPC to scan the device just as if you'd assigned to it in FSUIPC.

The com library functions are, however, treating the device as a normal serial device, with some special decoding functions added for regular HID devices which have defined data formats. 

Makes sense. However I assume at the end of the day, FSUIPC's joystick scanning also uses a low level HID connection. So it's just weird that the regular scanning interface is able to retrieve the data without delay.

---

Side question on bug reporting in general: Completely unrelated to vJoy (I actually completely removed it for now, during the course of testing we followed). Using a plain xbox360 controller, I'm also seeing some strange delays with axis values coming in when using com.gethidvalue. This is actually vaguely similar to the button issue. The reports coming in from com.gethidvalue "lag" behind, about .5 seconds, from the reports coming in via ipc.axis. They also seem to "queue up" - with new data coming in for a second or more after input changes have ceased. Now - I've simply switched to ipx.axis, so this isn't an issue for me. The real question is: Do you "want" bug reports such as these and if so, are forum posts your preferred way to receive them?

[Pete Dowson]

3 hours ago, Matthew Twomey said:

However I assume at the end of the day, FSUIPC's joystick scanning also uses a low level HID connection. So it's just weird that the regular scanning interface is able to retrieve the data without delay.

Yes. But may be if that wasn't happening, the additional HID access would be fast too. As I said before, perhaps it's more to do with having two accesses or more running.

3 hours ago, Matthew Twomey said:

Using a plain xbox360 controller, I'm also seeing some strange delays with axis values coming in when using com.gethidvalue. This is actually vaguely similar to the button issue. The reports coming in from com.gethidvalue "lag" behind, about .5 seconds, from the reports coming in via ipc.axis. They also seem to "queue up" - with new data coming in for a second or more after input changes have ceased.

The problem is likely that the COM port buffer is getting quite full due to records arriving faster than you are processing them. That is why com.readlast was provided, to discard all the interim queued records.

I suspect you are expecting too much from a plug-in facility. Lua plug-ins are interpreted, and also deliberately "slowed" (i.e. deliberately not given as much time as they would utilise if allowed). This is part of FSUIPC's purposeful concentration on providing facilities without impacting on the flight sim performance.

For all the purposes the Lua plug-in facility was added I think it does well. It is really not a substitute for a real driver. If you need time-critical application of your controls, I suggest either using only the standard facilities, or finding or writing a suitable driver.

3 hours ago, Matthew Twomey said:

Do you "want" bug reports such as these and if so, are forum posts your preferred way to receive them?

Questions and observations, as well as 'bug' reports, are always welcome, and, yes, forum posts are really the only acceptable way. Please don't start resorting to Private Messages or emails.

Pete

 

[Matthew Twomey]

1 hour ago, Pete Dowson said:

I suspect you are expecting too much from a plug-in facility. Lua plug-ins are interpreted, and also deliberately "slowed" (i.e. deliberately not given as much time as they would utilise if allowed). This is part of FSUIPC's purposeful concentration on providing facilities without impacting on the flight sim performance.

Yep fair enough. I'm really just exploring and getting my feet wet (I'm totally new to the FSUIPC world). I agree that the sim performance is paramount.

1 hour ago, Pete Dowson said:

For all the purposes the Lua plug-in facility was added I think it does well. It is really not a substitute for a real driver. If you need time-critical application of your controls, I suggest either using only the standard facilities, or finding or writing a suitable driver.

Yes - it's a very handy feature and most of what I've tried out via Lua worked very well. I was just exploring and figuring out where the limits lay.

[dedel]

This is an interesting discussion although it is rather old now.

I am connecting a generic HID device (not a joystick) to the PC. It converts my CAN-bus (with CanAerospace protocol) to HID. By means of the LUA interface of FSUIPC I catch the reports and distribute them to the offsets 0BB2, 0BB6 and 0BBA (Elevator Position, Aileron Position and Rudder Position). This arrangement acts like a joystick. I used both, an event.com solution and an event.timer solution. The first showed only spurious reaction while the latter (with an intervall time of 20ms) has fast responses when used with Prepar3D v5. The same lua script is awfully slow when used with MSFS and FSUIPC7.

My goal is to connect a CAN-bus to FSUIPC. It might be highly configurable through the LUA interface. However, timing seems to be a problem.

Detlef

[Pete Dowson]

1 hour ago, dedel said:

I used both, an event.com solution and an event.timer solution. The first showed only spurious reaction while the latter (with an intervall time of 20ms) has fast responses when used with Prepar3D v5.

Did you use com.readlast on the event.com signal? Otherwise you could be missing some signals unless when the even occurs you read and process all of the input received. In the case of com devices there's really not such a great advantage of using event.com, but it depends very much on the devices concerned.

As for performance with MSFS I'm afraid that's a general problem with all aspects involving SimConnect with MSFS. Part of that is because FSUIPC is a separate process and so the communications are nowhere near as efficient, but it is also to do with the dreadful SimConnect implementation at present. You should also look at the CPU usage of MSFS (and FSUIPC for that matter). Most folks seem to let MSFS run riot. It needs limits, same as P3D.

Pete

 

[dedel]

I did not use com.readlast, just com.read. My device sends a report only when there are new data. So I moved the joystick slowly to achieve a rare update but it misses several inputs and suddenly jumps to a new value.

I am afraid I have to change my HID device into a composite one with a joystick interface and a keyboard interface until SimConnect gets properly implemented. Then I can feed FSUIPC with conventional inputs. Let's see what happens.

Detlef