I'm not sure
1) If it was, the Interlock in FCC would not be neccessary. So the educated guess is, that it is not.
2) Operating the trim switches in AP on leads to disengagement. Another relay to priorize manual input woud be superfuous.

True, except MCAS is enabled when AP is off, perhaps another overlooked failure mode/path?

Just wanted to highlight that pre MCAS concurrent activation of manual and AP channel was software interlocked as well.

Another educated guess would be, that not AP has priority over manual, but one direction has priority over the other because it's likely to be implemented by a reversion switch both channels are connected to. So from this scenario ANU would be the "default" direction and AND the "reversed" direction activated by either manual or AP channel being switched AND.

Very disturbingly, it looks like that might well be the case. I hope it is not.

Embedded real-time software design carefully budgets the available CPU for the worst case. It would be deeply disturbing if the problem came from that direction, so I'm going to go out on a limb and guess that that's not it. Those programs tend to be extremely static in the sense that tasks/data do not arrive ramdomly or with variable rates, but everything is done on preallocated resources. All the fancy features of scheduling are dispensed with in favor of extreme predictability.

Frankly, if this is the case, as a software engineer, I would be appalled. This is Real-time Systems 1.01.

​​​

Agreed - this was SOP when doing FADEC software changes to the 1980's era engine controls where memory and throughput were at a premium, and making hardware changes to thousands of in-service units was simply not an option. There was often more focus on what they could get rid of to make room then there was on the planned changes.

BTW, while comparisons have been made to the 1201 and 1202 error codes during the Apollo 11 landing, the reason for that was Buzz left the rendezvous radar on during the landing - something that wasn't per the checklist and hence hadn't been checked. On some of the older FADECs, there was logic to drop 'unneeded' processes (usually condition monitoring stuff) if the processor became overloaded.

OK, not Boeing (although it is, now) and not commercial, but military flight control systems, but I did see how they did this at McDonnell Douglas some years ago. They had a big Honeywell computer that was interfaced to the FCC, and had some controls and instrument panel displays provided by another computer, like a Unix workstation (Sun, SGI or so). The Honeywell simulated the aircraft flight dynamics and all the sensor inputs (air data, gyros, feedback from flight control positions sensors, etc.) So, it was to mimic everything the FCC would sense while flying the aircraft. It also recorded all the inputs and outputs so they could be compared with what the FCC was supposed to do.

I'm guessing this is the sort of system Boeing is using to test the 737 Max FCC, and they've got the necessary flight controls rigged to it so the test pilots are doing the normal trim settings, etc. But, it is probably on a desktop with most of the indicators and controls just appearing on a couple screens.

And, from the VAGUE descriptions I've seen so far, it sounds like it could be a problem with priority of various tasks on the FCC. It seems these days an FCC really should NOT be running out of CPU cycles.

Jon

Still waiting for more details, but I found a trim electrical schematic with a slightly different layout, but may add some clarity to the schematic BDAttitude posted above at post #735, in particular the function of the Main Electric Trim Interlock. I'm not claiming to be an expert in reading wiring diagrams, but here's what I see. Flight deck inputs come from the left. The right side represents the trim motor and associated electronic controls. All the FCC inputs (MCAS, STS, Mach Trim, MCAS) appear to come in (off another schematic) into the trim motor box from the right. Various control and limit relays are in the middle.
.


https://cimg6.ibsrv.net/gimg/pprune....c807fc2479.jpg


.
If I am reading this correctly the "Main Trim Arm" relay is activated by one of the pilot yoke switches which, among other things, sends a signal to and opens the interlock relay contained in the trim motor box on the right side:
.

https://cimg6.ibsrv.net/gimg/pprune....5a4983386.jpeg
.

The interlock relay appears to be a basic relay and not a function of any IC processors. This relay appears to be spring-loaded closed allowing automated trim inputs by default (which makes sense because the STS and Mach Trim systems need to be active full time). When a Main Electric Trim switch is actuated, the interlock opens, and this "open" signal goes off the right hand side of the page presumably into the FCC logic which should stop any automated inputs. There is no way to tell from this diagram how the FCC handles that input.

If for some reason the FCC logic does not process the "stop" signal, then I presume that both the Main Electric Trim and the FCC could attempt to send trim signals to the box marked "Controller" located just above the box labeled "Brushless DC Motor." We can't really tell from this schematic if that could happen, or what the Controller would do if it received conflicting signals.

So sorry, no definitive answer, but perhaps narrows the focus some.

All of this should be qualified by the fact that this so far appears to be an issue with the updated FCC software/firmware. Not sure if it could be extended to the original software.

https://www.sfgate.com/business/arti...o-14054004.php

Apologies if it has been posted before, but the FAA finds a new problem with the microprocessor that can induce a dive. Not related to the two crashes they say but....are we sure?

Nevermind, posted already

The 737 is a very safe 50 year old design. The problem lies with the politicians de-fanging the FAA and the defanged agency and Boeing agreeing on a "nudge nudge wink wink" way of certifying its successor without due diligence. The FAA should have the budget to certify properly, as it used to.

If Boeing had known they faced a full check by an independent agency they would have made a good new plane rather than sneak through a pig in a skirt with lipstick.
Edmund

Basically, the accidents have opened a can of worms with the B737, the deeper they go the more they find wrong. Issues which have sat quietly under the radar because they hadn't yet caused problems are coming out into the open. The aircraft is going to be taken apart to the last rivet and evaluated against modern safety standards, 50 year old bicycle chain and cable technology won't cut it in the era of fly by wire.

Every aspect will be looked into from technical to the certification process and no one is going to put his head on the block by signing off unless numerous experts and committees give it the OK.

Universities will be using Boeing's response to the accidents as a case study in future years.

Seems to me that the ' slow" reaction may be due to either a G limit on rate change on the stabilizer or a speed input limiting the rate of change.
Based on the assumption thst MCAS only needed at cruise altitude and speed parameters. But when they later changed the max nose down to 2.5 degrees, they did NOT follow thru with the effects on all other parameters.

Ethopia was at high speed- low AGL and wound up with the worst of both worlds..

I see the MAX as a hurried response to the Airbus Neo. Boeing skipped some sanity checks in the MAX "adaptations"; the FAA blessed the design with less oversight than appropriate.
MCAS was the culprit for two fatal crashes... it could have been another system if the dice rolled another way, Anyway both the FAA and Boeing have some trust to regain.

From SEATTLE TIMES

https://www.seattletimes.com/busines...oeing-737-max/

IMHO - MAX not RTF until Novemeber at earliest- and maybe NG may need ' updates "

Has Transport Canada found something else, the wording is a bit vague?

Certification experts with Transport Canada know of an “unacceptable failure” in the updated flight control computer on the Boeing 737 MAX 8, and they’re looking into how this will affect the ministry’s “ongoing validation efforts,” a statement said Thursday.

The statement came one day after reports emerged that the Federal Aviation Administration (FAA) had found a new risk in the grounded planes that has to be addressed before they can fly again.

What happened to the trim wheel issue? (required strength to move, MAX and NG)

At least finally it looks like the FAA are doing their job instead of rubber stamping and it looks like the MAX won't be flying this Summer. I wonder what Mr Parker's next statement or implied criticism will be.

from my experience in obtaining aircraft certification there is a big difference between FAA and EASA attitudes. In the US Boeing and politicians hold much greater influence over the certification process ( Boeing self certification) than in Europe where the authorities always take a much harder stance in front of the manufacturer.