New Annunciators in NGXu not output

[Pete Dowson]

I searched back in my correspondence to when this was tested for me by another user. This was in november last year.

I made a little Lua file for him to use in tests. I attached it here. Please place it into your P3D Modules folder, then, in FSUIPC Options assign an otherwise unused Keypress to “Lua NGXuCheck”. 

When you’ve loaded the NGXu, use the assigned keypress. It should display, on screen, the values of certain offsets. these are also Logged. Here the log is like this:

 

LUA.0: FUEL_PumpCtrSw(2) at 6461 = 0, 0
LUA.0: FUEL_annunENG_VALVE_CLOSED(2) at 6463 = 0, 0
LUA.0: ELEC_DCMeterSelector at 6473 = 0
LUA.0: FMC_flightNumber at 6614 = ''
LUA.0: DOOR_annunFWD_ENTRY at 6C14 = 0
LUA.0: AIR_DisplayLandAlt at 6C88 = ''
LUA.0: FUEL_AuxFwd A and B at 6C91 = 0, 0
 

They are all zero here because this was before i had any PMDG aircraft running.

 

In your case these should reflect their respective switch or value settings. So please change each of them, one at a time, and use the keypress each time to see if it has changed correctly. I need to know any incorrect indication, or confirm they are correct. I’ve tried to choose indications which you should be able to change and check yourself quite easily.

 

With switches the values are 0 for off, 1 for on. The DC Meter Selector goes from 0 to 7 or maybe 1 to 7 according to the selection.

NGXuCheck.zip

[Pete Dowson]

17 minutes ago, Alpin-Flier said:

I start always with 3300. Now I made some test with different formats. You can see it in the joined log file. I increased the value to 3301 and then back to 3300. No idea, where the long number in your test block comes from.

But but but! The 3300 and 3300 values occur in offset 6C80, not 6C60 as documented and mapped!

   488359 Monitor IPC:6C80 (U32) = 3301
   488359 Monitor IPC:6C80 (U16) = 3301
   488359 Monitor IPC:6C80 (U16) = 0xCE5
   488359 Monitor IPC:6C80 (U32) = 0xCE5
   488359 Offset 6C80 = E5
   489406 Monitor IPC:6C80 (U32) = 3300
   489406 Monitor IPC:6C80 (U16) = 3300
   489406 Monitor IPC:6C80 (U16) = 0xCE4
   489406 Monitor IPC:6C80 (U32) = 0xCE4

If this is really at 6C80 instead of 6C60 it implies all of them above that are 32 bytes out!!! 😞

What made you choose 6C80, or is it monitoring it as part of the Monitor4 entry I gave you? If so why is it logging in decimal and hex?

This is really weird. When did you decide it was the value at 6C80 instead of the documented one?

BTW, I checked back to me previous tester's reports. he was using an NGX comparible setup, not using the new NGXu values. So you are, in fact, my first real NGXu tester! I'm going to have to continue until i get this working ... oh dear.

Pete

 

 

[Alpin-Flier]

48 minutes ago, Pete Dowson said:

BTW, I checked back to me previous tester's reports. he was using an NGX comparible setup, not using the new NGXu values. So you are, in fact, my first real NGXu tester! I'm going to have to continue until i get this working ... oh dear.

Oh, this explains a lot. I will help as much as I am able, of course, to sort it out.

48 minutes ago, Pete Dowson said:

What made you choose 6C80, or is it monitoring it as part of the Monitor4 entry I gave you? If so why is it logging in decimal and hex?

This was with the new dll's, you sent me. The original (..154) made a lot of crazy outputs. I have seen, that changes to the ADF were visible in the log-file at 6C80. So I wanted to see how the frequency is shown in different formats. And as we can see, U16, but also U32 show the correct result in decimal. The hex format shows 0xCE5, but the log file shows 488359 Offset 6C80 = E5 so it must be a part of the correct value. So I aks myself, how the log file treats formats of the vars. E.g.  a change from 3300 to 3301 is only shown in 6C80. The rest, probably at 6C81,  does not change, so it is not shown in the log. This is confusing. But perhaps I am completely wrong.

I made now a test  with the original version (6C6A for ADF) producing high decimal numbers. But shifting to 6C6C and U32 format I get the correct frequency! The lower part of the whole data block seems to work. Problems start at 6C7D. Is it a question of different data formats at different offsets? Well, I am not very experienced with SW...

To start the NGXu, begin with the raptor (default), then change the aircraft to NGXu (not as scenario). It should be at the preselected runway start position with running motors. Don't select any cold and dark, because then you get warnings (e.g. battery discharge) and must start APU and connect busses. Alternatively: I send you my test002 exemple, that you can put in the Documents/Prepar3d v4 Files directory and then select it as scenario. I hope this works.

Urs

test002.fxml test002.wx

[Pete Dowson]

9 minutes ago, Alpin-Flier said:

The hex format shows 0xCE5, but the log file shows 488359 Offset 6C80 = E5 so it must be a part of the correct value. So I aks myself, how the log file treats formats of the vars. E.g.  a change from 3300 to 3301 is only shown in 6C80. The rest, probably at 6C81,  does not change, so it is not shown in the log. 

0x3E5 = 3301  (3 x 256  +  14 x 16  + 1 = 3301, check yourself on a calculator. Note that in Hex A = 10 .... F = 15, so E = 14.).

0x3E4 = 3300 (one less). The "high" byte (offset 6681) doesn't change still 0x3. Only the low byte changes from 0xE5 to 0xE4.

(Intel processors store numbers from the low prt to the high part.  Some other makers did the reverse).

13 minutes ago, Alpin-Flier said:

I made now a test  with the original version (6C6A for ADF) producing high decimal numbers. But shifting to 6C6C and U32 format I get the correct frequency!

Sorry, I am confused. 6C6C is not the same as 6C80 as before. Can you explain please?

When you say "original version", are you talking about the official issue of FSUIPC5 (5.154) or do you mean something different?

17 minutes ago, Alpin-Flier said:

To start the NGXu, begin with the raptor (default)

Is this mandatory at P3D start time, or can I switch from my normal plane to that first? I can only get the NGXu to run on my Piper Cockpit (another hardware cockpit) which currently boots into a Piper Arrow III.

18 minutes ago, Alpin-Flier said:

It should be at the preselected runway start position with running motors.

You mean start the engine in the Raptor first? I assume you mean motor = engine?

19 minutes ago, Alpin-Flier said:

Don't select any cold and dark, because then you get warnings (e.g. battery discharge)

Surely you only get battery discharge after turning on the battery. Cold and dark = battery off too! (I do know all about starting an 737 from cold and dark. i do it all the time in my NG cockpit! 😉 ). At least with cold and dark I'd know what to do. By default this thing is starting up in a crazy state!!

22 minutes ago, Alpin-Flier said:

I send you my test002 exemple, that you can put in the Documents/Prepar3d v4 Files directory and then select it as scenario. I hope this works.

Okay, thanks. I'll try this tomorrow. i'm taking the evening here off. I'm flaking a bit (old age. 77 this year, and starting to feel t!).

Don't I need a "sav" file for the cockpit state too?  See your PMDG\737NGXu folder. I suspect without that I'll get the same default state I'm getting now?

Thanks,
Pete

 

 

 

 

[Alpin-Flier]

14 hours ago, Pete Dowson said:

0x3E5 = 3301  (3 x 256  +  14 x 16  + 1 = 3301

Not really correct. The log shows 0C for the higher byte, E5 for the lower. So take C as 12:   12 x 256 + 14 x 16  + 5 = 3301. There we are...

Lets start from the actual dll version (..154) again. The correct ADF value is found in 6C6C (not 6C6A). Then the hex values in 6C6C and 6C6D are correct:

"07 6C" for 1900, "0C E4" for 3300, "44 5C" for 17500

Then three booleans on 6C6E, 6C6F and 6C70 follow for the ATS servo commands. I can check at the moment only the AT command on 6C70, it works fine.

Then 16 bus booleans follow to represent different bus states. They work all correct up to 6C7C. But then there is no signal any more. All bytes on 0, no influence from the sim. This is also valid for booleans following on top of the busses. There is some strange inputs on 6C8D (toggles between 0 and 48), 6C8E (0...145) and 6C8F (0...65). I think these are the Flight and Land alt values. But dialing these values does not influence the offsets.

So something goes wrong from 6C7D upwards.

14 hours ago, Pete Dowson said:

Sorry, I am confused. 6C6C is not the same as 6C80 as before. Can you explain please?

When you say "original version", are you talking about the official issue of FSUIPC5 (5.154) or do you mean something different?

I think you shifted offsets for test purpose in versions 153g, 153h and 153i. So I did the tests above again with the official 5.154 version to avoid confusion.

14 hours ago, Pete Dowson said:

Is this mandatory at P3D start time, or can I switch from my normal plane to that first? I can only get the NGXu to run on my Piper Cockpit (another hardware cockpit) which currently boots into a Piper Arrow III.

You can take any plane in P3D as default at start, but not one from PMDG. After this, you can select the PMDG, by aircraft or scenario selection. When you want to change between PMDG aircrafts without leaving P3D, select the default aircraft inbetween and then again the PMDG. That seems to work fine.

 

15 hours ago, Pete Dowson said:

You mean start the engine in the Raptor first? I assume you mean motor = engine?

It is not necessary to start the raptor or your other default plane. But the start screen must show your default first. PMDG explains this so: When showing the start screen, some SW loading has already be done in the background.

15 hours ago, Pete Dowson said:

At least with cold and dark I'd know what to do. By default this thing is starting up in a crazy state!!

Well, I can understand that. But you told me also not to be interested operating the PMDG, just to have it ready for tests. And so a plane with running engines (of course !) on the runway, but with park brake set, gives the easiest access. This is also recommended for the first tutorial. Unfortunately the NGXu has no "tutorial 1" scenario any more (as NGX had). But it should not be really a problem. By the way, I can tell you, that the PMDG NGX is worth to deal with.

15 hours ago, Pete Dowson said:

Don't I need a "sav" file for the cockpit state too? 

It seems that I have a default config for test002. You can select the panel state in the FMC: Menu / PMDG Setup / Panel state load

Urs

[Pete Dowson]

2 hours ago, Alpin-Flier said:

Not really correct. The log shows 0C for the higher byte, E5 for the lower. So take C as 12:   12 x 256 + 14 x 16  + 5 = 3301. There we are...

Yes, of course. Sorry. I was thinking of something else at the time -- I've got three things on at the same time. I'm busier now I've retired than I was before! 😞

2 hours ago, Alpin-Flier said:

I think you shifted offsets for test purpose in versions 153g, 153h and 153i. So I did the tests above again with the official 5.154 version to avoid confusion.

No, I didn't shift them. Just revised the code (in version 5153i only) to make it clearer what was being moved where. The only changes in 5153g and h was the extra logging.

I'm still not understanding how the correct ADF frequency got to offset 6C80.

2 hours ago, Alpin-Flier said:

You can take any plane in P3D as default at start, but not one from PMDG. After this, you can select the PMDG, by aircraft or scenario selection. When you want to change between PMDG aircrafts without leaving P3D, select the default aircraft inbetween and then again the PMDG. That seems to work fine.

Okay. That makes it a bit easier.

2 hours ago, Alpin-Flier said:

But you told me also not to be interested operating the PMDG, just to have it ready for tests. And so a plane with running engines (of course !) on the runway, but with park brake set, gives the easiest access.

Okay, good. So that's what the flight you provides sets up? 

2 hours ago, Alpin-Flier said:

By the way, I can tell you, that the PMDG NGX is worth to deal with.

Not for a complete hardware cockpit. The main software for such is Prosim, SimAvionics, or Project Magenta (the last now being rather long in the tooth). I use Prosim737 which is excellent in its simulation of all 737NG systems, controls, indicators and displays.

2 hours ago, Alpin-Flier said:

It seems that I have a default config for test002. You can select the panel state in the FMC: Menu / PMDG Setup / Panel state load

But if I just load your flight I'm okay? No need to load a panel state file? If I do, then the only installed ones are:

Cold&Dark
LONG
SHORT

plus those from my own rief aborted test and the usual "previous flight".

What are "SHORT" and "LONG"?

Pete

 

[Alpin-Flier]

52 minutes ago, Pete Dowson said:

I'm still not understanding how the correct ADF frequency got to offset 6C80.

Yes, really strange, if you did not "offset offsets". For the moment I go on with the original 154. And I tested now also all three AFS servo commands during a flight. So I found A/T in 6C70 (as said before), Pitch in 6C71 and Roll in 6C72. They are shown correct with 0 and 1. Then at 6C73 the booleans for the busses start. 6C6E and 6C6F seem to have no function.

52 minutes ago, Pete Dowson said:

So that's what the flight you provides sets up? 

Yes. You are at the holding point for runway 28 in Zurich, ready for lining up. And it is independent from an earlier panel state. So engines should run, no warnings. But set park brake, before you go on. Good practice for pilots, who want to survive when they try something..😄

52 minutes ago, Pete Dowson said:

But if I just load your flight I'm okay?

Yes. But you can change it in the FMC for Cold'n Dark, Short (for short flights) or Long (for long distance). Up to now I used only short.

Urs

Edit: Reading again through the last posts I think to know the reason for the "wrong" offset. I made that test with version 153i.

[Pete Dowson]

I think I hsve resolved it, or at least most of it.

PMDG have apparently used a different value alignment for their data structure. Mostly FSUIPC has to use one-byte alignment, as most of the SimConnect and other data needs also assume this. The one byte alignment makes sure every value follows on directly from the previous one no matter what type it is.

Other alignments (e.g 4 byte) ensure that 16-bit (2 byte values) start on 2 byte boundary,  32-bit or Float values on a 4 byte boundary, etc. This can result in unused bytes in between values unless the data structure is carefully designed to avoid this.

The expansion of the PMDG data to include new values for the NG3 seems to have departed from this.

Please try FSUIPC 5.153j (attached) for me. It still has those test bits I added, but it does seem to be okay for the values we were testing before.

If you can, I'd like a good sample of the values tested throughout, not just in the new NGXu section, because I'm worried I've possibly messed things up for the NGX part of the data.

Also, towards the end of the added data I've placed 7 new bytes, assorted FUEL values (from FUEL_AuxFwd to FUEL_GNDXfr. I don't know how to operate these so cannot check them.

I've found it very difficult indeed to operate the panels on the PMDG aircraft. I would normally use specific views for each (selectable on Views menu). However, the mouse won't operate the switches and dials on those specific views. They appear to be just views, not usable panels. Very strange and most annoying.

So I try to do things on the virtual cockpit, but I'm hopeless trying to move it to where I need it, and get it the right way up (!). My extreme tunnel vision doesn't help (I have advanced Retiinitis Pigmentosa). I really don't know what folks like about virtual cockpits. I'm very spoiled having a nice hardware one. :-)

Anyway, thanks for any checking you can do for me. When it is finallly shown to be okay I'll let John know (he's in charge of FSUIPC5 development now) and see if he wants to fix it in a version soon, or wait for something else to make a new release worthwhile. If the latter I'll tidy this version up for you to use if you wish.

Pete

 

FSUIPC5153j.zip

[Alpin-Flier]

Dear Pete

Yeeeeeeeeessssssssssssssssss!!! You did it. 😃 😄😃 The whole new block is working now. Even the Flight and Land Altitude windows work, including the negative sign. I was preparing an Excel list to ease design, not needed anymore now, but I think, it is still useful (see attachment).

Tomorrow I will check also the new fuel offsets, because they are only needed in the B737-900 version, that I never used up to now. And also check other data areas and then send a log file, if it looks reasonable.

You are right with the difficult mouse control on certain panels. I think it has to do with screen resolution, focus, full_screen and similar stuff. I use this only on my test place with 3 monitors in viewgroup mode. Some panels inside this window (e.g. FMC) work fine with the mouse. Of course, I also prefer my homecockpit downstairs.

Thanks for all the good work and best regards

Urs

New Offsets NGXu.xlsx

[John Dowson]

16 hours ago, Pete Dowson said:

When it is finallly shown to be okay I'll let John know (he's in charge of FSUIPC5 development now) and see if he wants to fix it in a version soon, or wait for something else to make a new release worthwhile. If the latter I'll tidy this version up for you to use if you wish.

I think its worth releasing this as a new version (5.155) once its verified. If you could push the changes I'll merge them into the 5.154 release and release later this week.

John

[Alpin-Flier]

16 hours ago, Pete Dowson said:

If you can, I'd like a good sample of the values tested throughout, not just in the new NGXu section, because I'm worried I've possibly messed things up for the NGX part of the data.

Please find enclosed a commented log file for all new NGUx vars. The Aux fuel switches (only used in B737-900ER) also work fine. Good job!!

Please let me know, which of the other NGXu vars could be critical, so I can test them in the same way.

Urs

Edit: Hi John, just saw your post. These are really good news 🙂

FSUIPC5_NewNGXu.log

[Pete Dowson]

1 hour ago, Alpin-Flier said:

Please let me know, which of the other NGXu vars could be critical, so I can test them in the same way.

Looks good for the NGXu additions. Can you also check just a random (scattered) sample of the ordinary NGX values please? Assuming I haven't messed those up I think we're good to go, and I'll get the changes to John.

Pete

 

[Alpin-Flier]

I did now an extensive test on most NGXu vars from offset 6420 upwards. I had also a special look to multiposition switches and displays. Gentlemen, everything is working fine, offsets are at their correct positions, values represented correct. There is a small correction in your offset mapping file: offset 6469 is not a boolean, but 0 for off, 1 for dimmed and 2 for highlighted.

So I think you can go on with the corrected version. I will be happy to use it as first. It was an honour to assist you 🙂. 

All the best

Urs

[Pete Dowson]

14 minutes ago, Alpin-Flier said:

So I think you can go on with the corrected version. I will be happy to use it as first. It was an honour to assist you

Okay. Thank you very much for testing!

Pete

 

[John Dowson]

FYI, FSUIPC 5.155 has been released, containing this fix.

John

[Pete Dowson]

23 hours ago, Alpin-Flier said:

There is a small correction in your offset mapping file: offset 6469 is not a boolean, but 0 for off, 1 for dimmed and 2 for highlighted.

Is that how it behaves? Because the PMDG listing has it as: 0: Closed  1: Open  2: In transit (dim)

Maybe an error in the PMDG list?

Pete

 

[Alpin-Flier]

This is an error since longtime and was never corrected. The (dim) remark should be next to Open. During transit the lamp is highligted in the VC.

By the way, I asked PMDG also to make the anti-ice-switches working the same way. But there was no success, unfortunately. I had to do it with script timers. Is's not really a problem.

Thank you very much for the final version. I will install it tomorrow.

Have a nice weekend

Urs

[Luke Kolin]

5 hours ago, John Dowson said:

FYI, FSUIPC 5.155 has been released, containing this fix.

The Installer appears to be contained in a ZIP file within a ZIP file, with the same name.

Cheers!

[John Dowson]

Yes, sorry - don't know what happened there. Also looks to be the wrong version (or at least the document). I've just re-packaged and uploaded, so please try again.

Sorry about that.

John

[Luke Kolin]

No worries, just wanted to let you know.

Cheers!