HELP WITH FSUIPC, COCKPITSONIC AND FDC (FLIGHT DECK COMPANIO

[mallorca737]

HI,, I NEED YOUR HELP!!

1-i have a full cockpit hardware from cockpitsonic it is all usb conected to FS COMPUTER, to run all i have tu run a driver called B737.exe (it use fsuipc all time, it use pmsystems and all projectmagenta).. ok all this work very fine.

http://www.cockpitsonic.de

2- i use a program called FDC "flight deck companion" "it is a virtual copilot, gpws, etc etc... it need and use "fsuipc"

http://www.oncourse-software.co.uk

both programs works perfect if they dont run at same time... but,, FDC CRASH if i have the driver of cockpitsonic runing

from oncourse sofware thay said:

I guess it must be doing something with FSUIPC and that whatever it does it conflicts with FDC. I think this might be a question for Pete Dowson (FSUIPC author) to see if he knows what might be occurring

this is the email that i writed after a lot of tests to they with full problem,, plese read to:

WELL, i find the problem...

i am using hardware systems from "cockpitsonic"

all systems are conected to a FS computer by USB.

for operating all systems i have to run a driver called b737.exe

now i can see when i dont start up systems (hardware) and i use the keyboard your FDC WORKS FINE!!!!

at the moment that i run b737.exe (driver cockpitsonic) and i touch flaps or speed brake your FDC crash!!

i make another test and when i only put voice to copilot and for example i set "flaps 1" copilot voice all time repeat "flpas 1, flaps 1, flaps 1, flaps1, flaps 1" and after that FDC crash..

if i make same test without driver cockpitsonic all works and copilot only say 1 time "flaps 1"....

I CANT UNDERSTAND,, WHY CRASH FDC WITH COCKPITSONIC driver....

DO YOU HAVE ANY IDEA?

Mr Peter,, what do you think?????

i use last version of fsuipc for FS2204 and vista.

regards

[Pete Dowson]

at the moment that i run b737.exe (driver cockpitsonic) and i touch flaps or speed brake your FDC crash!! i make another test and when i only put voice to copilot and for example i set "flaps 1" copilot voice all time repeat "flpas 1, flaps 1, flaps 1, flaps1, flaps 1" and after that FDC crash..

If it is FDC crashing then the error MUST be in FDC. There is no way anything else can make a separate process crash. Possibly this B737.EXE program is writing stuff into FS, via FSUIPC, which is out of some range which FDC can cope with, but it most certainly should not make it crash.

The first step to working out what is going on is to find out what Windows says about the FDC crash. Isn't there ano error message? Does it say "access violation" or "overflow" or what?

I really think that without the FDC author helping to determine WHY his program crashes, it is going to be almost impossible to make any determination about what is that is wrong and therefore how to get it fixed.

The best I can do for you is check the actions of the B737.EXE driver within the first few seconds, up to the approximate elapsed time of the crash. But to avoid complicating matters, I need to to see ONLY the actions of that driver. So, please do this:

(a) Make sure NO OTHER FSUIPC programs are running at all. That is nothing of PM, nothing of any add-on aircraft, no oher FSUIPC-using DLLs in Modules folder.

(b) Run FS. In the FSUIPC Logging enable IPC Write and IPC Read logging.

© Run B737.EXE to the point where it would crash FDC if that were actually running.

(d) Close FS, ZIP up the FSUIPC.LOG file and send it to me at petedowson@btconnect.com.

That's the main thing. You could then also do exactly the same but run FDC as well, so I can see the difference, but that will be more confusing and useless anyway without that first log.

Finally, you could do the same with only FDC, no B737.EXE.

Be sure to rename the three logs appropriately. so I know which is which.

i use last version of fsuipc for FS2204 and vista.

Never just say "latest version". Folks have said that and actually meant "the latest version I have seen", and were using one a year out of date. ALL my software modules have version numbers. Please quote them.

Regards

Pete

[Dave March]

If it is FDC crashing then the error MUST be in FDC. There is no way anything else can make a separate process crash.

Wow! Really?

Just for the record FDC is not crashing.... it detects a problem, writes to an error log, displays a message to the user, disconnects from FS then ends!

If I run this B737.EXE program alongside FS and FDC, using keyboard commands to select flaps, everything is fine and runs without any problems, but of course I do not have any hardware attached and I believe the issue only occurs when the user moves his hardware levers. My 'guess' is the data at x3BFA and/or x0BDC is not what I'm expecting. Probably caused by varying lever movements rather than moving from one détente to another.

[Pete Dowson]

If it is FDC crashing then the error MUST be in FDC. There is no way anything else can make a separate process crash.

Wow! Really?

Hi Dave,

Yes, really -- with the exception of debuggers (and programs of similar privilege) of course which can do anything they want, almost. All other crashes come about as a result of unexpected and unchecked data input, hardware glitches or other levels in the same process -- i.e. drivers and libraries. This is the whole point of the virtual memory system used in Windows for many years. Each process is in its own little universe.

Just for the record FDC is not crashing.... it detects a problem, writes to an error log, displays a message to the user, disconnects from FS then ends!

Okay, that's better. No indication from that what is wrong?

If I run this B737.EXE program alongside FS and FDC, using keyboard commands to select flaps, everything is fine and runs without any problems, but of course I do not have any hardware attached and I believe the issue only occurs when the user moves his hardware levers. My 'guess' is the data at x3BFA and/or x0BDC is not what I'm expecting. Probably caused by varying lever movements rather than moving from one détente to another.

3BFA is a read-only value which is computed by FSUIPC from the number of flap positions it gets from the currently loaded aircraft. B737.EXE won't be able to change that (or at least I *think* I write-protected it).

0BDC could conceivably be anything in the range 0-16k. It's used to both control the flaps from a client program and to reflect the position. Can you say how values here could cause a problem, please?

The logs I requested should help if all it is are unexpected unchecked offset values. ;-)

Best Regards

Pete

[mallorca737]

hi i sended you the files..

i make a quikly test with fsx and version4 of fsuipc and i have the same problem..

i never use fsx for my home cockpit the are no many addons, i only make test because it is maybe important for you that the problem it is present in fs2004/fsuipc3 and fsx/fsuipc4

but i only will use fs2004.

i will put a short video in youtube with problem... i send you the link when i have it tonight...

regards

[Pete Dowson]

hi i sended you the files..

Please, please ZIP files before sending them! These are all simple text files and zip up real small. I'm sure I asked you to Zip them? You just jammed up my email for 20 minutes!

i will put a short video in youtube with problem... i send you the link when i have it tonight.

I don't see the point of that.

I'll look at the logs after dinner (just been called by my better half!).

Regards

Pete

[mallorca737]

ok i will zip now,, but the log file is 5.5 mb??? it is normal!!!!,, and yes i am sure it is a log file, but is very longgggg...

[Pete Dowson]

ok i will zip now,, but the log file is 5.5 mb??? it is normal!!!!,, and yes i am sure it is a log file, but is very longgggg...

No no no! Dont' send it again!!! Please!

The one with everything operating would be long. There are lots of things going on.

Pete

[Pete Dowson]

hi i sended you the files.

From initial analysis, it looks like you did not stop all other FSUIPC client programs -- you appear to have "pmdgOptions.DLL" running and confusing things somewhat. You need to remove add-on DLLs when isolating clients.

Also, the Log you called "only b737exe" definitely has FDC running too! It adds its entry "Connect FDC" to the Modules menu, via FSUIPC. However, you didn't do the Connect, so I don't think it interfered too much.

As far as I can see the problem must be that FDC cannot cope with unexpected values in offset 0BDC. This gives the Flaps setting, and it is both a control and a read-out to show where the flaps lever is.

Normally the flaps lever will be moved from one notch to another, and the values written and read here will closely approximate the notch position. For a B737 there are 9 positions, and the range here is from 0 to 16383, so the increment between each notch is about 2048. Thus, notch 0 (flaps up) is 0, 1 is 2048, and so on. But these numbers are only approximate and may vary a little from the "correct" notch value.

However, it is perfectly permissable for a program such as B737.EXE to write whatever values it likes here, within the range 0-16383, and it does seem to be doing just that. I think it is merely sending the AXIS value, ranged to 0-16k. Maybe you do some sort of calibration for the notches?

I can't see anything wrong really with what B737.EXE is doing, I think it is a problem in FDC -- it appears to be making assumptions as to what is permitted in that offset, and it goes wrong if there's a value there it doesn't expect. If it wants to log, announce or otherwise act upon the selected flap setting, then it needs to round the value it reads to the nearest notch value. This is what FSUIPC does when you assign a non-notched axis to Flaps directly.

If the authors of B737.EXE are amenable to changing their driver, they of course could do the rounding of the Axis value themselves, before writing to offset 0BDC. That would make their program more reliable too. But really FDC should check and adjust for permissable values in any case -- there may be other programs doing the same as B737.EXE, as writing a driver to directly set offsets from axis values is easy. In fact my EPIC module, EPICINFO.DLL, could be easily programmed, in one line in its parameter file, to do the same thing.

So, I think this would be very easy for Dave March to fix. In case he is not following this thread any more perhaps you would relay my assessment to him?

BTW it is good to know it is the same in FSUIPC4. I'd be rather concerned if it wasn't! FSUIPC4 is supposed to be compatible with FSUIPC3! ;-)

Regards

Pete

[Dave March]

Pete

As far as I can see the problem must be that FDC cannot cope with unexpected values in offset 0BDC.

Well I don't think it's quite as easy as that and I would have to provide an interim version of FDC for the user to run so I could see exactly what is occurring. In the case of the 737 FDC does expect to work with values in 0BDC of 0, 2048, 4096, etc. (and yes we do round our calc's). During normal flight operations we also wait for the movement between détentes to complete before making our audio callouts to confirm a flap setting. Eg. we monitor 0BDC until it matches one of our expected values. However, what I think is happening here is the hardware lever is probably positioned somewhere between two détentes when we make our initial checks (when the program starts) using offset 3BFA and 0DBC to determine the current position or the flaps.

But really FDC should check and adjust for permissible values in any case

Sorry, I don't agree. As mentioned above we do check for movement between détentes but if a value in 0BDC falls way short of what it should be when movement stops then that would not be permissible.

It's always strange, as you know only too well Pete, when something that's been working without any reported problems for many years suddenly rears its ugly head to bite you where it hurts.

Thanks for your input

[Pete Dowson]

Well I don't think it's quite as easy as that and I would have to provide an interim version of FDC for the user to run so I could see exactly what is occurring.

I was thinking that if my diagnosis was correct, or close, it should be easy enough to put to the test by using any joystick axis in place of the user's B737.EXE and his hardware. Then you could do it to see.

For this you'd need the latest interim version of FSUIPC3 -- 3.783 -- from the Other Downloads announcement.

You also need a macro file. Create a little text file containing only this:

[Macros]

1=To 0BDC=Cx02000BDC

and save it into the FS9 Modules folder as, say "Axis.mcro".

When you load FS9 (or if it is running, reload axis assignments, buttons or keys) that macro will also be loaded.

Assign an axis in FSUIPC's Axis Assignments to the new control you'll now find in the "FS controls" drop down. It will be called

Axis: To 0DBC

(the filename of the macro file plus the name from the definition in the file). Then whatever values that axis comes up with will be written direct to that offset. Of course with most axes you'd get a range of anything from -16384 (which would look like 49152 in that offset) to +16384. But you should be able to test what FDC makes of it. If it doesn't cause the error then we'll know immediately it must be something else, and will have to search deeper.

It might be a good idea too to go into FSUIPC's Logging tab and on the right-hand-side set Monitoring for offset 0DBC as a U32. If you check "FS display" below you will see the values real time on screen.

However, what I think is happening here is the hardware lever is probably positioned somewhere between two détentes when we make our initial checks (when the program starts) using offset 3BFA and 0DBC to determine the current position or the flaps.

Yes, that is indeed possible when using analogue flap controls. It will happen for analogue axes not equipped with detentes, or equipped but badly calibrated, or ones meant for a different number of detentes.

The answer is to always round to the nearest good value.

Sorry, I don't agree. As mentioned above we do check for movement between détentes but if a value in 0BDC falls way short of what it should be when movement stops then that would not be permissible.

Well, I'm sorry, but I don't think you can really prevent it. If you wish to keep FDC like this then possibly it will simply remain incompatible with some hardware implementations. In this case maybe this user will be able to persuade who'sever hardware it is to change their driver and things will be quiet again, till the next time.

It's always strange, as you know only too well Pete, when something that's been working without any reported problems for many years suddenly rears its ugly head to bite you where it hurts.

Happens all the time here. Aren't you used to it yet? ;-)

Regards

Pete

[mallorca737]

hi i sended you the files.

From initial analysis, it looks like you did not stop all other FSUIPC client programs -- you appear to have "pmdgOptions.DLL" running and confusing things somewhat. You need to remove add-on DLLs when isolating clients.

well, i have a pmdg default when i start fs,, but i change as you can see to fs2004 default aircraft before to begin test...

maybe if you need i can save a sesion with a ds2004 default aircraft exit fs.. and run it with a non-pmdg aircraft...

this is the link to the short video that i rec.. i think this video will help you to understand much better the problem, yo need to turn on your sound/spakers..

http://es.youtube.com/watch?v=xHeG6VE9-nA

regards

[Dave March]

Wow! The repeating flaps one, flaps one, flaps one is not something you mentioned before... at least not that I remember ;-)

Anyway this is obviously not an issue for Pete and I would suggest you either move back to the FDC support forum or email me, as I do not visit this forum on a regular basis.

[mallorca737]

HI,, I NEED YOUR HELP!!

at the moment that i run b737.exe (driver cockpitsonic) and i touch flaps or speed brake your FDC crash!!

i make another test and when i only put voice to copilot and for example i set "flaps 1" copilot voice all time repeat "flpas 1, flaps 1, flaps 1, flaps1, flaps 1" and after that FDC crash..

if i make same test without driver cockpitsonic all works and copilot only say 1 time "flaps 1"....

regards

yes i tell you about copilot repeat all time "flaps 1"

[mallorca737]

Peter,, have you see the video???

what do you think?

[Pete Dowson]

Peter,, have you see the video???

what do you think?

Don't need to. Please see the analysis I've done. I think you need to go to the FDC support forum now, as Dave suggested.

Regards

Pete