Printable View
That's the reason why I said take a spline.
Maybe it is a little bit complicated to program as you have to solve some matrices but all in all I think you will get a result of +/- 0,2 % N1 I think with just a few values.
That accuracy should be enough.
I tested it around 1,5 hours and found a lot of problems:
- Cannot set both QNH decimal points in SIOC creator. No setting box appears if clicking on the graphic.
- EFIS "Long push=pull" is not saved. If I click again on the encoder, the option box is unchecked.
- Right EFIS is still INOP.
- Mectric Alt is INOP.
- If I push the EFIS QNH encoder, no "STD" is displayed.
- Direction of encoders is not working. I have some encoders which need a "-1" that the value goes in the other direction. Or am I making a mistake by entering "-1"? How can I set a direction?
- Sepearte thrust levers would be nice.
- If I press APU Start before the flap is open, I can see N1 increasing if the flap comes open, then N1 goes down to 0 % and N1 increases again. APU comes available. Just optical issue.
- Both PFDs have less than 1 fps! It's unflyable.
- SD: Fuel used is INOP. Maybe just FSX function?
- Sometimes I got I lot of error messages from FMGS server: "Access violation at address 004FE6CF in module 'FMGS Server.exe'. Read of address 00000074."
Is there any moment when your FMGS has no control of flight controls? I wrote my own FBW software to use my gameport joysticks with sidestick priority. Even if AP was disconnected I got control problems. When I closed your AP/FBW program it worked. Unchecking your own FBW function did not solve the problem. I think your AP/FBW and my FBW have some trouble with each other.
So if there is any time, when your software has no control of the flight controls I would be nice if it could write a FSUIPC value. So my software could recognize if it is allowed to control or not.
Unfortunately it was unflyable today... Also got problems with AP which shot me into low earth orbit :D (Maybe performance?)
Got another problem: After starting MCDU and SD on both appeared the message " '' is not a valid boolean value.".
Tried to restart it but without success.
Hello,
I'm away for the weekend, I'll check all those problems when I have a better computer than my iPhone ;)
JeeHell
Hi Kikigey.
I had the same trouble.
Check if the version of MCDU and FMGS server are the same and updated.
Regards
JeanLucques
Hello,
I will check all your SIOC problems with my hardware, and correct the SIOC creator issues (decimal points, long push, encoder direction which should be 1 or -1 as you did).
By the way, just to be sure, STD is achieved by pulling (or long pushing ;) ) the encoder.
Metric Alt is not yet available at all, and not planned for the next release. Unless a lot of russian simmers beg for it ;)
Separate thrust:I will see if I can easily add that in next release, without being too unrealistic (for example, engine failures and all are not yet planned, but the LVR ASYNC will be displayed)
PFDs: maybe it is because of FSUIPC if they are on a network (which is the case on your sim I guess). Check if FSUIPC updates frequently enough, maybe your network is in cause (some Wifi adaptaters seem not to work correctly with FSUIPC, I had the case and it is documented in wideclient documentation if I recall correctly). On my setup, I can launch FSX and the whole suite without fps problems.
SD: yes I think the fuel used offset is FSX only, I'll see if I can find a workaround.
"Access violation" and "not valid boolean" errors : hard to tell why, I guess some part of my code is not clean and tries to read an address in memory already freed... If you have any idea when it happens the most frequently?
FBW troubles: well for the time being, the FBW module ALWAYS has control over the govern offsets. In AP mode, it is obvious why, in manual mode, the FBW maintain a path (i.e. FPA and roll angle) so it needs to use the governs at all times as well. If you check 'no FBW' then the software applies the joystick input to the offset, with the sensitivity correction as well. I will try to see if I can leave completely alone the governs' offsets if you use 'no fbw' option, but if you want to use my manual mode, that won't be possible.
If you tell me exactly what you need for your own software, maybe we can find a workaround?
For the last AP issue, what was the phase of flight?
@JehanLucques:
Maybe I started the wrong FMGS server. My 2 folders of an old and the new version are named almost identical... Will check it the next time.
@ jeehell:
Metric Alt and seperate thrust levers are not important ;) I just wrote down what might be a bug or could be interesting.
PFD: Yep, I'm running it via network. Will check if there is any solution on that.
I noticed the access violation after my flight. So I cannot tell you, when it appeared. Maybe I can perform some test flights the next weekend and pay attention when it appears.
My FBW software writes aileron, elevator, rudder and brake values. If you could add an option where I can turn the raw joystick input off it would be great. Then you could add a FSUIPC offset where I can read if your software has control of the flight controls. So if AP is active there could be a "1" for blocked controls. If your FBW or joystick input is active, there should be a "1", too, for blocked controls. Just if FBW and raw input is off, there should be a "0". In that case my own software would set the controls.
So I would turn your FBW and raw input off to use my own FBW software. When I activate the AP, the offset is set to "1" and my software knows 'now I have no further control because AP is active' (or your FBW/raw input is active) and my software will write no further values so that your software has full authority.
It was initial climb. I rotated, retracted the gear, flew a few hundred feets manually and then engaged the AP for initial climb to 5000 ft. I engaged OP CLB and the pitch angle increased for a VS of around 8000 ft/min. Maybe the problem is caused by the missing of real aircraft performance and/or the presence of my FBW software.
Hi, i would like to see this implementation, i suggest you to make all instruments in one openGL window that we can expand over multi monitors if we want.
The benefit of this would be we can use the display transfer feature in our bus! Like expanded mode in Project Magenta, where you open the window maximize that open the menu and select witch instrument to display.
Hi,
This one is quite difficult for the moment. In the (far) future, I plan to mix the PFD and ND in one exe and the SD and EWD in another one, so switching will be possible, but for the time being it is not possible. I have some CPU limitations with the openGL component I use which I haven't been able to bypass yet.
If you really need the switching thing, I could perhaps do some tweaking such as "physically" moving the ND window where the PFD window is and vice versa?
Anyway, it'll be in a few versions at least, not in next version which is due very soon I hope (with the latest bug you had corrected)
Cheers,
JeeHell
It would be a nice trick i think and can work, we could try.Quote:
Originally Posted by jeehell