Jump to content
The simFlight Network Forums

Strange problem since FSUIPC V3.10


Recommended Posts

Hi Peter,

I have made a strange observation while using FSUIPC 3.10 in my setup. Firstly some background information, I have the full PM Boeing software all latest versions, GC 402, MCP 369, CDU 340, WideFs 6.10, FSUIPC 3.10 (registered versions), Epic USB with Epicenter V55 and FS Communicator V1.0.57.

I have been experiencing the following problem associated with the PM Offsets 4E2 & 5408 since loading FSUIPC 3.10, the offset size was set to 2 bytes in FS Communicator and had worked happily for many months. After loading FSUIPC V3.10 the MCP crashes with the following message “Runtime error 6 overflow”, FS has to be restarted to clear this problem.

After reloading all my software and operating system the problem still occurred, I removed all of my FS Communicator programming and the problem disappeared, I then added the keys back one at a time until the failure occurred, it appeared that the following PM offsets 5408 & 4E2 were causing the problem. I used the FSUIPC Log function to monitor these offsets when FS Communicator is started, the MCP crashes only if the byte size for 5408 is set to 2 bytes, when set to 1 byte all works well, in addition I noticed the value of offset 5409 is the same a 5408 when 2 byte size is used in FS Communicator.

I’m no expert but I find it strange that this problem should manifest itself after everything has been running for months, now even when using older versions of FSUIPC the problem occurs therefore I don’t know if FSUIPC I the cause or not, but I thought I would share my experience with you. I have also loaded every version of the MCP I have going back to ver 347 and FSUIPC back to 3.04.

I hope this information is useful, keep up the great work you are doing for this hobby of ours.

Best Wishes, a very satisfied customer.

Link to comment
Share on other sites

I have been experiencing the following problem associated with the PM Offsets 4E2 & 5408 since loading FSUIPC 3.10, the offset size was set to 2 bytes in FS Communicator and had worked happily for many months. After loading FSUIPC V3.10 the MCP crashes with the following message “Runtime error 6 overflow”, FS has to be restarted to clear this problem.

Neither of those locations are touched or used at all by FSUIPC. They are purely for Project Magenta talking to various parts of itself and for programs to interface to it, via FSUIPC's application-allocated address space.

I used the FSUIPC Log function to monitor these offsets when FS Communicator is started, the MCP crashes only if the byte size for 5408 is set to 2 bytes, when set to 1 byte all works well, in addition I noticed the value of offset 5409 is the same a 5408 when 2 byte size is used in FS Communicator.

I'm not really sure what you mean here, as it is a little ambiguous. The "byte size" where? Surely not in the monitoring function (you are using the on-line Monitor facilities in FSUIPC, aren't you? Much easier than poring over a lengthy log file afterwards, unless you need the 'evidence' of course :) ). I assume this is something to do with FS Communicator?

I dont know FS communicator at all, I'm afraid, but this question really sounds as if it needs addressing to someone who does. But even more important, since it is the MCP program which is crashing, if it is reproducible then you should most certainly be talking to Project Magenta support.

I too use all the latest Project Magenta modules along with, of course, FSUIPC and WideFs, but I don't use FS Communicator. But certainly, if I had a crash in one of Enrico's modules I'd be getting the data together and sending it to him immediately. However, I know he's a bit behind at present after some time in the states and at the AVSIM conference last weekend.

Please let me know what the outcome is.

Regards,

Pete

Link to comment
Share on other sites

One further observation. If I understand this part right:

"I noticed the value of offset 5409 is the same a 5408 when 2 byte size is used in FS Communicator."

you mean that the logging shows FS Communicator writing the same value to both 5408 and 5409?

Since the offset 5408 is used by the MCP to allow programs to set its Heading register, the range is presumably 0 to 359, or possibly 1 to 360. So the largest value which can possibly be valid in 5409 (the high byte of the 16-bit value) is 1. (360 = hex 168). Any more than 1 in 5409 would not be valid. Now, perhaps MCP.EXE should be resilient to such errors, but really I think you need to look at how or why FS Communicator is doing this. Trace it back. WHERE is the data coming from?

Regards,

Pete

Link to comment
Share on other sites

Thanks for the quick response, yes I’m using the on-line Monitor facilities in FSUIPC, a very useful tool. I will send the observation to PM, I just wasn’t sure where to start. I will keep you updated.

Re-check that 5408 is being written incorrectly by FSCommunicator first -- do that with IPC Write logging. I don't know if it runs when PM isn't running, but best to just run FS with FSCommunicator, then you know that it is it, not something else.

If FSCommunicator is writing bad Heading values to 5408 you can't really blame MCP.EXE for falling over -- even if it didn't, it would go wrong. I expect Enrico doesn't like checking all parameters because of the possible performance overheads.

So, you really need to find out WHERE FSCommunicator is getting the bad data, or is it the program itself going wrong? Are you feeding the data from the EPIC? Maybe the EPIC interface is going wrong, or the EPL itself? You need to track back one stage at a time. If you were using EPICINFO I'd recommend that you enable its logging and see what the heading value was at the interfaces there -- from EPIC ot EPICINFO then EPICINFO to FSUIPC. But with FS communicator you'll need to use whatever aids it comes with.

Regards,

Pete

Link to comment
Share on other sites

Julian,

You might want to go back to the author(s) of FSCommunicator and have them check their handling of FloatingPoint Obverflow exceptions in the application. If he is using something other than MS products to program the app he might need to change his code a bit.

I use Borland CBuilder and when FS2004 came out I needed to add the line _control87(MCW_EM, MCW_EM); to my initialization code to keep the Borland application from throwing an error.

Just a thought.

Jay

Link to comment
Share on other sites

How doI use the logging function of EPICIO that you mentioned in your previous post.

I didn't mention EPICIO. I don't think that has a logging function -- but you could check with R&R about that.

I mentioned logging in EPICINFO. That's all described in the EPICINFO documentation. But if you aren't using EPICINFO it isn't any use to you.

Regards,

Pete

Link to comment
Share on other sites

I have completed some additional testing, If you wouldnt mind I would like to send the files to you for you to review, what is your e-mail address, i don't know how to add an attachment to this Forum.

Do you think they will be of use to me? Or are they more likely to be useful to FSCommunicator's author? I really know nothing at all about FSCommunicator.

Anyway, whatever way you do it, please Zip the stuff up.

Providing the file is small enough you can send it here. When you are editing your message, look below the area where you are typing. There should be a button "Add an Attachment". When you press that you will be able to browse to find the file you want to attach.

However, if you prefer to keep it between us, send it to me at petedowson@btconnect.com.

I'm off to bed now (it is 2:30 am here), so I won't get to it for a few hours.

Regards,

Pete

Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.