Pete Dowson

Strange, because my friend, the one with the Cirrus, seems to find it working now. Unfortunately you appear to have the Logging options all wrong now so I can't see why it is wrong. Please set them like this: [Debug] Console=No LogComms=no LogData=No LogDecode=Yes LogDevices=yes LogDeviceChanges=no LogToDebugger=No LogIPCwrites=Yes LogTxData=No LogReadCounts=No LogMacroNames=Yes Pete

I like paper copies too. Incidentally, the Lua language, as used in the Plug-Ins, is not of course documented by me, but full documentation and help is available on the Lua website. There's a reference to this place in my Lua documents. I've actually purchased several of the printed Lua guides and manuals which i've found invaluable. They are available through sites like Amazon. Pete

Okay. But in that case look in the Lua files provided in your "FSUIPC Documents" folder, in the Modules folder. The manuals are there, plus a ZIP of different working examples. Pete

I don't know what that means, but there are facilities to drive it directly in the FSUIPC Lua "gfd" library. I suspect they are just talking about their own software. Hmm, he must have dropped the boards with outputs on them, as I'm sure they used to be listed. There are lots of other makers though, or you could go to an Arduino board. Just using Lua doesn't give you control of lights. you still need some hardware interface. It would be that you'd need to program, and depending what you end up with it might come with an interface you can use directly in any case. Most control boards made to interface to FS use FSUIPC offsets. I think you should go and check out the various advertisers in www.mycockpits.com, or chat to folks in the forums there. What do you mean by "had Lua up and running"? Lua is built into FSUIPC, so it is "up and running" as soon as you have FS running with FSUIPC installed! Er, where did you get this "MenuDemo" plug-in from? It isn't one of those installed with FSUIPC. And there are no La files "listed by default" in the INI file. If you mean the [LuaFiles] section, that is created dynamically from the Lua files found in your Modules folder. It serves to relate numbers to names when referenced in assignments, that's all. I loaded up FSX ,went to FSUIPC4 – Buttons and switches, selected a switch to open your lua file, filled in “Lua MenuDemo” in both sections where it says “Control sent when button pressed” and pressed OK. Both sections? There's only one for "press" -- the other's for "release". You'd have the thing be run/killed/run again with one press/release action. Why would you want that? Perhaps that's what the MenuDemo lua does? I don't know without looking at it. Where did you get it? I think you need to sit down and read about these facilities before you start messing. none of those run a plug-in, they are concerned with controlling an already running one, that's all. You seem to be miisunderstanding nearly everything. What menu on screen are you expecting? What do you think this plug-in you selected (at random?) does? I am confused by what you are trying to do here. Pete

petedowson@btconnect.com

I don't know SB at all, neither SB3 nor SB4, but I always thought part of it had to be run on the FS PC? I know SB4 uses Simconnect, but aren't there still some DLL modules which need to load directly into the FS process? There are two ways to talk to SB4. For PTT one is by the ex "Roger Wilco" messages, sent directly to the SB process. And that part, I think, is the same for both SB3 and SB4. For a Networked PC that's handled by WideClient. You don't say anything about having WideClient on your SB PC though? SB4 also uses Client Data, which works through SimConnect, but I've a feeling FSUIPC only uses that method for the transponder mode and ident actions. Pete

I'm here most days, except when on holiday (and notices of that are posted in Announcements). Did you want to talk privately, or is it just a support matter? Pete

How do you work that out? The INI file sees two different X-55 installations: 0=Saitek Pro Flight X-55 Rhino Throttle 0.GUID={FB4BBC80-F235-11E3-8007-444553540000} 1=Saitek Pro Flight X-55 Rhino Throttle 1.GUID={FB4CCDF0-F235-11E3-8008-444553540000} How you arrived at that I don't know, but maybe you are trying to assign "the wrong one". I suspect you should uninstall both of them (using Widesows' devce manager) and let it be re-installed. If there's still a problem it's to do with the way the Saitek drivers install -- a matter for Saitek support. Regards Pete

One other thing. I just realised that the format of your macros may be incorrect: The format documented for macros normally includes a parameter, so all your lines should have ,0 or whatever at the end, like: 14=Avionics=C1126,0 Maybe I should or do assume 0 if omitted, but I'm not sure without checking. The format laid down (it is in the FSUIPC Advanced User's manual) certainly doesn't say you can omit the parameter, even if in this particular case it doesn't matter. FSUIPC always has to send a parameter in any case and it is better being explicitly 0 than some random number. Pete

Before I go storming off to alter code for more logging, there's some obvious checks we could do as it stands: Looking at the documentation, I can see immediately that "LogDecode=Yes" and "LogMacroNames=Yes" would be useful as it stands. The first should already be set, so you will already have logs showing whether the decoding action is correct. Perhaps you can enable the macro names one too for me, and show me the result of, for example, operating your Avionics switch. Also, without even adding any options, there will be a "PFCmacroindex.csv" file produced -- please show me that. this shows which commands have macros assigned. [LATER] Okay. Checking back on the recent history of PFCHID, and subject to receiving confirmation from him, that friend of mine was happily using macro files, fully working, with PFCHID version 1.36. He's now on 1.37, which is the same as 1.36 but with multiway switch support (i.e. the capability of invoking different macros for different positions on the one switch). I've taken 1.37 (which wasn't released generally) and added some extra logging in places where a choice of macro file is being made, and when it is being read (macro files are re-read if they are edited even without the aircraft selection being changed). It is now version 1.39, and is available in the Download Links subforum. Please use that and show me the logs. [LATER STILL] My friend says it selects the correct macro file and uses to to start with, but if you change aircraft it doesn't appear to change to the correct file. very odd. I thought this was the very bug fixed back in Version 1.34! I shall look at this in detail tomorrow. I hope to see your logs by then? Pete

The Lua plug-in facilities do provide programming for serial ports and standard Windows HID USB devices, but it isn't straightforward either way. You'll need to learn how to program whatever board you do get. I'm afraid I don't know much about any hardware OUTPUT boards. I do use some Leo Bodnar input boards for switches and dials. I know he does also make output boards for lights and displays too. One easy solution, but not so cheap I fear, is the GoFlight digital input/output board -- GF-DIO. This can be driven directly using the gfd library, in the Lua provisions in FSUIPC. See http://www.goflightinc.com/collections/modules/products/gf-dio-digital-input-output-board. Ah, you know about Bodnar boards then. He does do output/display control boards too I think. But they would need programming. The BU0836X boards are easy because they emulate a standard joystick type device. Hmm. The GF-DIO board is way way too expensive just for 9 lights. You need to go for the cheapest solution you can find. There is of course the GoFlight WP6 with 6 warning lights, again with built-in support in Lua. BTW if you had an older PC running XP, you could have connected it to the FS one in a Network and used WideFS to link up your TRC gauges and so forth. I'm using several small PCs running XP in my cockpit for the gauges and displays, and for most of the switches and so on. Only the main control axes are connected directly to the FS PC. Regards Pete

Well, as I said, I'll take a look when I get a chance. First I'll look at the documentation, which I think you'll find does list a number of logging options, some of which I'm sure would be useful. The INI file probably even lists them with their default "off" or "no" settings, I don't recall at present. But if the logging isn't currently sufficient I will look at adding more. Meanwhile I shall also ask a friend who have the Cirrus 2 Pro to check things out on his for me. I'll get back to you within a day or two. Pete

But the switches, like the avionics one, still does what it is supposed to do by default? Obviously if the codes reaching the driver are wrong, it can't select from the MCRO file in any case. The "Macro problem" which i fixed was to do with occasional incorrect selection of the macro file for specific aircraft -- the actual execution of the macros was correct, but it sometimes was not reading the aircraft name and switching files. That's why I've been asking you to try these other macro file namings. Maybe that would be best, but I'd like to be sure the driver is doing the right thing. I'll get back later when I've looked at the logging available. Is it only the "do nothing" control not working? Surely if you assign to an operative control it works? That's the whole point of the macro files, and has always been used to program the switches for other things. There would be very many more support requests here if that all suddenly stopped working, so maybe the correct codes aren't being seen. That should be easy to check with logging. Pete

The Installation and Registration document which was included in the ZIP you download containing the FSUIPC Installer tells you what you get and where it is installed. You mean you want to program an FSUIIPC application? For that you need the FSUIPC SDK, available in the same places as the FSUIPC download -- i.e. here in the Download Links subforum, and over in www.schirati.com/dowson. Pete

Okay. I will look to see if there are logging facilities incorporated which will help me see what is happening. It is getting late here now, so it won't be till later tomorrow at the earliest. Meanwhile, one more test, please. Try with your CUB mcro file as PFC.mcro, and with a default INI file -- i.e. no special aircraft sections. If there aren't logging features which are likely to tell me what is happening, I will add some and give you a test version so we can find out. I don't really understand what could be going on because this was all working, so i am puzzled. Pete

You realise 1.36 is the current version? What do you mean "again". Were they not working, then working, then not working? Please explain. It is no use saying such things with no explanation! So, is the problem you are reporting that the "do nothing" command doesn't "do nothing", or that the CUB.MCRO file is not being selected? For example, what happens if you select the CUB file as the default in the PFC.INI file, or rename (temporarily of course) the CUB file as PFC.MCRO? What if, instead, you assign "Avionics" to something which does something else, other than "do nothing". Does that work? I need to ask these questions because I no longer own any PFC equipment on which i can test these things. You have to do the testing I'm afraid. And PFC themselves seems to have moved a long way away from all this stuff. Pete

This does look like an error in WideClient. How did you "come to understand that this problem was WIDEFS"? How do you decide that? In any case, I would need the Version number of the WideClient you are using, and the WideClient log file. Also, the Windows event viewer data for the error, as there is insufficient information in your picture. And why would you even be considering reformatting your PC just for an error on shut down which therefore obviously does not matter very much as it doesn't affect anything? Or am i misunderstand your words? Pete

Sorry, I think it must have been someone else. I wouldn't know how to record a flight let alone replay one. I think there's an add-on "FSrecorder" program, but I've never used it. Certainly nothing in Lua has anything to do with flight recordings. Searching posts from you in this Forum, the only other time you've ever talked to me was in this post: http://forum.simflight.com/topic/75430-thanks-pete/ last October. I see nothing to you regarding flight recording. Regards Pete

Yes, good idea, actually. Beware of using any control which may have an adverse effect even though it looks like it shouldn't. Better probably to use a custom control number -- i.e. well outside the FS range. Avoid those used by PMDG too. their 737NGX uses a fair few above the normal FSX range. Yes, the Lua function event.control can be used to receive the control and its parameter. Pete

No. Windows default core scheduling should be as good if not better. Most of what FSUIPC has to do must be run in the main FS thread or it won't work. In fact 95% of what FS does in in one main thread, and there's no way of splitting it. FSUIPC does use a few separate threads, but apart from those dealing with Networking (for WideFS) they a very small and do very little. Anyway trying to assign individual threads within a single process is generally not a good idea -- things can get much worse that way. It's other processes you want to keep off. Most of the Windows base processes run in core 0 so with FSX use an affinity mask setting which avoids core 0. If you want better sharing out of cores you'd be better off moving to P3D where they have made some improvements in that area, as well as shifting graphics work to the GPU. . FSX was never designed to take much, if any, advantage of multiple cores. Disconnects are not anything to do with FSUIPC and nothing it can do about. They seem very very prevalent with Saitek devices. I don't know if that's just because they are so popular and therefore used a lot, or if they are really so bad, but I rarely if ever see anyone saying any other makes disconnect. I don't use Saitek at all and have never ever had any disconnection problems. Of course i am using Windows 7, which is probably the most important difference. Pete

Version 4.911 is well out of date and unsupported. You need to update. Version 4.934 is the oldest currently supported. Why "on the Internet"? What is wrong with using the documentation supplied for FSUIPC? Do I waste my time writing it all? What performance, exactly, would you expect? An outer marker is a transmitter. You RECEIVE a signal, not SEND one! It's an input not an output to be controlled by a button! You said Surely lights are lights, not buttons? How does programming buttons deal with warning lights? You seem to have things backwards. To drive warning lights you need to READ values from FS and WRITE to your hardware boards to light the lights! Yes, and all of those are read-outs, values which tell you the state of that thing, be it a signal, setting or whatever. What do you hope to happen by WRITING to those offsets by pressing buttons? Don't you see, it makes no sense! You can certainly use the offset setting controls to send INPUTS to FS, for controlling things you can control. How you expect to use buttons and switches to make warnings happen, i don't understand. The warnings and so on are results of other things going on, they are OUTPUTS from FS, there in the offsets for you to read and take action upon (like lighting a light, for example). Obviously, in order to do that you'd need to READ the offsets values and use the result to WRITE to your hardware. This needs a program. Yes, it can be done as a Lua plug-in, or it can be written in Basic, or C, C++, and almost any programming language. The Lua facilities are explained in the installed documentation you already have, and the main programming interface is explained in the FSUIPC SDK. Regards Pete

The PFC.MCRO file is just another macro file and abides by the rules for those as described in the FSUIPC Advanced User's guide. I'm afraid the .MCRO file format, and the internal tables these files generate, don't cater for Lua plug-in execution. The problem is that there's really only room for one name, the macro name (which can be an L:Var name, distinguished by the L: part). I suppose it would be conceivable to have another name format for macros -- which would need to be something different from "Lua name" because that entry would occur in the drop-down list for assignments already. However, it would be a complex change which I'm not really willing to undertake at this stage. If you really want to run a plug-in (or use any Lua-related controls, like LuaValue or LuaSet) from a macro file entry the only way I can think of achieving this would be to use the controls to send a unique key press combo and program that in FSUIPC's Keys tab to execute the relevant Lua function. Sorry, I know it isn't very elegant. If i can think of an easier way to implement this I'll do so, but it's not cropped up before. And I'm afraid the code for processing Macro files is now so old I'd be scared stiff of wrecking it if I started messing now. Regards Pete

That's odd, because FSUIPC does do a re-scan when you enter the relevant options screen, whilst with FS once a control is disconnected it is normally necessary to restart FS to get it seen again. The calibration tab works with FS controls, no matter where they come from, so if you assigned things in FSX the calibration is still active. It is nothing to do with assignments, they are two distinct functions. Is the AutoScanDevices parameter in the INI file set to "Yes"? I also ALWAYS need to know the version number of FSUIPC please. If not the latest try updating. Not similar if nothing, neither FSUIPC nor FSX saw them. I'm afraid I am very doubtful that FSUIPC can "fix" bugs in Windows 8 and Saitek drivers. I don't know who's been spreading such rumours, but none has ever emanated from me. FSUIPC does virtually the same thing as FSX, using the same Windows interface etc. I really don't see why there could be any difference. Pete

Try FSUIPC4934dTest.zip. It is somewhat between the original and the last one. You can also vary its polling rate yourself, to try to get better than the default. The parameter PollInterval=10 in the main [Axes] section tells FSUIPC to poll all axes at 10 mSec intervals (i.e. 100 times per second). That's always been the default. You can try faster polling (minimum value here is 5 mSecs, or 200 times per second), but you may be better to try any higher value to poll less frequently. On my test system, '5' definitely impacts frame rates, but I see no difference in axis smoothness nor frame rates between, for example, 10 and 20 (100 pps and 50 pps). I think FS's poll rate is a lot slower, around 20 pps or less (a value of 40 or 50 here). BTW there is also a separate PollInterval parameter in the main [buttons] section, which controls the button polling rate, defaulting at 25 mSecs (=40 pps). You can change these values, to experiment, whilst FS is running Just edit the INI file, then go to the FSUIPC Options, and tell it to reload axes (a button on the Axes tab) to force it to re-read all of the [Axes] sections. Similar method for buttons. After this i've run out of ideas I'm afraid. Pete

Rather than pictures, why not just say what you want in the first place? It seems all you want are PMDG command to increment or decrement the ND range. Correct? Don't PMDG provide any keyboard assignable facilities for such things? It would seem very remiss of them if so. Have you checked? FSUIPC provides access to all FSX commands, and a number of extra ones which are added for convenience, but it cannot provide commands for every single differently-implemented add-on for FSX. The facility you are using is designed to send custom controls -- I assume you got the number from the PMDG document listing all of those. That same document should tell you what sort of parameters you can use. I would guess (it has to be a guess because i don't use any PMDG aircraft) that the knob is normally turned by left or right mouse clicks. See if there are parameters which do that. There are some solutions for controlling the PMDG 737NGX in assorted threads in the User Contributions subforum. You might find what you want there. Otherwise you need to go to the PMDG forum where there will undoubtedly be folks who have already done this. Pete