Pete Dowson

You should change the "AutoAssignLetters=No" to Yes, in the [JoyNames] section so that FSUIPC uses letters, not ID numbers, to assign things. It can then track changes like that. Is the INI you supplied before or after the change? Because it looks okay, except for this spurious Button assignment: 28=U1,7,C0,0 -{Custom control: <0>}- which won't do any harm, but I suggest you delete that line in any case. On the yoke you've assigned some buttons to two functions, "Press" to one and "Release" to another. That's okay if the switch is a toggle on/off latching switch, but otherwise, if it acts like simple momentary buttons, it will cause actions you don't expect. Otherwise I can't really see anything wrong. I've not checked the Profiles though. These symptoms: don't make a lot of sense unless there are conflicts, so make doubly sure that you have turned off joystick devices altogether in P3D4 -- do not just de-assign things, as they will likely be re-assigned if it thinks you've connected something different. If you still have problems you'll need to very specific. Use a default aircraft, and note down exactly what goes wrong -- which button, what results. For the panels suddenly appearing spontaneously, if that is due to a button going wrong you can determine which by using Button/Key logging 9Loagging Tab). If you enable the Console Log too, and (temporarily) run P3D in Windowed mode (ALT+ENTER) the you can see it logged when it actually happens. Pete

Thanks for letting me know. Looks like the link is to a file which had its name changed. I've fixed it now, but meanwhile please also look in the SubForums above this main Support Area. If the one called "download Links" you can always fine the most up to date copies of all my software, including things you cannot get on the Schiratti site. The "Dowson" page on the Schiratti site is not mine and i cannot change it or edit it. Mr. Schiratti does that from time to time. But the links there point to file which reside here and which I control. But inthe SubForums I can provide much more. Pete

No, I don't think so. As I said, I tested with it unregistered and using the exact commands via the offsets which were shown in your log (last few lines) -- excepting a different pathname for the WAV file -- worked fine. It is something else in your system. Sorry, I don't know what apart from the sound driver (BIOS and/or Windows) or WAVe file it could be. It just has to be one of those. Yes, I use FSCrew's RAAS Pro, and it is very good. I started with the freeware one, but the improvements are worth it. Pete

Ah, sorry. Didn't notice it wasn't registered! I should have seen that in the Log you posted. Yes, that explains it. I just removed my .KEY file, to make FSUIPC4 appear unregistered, and tested exactly what FSRAAS20 is doing (except with a different WAV file, as I don't have that), and it worked fine. I tried both a WAV file which existed (thunder, as it happened), and that played okay, and one which doesn't exist, which just gave the approriate status back to the program. Without a sound card choice it will just use the default sound card (or motherboard option) set in Windows. So, sorry, I still think the crash is in the Windows sound system somewhere, either due to a bad sound driver or a corrupted WAV file. Pete

The code is identical in FSUIPC5 to that in FSUIPC4, but maybe there's a 32-64 bit difference I've missed. I'll have to do some tests here. Do those AlsoManage lines work okay in FSUIPC4? I'm wondering if you need "" around the complete path, because of the spaces in the folder names. (FSUIPC doesn't process INI lines directly, it uses a standard Windows function). I'll come back to this when I've done some tests myself. Meanwhile can you confirm that you are using the latest version, 5.121a? I don't want to waste time if it is something fixed by a recent change. Pete

Sorry, I don't know. I do get notifications of USB devices connecting or disconnecting. I normally take no notice except for Joysticks which are assigned, which provokes a re-scan. I suppose I could add a facility for an event to be triggered on an opened device disconnect/reconnect, if I can tie the details in the connection change notice with the device you have opened. Assuming I can it would be something like event.comconnect(dev, "function name") with thefunction being provided with a boolean indicating connection or disconnection. But I'm not sure about that. I'm wondering if the handle ("dev" here) effectively becomes invalid if the device disconnects, in any case. I'd have to investigate all this before I did anything. Of course readfeature used for this would only be of any use if you knew that the device does suppert this and always has feature data to supply. Pete

Ah, you design your own? Very clever. Do you use stock USB/HID chips? I'll put "readfeature" on my list of "things to do", but at present can't promise any timescale. It might not be till mid-October or later. Pete

Actually, I don't recall ever hearing from anyone having used even the latter. I've never had any way of testing it, apparently not having any devices with 'features'. What device are you using where these functions are useful? I see that there is indeed a "GetFeature" function in the HID API which I could use. (The writefeature function uses the API's "SetFeature"). Can I ask which version of FSUIPC you are using? I would be amenable to implementing a "readFeature" function for Lua in FSUIPC5, which is subject to full development still, but I'd be more reluctant with FSUIPC4, or is it WideClient you are interested in? Either way I'd have to ask you to test it. (Well both Read and Write, really). Pete

It's a correct file, but there's lots of it missing! It looks like it is corrupted. Typicallly, by default, the [General] section alone has 98 lines -- you have only 33 lines! And that includes the two logging ones which you presumably enabled in the Options screen. So just there are 2/3rds of the parameters missing. After the [General] section there'd be these sections before the [WideServer] section: [JoyNames], [Axes], possible [MacroFiles] and [LuaFiles], then [Buttons], [AutoSave], [GPSout], [GPSout2]. After the [WideServer] section there would be a [Sounds] section, listing the sound output facilities found. Here's mine, as an example: [Sounds] Path=E:\Prepar3D v3\Sound\ Device1=Primary Sound Driver Device2=Speakers (Realtek High Definition Audio) Device3=DELL U3415W-4 (NVIDIA High Definition Audio) Device4=Realtek Digital Output (Realtek High Definition Audio) If what you show is really the INI you obtained from the FS Modules folder, next to FSUIPC4.LOG and FSUIPC4.DLL, then it must have been corrupted. Delete it and run FS again to generate a correct one. Pete

That looks very much like a problem with the sound driver, or maybe a corrupt WAV file. Can you find the WAV file and see if it plays when you double-click it? The sound devices FSUIPC found are listed in its FSUIPC4.INI file. Check that. Make sure it is defaulting to a working sound device. Pete

Just typer Event Viewer into the Start edit area (bottom left) and press Enter! Same as finding and starting any other program Windows is aware of. Pete

So the last thing it does is ask FSUIPC to play a wave file, then FS crashes. So what does the Windows crash report show? Pete

Perhaps that's what your device needs, a string starting with a zero character. "str = string.char(0,49)" is almost the same as str = "\01". i.e. a zerobyte (\ is the escape character) and the character '1'. But the latter will also be terminated by a zero. I don't think the former is (but I don't know offhand). The string library is a standard Lua library, not my own code. You only close the device when you've finished with it. If you have no signal for this, but just want to carry on forever, then don't worry -- it will get closed when the session ends. Or you could do it in another function called by event.sim(CLOSE, "function-name") Pete

FSUIPC does not write to fuel levels, whether registered or unregistered. There are no facilities in FSUIPC to maintain fuel levels unless a client program does so by using FSUIPC to write to fuel offsets -- but that would work whether FSUIPC was registered or not. It sounds like you have some other add-on doing it. You'll need to stop them all running, then add them back one by one. This includes anything installed IN FS, i.e. via DLL.XML entries, and LUA files (plug-ins) in the Modules folder.. Pete

Do the Windows crash details point ot any specific module? (View crash logs in Windows Event Viewer)? If that indicates FSUIPC4 then let me see the details. Also make sure you are using the latest version -- 4.971. I cannot support anything earlier. Probably you need to go to the FSRaas support forum, wherever that is. I'm pretty sure they have a web site. Pete

What code? What protocol is the device using. Honstely, you are asking the wrong person in the wrong forum. Try the support forum for that device, or buy uoirself a decent USB monitor, as I did for my devices, to work out what is going on and what is needed for your device. Why? What's the point of a trace log with no source code to see what was being executed? Or are you talking about the code you posted much later? Did you expect me to magically relate the two with so much intervening goings on? Sorry, but I am not interested. All I can tell you is what you write to a correctly open COM or HID device IS being sent out to that device. What it does with it, whether it recognises it, is something I cannot possibly help with. Pete

I don't know, but If there isn't one mentioned in the SimMarket page for either then I expect the answer is that there isn't. Pete

No. The quotes needed when there are spaces in he pathname are really annoying. Something like this should really work: RUN1=READY,CLOSE,"C:\Prepar3D v4\IvAp v2\ivap_dllhost.exe" "C:\Prepar3D v4\IvAp v2\ivap_fsx.dll" but it might be that Windows only gives me the first part.(INI files are handled by a Windows API). In my system I always take great care to only use folder names with no spaces. Doesn't the FSUIPC5.LOG show what it reads and what the error is? 5.121a is not the current supported version. Pete

Latest version is 5.121a. I'm afraid much of what you say sounds like a mix up of assignments. How many joystick devices are you using? Are you using Joy Letters, so that the assignments can keep track of any changes in connections? Did you disable controllers completely in P3D itself? Button actions occurring without touching any buttons isn't good. Possibly that is a bad device connection, unless one of your axes iss jittering and somehow that's been assigned to panel selection. Perhaps a sight of your FSUIPC settings will clarify -- paste in the contents of your FSUIPC5.INI file, from the P3D modules folder. Pete

Why not try it? I don't know your device. I don't know what format it expects this value to arrive in. Pete

Of course you use com.read and com.write on HID devices. The ONLY difference is how it is opened, because of the way of identifying it (using VID and PID instead of port number)!!! The code in FSUIPC and in Windows is the same for all devices, once they are opened and a handle has been obtained. There are some extra features for HID devices, as documented, but the basics are just serial reads and writes. The "S" is USB is for "serial". Pete

But it's the same as com.read except you provide the data instead of receiving it! com.read is str, n = com.read(handle, max to read) where you get the data rwad in the string 'str' and the number of bytes read in 'n', whilst com.write is n = com.write(handle, "string") where n returns the number of bytes actually written. An example would be n = com.write(dev, "this is being written") What more could you possibly expect me to say? It's effectively a direct call into the Windows API "WriteFile" with the file handle being the one obtained for your HID device. FSUIPC does place the write data into a buffer first, so that a separate autonomous thread can be used to avoid holding yup other things in FSUIPC. Here's the Lua for my Parking Brake device, operating the LED indicator via an Arduino. It isn't a "HID" device, but the only difference between ordinary COM and HID is how the device name is obtained, in the opening. port = "com3" portspeed = 9600 parkbrkpin = 12 parkbrkoffset = 0xbc8 h = com.open(port, portspeed, 0) function parkbrk(off, val) data = 192 + parkbrkpin; if val >= 32767 then data = data + 32 end str = string.format("%d\x0d", data) com.write(h, str) end event.offset(parkbrkoffset, "UW", "parkbrk") Pete

Sorry, why would I want that? I'm really not wanting such information. I was only trying to help you make proper use of the FSUIPC Lua HICOM library. That's my program. Okay then. Seems as if your HID device is probably using an unofficial ID. Normally I think they have to be issued by some authority - see http://www.usb.org/developers/vendor/, and this costs money to register. Doesn't matter to me or Windows, though. This site: http://pcidatabase.com/vendors.php?sort=id lists your 0x1234 as being ownded by "Technical Corp". Is that right? Seems unlikely as the only device of theirs so far listed is Device ID:0x0866, Chip Number:C79, Chip Description:NVIDIA GeForce 9400M. Sorry, I don't know your device. How display devices implement different things is up to them. Surely the device you are using doesn't use "writefeature" for its displays?. It should surely use normal writes? Often 7-segment displays actually need very low level data, driving the actual voltages on the separate lines feeding each chip. That may or may not be handled by microcode on the device. But I've no idea. I've only ever found out about hardware devices I've actually used or got hold of myself, and even then it is usually first a matter of using other programs, like USB Monitors which log what goes on between PC and devices, to work out how to drive them. I can support my software, I cannot undertake to support hardware as well I'm afraid. Sorry. Pete

No. HID ports are, like all USB ports, are treated like COM in the Windows API for reading and writing, but the port name is much more complicated than that, and obtained by reference to the PID and VID values you need to program in your Lua when using OpenHID. And don't you have to supply such information for that? You need to identify the device somehow! In your log: 202817 LUA.0: Local: USB_DEVICE_VID = 4660 202817 LUA.0: ...es\Microsoft Flight Simulator X\Modules\ipcReady.lua:8 202817 LUA.0: Local: USB_DEVICE_PID = 1 4660 is hex 0x1234 which seems an very unlikely VID. And a PID of 0x0001 is even more unusual. Are you sure you have those correct? Where are you getting them from? Without seeing the Lua code you've come up with I can't really interpret the log any further, can I? It is a waste posting it really. No. I don't think any USB device I've got uses the "feature" option. And since the HIDdemeo is simply showing results of reading data on one specific user device, it isn't likely to write to it and possibly much their device settings up, is it? You are not picking out the importasnt aspects of the example. You should be able to interpolate for yourself into other read and write facilities. Why would I need that information? Pete

com.write writes the data to a port you've already opened. It just calles the Windows function to do that. How would you expect it to work. I successfully use Lua to read and write from/to an Arduino in my cockpit. Please do see the HidDemo Lua example in your FSUIPC documents folder, inside the Example Lua Plugins ZIP, and use the Logging facilities to check what is going on -- log data using ipc.log and enable the Lua trace/debug option in the Logging tab for a line by line trace. Just saying it is not working is no help to anyone. I can't help with zero information. Pete