(SOLVED) PM Mcp error log saying: failed to access thrust bin

[Pantu]

Hi All,

since I moved from FSX to P3Dv4 and Win 10 recently, I couldn´t perform one single landing with PM autopilot and PMs 737-800 flight model for P3D.
The MCP seems to ignore speed settings of the flightplan especially on descent. Using VNAV on the descent the throttle should go to idle but min I can reach is about 40% and speed is building up. Spoilers are more or less effectless.
Also the N1 bug on the upper EICAS is missing. Regardless what is set in the CDU.
Checked the error log of the MCP and found one line saying: failure to access thrust bin.
Don´t know what that message means as there is a copy of the NetDir thrust.bin in the root dir of the Mcp. It can be read and also be altered.
PM file check confirms erverything ok. All read and write access file sharing and netDir.
Don´t have a clue what´s going wrong here.

BTW I´m happy to see this forum alive dealing with PM stuff as cockpit.org forum is obviously dead.

Hope some of you PM gurus out here may have an explanation or solution for my problems.

Thanks a lot in advance

[jr2mey]

If you are using wide client, check your error log to see if you are intermittently dropping and reconnecting your network.  This can occur in both wired and wireless setups.

I had this occur to me when I had one computer that was dropping/reconnecting and slowing down my entire network for some reason.

[Pantu]

Thank you James
Will give it a try.
What still puzzles me is that The N1bug on the upper Eicas is not diplayed even though it is set to on in the pfd ini

Best regards
Pete

[Trevor Hale]

Also Pete, we just helpped another group of guys with their PM autopilot issues, Look back a couple posts.  You will see one where we covered in depth issues to look at for VNAV and throttle hunting. as well as Autopilot settings.
Hope we can help.
Trev

[Pantu]

Hi James and Trevor,

thanks again for your input. Have again and again checked everything back and forth but couldn´t find any hint in any log file why the MCP couldn´t access the thrust.bin file. Also pmcheckfile reported the FSPlans sharing as well as the NetDir sharing (NetDir = \\pc2\NetDir) being ok.
Digging further eventually I found the culprit:
Due to my own stupidity I had created a folder "NetDir" in the root of PC2 (Here is the CDU installed) and shared it as NetDir. I blindly believed in pmfilecheck´s findings and did not realize that this folder was empty and hence the MCP couldn´t access the thrust.bin file as there was none. The CDU writes only in its own folder "NetDir" inside the CDU directory.
If one only shares the main folder (CDU) also the subfolders are shared. So the NetDir residing inside of CDU is shared, but as: NetDir = \\pc2\CDU\Netdir.
The MCP and other PM programs however expect the NetDir on: \\pc2\NetDir.
It is therefor absolutely necessary to follow the sharing procedure described in the projectmagenta doc manual!
After correcting the problem I made a first flight with a perfect autolanding.
Now I´m a happy camper again.

Thanks again and best regards
Pete

[Trevor Hale]

Great Job Pete, and thank you for coming back and reporting the issue.
Excellent work.
Trev

[jr2mey]

Great to hear that you got it figured out Pete!  That NetDir set up can be a buggar. Also, thanks for sharing your find.  Who knows, who will have a need for this info in the future!

[RayS]

Glad this got resolved.

My $0.02 worth, for what it's worth.

File/folder sharing seems like such an antiquated approach nowadays. Things like this really need to be database-driven. This eliminates SO many issues with windows updates, security vulnerabilities, permissions, etc...

In the data world we call it 'Single source of truth'. CDU needs to set VSpeeds for a fully-loaded flight? Write it to the database. PFD needs to display new VSpeeds? Make a call to the database.

But when people hear "Database", what they really hear is "Complexity". However, when Microsoft performs an update and blows away file sharing or imposes a new security profile, there is a very real, tangible and very frustrating amount of complexity in getting all of that working again.

I've spent some time adding database functionality to what used to be the FreeFD product from Don Lafontaine (Avidyne systems) and let me tell you, it is FAR better to read/write data from a database than having to traverse the file system to read/write to files.

Maybe someday Don and I will bring this to fruition.   :-)

 

[Trevor Hale]

Ray. Would you not have to set up sharing (regardless of database or not) Because the database would still need to be shared between computers wouldn't it?
Trev

[RayS]

Trevor,

The concept of sharing doesn't really apply in the database world. Even this site, which uses a MySQL database, isn't shared. Rather, clients, only need an IP address or a UNC to access the data. The entire file-sharing security model at the OS level has no bearing on connection success or not.

What DOES affect access is firewall configurations. I've heard that Microsoft will sometimes push out an update and it will blow away custom firewall configurations. (Corporations may also place restrictions on company-owned computers that will prevent access.) People using company laptops on home networks may experience this) 

Basically you tell your clients that a database is at IP Address 12.34.56.78 or a friendly name like \\MyDB Server), on Port 3306 (If it's a MySQL database. 3306 is the default port# for a MySQL database.)

I can only imagine my own career if Windows updates kept breaking everyone's database access!