Using SC-Pascal7 with FSUIPC

[Alpin-Flier]

Hello Peter

I'm a retired electronic engineer, living in Switzerland, since about 50 years a flight enthusiast, but new to this forum. Let me first thank you for all the fantastic work you do for the flight simmer community.

Since about one year I'm building up a B737NG cockpit with material from Opencockpits (pedestal, FMCs, clocks), Hispapanels (MIP,MCP) and Cockpit-for-you (throttle). Everything fits nice mechanically but now I came to the software trying to understand what's going on there. I installed the new PMDG737NGX on Prepar3d_V2.4 working very well on my PC Win7 system.

I went through a lot of descriptions of FSUIPC and made many tests to see if I understand it well. The external systems are IOPC-Server from Opencockpits and sc-pascal7 from Hispapanels. Sc-pascal7 can connect to IOPC-server, but also to FSUIPC directly. Some simple reading of data works nice on both systems. But writing seems to be quite a tricky thing (or impossible?).

My actual task is to control the dimming of six DUs by the lower MIP potentiometers. As first test, I connected one axis (speedbrake) to the brightness control of the captains outer DU, using the axis assignment window of FSUIPC. After some struggles I succeeded. Important to know: when I put in the offset value 69961, it is stored wrong in the fsuipc.ini and I must correct it there (x01001149 to x00011149 resp. 69961). The axis must be put to raw to get values from 0 to 255 being transfered. Then I can control the brightness with the speedbrake lever. The fsuipc console window shows FS controls as soon as the lever is moved:
FS control sent: Ctrl=69961, Param=117

Now to the external connection with sc-pascal7. At connection setup I can define offset parameters, that will be used. Then, on switch or pot or encoder changes sc-pascal will send a write to FSUIPC. This part works fine because I see the writes arriving in the console window of FSUIPC. But it is different from the FS control above:
WRITE0[2028]  11149, 1 bytes: AD

Values are ok, because they are in hex, but nothing happens to the DU dimming. Obviously I don't understand the relation between "WRITE0..." and "FS control sent...".

Thank you very much for any help.

Urs

[Pete Dowson]

[MOVED FROM FAQ subforum to the proper Support Forum]

 

 

Since about one year I'm building up a B737NG cockpit with material from Opencockpits (pedestal, FMCs, clocks), Hispapanels (MIP,MCP) and Cockpit-for-you (throttle). Everything fits nice mechanically but now I came to the software trying to understand what's going on there. I installed the new PMDG737NGX on Prepar3d_V2.4 working very well on my PC Win7 system.

 

The PMDG aircraft are notoriously difficult to interface to a full blown cockpit, as they implement all of the systems internally. The NGX does have an SDK, but it will onvolve a lot of work with programming and so on.

 

I would strongly recommend looking at a proper cockpit software package such as Prosim737 which is much easier for cockpit installations and probably already supports directly some of your hardware.

 

Important to know: when I put in the offset value 69961, it is stored wrong in the fsuipc.ini and I must correct it there (x01001149 to x00011149 resp. 69961).

 

No! 69961 is NOT an "offset". Offsets range from 0 to 65535, but are normally expressed in hexadecimal (x0000 to xFFFF). 69961 is probably an FS control, but even then it is over the end of the range FSX and P3D use internally, so it is probably one of the extension controls used only by PMDG.

 

The encoding x01001149 is the FSUIPC encoding for the "Offset byte set" control, setting the parameter value you provide into offset x1149. The coding x0001149 certainly wrong and does not represent a valid FSUIPC-added control, so its results will be unpredictable. Please try to avoid editing the INI file yourself without first studying the FSUIPC documentation -- in partculr, for control encoding, the Advanced Users manual.  But you should very rarely have to in any case!

 

The fsuipc console window shows FS controls as soon as the lever is moved:
FS control sent: Ctrl=69961, Param=117

 

That's okay, with event logging enabled, but that is not where you saw the Offset byte set control!

 

But it is different from the FS control above:
WRITE0[2028]  11149, 1 bytes: AD

 

That is the erroneous result of your assignment to an FSUIPC offset control with an incorrect value. You should delete whatever you've done there as the results will be unpredictable and could easily crash the simulator.

 

Offsets are relative addresses to a data area inside FSUIPC's memory, which can be read to obtain data and written to change it. Controls are requests to FS (or add-ons) to do something. You are mixing the two up, quite thoroughly I'm afraid.

 

Pete

[Alpin-Flier]

Hi Pete

 

Thank you very much for your detailed answer. I think I have understood how to proceed.

 

Have a nice weekend

 

Urs

[Alpin-Flier]

Hi Pete

Hope, you are still there :-). I need again your help to understand why I cannot read individual offset values from FSUIPC. I use a special pascal version, the sc-pascal from simio electronics.

The following procedures resp. functions work well:
- On any FSUIPC change the offset and the related variable are received
- At program start (connecting with FSUIPC) all variables are received to update the cockpit

But during program I cannot read individual offset values. There is a function
- ReadFSUIPC(offset,bytes)
but it returns always a NULL

I have the impression that PMDG delivers only values at changes. In the meantime no values are available. Is this correct or does scpascal access FSUIPC probably in a wrong way?

Your help is most estimated.

Best regards and all the best for the new year

Urs

[Thomas Richter]

Hi,

easiest way to check what value is readable is by using FSInterrogate, you will find it in the FSUIPC SDK. Just to make sure it is not related to the pascal version you use.

Thomas

[Alpin-Flier]

Hi Thomas

Thank you very much for answering. I'm using the FSInterrogate from beginning, a really valuable tool. And you are right: reading values repeatedly results in correct readings. So the problem must be inside scpascal or at least how I use it. I will try to find the solution there.

Thanks again and all the best for the coming holidays.

Urs