Replace event.vriread with event.com

[Artem Crum]

Pete,

Another theoretical question. Currently I'm using the event.vriread to handle VRi MCP Combo events and it works fine. But there is little (non-critical) problem with it. If VRi device was not switched on before the FSX/FSUIPC was started, then vriread event doesn't work. But even with not working vriread, I can successfully send comands to the MCP Combo using com.write call (no matter when it was switched on).

1. Is there any way to ask FSUIPC to reinitilize vriread library on a runtime?

..or..

2. Can I replace event.vriread with event.com without big performance loss? This is more interesting for me, because then I will not need to do any changes to fsuipc4.log to make VRI devices working.

[Pete Dowson]

Another theoretical question. Currently I'm using the event.vriread to handle VRi MCP Combo events and it works fine. But there is little (non-critical) problem with it. If VRi device was not switched on before the FSX/FSUIPC was started, then vriread event doesn't work. But even with not working vriread, I can successfully send comands to the MCP Combo using com.write call (no matter when it was switched on).

The VRI facilities are initiated by the INI file entries telling it which COM ports are used for what. If the Open command fails at that time, during initialisation, then the device isn't connected for that session. The same does actually apply to FS's own use of devices. The Lua basic COM library facilities open ports and close them by specific programming, not by initialisation through INI file declarations.

1. Is there any way to ask FSUIPC to reinitilize vriread library on a runtime?

Not without a massive amount of re-organising code, which I am not willing to do. Sorry. Too error prone. And really, considering most users wil also be using SerialFP2 alongside FSUIPC Lua additions, and that would certainly not be easily introduced later, it really doesn't have a huge application among users. The whole design of the VRI facilities was to make it relatively easy for VRI users to use FSUIPC, not replace the whole of VRI's programming.

2. Can I replace event.vriread with event.com without big performance loss? This is more interesting for me, because then I will not need to do any changes to fsuipc4.log to make VRI devices working.

There is no particular reason why direct COM programming would be less efficient, except possibly in the decoding of all of the VRI commands. That's quite a lot of code in fast C compared with interpreted Lua. And a lot of work for you. But as the speed only has to match use button pressing abilities, efficiency and speed are not at all of the essence, are they?

Regards

Pete

[Artem Crum]

There is no particular reason why direct COM programming would be less efficient, except possibly in the decoding of all of the VRI commands. That's quite a lot of code in fast C compared with interpreted Lua. And a lot of work for you. But as the speed only has to match use button pressing abilities, efficiency and speed are not at all of the essence, are they?

I have already done the optimized Lua parser for VRi MCP Combo "language". It works fine without any visible delays on buttons and rotaries operations. All LINDA's comunication with MCP Combo is based on this parser and tested in all possible conditions. But I thought that event.vridrv does some serious pre-parsing of raw COM-port coming data from MCP Combo. That was my question about, And in fact I've just replaced the event.vriread with event.com and the same parser works fine without any modifications in it's code.

It seems that event.com(dev, 8, 3, 0, 'vriHandler') does pretty much the same job as event.vriread(dev, 'vriHandler'). The only difference I see for the moment is that event.com sends an empty datastrings from time to time... :-)

Or am I missing something?

Edited June 16, 2011 by Artem Crum

[Pete Dowson]

It seems that event.com(dev, 8, 3, 0, 'vriHandler') does pretty much the same job as event.vriread(dev, 'vriHandler'). The only difference I see for the moment is that event.com sends an empty datastrings from time to time... :-)

Or am I missing something?

There's no pre-processing except for the data being checked and found to be representing a button which has has been programmed in FSUIPC. Then the data received won't cause an event, only a button signal to FSUIPC. What other pre-processing do you think there might be?

It is an intercept on one of the two devices involved in the SerialFP2 < ---> FSUIPC <---> VRIdevice relationship. The intercept occurs after the programmed button check, but before any filters set in the INI file, and before the data is passed along the chain (either way, to SerialFP2 or the device). But this is also after it has been copied to a possible secondary read channel.

And, of course, as you found, it only works for a VRI device opened by FSUIPC initially, as a result of the INI settings.

Regards

Pete

[Artem Crum]

I'm doing all this com-port (and HID, and FSX too) staff for the first time in my life, so I just don't know if there any nuances until face them myself. I'm doing things and learning them at the same time now. And there are many discoveries on each step. But sometimes it meens that I have to do a step back to make the same thing a better and the right way. Vriread and direct com-port read is the case. :-)

Thank you for explanation and your patience!

[Artem Crum]

Deleted... need to investigate it myself. Sorry.

Edited June 19, 2011 by Artem Crum