zetato Posted August 11, 2010 Report Posted August 11, 2010 Hi Pete, this is the first time for me in this forum, and I'm writing cause having some troubles trying to use my VRI M-Panel whit some add-on aircraft using the new facilities of your FSUIPC 4.60 (updated to 4.61). Speaking for example about F1 ATR72 FSX version, it seems to be not a problem to program all the autopilot functions in the button/switches section of FSUIPC, especially using the mouse macro function (the only way for some panels), but the broblem arise during the use of the programmed functions. In particular using the keys of the AP/C section of M-Panel, it happens that, for example, if I select HDG and press the rotary, the function is selected, but when I'm turning the knob to change hdg value, something from FSX came back to the panel changing my function selection that become itself SPD or maybe VS, so its impossible for me to have a steady selection of the vertical modes to operate correctly. Leaving apart the problem of the misleading of the indicated value for som parameters (I knew that possibility from VRI docs), what I'd like to find, is a way to filter maybe via FSUIPC this feedback from the simulator that is actually forcing an undesired "self preselection". I'd like to specify that if I use simply programmable keys of my Logitech G11 keyboard, all the mouse macros of FSUIPC works very well and without any problem, so I Know it's not a problem of your perfect module, but of the "closed source" program of the F1 autopilot gauge VS VRI panel, but at the moment I'm trying all the ways. I already wrote to Andy, and he saw similar problems during his tests, but had no solution from the VRI side, so suggested me to ask you if some trick is possible from FSUIPC side. If some log is needed to investigate I'll send you asap. Thank you in advance. Mauro
Pete Dowson Posted August 11, 2010 Report Posted August 11, 2010 ... Speaking for example about F1 ATR72 FSX versionwhen I'm turning the knob to change hdg value, something from FSX came back to the panel changing my function selection that become itself SPD or maybe VS Sorry, can you clarify that please. Are you saying that when you change the A/P Heading the SPD or V/S values are also changing in FS? Or only on your panel, so that the panel then no longer matches FS? ... what I'd like to find, is a way to filter maybe via FSUIPC this feedback from the simulator that is actually forcing an undesired "self preselection". If you stop those (which is perfectly possible if you know the parameter format) then you will stop FSX values being shown correctly on the panel. Surely this is undesirable! You then cannot realy on the M-Panel and will always have to refer to the FS screen instead! I'd like to specify that if I use simply programmable keys of my Logitech G11 keyboard, all the mouse macros of FSUIPC works very well and without any problem, so I Know it's not a problem of your perfect module, but of the "closed source" program of the F1 autopilot gauge VS VRI panel, but at the moment I'm trying all the ways. The VRi Panel is only reading and showing the values it gets from FS, surely? I don't understand where it could be getting incorrect values from. I already wrote to Andy, and he saw similar problems during his tests I have an M-Panel here and haven't seen any problems with it. Is it related purely to the add-on aircraft you are using? Of course I've only ever tested it with default aircraft. I really don't see how VRi can support many of the add-on aircraft with their non-standard non-FS autopilots. If some log is needed to investigate I'll send you asap. If you simply want to stop the VRi device displaying FSX values, then you simply filter off the commands it receives telling it to do so. However, I'm not sure you'll be pleased with that. If you know how to get the correct values to be displayed then you could write a Lua program which "corrected" them. With some add-on aircraft which do their own thing there is no way to read the A/P values - PMDG aircraft are like that. I don't know if the F1 ATR72 is as bad. To block them you need to use the VRi Lua facilities provided by FSUIPC, as documented in the "Lua Plugins for VRInsight Devices" document provided. You may already be using the example shown there to get the M-Panel pressure display showing optionally in hectoPascals or inches rather than only inches. If not, do so now, then simply add lines like the following to stop the driver setting the displays: WrFilter.2=SPD? WrFilter.3=VVS+? WrFilter.4=VVS-? The strings for HDG and ALT are similarly HDG? and ALT? Regards Pete
zetato Posted August 11, 2010 Author Report Posted August 11, 2010 Are you saying that when you change the A/P Heading the SPD or V/S values are also changing in FS? Pete, what I'm trying to tell (apologize for my bad English), is that if I select HDG on M-Panel AP/C section, than I press the knob to activate, it works well, but just a little later, moving, or also without moving the knob to change hdg, often, the selection on the M-Panel changes itself from HDG mode to SPD mode or VS mode, apparently depends from which manouvre the airplane is performing, the values on FSX panel are correct, but if I'm rotating the knob to change heading, and the selection move itself on M-panel on Speed, the result is that I'm thinking to continue to change heading, but if I do not look at M-panel in that moment, I'm in fact changing the speeed request. If you stop those (which is perfectly possible if you know the parameter format) then you will stop FSX values being shown correctly on the panel. I know that, but maybe this could be the only solution, and I'd like to try. The VRi Panel is only reading and showing the values it gets from FS, surely? I don't understand where it could be getting incorrect values from.I have an M-Panel here and haven't seen any problems with it. Is it related purely to the add-on aircraft you are using? Of course I've only ever tested it with default aircraft. I really don't see how VRi can support many of the add-on aircraft with their non-standard non-FS autopilots. Sure it works perfectly with default airplanes, and I know this is a F1 ATR Panel issue, I'm just trying to have the best possibility to use this hardware also with my add-on aircraft. If you simply want to stop the VRi device displaying FSX values Thats not the point, I can simply not refer to the M-Panel display regarding non matching value, but what I'd like to optain, is a way to avoid that M-Panel is forced (by some feedback signal from F1 ATR gauge I suppose) to change itself mode during the normal use. Please, let me know if this is what is possible to do with the filter commands, and it's not only a way to avoid to display the values of parameters but without any effect on the signals are forcing the selections on M.Panel. Really thank you. Mauro
Pete Dowson Posted August 11, 2010 Report Posted August 11, 2010 ... is that if I select HDG on M-Panel AP/C section, than I press the knob to activate, it works well, but just a little later, moving, or also without moving the knob to change hdg, often, the selection on the M-Panel changes itself from HDG mode to SPD mode or VS mode, apparently depends from which manouvre the airplane is performing By "mode" here you only mean the selection of which value the dial is changing, right? If so, then I am pretty sure that is all local to the device. I've no idea why yours is doing that -- I cannot make it happen here. I don't know any command which can be sent from the PC to the M-Panel to change the selection, but maybe that's because I've no add-on aircraft. Maybe you have an early model M-Panel with some bugs in its firmware? Have you asked VRi Support? Sure it works perfectly with default airplanes, and I know this is a F1 ATR Panel issue There's where I get lost. I don't understand why an internal action would vary depending on the aircraft. Maybe the bug in the M-Panel firmware is dependent upon some sequence of commands from SerialFP2 which doesn't occur with default aircraft. If that seems to be the case, then by all means see if you can isolate a log of the sequences just prior to when you notice this discrepancy. You need to enable the VRi logging as documented (i.e. Debug=Please, LogExtras=x4). When you get the log please only show me the stuff for the few seconds before it goes wrong, else there will be too much to wade through. And tell me what you were adjusting and what it changed to in error. Please, let me know if this is what is possible to do with the filter commands, and it's not only a way to avoid to display the values of parameters but without any effect on the signals are forcing the selections on M.Panel. Since we don't know why the selection is changing I couldn't say. But you now know how to stop the display commands going to the M-Panel. Maybe there are other commands responsible for the selection change - if so, I've not seen them, but we should see them in your log. Regards Pete
zetato Posted August 11, 2010 Author Report Posted August 11, 2010 Thank you Pete, as soon as I'm able to perform some tests will record a log for the few moments the problem appears and then I'll post to have your opinion :wink: I'm already in contact with Andy from VRI (I know he reads this forum too), and he suggested me to contact you, but anyway, a "brain conjunction" maybe will found something interesting also for other users with similar add-on issues :D See you soon!
zetato Posted August 11, 2010 Author Report Posted August 11, 2010 Hi Pete, here some part of the log file: In this point I'm in flight and inserting AP 444431 VRI command APMMST+ trapped as Joy 260 Btn 8 Press (On) 444462 Button changed: bRef=0, Joy=260, Btn=8, Pressed 444462 [buttons] 1=H260,8,K90,8 444462 SendKeyToFS(0000005A=[Z], KEYDOWN) ctr=0 444478 Sending WM_KEYDOWN, Key=90 (Scan code 44), Ctr=1 444509 KEYDOWN: VK=90, Waiting=0, Repeat=N, Shifts=0 444509 Macro: mouse action="F1ATRB.DLL":X8110*Xa100 444509 .. This key is programmed in FSUIPC4 'Keys' options 444509 *** EVENT: Cntrl= 65792 (0x00010100), Param= 0 (0x00000000) AUTOPILOT_ON 444509 *** EVENT: Cntrl= 66069 (0x00010215), Param= 0 (0x00000000) YAW_DAMPER_ON 444540 VRI com3 <--- DSP4 84% [to Device] 444618 *** EVENT: Cntrl= 66124 (0x0001024c), Param= 99900 (0x0001863c) AP_ALT_VAR_SET_ENGLISH 444618 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 2204 (0x0000089c) AP_VS_VAR_SET_ENGLISH 444618 *** EVENT: Cntrl= 65808 (0x00010110), Param= 0 (0x00000000) AP_ALT_HOLD_ON 444852 VRI com3 <--- DSP4 84% [to Device] 444930 *** EVENT: Cntrl= 66036 (0x000101f4), Param= -3000 (0xfffff448) AP_VS_VAR_SET_ENGLISH 445117 VRI com3 <--- DSP4 84% [to Device] 445226 *** EVENT: Cntrl= 66036 (0x000101f4), Param= -3000 (0xfffff448) AP_VS_VAR_SET_ENGLISH 445445 VRI com3 <--- DSP4 84% [to Device] 445507 *** EVENT: Cntrl= 66036 (0x000101f4), Param= -3000 (0xfffff448) AP_VS_VAR_SET_ENGLISH 445726 VRI com3 <--- DSP4 84% [to Device] 445788 *** EVENT: Cntrl= 66036 (0x000101f4), Param= -3000 (0xfffff448) AP_VS_VAR_SET_ENGLISH 446022 VRI com3 <--- DSP4 83% [to Device] 446084 *** EVENT: Cntrl= 66036 (0x000101f4), Param= -3000 (0xfffff448) AP_VS_VAR_SET_ENGLISH 446318 VRI com3 <--- DSP4 83% [to Device] 446412 *** EVENT: Cntrl= 66036 (0x000101f4), Param= -3000 (0xfffff448) AP_VS_VAR_SET_ENGLISH 446630 VRI com3 <--- DSP4 83% [to Device] Note that the string AP_VS_VAR_SET_ENGLISH is always present in all the log parts when there are no other parameters to be displayed So far this point seems all ok on FSX an M-panel. Now I'll select AP/C mode on 4 way switch, and all is already ok. 460234 VRI com4 <--- FUNAPCTL [to VRI Driver] 460234 VRI com3 <--- DSP4 84% [to Device] 460374 VRI com3 <--- FUNAPCTL [to Device] 460468 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 2899 (0x00000b53) AP_VS_VAR_SET_ENGLISH 460530 VRI com3 <--- SPD060 [to Device] 460733 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 2806 (0x00000af6) AP_VS_VAR_SET_ENGLISH 460827 VRI com3 <--- ALT99900 [to Device] 461029 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 2704 (0x00000a90) AP_VS_VAR_SET_ENGLISH 461123 VRI com3 <--- VVS+270 [to Device] 461310 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 2588 (0x00000a1c) AP_VS_VAR_SET_ENGLISH 461451 VRI com3 <--- VVS+260 [to Device] Now, here in the middle I tried to preselct HDG mode pressing the COM/HDG button, but each time I released that button the "underscore" sign has moved itself below the VS indication on display. The log seems have no trace of what I tried to do. 476583 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 2486 (0x000009b6) AP_VS_VAR_SET_ENGLISH 476895 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 2482 (0x000009b2) AP_VS_VAR_SET_ENGLISH 477175 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 2477 (0x000009ad) AP_VS_VAR_SET_ENGLISH 477425 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 2472 (0x000009a8) AP_VS_VAR_SET_ENGLISH 477737 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 2468 (0x000009a4) AP_VS_VAR_SET_ENGLISH 478002 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 2463 (0x0000099f) AP_VS_VAR_SET_ENGLISH 478299 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 2458 (0x0000099a) AP_VS_VAR_SET_ENGLISH 478579 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 2453 (0x00000995) AP_VS_VAR_SET_ENGLISH 478829 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 2448 (0x00000990) AP_VS_VAR_SET_ENGLISH 478876 VRI com3 <--- VVS+240 [to Device] 479125 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 2444 (0x0000098c) AP_VS_VAR_SET_ENGLISH 479406 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 2440 (0x00000988) AP_VS_VAR_SET_ENGLISH 479749 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 2437 (0x00000985) AP_VS_VAR_SET_ENGLISH 479999 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 2435 (0x00000983) AP_VS_VAR_SET_ENGLISH 480280 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 2435 (0x00000983) AP_VS_VAR_SET_ENGLISH 480561 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 2435 (0x00000983) AP_VS_VAR_SET_ENGLISH 480857 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 2435 (0x00000983) AP_VS_VAR_SET_ENGLISH I was no able to select HDG mode at all, cause the selection was always moving to VS without give me the time to press the rotary knob. Let me know if those logs are showing something of interesting, and in case, tomorrow evening, I can retry until able to insert HDG SEL to see whats yhe log will record also after that action. Thanks. Mauro
Pete Dowson Posted August 11, 2010 Report Posted August 11, 2010 In this point I'm in flight and inserting AP Sorry, what does "inserting AP" mean? Note that the string AP_VS_VAR_SET_ENGLISH is always present in all the log parts when there are no other parameters to be displayed No. the string is the name of the FS control, equating to control number 66036. You or something is constantly setting the V/S -- presumably the A/P is doing this dynamically as part of its vertical path control (for speed or altitude maintenance). However, even though it is stable as -3000 it seems to keep sending it to FS in any case. That is a bad part of the add-on aircraft design and is probably one of reason your problem is more obvious on that add-on aircraft. However, as shown below, it could happen with default aircraft too as there does indeed seem to be a bug in the M-Panel firmware. So far this point seems all ok on FSX an M-panel.[/qNow I'll select AP/C mode on 4 way switch, and all is already ok. 460234 VRI com4 <--- FUNAPCTL [to VRI Driver] 460234 VRI com3 <--- DSP4 84% [to Device] 460374 VRI com3 <--- FUNAPCTL [to Device] 460468 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 2899 (0x00000b53) AP_VS_VAR_SET_ENGLISH ... This is nearly 14 seconds later. Evidently the aircraft is now climbing instead of descending -- the V/S is being set to +2899 etc ... 460530 VRI com3 <--- SPD060 [to Device] 460733 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 2806 (0x00000af6) AP_VS_VAR_SET_ENGLISH 460827 VRI com3 <--- ALT99900 [to Device] 461029 *** EVENT: Cntrl= 66036 (0x000101f4), Param= 2704 (0x00000a90) AP_VS_VAR_SET_ENGLISH 461123 VRI com3 <--- VVS+270 [to Device] The aircraft is changing the V/s and the altitude target (99,900 is set so high as target so that the V/S is maintained until changed, rather than reducing 500 feet from a target altitude). Now, here in the middle I tried to preselct HDG mode pressing the COM/HDG button, but each time I released that button the "underscore" sign has moved itself below the VS indication on display.The log seems have no trace of what I tried to do. Yes, it does. It shows quite clearly that the V/S, and once the Altitude, was changed and continues to be changed. I was no able to select HDG mode at all, cause the selection was always moving to VS without give me the time to press the rotary knob. The bug appears to be in the M-Panel firmware. It seems to automatically select the last value sent by the PC. It should not do that. Report it to VRi, get an update for the firmware (if they can do such things). [bTW I think Andy is not part of VRi, but an enthusuastic and helpful user who voluntarily maintains the Forum] Tomorrow, if I have time, i will see if I can reproduce it with a default aircraft. It should do the auto-selection if I use the V/S adjuster on screen and i should see the selection move away from what I wanted to adjust on the M-Panel. If it happens on mine it is a general firmware bug. If not it may depend on the version. Unless you can get the M-Panel fixed I'm afraid the only answer is to block the commands from the SerialFP2 driver to the M-Panel as already discussed. It is rather a serious deficiency in what is otherwise a nice little product. I might try it also on the MCP-Combo device, just to see if it suffers the same way. Regards Pete
zetato Posted August 12, 2010 Author Report Posted August 12, 2010 Ok Pete, so like supposed the M-Panel (maybe cause a bug in the firmware) take care about the continuos V/S setting coming from F1 ATR Autopilot. Sorry, what does "inserting AP" mean? I was intending "Engaging Autopilot" presumably the A/P is doing this dynamically as part of its vertical path control Yes, I think so, and the same thing happens on E-Jets from Wilco if I use the FLCH (Flight Level Change) function on the Aircraft panel, in fact, in that case on the M-Panel display, the preselection changes itself between SPD, ALT and V/S dinamically. even though it is stable as -3000 it seems to keep sending it to FS in any case. That is a bad part of the add-on aircraft design and is probably one of reason your problem In fact, at that moment I had no vertical mode engaged, only A/P master, I think anyway it works as "Attitude Hold" Yes, it does. It shows quite clearly that the V/S, and once the Altitude, was changed and continues to be changed. Yes, V/S and AlT are changed due to an uncontrolled pitch attitude (I was checking on second monitor the log console), but I'm not able to see the log of my keypress on COM/HDG button. The bug appears to be in the M-Panel firmware. It seems to automatically select the last value sent by the PC. It should not do that. Report it to VRi Will do Pete :wink: Tomorrow, if I have time, i will see if I can reproduce it with a default aircraft. Many thanks to your attention! Unless you can get the M-Panel fixed I'm afraid the only answer is to block the commands from the SerialFP2 driver to the M-Panel as already discussed. It is rather a serious deficiency in what is otherwise a nice little product. In case I'll try to block it (hoping to be able), and yes, I agree that M-Panel is really a nice product, and thats the reason that is forcing me to find a way for use it also with add-on aircrafts :D Thank you for now, I'll mantain you informed about any new! Ciao Mauro
Andydigital Posted August 12, 2010 Report Posted August 12, 2010 I might try it also on the MCP-Combo device, just to see if it suffers the same way. It doesn't effect the MCP Combi at all, its only an issue with the M-panel and only with aircraft that use advanced custom auto pilots that make many changes to the VS. If it does require a firmware update rather than a SerialFP2 software update then you are stuck as VRI has already said in no uncertain terms that they cannot have users updating firmware in the field because the risk of bricked hardware is very high. I'm going to the AstrasimExpo at RAF Cosford later this month and the software developer for VRI will be there so I will be able to speak to him in person, I'll have a chat with him and see if anything can be done. Will you be going Pete?
zetato Posted August 12, 2010 Author Report Posted August 12, 2010 Hi Andy, happy to see that you already read this discussion. So do you think to have mode to speak directly with the software developer? Do you think is needed for me a contact with Tech support or can I wait some news from you? I'm always ready for any test, and thank you for all :wink: Mauro
Andydigital Posted August 12, 2010 Report Posted August 12, 2010 Please still contact them and explain as best you can what the problem is, then hopefully he will get chance to look into it a little before he leaves Korea for the UK.
zetato Posted August 12, 2010 Author Report Posted August 12, 2010 Ok, will do this afternoon!! Thank you :wink: Mauro
Pete Dowson Posted August 12, 2010 Report Posted August 12, 2010 It doesn't effect the MCP Combi at all, its only an issue with the M-panel and only with aircraft that use advanced custom auto pilots that make many changes to the VS. So it's related to the number of requests reaching the M-Panel? Some sort of overrun causing corruption internally then. If it happened on just any old change in the aircraft then it should be noticeable more often, with default aircraft too. [LATER] No, it isn't related to the number of requests at all. I've just tried it with the default FSX 737. If I show the A/P settings on the M-Panel, with any of the 4 items selected, ready to be adjusted, then adjust one of the other values on screen, even a single change makes the M-Panel select that item, so that if you are operating the knob to adjust something when FS, for any reason, changes one of the others, you get in a mess. This is most certainly a deliberately designed action, not a bug, but it is an incorrect design decision on VRi's part. Certainly they did not make the same mistake on the MCP Combi, as you said and as I've just proved to myself. ;-) If it does require a firmware update rather than a SerialFP2 software update then you are stuck as VRI has already said in no uncertain terms that they cannot have users updating firmware in the field because the risk of bricked hardware is very high. I'm afraid it does make the M-Panel much less worthy that I originally thought. Such a shame for what is otherwise a neat gizmo. Perhaps they should be persuaded to work out a way of updating firmware without "bricking" it. I'm going to the AstrasimExpo at RAF Cosford later this month and the software developer for VRI will be there so I will be able to speak to him in person, I'll have a chat with him and see if anything can be done. Will you be going Pete? No, not Cosford, but I am going to the Battle of Britain Show as Duxford on the 4th September. There's a FlightSim show there -- Flight1's I think. I usually see the VRi folks at the Lelystad show in November, but I've decided to go only every other year now, as the last two years were much the same and I got rather bored being there the whole weekend! ;-) Best Regards Pete
Andydigital Posted August 12, 2010 Report Posted August 12, 2010 I use the M-panel in combination with the MCP so this issue doesn't really cause me any problems and many of the aircraft I use still use the default autopilot and it doesn't cause any problems in those aircraft for me. I do tend to use the M-panel more often on its own when flying small GA aircraft and just use the buttons on the MCP for switching things on and off, in this situation the M-panel works very well. To be honest if people want to fly advanced aircraft more often than not then I think the MCP is definitely a better purchase for them anyway. I will discuss it with the dev when I see him at the show though.
Pete Dowson Posted August 12, 2010 Report Posted August 12, 2010 I use the M-panel in combination with the MCP so this issue doesn't really cause me any problems and many of the aircraft I use still use the default autopilot and it doesn't cause any problems in those aircraft for me. Actually, after more experimentation, I see why. The selection changes to the last value sent from the PC, but then changes back to your current selection. It is quite quick (though I can see the user occasionally catching it so it stays updating the wrong value). The problem, more obvious with A/P implementations which are constantly manipulating things like V/S, is that the selection will not have time to revert to the user's choice before the next value is in. The ATR example in this thread is actually worse again because the implemented A/P seems to be sending V/S settings to FS even when there is no need, when there's no change occurring, as illustrated by the repeated settings of 3000 in the log. That's just poor implementation in the aircraft. Unfortunately there's no indication sent to the PC when the user selects a particular entry. If there were I could deal with it in a Lua plug-in -- by saving copies of any V/S or other values sent whilst the user is causing other values to be sent, and only sending the new VS (or whatever) when things have been quiet for a while (half second or so, maybe). Actually that could be done anyway, I suppose. It wouldn't be foolproof of course. A hesitation of half a second doesn't mean the next change won't occur immediately I try updating the VS (or whatever). Maybe I should offer Mauro a Lua plug-in with this attempted to see if it helps? To be honest if people want to fly advanced aircraft more often than not then I think the MCP is definitely a better purchase for them anyway. Yes, i cannot disagree. It's a nice piece of kit. The really admirable thing about the M-Panel is how much functionality they've managed to package into such a small unit. Good for those with little space! ;-) Pete
Andydigital Posted August 12, 2010 Report Posted August 12, 2010 Maybe I should offer Mauro a Lua plug-in with this attempted to see if it helps? Mauro said he would be happy to test stuff so I'm sure he wouldn't mind helping, thanks Pete.
Pete Dowson Posted August 12, 2010 Report Posted August 12, 2010 Mauro said he would be happy to test stuff so I'm sure he wouldn't mind helping, thanks Pete. Er .. it would be me helping him, wouldn't it? I don't need any help as I don't actually use the VRi devices! ;-) I'm trying something now. After I wrote the last message I had some doubts, so I'm doing an experiment. Pete
Andydigital Posted August 12, 2010 Report Posted August 12, 2010 What I meant was that I would have thought Mauro wouldn't mind testing the Lua for you once you have made him one to test, or is that not what you were getting at? Then I was just saying thanks for helping Mauro with his problem.
Pete Dowson Posted August 12, 2010 Report Posted August 12, 2010 I had some doubts, so I'm doing an experiment. This seems to mostly work, but needs checking in a real environment with an add-on aircraft. First implement the "VRI_SetBaro" example as in the VRi Lua plugins document. But in the FSUIPC.INI file change the line "Lua=VRI_SetBaro" to "Lua=VRi_SetBaroEtc". don't have any other filters than those shown in the example. Then put the VRi_SetBaroEtc.lua plug-in from the attached ZIP into the FS Modules folder. Run FS and seehow it goes. It won't be perfect, but it might help. You may need to adjust the delay -- the line if (ipc.elapsedtime() - timeinput) < 500 then operates the half second delay. For more increase the 500, for less decrease it. Regards Pete VRI_SetBaroEtc.zip
zetato Posted August 12, 2010 Author Report Posted August 12, 2010 Oh, sorry for the late, I was away. I'll try immediatly and will give you a feedback asap. Thank you both for now! :D
zetato Posted August 12, 2010 Author Report Posted August 12, 2010 Pete, you're on the right way! At the moment I had a sure improvement after setting the delay value to 100 ms (I was expecting the opposite reducing that but.....) There are already some self changes in selection, but now AP/C functions are usables also with the "hard to convince" F1 ATR Autopilot. I'll continue to test now and then tomorrow evening, if you have some other ideas let me know Many many thanks for your effort, I sure was not able to write the Lua plugin, but reading it I understood most of what you've done! Thank also to Andy, supporting me in this tests, I know MCP is the best, but when I get M-Panel, money were not enough for the bigger brother. Anyway I'll continue to test, and sorry if will be back again to disturbe you both, you've been very kind :D If you need some test, explanation or log from me for any purpose write me immediatly! Mauro
Pete Dowson Posted August 12, 2010 Report Posted August 12, 2010 At the moment I had a sure improvement after setting the delay value to 100 ms (I was expecting the opposite reducing that but.....) There are already some self changes in selection, but now AP/C functions are usables also with the "hard to convince" F1 ATR Autopilot. Okay. I knew it couldn't be perfect -- there are bound to be times when your adjustments just occur at the wrong time in relation to the aircraft's changes. But as long as it is better, I am glad. I'll continue to test now and then tomorrow evening, if you have some other ideas let me know No others. Even if you programmed it all yourself, not using SerialFP2, you could not overcome the fact that writing to the V/S display (or any of the others) causes the selector to move to that value, even if only for a short time. That action is done within the M-Panel's firmware, so you cannot program around it from outside. Regards Pete
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now