Win7 64 bit no data seeming to get to stand alone EICAS gaug

[JBaymore]

Hi all. I've been trying to debug this issue to no avail. Pulling my hair out (what is left of it :wink: ).

I have a brand new i7-960 3.2 gig quad core machine running Win7 64 bit Professional. Not clocked. 6 Gigs of DDR3 RAM. Running fs2004 version 9.1.

In the past I have had my simpit setup on a home 100 Mbit/sec. hard wired and switched network....and it was working fine when the main sim machine was an XP Pro 32 machine. I did not change anything on all of the other simpit machines. Just changed the main flight sim (fs2004) machine. The switch is fine. The cables are fine.

After the new i7 machine and Win7 install, I reloaded fs2004, updated one version level of FSUIPC and WideFS. (Went from the just prior one to the most recent.) Installed the new FSUIPC dll in the modules folder and also the new WideServer dll. Put the new WideClient on the remote machines.

Have test flown fs2004 a LOT already at the desktop level, and all appears to be just fine. Now I need to get the simpit working again. This is where trhe trouble is starting.

I am running fixed IPs on all of the network machines that run the stand alone gauges for the simpit. I have added the Wideserver IP address and TCP into the WideClinet config file. As just one example, from the Win7 (sim) machine I can see the XP machine that holds the external cockpit gauge just fine. I have created a rule in the Win7 firewall that allows all duplex traffic from the local fixed IP for that machine. The XP machine allows the fixed IP of the Win7 machine in. All of the shared folders on the XP machine are visible. I have shared the folders for FS9 on the main Win 7 sim machine, and also the folder for WideClient on the XP machine ruinning the EICAS.

I am currently experiencing a totally WEIRD problem with my stand alone gauges that have worked just perfectly (stellar as a matter of fact!) up until now. I'm totally baffled! I've spent hours and HOURS trying to get this solved already.

WideClient on the XP machine reports that it is connected. On the Win7 sim machine I see the "connected" message on the top fs2004 menu bar. If I close WideClient, I see it disconnect on the fs2004 menu bar, and if I re-start it... I see it say "connected" again. But the display on the stand alone EICAS guage that I am running on an XP machine remains totally blank......... as if there is NO data streaming into it. It is just a big black and blank face. I THINK this is the display it would have when there is a total failure of the aircraft's MFDs in the sim....... but I am not sure of that fact....never having experienced that from the sim in the past. (And yes, in the aircraft I am using in the sim, the simulated panel displays are working. :wink: )

HOWEVER, when I leave the EICAS gauge running and then shut down WideClient on that XP machine, the EICAS gauge shifts its display to the "INOP" message that it gives when it is not getting any connection data. So it appears that there is a distinct difference between when WideClient is "connected" to the EICAS gauge.... and when it is not. SOMETHING seems to be getting thru that keeps the INOP message from popping up.

This same exact thing happens to the same supplier's PFD gauge running on a different Win98 machine.

Here's the REAL kicker in all this..........

Running on the same machine right next to the EICAS or the PFD gauges..... I can run another gauge (like say Danny Ho's TACAS unit or SaWXR) and those gauges have data reaching them just fine from WideServer/WideClient! THey show what they are supposed to show. So they are displaying stuff and the gauges right next to them are not. They have always worked together nicely in the past.

What the HECK is going on here?

Here's my WideClient Log File from a test session from on one XP machine:

********* WideClient Log [version 6.78] Class=FS98MAIN *********

Date (dmy): 23/05/10, Time 21:15:47.796: Client name is BETHLAPTOP

1391 Attempting to connect now

1391 Trying TCP/IP addr 192.168.0.5, port 8002 ...

22469 Error on client pre-Connection Select() [Error=10060] Connection timed out

22469 Ready to try connection again

23516 Attempting to connect now

54625 Connection made okay!

76109 New Client Application: "eicas" (Id=1012)

135375 Received shutdown offset code = ADBC

135375 FS closing down (param=ADBC), disconnecting

135375 ********* Interim performance summary *********

135375 Total time connected so far = 79 seconds

135375 Reception maximum so far: 24 frames/sec, 2419 bytes/sec

135375 Reception average whilst connected so far: 16 frames/sec, 1492 bytes/sec

135375 Transmission maximum so far: 1 frames/sec, 689 bytes/sec

135375 Transmission average whilst connected so far: 0 frames/sec, 39 bytes/sec

135375 Max receive buffer = 634, Max send depth = 2, Send frames lost = 0

135375 **************** Individual client application activity ****************

135375 Client 1012 requests: 3304 (Ave 41/sec), Data: 5886000 bytes (74506/sec), Average 1781 bytes/Process

135375 ***********************************************

135453 Received shutdown offset code = ADBC

141953 Connection closed by server!

141953 Attempting to connect now

141953 Trying TCP/IP addr 192.168.0.5, port 8002 ...

154797 ****** End of session performance summary ******

154797 Total time connected = 79 seconds

154797 Reception maximum: 24 frames/sec, 2419 bytes/sec

154797 Reception average whilst connected: 16 frames/sec, 1492 bytes/sec

154797 Transmission maximum: 1 frames/sec, 689 bytes/sec

154797 Transmission average whilst connected: 0 frames/sec, 39 bytes/sec

154797 Max receive buffer = 634, Max send depth = 2, Send frames lost = 0

154797 **************** Individual client application activity ****************

154797 Client 1012 requests: 3471 (Ave 43/sec), Data: 6183594 bytes (78273/sec), Average 1781 bytes/Process

154797 ********* Log file closed (Buffers: MaxUsed 3, Alloc 4783 Freed 4783 Refused 0) *********

Can someone a bit more skilled than I please decipher this stuff above and maybe point me in the direction of a potential solution? I am hoping this is something simple and obvious to someone who actually knows what they are doing.... which obviously I am NOT!

THANKS in advance.

best,

...................john

[Pete Dowson]

What the HECK is going on here?

I've no idea I'm afraid. Your WideFS setup is working fine and you've actually proven to yourself in any case. Seems those gauges need something else, or something switching on, which you've perhaps omitted or forgotten?

Can someone a bit more skilled than I please decipher this stuff above and maybe point me in the direction of a potential solution?

There's nothing there to decipher, everything is running fine.

Do the folks who supplied the gauges have any support at all? What make are they? Some of the third party ones I know of don't use WideFS, but have their own network service.

Regards

Pete

[JBaymore]

Pete,

Thanks for the REALLY fast response (as always). Your support is, and has always been, "the best in the biz."

I've no idea I'm afraid. Your WideFS setup is working fine and you've actually proven to yourself in any case. Seems those gauges need something else, or something switching on, which you've perhaps omitted or forgotten?

There's nothing there to decipher, everything is running fine.

I was hoping that my somewhat cursory understanding of all this tech kinda' stuff was leading me to miss some important but subtle key line in the log file that was going to tell me where I was screwing up with all this. In reading it I couldn't seem to find anything. But I was thinking it was just the fact that it was ME reading it :wink: .

THANKS! Good to know that I have the local network stuff set up correctly. This is one of those "good news / bad news" situations. This certainly tends to point to the gauges themselves. They've worked fine for YEARS. This is really "out of the blue".

Do the folks who supplied the gauges have any support at all? What make are they? Some of the third party ones I know of don't use WideFS, but have their own network service.

I have notified them of the situation and they have responded and will look at the situation shortly. I will send them a copy of your response here also as a FYI to help them out. The gauges DO for sure use FSUIPC/WideServer/WideClient for the data stream.

Can you think of ANY relatively recent change in the latest couple versions of any of your software that might in any way affect the nature of the data stream that external gauges are seeing coming thru the "pipeline"? That might offer the gauge developers a clue. I'm guessing not........ but it does not hurt to ask.

Or... can you see any factor that having the fs2004 sim running on a 64 bit OS but the external gauges running on 32 bit OSs might affect the data stream they are seeing in some unexpected way? Again, I am assuming that the data coming out of the sim via WideServer is the same no matter what the OS it is on.......but I'm grasping at straws here looking for some clues to fix this. My "aircraft" is stuck at the gate!

I'd prefer to not name the company right at this point....... give them a chance to solve this if it is "thiers" :) .

Thanks again Pete, for the totally amazing support for your products.

best,

....................john

[Pete Dowson]

Can you think of ANY relatively recent change in the latest couple versions of any of your software that might in any way affect the nature of the data stream that external gauges are seeing coming thru the "pipeline"? That might offer the gauge developers a clue. I'm guessing not........ but it does not hurt to ask.

No, nothing. If you had not said this:

Running on the same machine right next to the EICAS or the PFD gauges..... I can run another gauge (like say Danny Ho's TACAS unit or SaWXR) and those gauges have data reaching them just fine from WideServer/WideClient! THey show what they are supposed to show

I might have suggested checking the FSUIPC Log file (a complete one, after FSA is closed), because that might tell me that the system date on the Server was incorrect. A system date set earlier than your FSUIPC or WideFS registration would seem to FSUIPC like an invalid key and it would supply bad data.

Or... can you see any factor that having the fs2004 sim running on a 64 bit OS but the external gauges running on 32 bit OSs might affect the data stream they are seeing in some unexpected way?

No. All these programs are 32-bit in any case. The underlying operating system isn't really relevant.

Sorry, I don't have any more ideas. If it might help the suppliers of the gauges you can log the data being sent and received by WideClient applications by setting "Log=Yes" in the client INI file.

Regards

Pete

[JBaymore]

Pete,

Again... an amazing fast response.

Here is a FSUIPC log file from my testing..... not from the same exact session as the WideClient file above... but from later attempts. (I have scrubbed out my email address for obvious reasons :wink: .)

----------------------------------------------------------

********* FSUIPC, Version 3.98a by Pete Dowson *********

Running on Windows Version 5.1 Build 2600 Service Pack 2

Verifying Certificate for "E:\Flight Simulator 9\MODULES\FSUIPC.DLL" now ...

SUCCESS! Signature verifies okay!

Running inside FS2004 (FS9.1 CONTROLS.DLL, FS9.1 WEATHER.DLL)

User Name="John Baymore"

User Addr="XXXXXXXXXXXXXXXXXXXXXX"

FSUIPC Key is provided

WideFS Key is provided

Module base=61000000

ClassOptions: UIPCMAIN=FF7F, FS98MAIN=FF7F, FS2KMAIN=FF5E

WeatherOptions(Orig)=6040B789[6040B789]

InitDelay: 0 seconds

WeatherReadInterval=4

LogOptions=00000001

DebugStatus=255

3588 System time = 23/05/2010 22:01:47

3588 \\NEWMAINOFFICE7\Flight Simulator 9\

3603 System time = 23/05/2010 22:01:47, FS2004 time = 12:00:00 (00:00Z)

9032 \\NEWMAINOFFICE7\Users\John\Documents\Flight Simulator Files\United 146-200 at Logan.flt

11060 AIRCRAFT\BAe 146-200 Eurowings Pro\BAE146-200_2k4v2.9.air

11185 Aircraft="United BAe 146-200"

68110 AIRCRAFT\b737_400\Boeing737-400.air

68126 Aircraft="Boeing 737-400"

72088 \\NEWMAINOFFICE7\Users\John\Documents\Flight Simulator Files\UI generated flight.flt

72696 Clear All Weather requested: external weather discarded

72962 Advanced Weather Interface Enabled

85676 Traffic File #19 = "scenery\world\scenery\traffic030528"

85754 Traffic File #31 = "scenery\world\scenery\traffic_000_woa_american airlines_su08"

85925 GoFlight GF45 detected: 1 device

85925 GoFlight GF166 detected: 4 devices

85925 GoFlight GFMCP detected: 1 device

86580 Traffic File #41 = "scenery\world\scenery\traffic_000_woa_cessna 421c ga_wi08"

86580 Traffic File #82 = "scenery\world\scenery\traffic_000_woa_northwest airlines_su08"

86627 Traffic File #139 = "scenery\world\scenery\traffic_254_woa_ultimate ga cessna 402_su06"

86658 Traffic File #101 = "scenery\world\scenery\traffic_000_woa_ultimate ga citation 550_su06"

86783 Traffic File #143 = "scenery\world\scenery\traffic_60_woa_fedex_su05"

86783 Traffic File #129 = "scenery\world\scenery\traffic_177_woa_ultimate ga gulfstream 4_su07"

86830 Traffic File #37 = "scenery\world\scenery\traffic_000_woa_british airways_su09"

86908 Traffic File #95 = "scenery\world\scenery\traffic_000_woa_swiss_su08"

86955 Traffic File #134 = "scenery\world\scenery\traffic_213_woa_ultimate ga learjet 45_su06"

86955 Traffic File #111 = "scenery\world\scenery\traffic_000_woa_wiggins airways_su09"

87033 Traffic File #36 = "scenery\world\scenery\traffic_000_woa_british aerospace hawker xp800 ga package_su09"

87080 Traffic File #77 = "scenery\world\scenery\traffic_000_woa_lufthansa_su09"

87126 Traffic File #81 = "scenery\world\scenery\traffic_000_woa_north american airlines_wi08"

87158 Traffic File #131 = "scenery\world\scenery\traffic_191_woa_united airlines_su07"

87158 Traffic File #136 = "scenery\world\scenery\traffic_227_woa_us airways_wi07"

535161 \\NEWMAINOFFICE7\Users\John\Documents\Flight Simulator Files\UI generated flight.flt

535817 Clear All Weather requested: external weather discarded

548437 System time = 23/05/2010 22:10:52, FS2004 time = 22:01:56 (02:01Z)

548437 *** FSUIPC log file being closed

Memory managed: 2 Allocs, 6533 Freed

********* FSUIPC Log file closed ***********

To me that looks "normal" ........ but then again... what do I know.

Once again... thanks. Will work with the gauge developers to see what is going on. Thanks for the "log" tip... will do that.

best,

...................john

[Pete Dowson]

Here is a FSUIPC log file from my testing

...

To me that looks "normal" .

Yes, it is fine.

Sorry, I've no further ideas.

Once again... thanks. Will work with the gauge developers to see what is going on. Thanks for the "log" tip... will do that.

Okaygood luck!

Regards

Pete

[JBaymore]

Thanks Pete. I'll keep you posted on the developments.

best,

..............john

[JBaymore]

Pete,

Just in case you see something that jumps right out at you as seeming totally "abnormal" .... here is a sample part of the WidelClient.log file:

---------------------------------------------------------

********* WideClient Log [version 6.78] Class=FS98MAIN *********

Date (dmy): 24/05/10, Time 12:59:46.765: Client name is BETHLAPTOP

969 Timing Thread Started

1000 SendReq Thread Started

1000 Trying TCP/IP addr 192.168.0.5, port 8002 ...

67422 Sending computer name and requesting base data ...

67422 Button Thread Started

87547 New Client Application: "BoeingEADI" (Id=1796)

87547 Write: Offset=330A, Size=0002

EC 03

87547 0 ReadLocal: Offset=3304, Size=0004

01 00 80 39

87547 0 ReadLocal: Offset=3308, Size=0004

07 00 DE FA

87672 78 ReadOk: Offset=0B74, Size=0004

D2 E2 3F 00

87672 78 ReadOk: Offset=0B78, Size=0004

94 02 00 00

87672 78 ReadOk: Offset=0B7C, Size=0004

14 F1 3F 00

87672 78 ReadOk: Offset=0B80, Size=0004

C3 04 00 00

87672 78 ReadOk: Offset=0B84, Size=0004

00 00 00 00

EDITED OUT TONS OF STUFF HERE .........

146047 0 ReadLocal: Offset=0B94, Size=0004

D2 D9 3F 00

146047 0 ReadLocal: Offset=0B98, Size=0004

C3 04 00 00

146047 0 ReadLocal: Offset=0B9C, Size=0004

00 00 00 00

146047 0 ReadLocal: Offset=0BA0, Size=0004

00 00 00 00

146047 0 ReadLocal: Offset=0AF4, Size=0002

B3 06

146047 0 ReadLocal: Offset=0E8C, Size=0002

0B 0F

146047 0 ReadLocal: Offset=02C4, Size=0004

00 96 00 00

146047 0 ReadLocal: Offset=3000, Size=0006

49 42 4F 53 00 00

146047 0 ReadLocal: Offset=0330, Size=0002

53 3F

146047 0 ReadLocal: Offset=0366, Size=0001

01

146047 0 ReadLocal: Offset=2EE0, Size=0004

00 00 00 00

146047 0 ReadLocal: Offset=07BC, Size=0004

00 00 00 00

146047 0 ReadLocal: Offset=07C4, Size=0004

00 00 00 00

146047 0 ReadLocal: Offset=07C8, Size=0004

00 00 00 00

146047 0 ReadLocal: Offset=07D0, Size=0004

00 00 00 00

146047 0 ReadLocal: Offset=07DC, Size=0004

00 00 00 00

146047 0 ReadLocal: Offset=07E4, Size=0004

00 00 00 00

146047 0 ReadLocal: Offset=07FC, Size=0004

00 00 00 00

146047 0 ReadLocal: Offset=0800, Size=0004

00 00 00 00

146047 0 ReadLocal: Offset=0810, Size=0004

00 00 00 00

146047 0 ReadLocal: Offset=0BAC, Size=0002

00 00

146047 0 ReadLocal: Offset=0BAE, Size=0002

00 00

146047 0 ReadLocal: Offset=0BB0, Size=0002

00 00

146047 0 ReadLocal: Offset=0BDC, Size=0004

00 00 00 00

146047 0 ReadLocal: Offset=0C29, Size=0005

30 31 2E 36 20

146047 0 ReadLocal: Offset=0C48, Size=0001

7F

146047 0 ReadLocal: Offset=0C49, Size=0001

00

146047 0 ReadLocal: Offset=036E, Size=0001

00

146047 0 ReadLocal: Offset=07CC, Size=0004

C7 F1 00 00

146047 0 ReadLocal: Offset=07E2, Size=0002

00 00

146047 0 ReadLocal: Offset=07E8, Size=0004

00 00 00 00

146047 0 ReadLocal: Offset=07F2, Size=0002

00 00

146047 0 ReadLocal: Offset=02C8, Size=0004

00 00 00 00

146047 0 ReadLocal: Offset=2ED0, Size=0008

00 00 00 00 00 00 00 80

146047 0 ReadLocal: Offset=0C18, Size=0001

00

146047 0 ReadLocal: Offset=2EE8, Size=0008

00 00 00 00 00 00 00 00

EDITED OUT TONS OF STUFF HERE...........

212328 0 ReadLocal: Offset=057C, Size=0004

00 00 00 00

212328 0 ReadLocal: Offset=0870, Size=0002

04 8E

212328 0 ReadLocal: Offset=0B4C, Size=0002

00 00

212328 0 ReadLocal: Offset=07D4, Size=0004

00 00 00 00

212328 0 ReadLocal: Offset=11BE, Size=0002

FF 7F

212328 0 ReadLocal: Offset=281C, Size=0004

00 00 00 00

212328 0 ReadLocal: Offset=3428, Size=0008

00 00 00 00 00 00 59 40

212328 0 ReadLocal: Offset=8700, Size=0001

00

212328 0 ReadLocal: Offset=8701, Size=0001

00

212328 0 ReadLocal: Offset=8702, Size=0001

00

212328 0 ReadLocal: Offset=8703, Size=0002

00 00

212328 0 ReadLocal: Offset=8705, Size=0001

00

212328 0 ReadLocal: Offset=8706, Size=0002

00 00

212328 0 ReadLocal: Offset=080C, Size=0004

00 00 00 00

225688 Timing Thread Terminated

225688 Button Thread Terminated

225688 SendReq Thread Terminated

225688 ****** End of session performance summary ******

225688 Total time connected = 157 seconds

225688 Reception maximum: 5 frames/sec, 270 bytes/sec

225688 Reception average whilst connected: 3 frames/sec, 140 bytes/sec

225688 Transmission maximum: 1 frames/sec, 592 bytes/sec

225688 Transmission average whilst connected: 0 frames/sec, 26 bytes/sec

225688 Max receive buffer = 445, Max send depth = 2, Send frames lost = 0

225688 **************** Individual client application activity ****************

225688 Client 1796 requests: 6958 (Ave 44/sec), Data: 10136403 bytes (64563/sec), Average 1456 bytes/Process

225688 ********* Log file closed (Buffers: MaxUsed 3, Alloc 7592 Freed 7592 Refused 0) *********

-----------------------------------------------------------------------------------------------

Maybe that is usefulmaybe that is not.

best,

.......................john

[Pete Dowson]

Just in case you see something that jumps right out at you as seeming totally "abnormal" .... here is a sample part of the WidelClient.log file:

Nope. Looks okay, but this part here:

212328 0 ReadLocal: Offset=8700, Size=0001

00

212328 0 ReadLocal: Offset=8701, Size=0001

00

212328 0 ReadLocal: Offset=8702, Size=0001

00

212328 0 ReadLocal: Offset=8703, Size=0002

00 00

212328 0 ReadLocal: Offset=8705, Size=0001

00

212328 0 ReadLocal: Offset=8706, Size=0002

00 00

tells me whose avionics suite it is. Maybe Ray will know what's missing, but it looks vaguely as if there should be another component filling in values in those 87xx offsets -- they are assigned to that suite only. ;-)

Regards

Pete

[JBaymore]

Thanks, Pete.

Yeah... I forgot you'd know the reserved offset addresses. :wink: You got that right, of course.

He is unfortunately on the road right now for a while. So it will be a bit before we can debug this.

That tip from you likely will help him when he gets back.

best,

......................john (part of the beta team)