Jump to content
The simFlight Network Forums

Pigeaon hole question


Recommended Posts

I dont know if it is more an FS.cfg matter or Epic one.

I would like every PH value to be sent to Epic when Fs start.

EX: I have 2 fuel gages not initiated until Fuel value changes.

I would like any thing like fuel,wiskey compass and others being

initiated when fs is loaded.

Of course I could make an INIT proc to match with a default FS setting.

But this is not what i would like.

I would like any Fs setting to be sent to Epic at start.

Link to comment
Share on other sites

I dont know if it is more an FS.cfg matter or Epic one.

I would like every PH value to be sent to Epic when Fs start.

EpicInfo does this already, for the selection of values you have chosen. If you are using EpicInfo (you don't say), just enable the logging and you will see.

Pete

Link to comment
Share on other sites

Yes I know.

When Fs start most of the PH are sent and set my stuff.

But I can't get fuel value at start.

I must wait next decrease of the value.

What I don't understand is if I look to Epicinfo log after the test flight, I can see the 100% fuel at the begining.

But this value is not being send to epic until 99%.

Pecular! :shock:

I made a test with a very simple code so I should see 100 at start on my display.

Niet it shows 0 then 99 after it spent 1% of the fuel.

I don't understand why "FUEL_TANK_LEFT_PERCENT=1 "

FUEL_TANK_RIGHT_PERCENT=1 do not sent to Epic at start.

Link to comment
Share on other sites

What I don't understand is if I look to Epicinfo log after the test flight, I can see the 100% fuel at the begining.

But this value is not being send to epic until 99%.

Nor do I, and I can't really help without Logs to look at. I don't use EPIC these days I'm afraid, I haven't for quite a while.

Are you sure it simply isn't being missed at the EPIC end? If the Log shows the correct PH value being sent, I don't think there's anyway it can't be. Are the values before and after being seen?

Regards,

Pete

Link to comment
Share on other sites

I find out that it is not an EPL problem.

I made several tests using PH091 and PH095 as FUEL_TANK_LEFT_PERCENT=1 and FUEL_TANK_RIGHT_PERCENT=1.

These without success to initiate fuel gages at FS start.

What I did is erase PH names from EPICINFO.cfg then put FSUIPC_READ_8=161,4,0B7C and FSUIPC_READ_9=162,4,0B94

Ofset 0B7C for FUEL_TANK_LEFT_PERCENT

0B94 for FUEL_TANK_RIGHT_PERCENT

They work perfectly. Initiate the gages at start and works very well on whole gages range.(using gauge module from R&R)

This is not the first time that I found that FSUIPC_read or write work better than PH variables listed in epicinfo.doc.

I wonder why :roll:

Link to comment
Share on other sites

This is not the first time that I found that FSUIPC_read or write work better than PH variables listed in epicinfo.doc.

I wonder why :roll:

All the named values are listed in a table, and they are all treated the same EXCEPT for a priority value, which tells EpicInfo how often to scan them.

I've just checked, and see that all the Fuel values are listed as "Very Low" in priority. I think this is because, unlike flying instruments, they do not need close monitoring for every small change.

The reason for the priority system dates back to the ISA version of EPIC, which was (and still is) very limited in its capacity to receive information. It was easy to swamp it, and it could actually hang and need resetting.

I'm wondering if this makes it late in the initialisation and actually misses the blocks being sent then. Certainly, if your have a lot of data being sent during initialisation, it will be the lower priority ones which miss out.

As a test you could set the CFG up so that those two are the ONLY items of information being sent. If that works, then the reason is the prioritisation, and the amount of data you are actually requesting.

The other thing you could try, probably more usefully, is reducing the MaxScanFrequency parameter. As you will see from the documentation, by default the lowest priority items are only checked every 30 frames -- you can reduce that all the way down to 1, making them all effectively the same, top, priority.

Sorry I haven't mentioned this stuff before, but it is because I don't remember any of it. I think it dates back about 7 or 8 years now, for the most part!

I suspect the FSUIPC_Read/Write options are automatically placed at top priority.

Regards,

Pete

Link to comment
Share on other sites

As a test you could set the CFG up so that those two are the ONLY items of information being sent. If that works, then the reason is the prioritisation, and the amount of data you are actually requesting.

So I kept only the fuel_left and right_percent and it works.

The other thing you could try, probably more usefully, is reducing the MaxScanFrequency parameter. As you will see from the documentation, by default the lowest priority items are only checked every 30 frames -- you can reduce that all the way down to 1, making them all effectively the same, top, priority.

I ave read the doc.

How do I change MaxScan parameter?

Should I add MaxScanFrequency=1 in epicinfo.cfg?

Is this change will affect EPIC or frame rate of FS?

Link to comment
Share on other sites

So I kept only the fuel_left and right_percent and it works.

Right, so the problem seems to be that there's too much initialisation data, or at least there would be for an ISA EPIC.

I ave read the doc.

How do I change MaxScan parameter?

Should I add MaxScanFrequency=1 in epicinfo.cfg?

As far as I can see from looking at the documentation myself, yes, that is all you do. It is just another EPICINFO.CFG parameter.

Is this change will affect EPIC or frame rate of FS?

Well, I expect it would have had a serious impact when EPICINFO was first written, for FS95. How much impact it might have now I don't know. Assuming you are using a USB EPIC and not an ISA one I should think the EPIC could cope, but I cannot be sure. I'd try it here for you if I could, but I think the easiest thing is for you to try it and see.

You could always try other values then, between 1 and 30.

Regards,

Pete

Link to comment
Share on other sites

I add MaxScanFrequency=10

then MaxScanFrequency=1

Still no change.

It must be simply the limit on the data sent, then, to protect the EPIC from hanging due to buffer overflow.

Can you manage okay using the FSUIPC_Read methods? Otherwise it looks like a matter of reducing the amount of data you need. If I get time I can try to look at the code to see if there's any way to relax the limit, but without being able to test things here properly I am a little reluctant to fiddle with code I am now so unfamiliar with.

Let me know. If it is desperate I can see if I can try something if you don't mind testing things and risking crashes.

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.