Pete Dowson

Okay.I see what is happening, but I din't understand why. It is not scanning the macro file initially in order to register the fact the there's a matching macroname. I don't know why it is missing that -- it does it here every time, and that works with or without a "real device" to connect to. Could you try changing aircraft, please? Maybe that will make it scan. I know the aircraft-specific selection of MCRO fles now works -- it seems to be missing that part at the beginning on yours. If that doesn't work, rename the [Config] section to be correct for your aircraft, [Config.Cessna] or whatever. I'll also try here without aircraft specific sections. Maybe it is only the default [Config] part it has a problem with. i must admit I'd not paid much attention to that in my testing as it was the selection of the correct MCRO file which was central to the original problems. Pete

The version of FSUIPC makes no difference. The FS altitude readouts have always worked, never changed. You need to go to support for your ACARs program. Pete

Please get the log again with this one (small logging changes to get more info): Same options. http://fsuipc.simflight.com/beta/PFChid140a.zip Thanks, Pete

No, don't get me wrong. I've not heard from him yet regarding 1.40. Earlier some things were working on his which didn't appear to be on yours. But the log doesn't show enough wrong (if anything wrong) with your firmware to explain how such a simple macro is being ignored. It's this latter aspect i find bewildering. It's deriving the right macro name yet not executing it. I'll do some changes in the logging and see if I can elicit more info about what is going on. Probably not today though. Pete

Okay. Something is VERY VERY strange going on. Using simulation, here, all macros are correctly obeyed. I'm waiting for a response from my friend regarding 1.40, but even with 1.39 he was getting positive results in circumstances where you get nothing. I think I'm going to have to change the logging actions substantially to find out what is going on. I find it quite unbelievable the differences at present. :-( I've obviously got a real problem having on way to test on real hardware. I'm not sure when i can get to this. I'll let you know in this thread when I have something. BTW my friend actually did find that the macro entry "1=Avionics", with no actual macro action specified at all, did succeed too in avoiding the default action. Pete

Sorry, that's the same as before. Please use these logging options: [Debug] Console=No LogComms=no LogData=No LogDecode=Yes LogDevices=yes LogDeviceChanges=no LogToDebugger=No LogIPCwrites=Yes LogTxData=No LogReadCounts=No LogMacroNames=Yes You'll need to restart FS of course. Also, it's using PFC.MCRO. Are you sure that's the one you showed me? Pete

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