[PFC Cirrus 2 Pro not recognized]

10 hours ago, jimbooo said:

I have PFC Cirrus Pro 2 USB console and radio stacks. All work in XPlane 11 and all switches and axes are functional in the PFC test program.

I have purchased FSUIPC7 and Wide FS and have installed properly.  i see the splash screen when I start and can access FSUIPC via the shortcut (Alt F).

Per the Manual instructions I have downloaded PPFChid64.dll and have placed in the FSUIPC7 folder.

I don't know the Pro 2, so couldn't swear that all of its switches and functions are supported in the PFChid driver. Do PFC supply a driver for XPlane? I know they changed focus to XPlane, away from MS, some time back.

10 hours ago, jimbooo said:

The manual says that I should see that program under the "add-ons" menu in order to activate it.

Which manual is that? The manual supplied with PFChid certainly doesn't. It will be loaded and run by FSUIPC automatically after the Sim is in a "ready to fly" state.

10 hours ago, jimbooo said:

I DO NOT see it and therefore I cant get anything to work.  I see my PFC equipment show up in the Microsoft window but nothing works (of course)

A couple yoke buttons do show but no axes show up.

On the Cirrus I seem to remember that the Yoke is a normal joystick device and seen by Windows and the Sim, not needing any attention from a driver. The rest of the functions on the Cirrus do need a registered FSUIPC and then you can assign switches and quadrant levers as desired.

A log is produced (PFChid64.LOG) when the driver starts. This will be is the same folder -- check for it.

Pete

 

[SIOC Axis to FSUIPC Axis ?]

18 minutes ago, John Dowson said:

Not sure what you are referring to here - I see no thread the OP referenced...

Not a direct thread link, just The reference to an ActiveSky workaround in the Prosim forum.

 

 

[SIOC Axis to FSUIPC Axis ?]

3 minutes ago, John Dowson said:

MSFS added radar/map capabilities in a recent update (SU9 or SU10 I think). These facilities are only available to WASM modules via the MapView API - see https://docs.flightsimulator.com/flighting/html/Programming_Tools/WASM/MapView_API/MapView_API.htm.

Therefore it is quite possible for aircraft (and other WASM modules) to use this API to generate various map types. At some point, when time permits, I will look into this to see if I can make something available via the FSUIPC WASM module to support map file generation - and independently of Active Sky.

John

Hi John,

That’s good news, but I wasn’t aware ActiveSky had such specific support for MSFS. Last I knew, Damian declined to do anything whilst MSFS had such a closed weather control interface.

I shall need to refer to the thread the OP referenced, to see what the ‘workaround’ is.

 

[SIOC Axis to FSUIPC Axis ?]

17 minutes ago, mroschk said:

For 2. Did not work here.
Whatever control i set up in FSUIPC is overwritten by Prosim when i use Prosim in Simconnect Mode, which is the Mode to use by Prosim devs

The point is you assign an offset in Prosim, not a control axis. It’s one of the options for every control axis.

If your controls are true axes then you can assign them in FSUIPC to a user offset, and use that in Prosim.

Pete

[SIOC Axis to FSUIPC Axis ?]

1 comes as a big surprise, as the cloud map from  P3D used for the radar is part of the complete weather system supported by P3D but not, as far as I know, by MSFS.  In P3D, Activesky needs a module running in the P3D process to obtain this data. I did not know that HiFi simulations had now produced a version specifically for MSFS.  Seems I should send congratulations to Damian if so.

Otherwise the map will be of the cloud positions intended by ActiveSky but not actually achievable with MSFS. They may show approximations but not in any sense accurate enough for navigation. In P3D the radar actually shows when you are in one of the rain clouds or can see one ahead.

On 2, I am saying you can use Prosim In SimConnect mode via FSUIPC offsets for controls.

I’ve got no more to say on this really, so I shall butt out now.

Pete

 

 

[SIOC Axis to FSUIPC Axis ?]

26 minutes ago, mroschk said:

Hi Pete,

you are only partially right.

1. If you use Prosim in Simconnect mode, you will get a relativ accurate Radar Display i Prosim ND.

2. Not correct. When you use Prosim in Simconnect Mode, then you have no chance to set up any Control ( Rudder/Tiller/Aileron/Elevator ) in FSUIPC, because Prosim overrides any input from FSUIPC.

Matthias

I don’t know how 1 can be right, unless MSFS now provides the data. It didn’t when I last looked.

 For 2, I have used Simconnect mode with almost all  my controls coming from PFC devices through FSUIPC. You only need to make the assignments in Prosim, specifying the offsets correctly. Prosim only overrides assignments made to the sim controls themselves.

Pete

 

[SIOC Axis to FSUIPC Axis ?]

4 minutes ago, mroschk said:

ok, Active sky is not controlling the weather, it only makes it possible to see the wx radar in prosim when prosim run in simconnect mode

But, as I said:

1) I don't think the weather radar so produced is of any real use in relation to the simulation in MSFS.

2) You can use SimConnect mode for inputs whether from FSUIPC or elsewhere. The SimConnect/FSUIPC mode selection in Prosim is to do with how Prosim controls the Sim, not the inputs .

Pete

 

[SIOC Axis to FSUIPC Axis ?]

2 minutes ago, mroschk said:

But i want to use FSUIPC Mode because of the Rudder/Tiller issue in Prosim. So its a big Problem as you see, i can have a Weather Radar OR Rudder/Tiller working.
But for my Homecockpit i have no other chance then using Prosim. But the developer of the Flightmodel which Prosim uses is not really up to date with the MSFS Changes.

I use Prosim too, in FSUIPC mode, but I think the FSUIPC/SimConnect choice is only concerned with how it controls FS/MSFS, nothing to do with inputs. I only use FSUIPC mode because of some problems I have otherwise with trims.

As I said, I can't see how any radar image from ActiveSky is going to be of use in MSFS because it really has no control over the cloud placement.

BTW I saw that the latest Prosim update (3.23B2) lists separate Tiller/ Rudder in its change list.

Pete

 

[SIOC Axis to FSUIPC Axis ?]

10 minutes ago, John Dowson said:

No, not at the moment. I didn't know Active Sky was available for MSFS....!
I will take a look at some point and see if it is possible to re-enable this functionality in FSUIPC7, although I am not sure when I will have time for this at the moment so it may take a while.

John

Although ActiveSky will run for MSFS, I don't think it is able to control the weather, and it certainly isn't able to create a usable rain cloud map!

Pete

 

[SIOC Axis to FSUIPC Axis ?]

57 minutes ago, mroschk said:

Also AXIS_STEERING_SET and AXIS_RUDDER_SET i have tried.
But always when i assign any Rudder Axis, the Tiller( Nose Wheel ) is controlled by the same deflection as the Rudder.
Isnt there any Option to separate these both Axis ?

Sorry, I don't know. That's really a question for MSFS support, or possibly specifically for the authors of the flight model you are using.

I'm a P3D user, but I don't know how the nose wheel turns in that, either, because when the aircraft is moving I'm always in the cockpit.

Pete

 

[SIOC Axis to FSUIPC Axis ?]

1 hour ago, mroschk said:

When i change the Offset for the PFC Tiller, only the Nose Wheel is controlled in MSFS...thats fine.
But then i connect my Rudder Pedals to the PFC Offset for the Rudder and when i change this, also the Nose Wheel is controlled in MSFS,
thats not what should happen and not what i am looking for.

I really did not know what is going wrong here?

You can use any of the offsets in the PFC list for any axis, and just assign it however you like in FSUIPC. The annotated usage in the list is just how PFC COM devices are added.

With the regular axis controls, assigned in FSUIPC, it is up to MSFS and the flight model what happens.  The regular controls are AXIS_STEERING_SET and AXIS_RUDDER_SET. Have you used those?

Pete

 

 

[SIOC Axis to FSUIPC Axis ?]

17 hours ago, mroschk said:

But anyway, i found vJoy and i am on the Way to try it out...seams to work !!

I've only just noticed this, and I can add something.

If SIOC scripts can write to FSUIPC offsets (which I think they can), then an alternative, without vJoy, is by writing to one of the offsets originally designed for PFC COM devices: 3BA8 to 3BC4. 

See the FSUIPC Offsets Status document for details.

Pete

 

[Issue MakeRwys]

7 hours ago, bradimarte said:

until SU11 all was OK, but now I have found that when execute MakeRwys, in the Runways.xml file it is not saved City, Country and ICAOName fields (as image attached here)

Sounds like MS has messed up the language files providing this data.

Sorry, but I'm not able to maintain MakeRwys these days. I've offered the source to anyone (needs to know C/C++) who wishes to take it on, but I have fully retired from programming.

Pete

 

[WideFS and FSUIPC4]

I managed to look at it this morning.

First, some questions about the files you posted:

Neither WideClient..LOG actually shows a crash -- they both show a normal shutdown requested by the server (the Sim).  They also show you were using UDP, not TCP. So, does this mean you changed to UDP and then got no further crashes?

The Windows error event shows that crash occurred on the 5th, but both LOGs are for the 4th. So, did you change back to TCP on the 5th?

Both logs show block sequencing errors occurring. That is a typical symptom of a bad connection. Running on UDP means blocks can go missing as there is no checking -- the error logged by WideClient is through its own checks built into its data formats.

Confirming that the problem appears to be purely down to a bad connection, the Windows event crash location is within either the select_open or tcp_open function in the Windows network package. It is not in WideClient code which I have any control over.

MY TESTS

I set up an FSX-SE session on my laptop (a Microsoft Surface running an up-to-date Win10). WideClient was running on my main development PC. If I could induce your crash this would enable me to use the Debugging facilities in Visual Studio. This PC is also running an up-to-date Win10.

I was running with TCP protocol, and let it run for an hour whilst manipulating controls in FSX-SE which would result in highlighted entries showing in your WND-based window. It is still running now, and shows no sign of any errors -- and the log is clear of block sequence errors (as I would expect when using TCP, or when using UDP with a good reliable connection.

So, I'm sorry, but I can't see there's anything I can do. You might need to try to improve your Wifi setup.

Pete

 

[WideFS and FSUIPC4]

8 minutes ago, gr8guitar said:

Okay thanks. This is what it came up with - if I did it correctly:

Thanks. That's much more informative!

Pete

 

[WideFS and FSUIPC4]

37 minutes ago, gr8guitar said:

Hello. Thank you for your reply. I agree, there shouldn't be a difference between Ethernet and WiFi and yet there is. To be honest, for me to resolve the problem, I bought some USB to Ethernet adapters. It seemed the most expedient because it works fine that way. I was hoping for an easier/quick solution when I requested help :). I realize the manuals have the details - but seriously, there are so many things to learn about FSUIPC. I know, through the years, I've read all of it but nothing sticks until either I need to apply a feature or I have an issue. FSUIPC is truly a great add-on. I'm including the files. I hope they give insight. Thank you.

Annunciator.log 2.71 kB · 0 downloads WideServer.log 2.12 kB · 0 downloads WideClient.ini 5.09 kB · 0 downloads WideClient.log 266.14 kB · 0 downloads Annunciator.lua 7.68 kB · 0 downloads

Thank you. I notice there's no Windows crash log -- does that mean one was not produced?

It won't be till Monday that I can get to this again.

Pete

 

[WideFS and FSUIPC4]

16 hours ago, gr8guitar said:

Okay. I changed the WideClient.ini to UDP and using ServerIPAddr. I did not see how to change the WideServer.ini on the host so I'm not sure how the host knows to run the UDP.

See this paragraph in the first section of the WideFS documentation entitled Configure your Network:

The Server automatically operates with any clients which connect, whether they be using TCP, UDP or SPX. You can mix them,
to suit the specific individual client PCs. Better, leave the protocol choice out of the Client INI file altogether and just use
“ProtocolPreferred= …” in the Server INI to select your choice. Details of these parameters are given below.

16 hours ago, gr8guitar said:

I may try IPX .I have an IPX wrapper that I obtained years ago that I use for WideView 2000. It was free then but it also worked with FS2004/9. I don't know if it'll work at all with FSX but I will try that too.

Hmm. I'm not at all sure that IPX/SPX is supported anymore. When it was removed from Windows the code became somewhat redundant and an unnecessary complication.

On this:

Quote

 

And then I came across Glenn Weston's usage of WND. Thank you Glenn for the idea. I then decided to look into that. Now it works great (after learning how to set and clear bits in XML) if the client is using an Ethernet connection - everything works. My "buttons" and MyDisplay.lua work fine whether Ethernet or WiFi. However, Annunciator.lua (my version of Glenn's WND example) does not work on a WiFi client. I've serached the Internet and did not find a solution. I did modify the firewall, even disabled it, but no effect. Again, this is happening on a lua that has WND in its logic. WideClient simply quits. I get this messsage at the end of the log:

5860 Stack EBP 012C1343->C5043D89, which is  (BAD) (Base=00000000).

If I don't use the WND in a lua and and a WiFi connection, no problems. Or if I use an Ethernet connection, no problems with using WND. Can anyone tell me why WND and WiFi are in conflict?

 

I would make these comments:

*  There's no relation between any function in the WND library and the Network connection, so the crash must be related to something else in your Lua script.

*  There's no way WideFS even knows whether you are using Wifi or a wired connection. There may be a way to determine this, but as there's no need to know I've never investigated it. The code is just Network code.

So, I need more information to investigate this:

1. The Lua file which generates the problem

2. The full WideServer and WideClient LOGs at the time of the crash.

3. If one exists, the WideClient crash details from the Windows Event Viewer.

I can test here with a Wifi connection, but I need the exact Lua code which leads to the error. I also need you to be using the latest (current) version of WideClient (7.160) so the addresses etc match.

Thanks
Pete

 

[MakeRunways new nav data api SU10 msfs]

Sorry, I have no plans to further update MakeRunways. I am now fully retired.

I can share the code, convoluted as it has become, with any C / C++ programmer wishing to take it on, with the only condition that is shall remain freeware.

Pete

 

[FSUIPC Controller Axis Resolution]

The Delta value, in the Axis assignment options, determines the minimum change which will be used. It defaults to 256 which, for a Windows calibrated axis (-16k to +16k) gives 128 steps. You can reduce the Delta value if you wish (read the description of this value in the User Guide first).

The PFC throttle quadrant I have (a very early COM-based one, not recognised by Windows) used axes with 0nly a range of 0-127 at best. They work fine for me. But perhaps PFC have improved the pots they use by now. The same low res pots were used in their flight controls (rudder, aileron, elevator, tiller) but I had those replaced by higher resolution ones and connected them via Bodnar USB boards.

Pete

 

[MkRwy have an issue with the latest (Canada) WU (illegal char in XML)]

On 10/11/2022 at 7:58 PM, pellelil said:

It appears MkRwy have an issue with the latest (Canada) WU. The XML (runways.xml) it generates for CAN9 contains an illegal char in the ICAOName field

Hi Pelle,

My MSFS is woefully out of date, from disuse for a long time. So could you please show me the relevant part of RUNWAYS.TXT and ZIP and attach the runways.xml.

Thanks,
Pete

 

[msfs2020 make runways question]

24 minutes ago, trisho0 said:

I ran Make Runways File: Version 5.13 intended for MSFS2020. The Make Runways at the end it generated several files as SceneList.txt and several csv files.

Where those files should be placed?

Patricio Valdes

They are files to be read by whatever program it is that you used MakeRunways for.  Normally you leave the files where they are and point that program to that location.

If you aren't using a program which asked for MakeRunways, then why did you run it?

Pete

 

[FSUIPC4 Freezing FSX-SE]

Without registration, FSUIPC is merely receiving stuff from SimConnect and writing stuff back at the request of application programs using it.

Therefore the problem must either be a corrupted FSX, affecting the SimConnect interface, or, possibly more likely, a misbehaving application.

You can check for the latter by trying with no FSUIPC applications running at all. for the former, do a re-install of FSX.

BTW If FSX is crashing, why are you not showing us the Windows crash report (from the Event Viewer)?

Pete

 

[MakeRwys not translating taxiways for a custom airport (EFHK)]

1 hour ago, Nadelbaum said:

Ok, here's the link to the Runways.txt part that contains the custom EFHK:

https://drive.google.com/file/d/1_DylzBRqIpdfdpPQNoNkjXtYeDrXs9A0/view?usp=sharing

I can see that most of the taxipaths are without a name (Taxiname #0), but I don't understand why, because I see the names in MSFS Dev mode and again, like said before, AIG AI Traffic follows the paths perfectly.

Well, yes. But all of the default taxiways are deleted explicitly.

I don't know why MakeRwys only gets one path with a name -- there are evidently more names than the one it sees. It maybe that the other named parts don't actually join up.

I downloaded the add-on and tried analysing it using the well-respected Aircport Design Editor (ADE) but it didn't even find any airport records, giving a failure I don't understand.

I'll try to trace through MakeRwys to see why no other named taxiways are found, but I'm not sure when I can do it or even if I'll be able to -- I retired because my coding and debugging abilities were deteriorating fast as I aged (I'm 79).

I suggest the best course for you is to run MakeRwys whilst the add-on is disabled (as I suggested) and use the results it produces before re-enabling the add-on.

Pete

 

[MakeRwys not translating taxiways for a custom airport (EFHK)]

19 hours ago, Nadelbaum said:

Any ideas of what could be going wrong?

The "EFHK only" section of the Runways.txt file you provided is for the default EFHK scenery, not the add-on:

          Official\Steam\fs-base-genericairports\scenery\0601\APX54100.bgl

Search down further in the file for the add-on EFHK.  It'll be near the end, with any other add-on sceneries. I suspect that the add-on is deleting most of the default and not replacing it. The file will show.

Try disabling the add-on EFHK and see if MakeRwys then generates the file correctly for you. I think it will.

Pete

 

[WIDEFS7 sees HOTAS 52 Buttons but not Axes]

23 hours ago, NobbyH said:

Unfortunately, my 737 cockpit was never sophisticated enough to justify taking up a Prosim737 subscription, version 2.1 covered all the function I needed and I am too old to justify spending more.

That's fine -- with Version 2 it was also recommended, but not mandatory, to assign and calibrate all the main aircraft control axes in Prosim itself. Those facilities are actually mostly unchanged in V3.

23 hours ago, NobbyH said:

Are  you suggesting that the direct Prosim v2 option would be better? 

Yes, I think so. But by all means ask on the Prosim forum.

Pete