[Setting Spoilers/Speedbrakes via Offset 0BD0]

22 hours ago, masmaz said:

if you see the image I attached there is the part of the joystick axis and under the FSUIPC configuration

One of the images you attached showed that you assigned the ProSim servo control to offset 0BCC. But 0BCC is just a boolean flag, values 0 or 1, indicating whether the speedbrake is armed or not. How do you expect your servo to move to positions 0 and 1? Even if it did move you would hardly see it.

0BCC and 0BD0 are set by the sim according to the axis position. I don't know anything about ProSim's assignable servo output, but surely it should go to a separate user offset, like those in the 66C0 range.  Maybe offset 0BCC will work, if ProSim drives the default speedbake. Certainly 0BCC is being set correctly here -- I don't have anything assigned to it in ProSim. I suspect assigning the Server output to 0BCC as well may cause conflicts with the Sim also setting it.

You said:

20 hours ago, masmaz said:

ok the solution is to use 2 offsets on mobiflight:

 on Mobiflight: Arm 0BCC Byte 4, 4800/16383
on Prosim: FSUIPC 32 bit U 0x0BCC

But you are using 0BCC, which is 0 for not-armed, 1 for armed. Surely you need the lever position, which is in 0BD0, or, better, a user offset, as I said.

I don't understand why Mobiflight needs the 'on ground' offset.  When the speedbrake is armed the detection of ground is automatic in the speedbrake operation. That's the whole point or arming it.

Pete

 

[Setting Spoilers/Speedbrakes via Offset 0BD0]

19 hours ago, masmaz said:

in prosim configured with FSUIPC U32 and 4 Byte on mobiflight

Sorry, I don't understand this part. Isn't your spoiler lever a normal joystick axis which you can assign directly, and calibrate, in ProSim?

19 hours ago, masmaz said:

Explain how your lever moves...?

I use my hand. It isn't motorized.

I don't know MobiFlight. But why are you not assigning in ProSim? Version 3 or ProSim really does need all control axes assigned and calibrated directly in its config.

Pete

 

[Setting Spoilers/Speedbrakes via Offset 0BD0]

3 minutes ago, masmaz said:

i'm struggling with the spoiler, with arduino, mobiflight, prosim and p3d.... with the offsets 0BCC and 0BD0. they don't work even if i set 4800 or 5620.

I tested this today with ProsimB737, version 3.16B24 (almost the latest).

My spoiler is assigned as an axis in ProSim, with the calibration, including the ARM position, done in ProSim. I logged the offsets 0BCC and 0BD0 and they were being updated correctly whilst I manipulated the spoiler lever.

So, you certainly should be able to use those offsets to drive your spoiler motor.

Pete

 

[MakeRwys error]

37 minutes ago, trisho0 said:

Ran MakeRwys again and Success! I guess now is OK?

I found an incomplete Area scenery lines from Scenery cfg file.

Yes, looks good now. Congratulations!

Pete

 

[Makerunway R5.bin Runway Number and Runway Designation Issues]

10 hours ago, forstmeier said:

Yes i will copy it there

Thank you!

10 hours ago, forstmeier said:

There are several differences between the various simulators.
If FSX + MSFS indicates Rwy 33 at LJMB, xplane is indicating 32

Perhaps they are using data from different dates. The magnetic runway headings can change due to changes in the Earth's magnetic field.  Of course, the True heading should be the same.

Pete

 

[MakeRwys error]

10 hours ago, trisho0 said:

Just ran the MakeRways inn P3Dv4.5 again but without Admin Rights and attached the Runways.txt for analysis.

If I run the MakeRways again WITH Admin Rights, it appears the error in question.

Any ideas, to give another try or simply leave it alone?

It looks like there's some sort of corruption which is causing the LorbySceneryExport program to fail to read the P3D4 add-ons.cfg files it needs to in order to find all the AddOn sceneries installed via XML files in your P3D add-ons folder (in your Documents). There should be one in you ProgramData\Lockheed Martin\Prepar3D v4 folder and another in your users\<user name>\AppData\Roaming\Lockheed Martin\Prepar3D v4 folder. The resulting MakeRwys_Scenery.cfg file is either empty, or in error:

Using "LorbySceneryExport.exe MakeRwys_Scenery.cfg"
LorbySceneryExport executed: Checking for "MakeRwys_Scenery.cfg"
Reading Prepar3D v4 scenery:
The CFG file being used is: "D:\Lockheed Martin\Prepar3D v4\MakeRwys_Scenery.cfg"
0 scenery layers to be processed

When you run without Admin rights, LorbySceneryExport cannot run. This is the error:

... ERROR: failed to run Lorby program, error=740!
Reading Prepar3D v4 scenery:
The CFG file being used is: "C:\ProgramData\Lockheed Martin\Prepar3D v4\SCENERY.CFG"
486 scenery layers to be processed

So MakeRwys has to revert to only using the Scenery.CFG file. This means that any and all add-on sceneries which install via the Add-On.xml method are omitted from the scan.

Please run with Admin rights again, and show me the resulting MakeRwys_Scenery.cfg which you''ll find in the P3D folder.

You should also run Lorby's AddonOrganizer program and check that it shows all you sceneries okay.

The addons method is not used by FSX, and your P3Dv5 installation must be okay,

Pete

 

[Makerunway R5.bin Runway Number and Runway Designation Issues]

6 hours ago, forstmeier said:

Years ago I wrote the program
"RwyLength"

Your post is very interesting. Are you wishing to allow others to make use of your work? If so, would you like to re-post this data to the "User Contributions" subforum, above? I can do this for you if you prefer, with just a small edit needed to divorce it from this thread.

Pete

 

[MakeRwys error]

34 minutes ago, trisho0 said:

After reading manual I ran the MakeRwys.exe file and got error message make runways failed to make fstartrc rws file.

Just that one file? The others were okay? I'd need to se the Runways.txt file to understand why.

35 minutes ago, trisho0 said:

I ran it as Administrator. But I ran without Admin rights, and it was fine. Why the manual says Must be run as Administrator?

Because access is needed to folders in your system which are normally protected. In particular, the Lorby scanning utility used for P3D must run with Admin rights.

If it works without that, fine, but in that case it must run with admin rights -- they don't reduce capabilities! Quite the reverse.

If you want further help you need to specify version numbers -- MakeRwys version AND sim version (FS98, FS2000, FS2002, FS2004, FSX, FSX-SE, P3D1,2,3,4,5 or MSFS).

Pete

 

[PFC quadrant Throttel 1 unstable MSFS 2020]

13 hours ago, angelfr said:

Since some weeks, my PFC (Precission Flight Controls) (Sim: MSFS 2020) quadrant have problems with the throttel number 1. It suffer fluctuations with different planes.
...
 It was working fine it the past.

The software for the PFC hasn't changed, so what has changed on your system? If this is happening with no changes in software, then it must be a hardware problem.

You appear to have some odd assignments in FSUIPC for different aircraft Profiles: for example these oddities:

B747: Steering, Throttles1+2, 3+4: no reverse, no spoiler, no flaps
A320 FBW: only Prop1
Cessna jet & F-358: nothing
CRJ 1000: Spoiler, Throttle (=all throttles), Throttle2 (?!)

And for the Hawk T1 you've assigned Throttle1 and Radiator cooling flaps (only), and have calibrated the Spoiler (not assigned).

This is all a bit of a mess, with no consistency. AND you've not actually calibrated any of the axes you've assigned in FSUIPC.

You so seem to have calibrated in the PFC driver itself, but with a mix of assignments, some in FSUIPC and presumably the rest left to the PFC driver, it is not easily possible for use to point to exactly what you might have wrong (assuming it isn't a hardware problem, which seems more likely.

13 hours ago, angelfr said:

It suffer fluctuations with different planes.

Fluctuations are commonly caused by multiple assignments to the same control, causing conflicts.  For example, one such conflict is where you have the generic throttle assigned to one lever (so controlling all throttles) and throttle 2 assigned to another (the CRJ1000 assignments).

14 hours ago, angelfr said:

I noticed that is the 6th lever (Reverse axis) which is mixing his inputs with the throttel lever. The last has priority but the rev lever change the input very often.

The reverser is just a throttle sending -ve thrust numbers to the same throttle, so the main throttle should be at idle when using the reverser and vice versa. With a professional style quadrant this is assured by the design of the levers (the one attached to the other). With separate levers it is your job to use them correctly.

14 hours ago, angelfr said:

Any sugestion will be apreciated

First off, concentrate on getting things working properly on one aircraft. There's no way we can diagnose problems with such a complete mix, each aircraft having its own odd set of assignments and calibrations, mixed between FSUIPC and PFCcom. Try to keep everything in FSUIPC because that has the Profile facility whereas PFCcom only has a few paricular types. The latter is a lot simpler if you only fly one or two different aircraft types, but you have many different ones and profiles would be better because of that, but you need ot be more consistent in where you are assigning and especially calibrating.

So, select an aircraft, sort out your assignments and calibrations in FSUIPC, and test. If you still have problems then it might be possible for us to help you via logging or other methods.

Pete

 

[Cant Find Some offsets]

10 hours ago, Zaid said:

Hello, I am trying to add overhead panel annunciators to the pmdg 737 with mobiflight, but i can not find most of the offsets needed, examples include, the AT/PRST, AP/PRST, FMC/PRST mastercaution button and fire warnign button. 

Just a correction. Those are not overhead indicator/buttons, but part of the MIP or Glareshield. Maybe you are looking in the wrong section? They are definitely listed. Look in the Glareshield section for Caution and Fire, and the Forward Panel section for the AT, AP and FMC inidicators.

Pete

 

[Issue Mouse macros]

I don't think very many of the gauges and switches in PMDG aircraft are susceptible to mouse macros. In FSX-SE (FSUIPC4) that facility relies on the coding of the gauges being strictly to FS2004 C++ programming, using the tools originally provided by MS.  The facility is a 'hack' into the code. Most gauges just aren't coded to suit. In P3D4 and P3D5 the mouse macro facilities depend on new facilities implemented for us by L-M, and are thereby more consistently applicable.

Pretty much ALL of the switches and dials in the PMDG 737 implementation can be controlled using the <custom control>s John mentions.  I think you'll need to explain exactly what switches etc you are trying to program for which you think  there's no provided control already. What have you actually tried?

Pete

 

[Runway Maker / PF3]

Can you explain a few things please: what is PF3? What is meant by "fax or p3 data"? What 'runway maker' are you talking about?

Actual names and version numbers please!

Pete

 

[Makerunway R5.bin Runway Number and Runway Designation Issues]

30 minutes ago, pshkong said:

Thanks! Very clear.

STOP PRESS!

I suddenly remembered: there are lines in the Log (Runways.txt) showing a computed threshold/start. This is actually computed with trig the way I said, thus:

                    // Compute better thresholds and get other stuff
                    rwy1.r.fLat = (float) ((double) rwy1.fLat - (((double) rwy1.r.uLen * cos((double) fHeading * PI / 180.0)) / 729132.0));
                    rwy1.r.fLong =  (float) ((double) rwy1.fLong - (((double) rwy1.r.uLen * sin((double) fHeading * PI / 180.0)) /
                                        (729132.0 * cos((double) rwy1.fLat * PI / 180.0))));
                    fprintf(fpAFDS, "              Computed start %s: Lat %.6f Long %.6f\n",
                                chWork2, (double) rwy1.r.fLat, (double) rwy1.r.fLong); 

So the positions given ARE the centres of the end lines of the runway!

I seem to remember I did this because so many runway "start" records were actually set at the hold point off the runway. This is especially the case for many add-on airports.

Sorry about my first answer. Most of this code is so old I don't remember it well (and old age isn't helping).

Pete

 

[Makerunway R5.bin Runway Number and Runway Designation Issues]

35 minutes ago, pshkong said:

Just a small question about make runway, how is the threshold offset being dealt with?  Does the threshold include the offset or not?  Many thanks!

The threshold lat/lon is just what is provided in the BGLs, usually from a "Start" record (the data used by the sim when you opt to start on a runway). No computation involving any threshold offset is performed. Makerunways' job is simply to extract and file the data. How it is used and what it all means is up to the user.

Possibly, if you actually want the coordinates of the very ends of the runway you would need to compute this from the runway length, the centre coordinates and the direction of the runway -- i.e. a bit of trig.

Pete

 

[Makerunway R5.bin Runway Number and Runway Designation Issues]

13 minutes ago, pshkong said:

The new version works like magic! 

Good. I'll make it the current version, then. Thanks for the quick feedback.

Pete

 

[Makerunway R5.bin Runway Number and Runway Designation Issues]

I had a look at the code and I think I've fixed the problem. It looks like it's been there since the very first version which was released in 1999, so it's over 22 years old! Surprising no one has reported before!  I assume the binary format is very rarely used.

BTW your version 5.128 is out of date, 5.129 is current. However, it would have made no difference.

Please try the attached and let me know. If okay I'll make it a proper release -- it is version 5.13 now.

Pete

 

MakeRwys.exe

[Unable to Manually Edit & Save FSUIPC6.ini]

13 hours ago, Sea2Sky said:

The idea was not have to update the ini file manually, but to back it up and have the ability to restore FSUIPC6 without the need of re-configuring the buttons in the FSUIPC application.

Yes, it is a very wise thing to backup your INI file. You shouldn't have a problem -- it is just a text file after all, in the FSUIPC installation folder.

13 hours ago, Sea2Sky said:

After making the necessary adjustments, I see that K# value is what appears to maps the keys. I was initially looking for documentation on FSUIPC6.ini key/values, but I don't think it's publicly available. I've been trying to decode the values using common sense with some process of elimination

What's wrong with looking it up in the FSUIPC Advanced User's manual, provided as part of the FSUIPC installed documentation? The section on button programming provides a complete list of the Key codes used.

13 hours ago, Sea2Sky said:

Still trying to determine what the P and R represent; initially I thought it was Push vs Rotary.

No, 'Press' and 'Repeat', as described fully in the document. If you want to find things out, supplied documentation is a good place to start!

Pete

 

[Makerunway R5.bin Runway Number and Runway Designation Issues]

2 hours ago, pshkong said:

Do you have an idea how what's going on?

No, sorry. I'll have a look, but it will be next week now. First, though, please tell me the version number and what simulator you are using it with. And are they default or add-on airports?

Pete

 

[SetbitsXX, ClearbitsXX, TogglebitsXX]

30 minutes ago, DrDave- said:

That is unclear with these routines include the read/write as shown above. Is the read/write included in the routine or should it be written similarly as above?

The words "equivalent to" is surely obvious? The setbits functions are simple and fast ways of setting bits in an offset without having to read that offset, "ORing the bits" (a simple logic operation), and writing it back. Not only does it do it in one call, it also prevents the offset value changing for some other reason after you read it and before it is written back (after all, the Lua thread may be only one of more threads also changing things -- like the values being continually received from SimConnect.

Your second sequence, reading the offset, setting bits in the offset, then writing what you read back would end up with no change to the offset.

Pete

 

 

[MakeRwys Jetways incorrect values in G5.CSV]

13 hours ago, bcarson said:

I think this is good to go.

Thanks for verifying! I'll make it a proper release this afternoon. No need to re-download it though.

Pete

 

[MakeRwys Jetways incorrect values in G5.CSV]

15 hours ago, bcarson said:

Must be some other obscure combination of object ids. 

Yes. The Gate identification is more complex that I'd remembered. The clue was that the KSNA gates with Jetways were not actually "1" etc, but "G1" etc. In other words the names weren't matching because another component is involved.

I think it's all fixed now. Please try this version (same version number, so please destroy the previous one).

Pete

MakeRwys.exe

[MakeRwys Jetways incorrect values in G5.CSV]

Hi Bruce,

I had a quick look this morning.

You are correct, and your diagnosis was spot on!

I checked the Jetway data definition in that FSDeveloper wiki document with the definition I was using, and mine was missing the "gate name" field. Evidently that was discovered after I used similar documentation to add the /Jetways facility to MakeRwys. So, it wasn't checking the gate names!

I attach version 5.129 of MakeRwys.exe which appears to be correct. If you confirm I'll make it the current release.

Thank you for your excellent report. Odd that the folks who asked me to add the Jetway facility, so long ago, didn't find the problem.

Pete

[EDITED: attached file removed. See later in thread]

 

[MakeRwys Jetways incorrect values in G5.CSV]

1 hour ago, bcarson said:

It is appearing that Makerwys is getting confused with duplicate spot numbers and identifiers. 

No, they are separate entities in the encoding. And internally names and numbers are linked by a serial reference, not directly related to either. I don't see how anything can be mixed up or confused, but perhaps you can see for yourself. The BGL format is here:

https://www.fsdeveloper.com/wiki/index.php/BGL_File_Format

I'll certainly check for you though.  Are the airports you mention (AYPY and KSNA) default ones  -- is that what you mean by "no overrides"?

2 hours ago, bcarson said:

Couldn't include full runways.txt and G5.csv due to size. 

Even ZIPPed? Anyway, it doesn't matter if they are defaults.

I might not be able to look at this for a day or two.

Pete

 

[PFCHid64.dll not supporting PFC430 hardware]

7 hours ago, zfehr said:

The Reality XP Garmin 430/530 work in FSX and xPlane using the PFC430 hardware. It was an earlier version of probably both the PFChid and FSUIPC that I could get the buttons and knob events to be recognized in FSUIPC. That is no longer the case and FSUIPC doesn't recognize input from the PFC430 hardware in either FSX or MSFS2020.

This is very strange as nothing has been changed for many years -- just the conversion to 64 bit in the case of PFChid64.dll.  The current PFChid was last built in July 2017. How many years are you going back for it to have 'worked'?

Pete

 

[Makerwys]

I moved your question from the Announcements subforum, where you posted it. What made you think that was a place to post support questions?

13 hours ago, mcduffrobert said:

Where does Makerwys get its info from when running the exe file?

From the BGL files which supply the Sim with the scenery of course. You can see it doing this when you run it.

13 hours ago, mcduffrobert said:

If I load up my addon scenery in the community folder,  does Makerwys read the scenery to update my my Makerwys files? 

It doesn't read it automatically. You need to run MSFS at least once after installing scenery, so the new stuff gets registered, THEN you run MakeRwys to update the data files it makes with the new information.

Pete