wstrzalka
-
Posts
18 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by wstrzalka
-
-
The entire story was about callback being generated more then once per physical event.
But now I realized I forgot to call event.cancel(...) while subscribing for notifications again when reconnecting, so .... never mind as everything works as it should.
Sorry for bothering you.
Wojtek
-
There is one minor issue I think
When I do play with it and connect/disconnect device, I do full device reinitialization (including com.close() and then com.openhid()).
Everything works OK but I noticed in the log file that with every such a cycle I do get one more events on every disconnected & re-connected.
Seems like com.close() is leaving some data.
It's not really an functional issue as with com.connected() only first from the series has status 2/3 while the shadows have 0/1 and those are easily ignorable () but I think it's worth you're aware in case there is smth bigger behind it ...
Sample log:
237246 LUA: Waiting for an event in "E:\FSX\Modules\driver\KX155.lua" 254999 LUA: HID Connection event: calling "onDeviceStatusChange" in "E:\FSX\Modules\driver\KX155.lua" 254999 LUA: Device disconnected 254999 LUA: HID Connection event: calling "onDeviceStatusChange" in "E:\FSX\Modules\driver\KX155.lua" 254999 LUA: Device disconnected noop 254999 LUA: HID Connection event: calling "onDeviceStatusChange" in "E:\FSX\Modules\driver\KX155.lua" 254999 LUA: Device disconnected noop 254999 LUA: HID Connection event: calling "onDeviceStatusChange" in "E:\FSX\Modules\driver\KX155.lua" 254999 LUA: Device disconnected noop 254999 LUA: Waiting for an event in "E:\FSX\Modules\driver\KX155.lua"Regards
Wojtek
-
With the function name correction it works as expected.
Thanks a lot !!!!
-
5 hours ago, Pete Dowson said:
FSUIPC 4.971b and 5.121c are now released -- see Download Links. The Lua facilities to check HID device connection status have been added.
Smth doesn't work for me:
********* LUA: "KX155" Log [from FSUIPC version 4.971b] ********* 80684 System time = 15/10/2017 19:10:22, Simulator time = 19:09:05 (18:09Z) 80684 LUA: beginning "E:\FSX\Modules\driver\KX155.lua" 80700 LUA: LINDA:: [LIB] FSX Functions loaded... 80700 LUA: [KX155] *********************** STARTING KX155 DRIVER *********************** 80700 LUA: [KX155] RELOAD !!!!!!!!!!!!!!!! 80700 LUA: [KX155] Checking connection ... 80700 LUA: [KX155] Connecting ... 80700 LUA: [KX155] Connecting to VID:03EB PID:2062 80715 LUA: [KX155] HID device found 80731 LUA: [KX155] HID report received 80731 LUA: [KX155] Handling HID report (3 bytes): 01 00 04 80731 LUA: [HID] Button 10 ON. Executing function: ComNav2_Power_on() 80747 *** LUA Error: E:\FSX\Modules\driver\KX155.lua:188: attempt to call field 'devconnect' (a nil value)While KX155.lua:187-189 looks like this:
event.com(handle, 3, 3, "onHidReport") event.devconnect(handle, "onDeviceStatusChange") event.offset(0x3118, "UW", "onCom2ActiveFrequencyChange")Seems like the new DLL was loaded but the function is not there ....
-
No problem at all until it works. It may be worth to mention in the doc however (unless it's already there as I could miss it)
-
That was tricky one.
I was convinced that I have either an option to get report events or to poll the reports with read. Didn't really expected a mix :)
After a fix it works as expected.
Thanks Pete
-
Hi Pete
I think I had found a bug this time.
I do use event.com() to register callback on incoming HID reports. If I do generate HID reports slowly it works as designed. But when I do generate a lot of reports in very short period - especially when I do it faster then I'm able to consume them - it starts misbehaving. The problem is I'm only getting a few reports out of many. The reports are not lost however but are stored somewhere in FSUIPC (I believe) and when I do press another button on the device - what triggers HID report - I do get one but it's the cached one from long time ago. Then the story repeats with subsequent buttons.
So it seems like all the events coming from USB are recorded, but when they come too fast, only for some part of them there is callback function called. Then when new reports come the new report is added to the end of some queue while the oldest one (and only one although there a bunch of backlog in the buffer) is send to the callback. From now on all the reports are not from the buttons I do press... This causes a lot of mess as you may expect :)
Interesting factor is that when I do call com.readlast all the buffers/caches/queues/... are flushed (I do get pretty decent 'discarded' value returned) and everything works as expected again.
I would imagine there to be lag caused by not consuming messages fast enough, but eventually to get all the awaiting reports until buffer is empty.
As of reproduction - I'm reliably able to reproduce it when I do tun encoder knob quite fast (I'm not able click fast enough to trigger it with regular button). When I do have LUA logging enabled it's happening every single time, but it sometimes also happens when I do disable logging and turn my knobs reasonably fast during flight.
Regards
Wojtek
-
9 hours ago, wstrzalka said:
That's great news. I will test (hopefully over the weekend) and get back to you.
I can confirm com.readfeature & com.writefeature work like a charm :D
-
On 28.09.2017 at 1:19 PM, Pete Dowson said:
Thus, not "messy" at all, really, but probably quite tidy! Sorry about my earlier pessimism.
I had read both messages same time so I was sad entire 20 seconds ;)
-
On 28.09.2017 at 12:34 PM, Pete Dowson said:
Okay. Big omission from the Lua com lbrary documentation.
I was looking into adding "com.readfeature", so I looked at the code. It is already implemented! It was included at the same time as all the other HID functions. I don't know how it missed out in the documentation.
There's also "com.readreport" omitted!
I think they were omitted because I had no way of testing them, no way of determiniing whether the results were correct even if I had appropriate devices.
I've now found that the GoFlight T8, P8 and RP48 devices have feature bytes, as do the Leo Bodnar BU0836 boards, so I could actually test that they do something. But whether what you get is right is another matter.
If you'd be so good as to test them on devices you know and let me know. If okay I'll add them to the documentation. Meanwhile here is what the entries would read:
str, n = com.readfeature(handle, repno)
Reads the feature bytes from the HID device via the “GetFeature” call.
The report ID to be used is given as “repno”, or 0 if none are used.
The returned value gives the data returned by the device, with the report ID in the first byte. “n” is zero if there was an error.
str, n = com.readreport(handle, repno)
Reads the input report bytes from the HID device via the “ReadInputReport” call.
The report ID to be used is given as “repno”, or 0 if none are used.
The returned value gives the data returned by the device, with the report ID in the first byte. “n” is zero if there was an error.
That's great news. I will test (hopefully over the weekend) and get back to you.
-
So if a rescan functionality is already built-in (and potentially can be extended to non-joystick devices) it should be quite simple to validate if the devices being opened with com.openhid() are still in system - especially for FSUIPC 5 where you do have mapping table already implemented. It would probably need to keep track of VID/PID/NO (or entire device path), not only map number to number but it seems doable [ I'm aware things seems much easier when you don't have too work on them, then when you have to code it :) ]
BTW - I had just found that the offset I'm using to force a device reconnect works only when LINDA software is turned on, so it's probably theirs custom hack to notify Lua to do device checks.
-
10 hours ago, Pete Dowson said:
I think I'd rather do something like saving the last error return I got (read by something like GetLastError in C) whist issuing commands for the device, and providing them on a request such as
n = com.geterror(dev)
That would be beneficial on it's own but not fully functional complete for the use case of device disconnect.
If you have input only device (eg. standard joystick) or like my radios input with output loopback (in perfect situation information on display changes only after I create an input from device first: knob turn results in displayed frequency change), and you want to use event library for read you will never find out smth got broken - as there will no longer be input from device there will be no output and no output is no error.
I did some research and I think best would be to register in OS using this API: RegisterDeviceNotification on com.hidopen(), with complementary UnregisterDeviceNotification on com.close()
Having that app will receive WM_DEVICECHANGE with two most interesting notification DBT_DEVICEREMOVECOMPLETE and DBT_DEVICEARRIVAL
Looking at the DBT_DEVICEARRIVAL I'm no longer 100% sure wheather the handle gets invalid after disconnect (it definitelly does in FSUIPC). That would need to be tested in detail ...
-
That's exactly the difference between regular reports & feature reports. The later once are always there so you can always request a read.
That's of course workaround and it would be much more convenient to have API for that. If com.openhid handle is OS handle I'm pretty sure it becomes invalid forever after you disconnect so the API would be more like one shot event.afterDisconnect.
If they are your internal handles sky is the limit... :)
Currently I did found some magic offset that gets set any time smth major happens (don't remember exact value right now but it's set also when any HID connects) and I reconnect just in case every time it's set. Works but if there would be more gentle way of doing that it would be great.
Anyway big respect as I was able fully program 2 way communication using FSUIPC plugin infrastructure. I initially started with custom C# app but it got too heavy and I abandoned it on behalf of Lua.
Feature read and disconnect notification are just a cherries on a pie to make things more compact and smooth :)
-
One more thing I wanted to achieve with readfeature is to check if the device is still there, as I think there is currently no way to detect it from the script for non-joystick device (write always returns the amount of bytes to be written for me). Or maybe I'm wrong and there is a way?
Wojtek
-
Thanks.
I do use Atmega chip with builtin hardware USB support. A bit of C++ does the rest :)
At the moment I'm finishing KX155 COM/NAV radio (both device C++ program & LUA FSUIPC plugin to talk to sim are ready (almost) - still need some smart way to get nice panel).
The device are 1:1 size & layout with original Bendix/King. I do have PCB manufactured for KT76 transponder & KR87 ADF so I'm going to start assembling them this week. And more to come ...
Wojtek
-
I'm on version 4 atm - still with FSX ;)
Currently I'm focused on hardware work but once complete I'm planning to jump to new P3D and FSUIPC - maybe also WideClient - but I'm not using it at the moment.
Regarding use case I'm working on my custom hardware and using HID features for device configuration (so the device remembers whether it's COM1 or COM2, display brightness etc..)
-
Hi
I do really miss Lua functionality to read HID feature report. Smth with signature com.readfeature(handle, reportID).
It would be complementary to existing com.writefeature(...)
Regards
Wojtek
[BUG] FSUIPC4 event lib gets out of sync
in FSUIPC Support Pete Dowson Modules
Posted
I've been off the business for quite a long time....
So I read this in the doc before multiple times and I think I got the most confused by this
"Your program doesn’t need to perform
any reads itself, thought there’s nothing stopping it—and it
may be wise if there’s more expected"
I understood it as a assurance that I will get the messages. I'm not sure if it's because of the statement itself or my english skills :D
I think I would figure it out with the supplement proposed