PhilippK87 Posted March 18, 2009 Report Share Posted March 18, 2009 Greetings, we ended up in a situation where FSUIPC and another program are required to communicate, now our specific issue is that the offset that we're using, namely the Cowlflaps (37F0) need to report back their status to that other program. I know from your documentation and through FSInterrogate that the very offset I'm dealing with is a double float value jumping betweeen 0.0 and 1.0. So far so good. "That other program" however only accepts integers, and I'm stuck there. Is there some, I dare say, rather easy approach to change the output of FSUIPC so that it provides proper Integers? Im by no means a programmer , I have a wee bit of technical knowledge, seeing that I prefer Linux at home, but as for programming...I guess I have to confess that I'm just more into "arts" than techsavy work. If there's more info required on what I am actually trying to do et cetera, let me know, thanks in advance, Phil. Link to comment Share on other sites More sharing options...
Pete Dowson Posted March 18, 2009 Report Share Posted March 18, 2009 "That other program" however only accepts integers, and I'm stuck there. Is there some, I dare say, rather easy approach to change the output of FSUIPC so that it provides proper Integers? Not anything built in. The only thing I can suggest is you have a little Lua plug-in which reads the offset, converts it into a form you like, and puts it into another offset -- one of the user-free ones from 66C0 to 66FF. Something like this, for example: local function convertCowl(offset, cowl) mycowl = cowl * 16384 ipc.writeUW(0x66C0, mycowl) end event.offset(0x37C0, "DBL", "convertCowl") or alternatively (I'm not sure which method will turn out to be more efficient): while true do cowl = ipc.readDBL(0x37C0) mycowl = cowl * 16384 ipc.writeUW(0x66C0, mycowl) ipc.sleep(100) -- limit to 10 updates per second (change number of millisecs to suit use) end The first one is more amenable to further additions, other events, should you need them, but its operation isn't so obvious to non-programmers. Save one of these as "ipcReady.lua" in the Modules folder and it will load up when FS is ready to fly, and operate from then on. You can read the converted cowl flap value as a 16-bit unsigned value, from 0 to 16384, in offset 0x66C0. Note that I've not tested them, so please confirm. Regards Pete Link to comment Share on other sites More sharing options...
PhilippK87 Posted March 18, 2009 Author Report Share Posted March 18, 2009 Hi again, now back from lunchbreak (sorry) and I just tried the first method. Please note that "tried" means I wanted to read the outcome thru FSInterrogate, if for whatever reason FSI is not able to read that ".lua" output let me know and I'll try and read it through the actual "second" program. I take it event.offset (0x37C0, ... has been a typo and you actually wanted me to use 0x37F0 ? Unfortunately both ways turned out to not show any changes in 66C0 - at least according to FSI. Will try your second suggestion now and report back. EDIT: The latter didn't seem to work either, but then that's just me, fiddling around with no deeper insight on what I may have been missing. I'd actually go as far as to say "ok, your suggestions probably work JUST FINE", I'd just need an idiot safe hand guiding me. Maybe there's some additional ...conditions,..something along those lines..that need to be sorted out before trying one of your suggestions and you took them for something that "goes without saying?" PS: Sry for the grammatical, structural weirdness, ..no native speaker (( Link to comment Share on other sites More sharing options...
Pete Dowson Posted March 18, 2009 Report Share Posted March 18, 2009 Please note that "tried" means I wanted to read the outcome thru FSInterrogate, if for whatever reason FSI is not able to read that ".lua" output let me know and I'll try and read it through the actual "second" program. I tend to use the built-in FSUIPC "monitor" facilities to check these things -- it is so much easier, and it shows optionally in real time on screen and in the log, for proof and proper checking. has been a typo and you actually wanted me to use 0x37F0 Ah, yes, sorry. i read the message and replied from (bad) memory. Unfortunately both ways turned out to not show any changes in 66C0 - at least according to FSI. Well, the first was certainly my error. Sorry. The FSUIPC log would have shown you that the Lua code was wrong: 64953 LUA: beginning "D:\FSX\Modules\ipcReady.lua" 64953 *** LUA Error: D:\FSX\Modules\ipcReady.lua:6: Event proc not found 64953 LUA: ended "D:\FSX\Modules\ipcReady.lua" The problem is the "local" before "function". Please delete that word -- I typed it semi-automatically because I've been using local functions a lot recently. You need any function called from an Event to be "global", else FSUIPC can't see it. Omit "local" and it becomes global. I've now tested that one here, with the 37C0 corrected to 37F0, and "local" removed, and it works fine. The latter didn't seem to work either, but then that's just me Well, with the 37C0 changed to 37F0 that worked fine, straight-off, here. Here's the FSUIPC4 log file with it running and the Baron left cowl flap being changed, using Monitoring of 37F0 as FLT64 and 66C0 as U16: 125281 SimRead: 37F0="RECIP ENG COWL FLAP POSITION:1" FLT64: 0.078 125344 Monitor IPC:37F0 (FLT64) = 0.07800000 125391 Monitor IPC:66C0 (U16) = 1278 127766 SimRead: 37F0="RECIP ENG COWL FLAP POSITION:1" FLT64: 0.156 127828 Monitor IPC:37F0 (FLT64) = 0.15600000 127828 Monitor IPC:66C0 (U16) = 2556 128234 SimRead: 37F0="RECIP ENG COWL FLAP POSITION:1" FLT64: 0.468 128281 Monitor IPC:37F0 (FLT64) = 0.46800000 128281 Monitor IPC:66C0 (U16) = 7668 128641 SimRead: 37F0="RECIP ENG COWL FLAP POSITION:1" FLT64: 0.78 128687 Monitor IPC:37F0 (FLT64) = 0.78000000 128750 Monitor IPC:66C0 (U16) = 12780 Maybe you should (a) make sure you are using the latest FSUIPC version (3.90 or 4.50, or 3.906 or 4.506 from the Updates above), and (b) enable the monitoring and check the log. I haven't checked this in FS9 yet -- you didn't mention which versions you were using -- but the Lua code is the same, so it should be okay. Let me know if you need me to test that too. Regards Pete Link to comment Share on other sites More sharing options...
PhilippK87 Posted March 18, 2009 Author Report Share Posted March 18, 2009 Thanks for the detailed response, will give it another try tomorrow and report back, again, thanks for your commitment!! EDIT: Everything's perfect with....provided that dumb folks like me use AN UP-TO-DATE .DLL :oops: "solved" Link to comment Share on other sites More sharing options...
PhilippK87 Posted March 31, 2009 Author Report Share Posted March 31, 2009 And hi once again, I take it there's no way of doing this the other way around? Meaning in my specific case I'd be delighted to be able to controll "37F0 (FLT64)" manually? Link to comment Share on other sites More sharing options...
Pete Dowson Posted March 31, 2009 Report Share Posted March 31, 2009 I take it there's no way of doing this the other way around? Meaning in my specific case I'd be delighted to be able to controll "37F0 (FLT64)" manually? Manually? What does that mean in this context? There are FSUIPC Offset controls for Setting or Incrementing both 32- and 64-bit floating point values. Why not use those? They take parameters in 1/1000th's so you can get the fractional parts that many floating point values need -- such as this one, from 0 to 1. Regards Pete Link to comment Share on other sites More sharing options...
PhilippK87 Posted March 31, 2009 Author Report Share Posted March 31, 2009 Thanks so far, what it seems to do is it DOES write changes to our offset, but seems to disregard our parameter (1638 as in 10% of "Integer"), it does alter it yes, but jumps wildly with no appearent control from our site. Link to comment Share on other sites More sharing options...
Pete Dowson Posted March 31, 2009 Report Share Posted March 31, 2009 Thanks so far, what it seems to do is it DOES write changes to our offset, but seems to disregard our parameter (1638 as in 10% of "Integer"), it does alter it yes, but jumps wildly with no appearent control from our site. You are writing it as a what? 16-bit value? if so all you are doing is writing to the lowest two bytes of the 8-byte double floating point value. I've no idea what that will do, it's a waste of time. If you wanted to do something really approximate you could write to the two 2 bytes, at the offset + 6, but you'd need to work out the correct exponent and mantissa values and put those in the appropriate bit positions. You could of course use a Lua program again -- to read a 16-bit value from one offset and write it as a double float to another. Haven't you tried that? It wouldn't be that much different from the program i showed you earlier. while true do cowl = ipc.readUW(0x66C0) mycowl = cowl / 16384 ipc.writeDBL(0x37C0, mycowl) ipc.sleep(100) -- limit to 10 updates per second (change number of millisecs to suit use) end Though really you should only do this when 0x66C0 is changed, so use an event (event.offset) to call a function, instead of having a loop like this. Regards Pete Link to comment Share on other sites More sharing options...
PhilippK87 Posted April 6, 2009 Author Report Share Posted April 6, 2009 Thanks sir, approved and working. Link to comment Share on other sites More sharing options...
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