Saitek X52Pro Mfd and Fip how to home

yes , currently the KA-50 gauge pack ( wip) Uses buttons and knobs for page two( abris, no visuals) the hsi and the other gauges in the sim with buttons and knobs will be matched.

I plan to do this for all of the gauges, and maybe add radio functions to the fip similar as with the X52pro.

Drawing the gauges is a slow process for me , faster than the scripting but still tedious effort and I am still learning how to do that.

It will be a bit but it will be...

Just an update: Drawing A-10 Gauges..After that P-51.

Pretty much have Huey and Ka -50 drawn. Still a learning process so,not exactly glamorous stuff , but working.

Need to "wire" the gauges and work on script.

I think I know why the FIPS are acting sluggish when more than one and will revise script. So hopefully soon we will have gauges for all DCS aircraft working for the saitek gear with corresponding buttons and knobs functional.

Saw another post that reminded me of another feature of the sdk and that may allow me to get the mfds,Schval, abris and other screens to the Fip. Will investigate after the above issues are completed.

Hang in there getting closer by minute.

Update... A-10 gauges pretty much done , still need to figure out how to draw a few things. Will get p-51 done then , sort out the lag time. After that will put out individual module gauge set. Once that is out will work on making a package gauge set that will work with all modules. Of course the wiki still needs more input. will do when I have better understanding of getting things to play nice together. X-52 pro readouts will be included.

Just busy and this is a bit more tedious than I thought it would be. Slow and steady and I should be caught up before they release the next module.

Per recomendation of algerad3 (I see he's pretty active in here :)), I'm writing to see if someone could give me a few directions where I should be headed.

Let me mention first, that I only play space sims, Tie Fighter at the moment to be exact, because I love that era of PC gaming, and am pretty sentimental ;)

Anyways, I'm not a beginner in software programming, although I have the time of programming in C and C++ way past me, as I am diving in C# and Java for a long time now. It's not an issue though to try C++ and to be honest I think it would be fun for me.

But first things first... I'm using Windows 7 x64. What stage I'm at at the moment is trying to run some samples, anything that I see is compiling and I can run, and I can see some effect, like writing on MFD "Hellow World" or blink a LED. But so far I have big problems related to that, and I can dig into it on my own, but I wanted to try my luck ask any of you in some guidence if you were going through the same thing.

Ok first thing are the samples in the SDK folder. First I tried the compiled samples, HelloWorld.exe and test.exe. HelloWorld does nothing, as soon as I run it the cmd window closes. Test.exe opens a small window, but does nothing as far as I can see. I looked into cpp file of HelloWorld in the main function, and there are some calls that look like trying to print some Welcoming message on the display, but I can't see anything new. The profile name is still there as it was before.

I tried to open the solutions for those 2, but both have problems right of the bat with conversion to Visual Studio 2010. (If any of you told me, I can work my way through it without any problems in Visual C++, then please tell me, I will go through the trouble of looking it over and installing it).

Then I looked over the web for the C# wrapper I found earlier, and I found couple of those wrappers, one including a sample, that was promising. Opened it in Visual Studio, it compiled without any errors (hurray), but I got exception on

AstroMech.DirectOutputClass.DirectOutput_RegisterDeviceChangeCallback(cb, 0);

line. Exception saying, the entry point in the dll cannot be found. I know the dll can be found, because one line earlier there is a call to Initialize, and that doesn't throw exception -> ergo, that function call went through alright. Alright I digged further, found the tool to look up the dll, and what I found interesting is that the method "DirectOutput_RegisterDeviceChangeCallback" is not there. Instead there is method "DirectOutput_RegisterDeviceCallback".

I think I got to the root of the problem and why the samples by Saitek don't work. Seems that the dll got updated, and that's why the samples don't work, and the wrappers don't either. Unfortunetly updating the EntryPoints didn't work completely, because I get different exception on the Enumerate method.

The bad thing is that the sdk reference page still shows the DirectOutput_RegisterDeviceChangeCallback method in the listing! What's even worse, looking into header file of the DirectOutput in the includes folder, shows the method, but the dll seems to lack them. So seems that Saitek updated the dll, but didn't update either includes, or the samples.

Anybody who went past this, could give me a hand here?

Lucas

I am only guessing here , but it looks like you have the old sdk reference sheet and examples. The Hello world and output test examples only work on the old sdk....( the one for X-52pro alone). Currently you seem to be working with the X52 pro and fip sdk. The functions have been changed to allow for multiple devices ( mostly more than one Fip).

Either one will do and if you plan on getting an fip or two down the road creating gauges then I would recommend sticking with the dll you have installed. The reference for that should be in C:\Program Files\saitek \DirectOutput.

Also, the reference in C:\Program Files(x86)\Saitek \Directoutput\sdk. should not be there, only \gauges.

If you have the examples "hello World " and "Output Test" but , the dll has the callback "DirectOutput_RegisterDeviceCallback". Then your Directoutput files are messed up. Uninstall all, Reinstall X-52 drivers and Directoputput, Then install new Fip/x52 drivers( if you want to get fips later , if not don't). That should sort it out.

If you only install the x52 pro sdk then you will find the saitek stuff in C:\Program files(x86) folder only.

Also, You have to install the x52 pro first before the Fip drivers to register things properly.

Also save the old reference sheet and then compare the new with the old. They changed the enumeration process in the new one.

Hard for me to explain in writing but, feel free to ask if you have anymore questions/ confusions.

@Up

Thanks a lot algerad3. Alright, I like to do things one at a time. First the Fip thing. I do not use it to be honest, and don't think I will in the near future, so we can put that aside for now.

With that said, what you propose is to reinstall the x52 drivers that include sdk? Ofcourse I can do that, but hard to imagine it will install different dll for DirectOutput. The only thing it would help is some registry information if something was messed up in the first instalation. But I saw stranger things in my life, so I will do that and see what happens.

Just to reafirm, before I downloaded the instalation pack from the http://www.saitek.com/uk/down/drivers.php

Selected the x52 pro, hit to download drivers and software and installed both. Is that the right place for most up to date stuff? I will reinstall just the drivers, to be clear, I will leave the software (smart profiler) as it is, since it seems it is a separate matter.

As for references I have both the Program Files(x86) folder and in Program Files folder. What's that about btw, why there are both? The x86 is for the old sdk, and the "Program files" is the newer sdk?

As for the folder contents, the first one consists of Gauges folder and the following files:

C:\Program Files (x86)\Saitek\DirectOutput\

==========================================

DirectOutput.dll 118 KB 2013-04-16 05:44:38 PM a

SaiFlightSimX.exe 140 KB 2008-04-04 11:34:12 AM a

SaiFlightSimX.exe.manifest 1 KB 2010-10-05 09:27:46 AM a

SaiFlightSimX.xml 4 KB 2011-05-12 11:22:48 AM a

SaiWinMediaPlayer.dll 89 KB 2013-04-16 05:45:00 PM a

The other one has SDK folder with the C++ header files in the include folder, and this set of files:

29DAD506-F93B-4F20-85FA-1E02C04... 4 KB 2010-10-05 09:27:46 AM a

3E083CD8-6A37-4A58-80A8-3D6A2C0... 1 KB 2010-10-05 09:27:44 AM a

DirectOutput.dll 155 KB 2013-04-16 06:16:06 PM a

DirectOutputSaiFip.dll 470 KB 2013-04-16 06:16:24 PM a

DirectOutputSaiHid.dll 314 KB 2013-04-16 06:16:26 PM a

DirectOutputService.exe 228 KB 2013-04-16 06:16:12 PM a

Fip1.jpg 116 KB 2010-10-05 09:27:46 AM a

Fip2.jpg 115 KB 2010-10-05 09:27:46 AM a

Fip3.jpg 113 KB 2010-10-05 09:27:46 AM a

Fip4.jpg 110 KB 2010-10-05 09:27:46 AM a

Fip5.jpg 113 KB 2010-10-05 09:27:46 AM a

Both dll's have different sizes, but both don't have the function I was writing about before.

Lucas

//Edit

Ok, things are getting back to me. The first one (probably the Program Files one) was installed with the saitek drivers, while the x86 was installed when I tried to install the SD6 by itself. Which basicaly proves the below picture

So seems I have SD6 and SD7 installed if I understand correctly. So I uninstall both, and which one should I reinstall, the SD7 with drivers, or the SD6?

//Edit2

I took your advice algerad3, uninstalled SD6 and SD7, and reinstalled the drivers (with SDK), and the strange thing indeed happened. Now the Api html I have seems is up to date, and the same goes for the header file. With it I was able to modifiy the Enumerate method, and the compiler goes past it.

I read in the meantime about the P/Invoke, and C# wrappers, and I'm actually pretty excited to try to do some basic (and maybe not basic) stuff with it :) I'll deffinetly will have to write an update C# wrapper first.

cheers

Lucas

Sweetness, So for now all is working I take it?

I found that the X-52 pro sdk ( directoutput 6.2) easier to use when I tried playing with it. It was created when only the joystick was on the market. When they created the Fips they had to create a more accomodating dll for both. ( 7.0)

When you update the drivers make sure the s.s.t program version and driver version match. ( if you use the s.s.s program.)

It sounds like you are on the right path, any more question feel free to ask.

Algerad.

@Up

Thanks, I did work it in the end, although not completely. I still had/have problems with adding more than 1 page. To be precise, adding seems to be working, but the callback doesn't return what I want, and I can only see the last added page on the MFD.

But... all in all, from enthusiastic to a little pessimistic it got me. I didn't read through the whole API sheet word for word, since I was occupied to get it to work in the first place. Because of that I assumed the "Soft Button" callback is for detecting the pressed joystick buttons, changed modes etc. To be honest this is where I saw me experimenting with some fun stuff, like for example pushing one button in a clutch mode, will change the leds on all the buttons accordingly, or same thing for mode changes (mode 1 - attack mode, mode 2 - navigation mode) etc.

I see now that the SDK is very heavily linked with only one purpose, and that is getting info back from the game and interacting with it. This is obviously the best of the 2, but I thought I could start with first, especialy since it's not as straightforward to get the info from the specific games, especialy dos games (if it's even possible). Getting say Freespace 2 multifunctional MFD + LED control based on the Modes, missle targetting (say the button will be blinking yellow when the lock is being aquired, and change to red when it's locked etc.

It's not a lost time though, deffinetly not. Got a bit of a play with P/Invoke which seems like something that might be usefull in my work someday.

That adding page just buggs me though. I'm almost sure the wrapper is set in the right way, but no matter passed the "active page" argument, seems that the added page is always becoming active. Also the page index I get in the callback is always "1 behind". Plus the problem that I can't scroll through pages I mentioned before, plus I don't get the pgup pgdn callbacks etc etc.

cheers

Lucas

Excuse me for sounding like I am tooting my own horn here, but have you taken a look at the Lua dll in this thread.

I was trying to put something together in c++ (learning phase) and then the lua dll was created. While I am currently focusing my project using the lua dll, I was able to gleam a lot more knowledge in how it should be put to use in other programing languages. I believe in the first ten pages are some examples you can look at for a better perspective.

I am pretty sure the answer you seek is in there , just can not remember details at the moment.

Excuse me for sounding like I am tooting my own horn here, but have you taken a look at the Lua dll in this thread.

I haven't, to be honest, mainly because I never written anything in Lua or even studied it. But I don't think at the moment it would do me any good, because the main thing for me was realisting that there is no delegate that reads the joystick input (buttons). That was a bit of a letdown for me, I wish I read the api method description for the "Soft buttons" sooner.

If that wasn't the case I'm sure I would figure it out sooner or later, even through Saitek support channel. I already saw the P/Invoke semantics very easy once I learned it and looked through some samples today. Also, I made the neceseary changes for the wrapper I already downloaded to make it work with the new API method calls and delegates. I would figure out all the problems in the end if I put my time to it, but currently don't feel as much enthusiasm as before, since the games I do play, it would be useless. None of those games provide any external output, nor I saw people writing open libraries that would provide that. And since the main goal (as I learned today) really is interacting with the joystick set by the game input, it's useless for me now, pretty much, unless I will make a disco of my joystick, that will just turn the leds on and off in some random fashion :P

I was trying to put something together in c++ (learning phase) and then the lua dll was created. While I am currently focusing my project using the lua dll, I was able to gleam a lot more knowledge in how it should be put to use in other programing languages. I believe in the first ten pages are some examples you can look at for a better perspective.

I am pretty sure the answer you seek is in there , just can not remember details at the moment.

Thanks for the hint algerad3, and I want to take this opportunity and thank you for leading me to this topic, and for your previous help to me. I appriciate it.

As for the above quotation, the method calls are now not the problem, but that the api doesn't provide what I thought and hoped it would. Lua wrapper might help me, but all in all I wouldn't have any purpose with it in the end.

All of the methods I executed went ok, except for the adding multiple pages, and reading the soft buttons input. Setting string on page, setting leds to change color, initialization etc all seemed to work fine.

cheers

Lucas

Hey Algerad, sorry for the long absence, I'm determined to get back into this! My new job is killing me (get home at like 8:30pm, need to sleep by 11..) but I will try and get back on. I recently bought the MI-8 expansion so hopefully that will be the necessary inspiration.

I'm trying to remember where I was up to before, and I've been looking through your impressive work on the FIPs, I need to read up on your socket idea. Since I last posted I had a Huey lua that was working pretty well and I can't remember if I released it. Same with the A-10c, I think my last public release was an embarrassing mess but I fixed lots of dumb bugs since then. I don't think I'll have time tonight, but I'm determined to get something out soon!

Welcome back, I understand how all that goes. Nothing more painful than getting into this stuff and having to stop for r/l and then returning. Oh, the confusion...

Made a series of gauges , not the greatest looking stuff, but some lessons have been learned. Now I just need to figure out who and why data is bottle necking with multiple fips. Add the x52 pro back in the mix and we should be good to go. Of course , real life has been slowing me down on this end quite a bit.

I am finding after several test that saitek.SetImage slows down the input stream during tcp transfer and gives a slow response to the gauge needles.

After closing the simulation, I still have to wait for the stream to catch up and close the tcp script.

Is there any way to speed up the transfer /input rate of this function?

I think I figured it out.

All this "stop and go" nonsense is making me forget where I am going after I stopped. One of those been there , done that ,solved it and forgot what , how , or why.

Basically..... Never mind.

I am finding after several test that saitek.SetImage slows down the input stream during tcp transfer and gives a slow response to the gauge needles.

After closing the simulation, I still have to wait for the stream to catch up and close the tcp script.

Is there any way to speed up the transfer /input rate of this function?

Unfortunately no; sending an image to the FIP is a slow blocking operation. You should have a separate thread do it (one thread per FIP) so your other activities don't have to wait.

well, my original plans are still up in the air. Had to do things a bit different.

I have things working ( at least the gauges. Still need to work on the button callbacks.)

Right now I am focusing on getting the gauges to display properly...math the input.

here is the ka -50 set... going to do the a-10 tonight , maybe get the huey done before the end of the weekend.

The lua I attached is set up for eight gauges. Take a look at the lua file and follow the tips for setting up the index and pages.

when using this for Dcs World make sure you start the gauges lua before starting a mission. If Dcs world crashes while loading , you forgot to start the gauges lua.

For some reason when using the lua files , dcs drops to desktop and you have to find the tile on the system bar and click to bring it back.

After missions you have to restart the lua gauge files with scite.

But we now have gauges , let me set up the rest of the modules and I will get the rest of the documentation done and ready.

Export.lua

Ka 50 gauges no buttons.lua

Gauges

You know, I think it might help if I add the gauges for the gauges pack.

Sorry, forgot that part.

Here are the gauges for the fips.

put the folder into C:\\Program Files\\Saitek\\DirectOutput.

The lua files already direct to that path.

Ka 50 gauges.zip

Is it me or does the new updates mess with these files ?

Trying to get things going for Huey and a-10 but I am not getting export info.

It was me , a quick reboot and as is well.

In other words ..... Never mind!!!!

work resumes

god speed, we could really use some gauges for a10

More gauges

Well , got some more gauges to play with here.

Huey and Ka 50 in this package.

Not much has changed for the Ka50 for now.. I only have a few of the Huey gauges working for now. Still a bit to work out.

Gauges Scite is the gauge program to be started in scite.

Exports.zip is to be opened and the lua scripts placed in user/saved games/dcs / scripts folder.

the other two zip folders ar to be opened and the folders placed in C/program files/Saitek/directoutput/ folder.

Not all of the gauges in the gauge folders are functioning yet.

The export script will pick the correct script according to module being flown.

Just be sure to start the right gauges script with scite.

If Dcs world crashes when loading or during startup.... you may have forgotten to start the script.

Follow the comments in the Ka50, huey gauges scripts, they are set up for an 8 fip run.

You can change the update speed in the export file ( i.e saitekuh1h) look for the last line "tNext = tNext + .9" changes can be made from .1-.9.

If you set tNext to low ( say .2) dcs may crash as it is not enough time to clear the output socket. A higher delay rate may help speed up fip response times. Experiment according to your rig.

Any questions post here.

Now on to the a-10.

saitek package.zip

Algerag, hi...

I'm sorry but I'm lost in this thread. It says "X52Pro MFD" but I feel to ask that "is this mod working with X52PRO?" - Because you say "gauge". Gauge & Saitek MFD... I'm confused a little bit.

I'm now at work and didn't try though...

Devrim,

Somewhere along the line I wound up working on both ..I do need to do more work for the X52pro.

I had been working on the X52pro and set up a tutorial for making scripts for the Pro. Then I needed to get the fips working as others had been waiting.

Now , I need to finish getting the a-10 - p-51 gauges going and then update the x-52 pro scripts .... in the end I will have both items working in the script and the script will decide whether to run the x-52 , the fips or both .

Now that I have a week to myself , I should have a lot done by next weekend.

So to Devrim and everyone else .... Still a wip just sharing as I go.

Thanks for very quick reply. And many thanks for your effort and addiction to it Algerad.

Best wishes.

Hi there,

I've just registered to this forum in order to get some help with the x52Pro MFD. The thing is you guys seem to have been using some kind of scripting language instead of the pure DirectOutput SDK so I'm not sure if you can help me with this.

Anyway, it seems you have already dealt with the last DirectOutput update (7.0.27.13) and you got the MFD and FIP working fine. In my case (programming in C++) I've found that softbutton and pagechange methods are never called when using the MFD controls so I can't get any feedback from the device. The sample "Test.exe" program also shows the same behaviour (there is a line in the GUI that should display the value of this controls, but it never changes).

I didn't have this issue with the previous version of DirecOutput and I'm surprised it's not discussed in the forums at all. Any idea of what I am talking about?