Jump to content
The simFlight Network Forums

wstrzalka

Members
  • Content count

    17
  • Joined

  • Last visited

Community Reputation

0 Neutral

About wstrzalka

  • Rank
    Member

Profile Information

  • Gender
    Not Telling
  • Location
    Poland
  1. Missing com.readfeature

    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
  2. Missing com.readfeature

    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
  3. Missing com.readfeature

    With the function name correction it works as expected. Thanks a lot !!!!
  4. Missing com.readfeature

    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 ....
  5. 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)
  6. 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
  7. 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
  8. Missing com.readfeature

    I can confirm com.readfeature & com.writefeature work like a charm :D
  9. Missing com.readfeature

    I had read both messages same time so I was sad entire 20 seconds ;)
  10. Missing com.readfeature

    That's great news. I will test (hopefully over the weekend) and get back to you.
  11. Missing com.readfeature

    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.
  12. Missing com.readfeature

    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 ...
  13. Missing com.readfeature

    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 :)
  14. Missing com.readfeature

    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
  15. Missing com.readfeature

    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
×