Quote from Hangar45 Admin on November 26, 2017, 7:21 pm

(Original thread started on 03-13-13 by Alan Norris)

Strange thing, after about 15 minutes of having the standby gauges up and running, I get a "Not Connected" message on the gauges yet FSX flashes messages across the screen telling me they are (but my MFD start flashing weird numbers for fuel on board. Basically it looks as if the sim is going haywire. Not sure what's going on here.

 

(Posted by Eric Tomlin on 03-13-13)

You are having some network issues. I believe you mentioned earlier that you are using a cable between two PCs? I highly, *HIGHLY* recommend getting a switch and using that between the two PCs if you do not already have this setup this way.

 

(Posted by Alan Norris on 03-13-13)

This may well be the cause of the issues I'm having with my gauges and other stuff. I will have to go the local electronics store and get one. Can you (or anyone explain) why a switch is better than a CAT5 cable -- after all we use CAT5 cables to connect to the switch?

 

(Posted by Dave Ault on 03-13-13)

I agree, The 'Not Connected' problem will be some sort of network problem.  I find that raising the task priority of Wideclient.exe will cure most of these network glitches.

 

(Posted by Alan Norris on 03-13-13)

How do we raise the "task priority" of Wideclient?

 

(Posted by Ron Rollo on 03-13-13)

Hey Alan, you do have to do this every time you start up your computer. That sucks......

 

Anyway, go to you Task manager: Ctrl-Alt-Delete

Then select: Processes

Right click on the Wideclient.exe bar

The bottom of that window will give you the "Set Priority" options.

Select "Above Normal" or "High". I find that "Real Time" causes issues.

 

What you are describing is definitely a networking issue. The question is what is causing it. Over riding the priority of Wideclient will help but if you still have the problem, you will need to check other areas in your network settings. Within Windows7 there are many ways to screw this up!

 

As Eric pointed out, having a “switch” to link your computers together is the best way to go, especially for anyone using more than two computers. I hope this helps!

 

(Posted by Alan Norris on 05-11-13)

As you may or may not know, Ron Rollo and I are still having issues with our sims. I am running two PCs -- one as a server which runs FSX only and the other as a client running JET45 InterfaceIT (for the FDS cards) and Dave Ault's standby gauges. The machines talk to each other using WideClient on the client machine and of course WideServer7 on the server PC.

 

I start my sim by running FSX on the server PC, then WideClient, all of the JET45 DUs and RMUs, InterfaceIT, and last of all the three standby gauges on the client PC. Everything runs fine for about 15-20 minutes or so (can vary longer or shorter) then this starts to happen:

 

The standby gauges start flashing the [b]Not Connected[/b] message then shortly thereafter the values on the EICAS display go haywire -- displaying fuel flows and fuel on board in the hundred of thousands of pounds. Also sometimes the LEDs in my switches start to turn on and off. It all boils down to JET45 either losing connection with FSX or getting corrupted data.

 

Here's a screen shot of the EICAS with the crazy data:

 

What I would like to do is take a short survey to see if you experience the same issues. What you are running?

 

Please post here with the following information (and please post if you never see any of these issues so I can see what your setup is):

 

Questions:

Do you experience any issues of strange data being displayed on the EICAS?

Do your standby gauges flash the [b]Not Connected[/b] message at any time?

What version of Windows are you running (if two PCs are being used what version on each)?

What version of FS are you running?

Do you run JET45 on a separate machine to FS?

How are the two machines connected -- crossover cable, switch, router?

Do you run InterfaceIT?

Do you use Dave Ault's standby gauges?

 

(Posted by Eric Williams on 05-11-13)

Yes I had issues. I directed you to the stutter video a while back. My issue was simply not enough horsepower in my standalone Jet45 PC. I now run 2 PC for only the DUs/RMUs/Standbys.

 

To see if yours is the same issue: Simply run one program/jet45 at a time for the 15-20 minutes you say. If no problems, add one more program, repeat.

 

You will know right away after trying just one module- if you get no trouble- its is leading toward PC loading issue.

 

(Posted by Alan Norris on 05-11-13)

I did that starting with the EICAS, then the PFD and when I loaded the MFD, it started. However my JET45 PC is a beast -- ASUS P8Z68-V PRO MB, Intel i7 2600 CPU, 8GB fast memory so I don't see how that is causing an issue.

 

(Posted by Eric Williams on 05-11-13)

If it is only the MIP monitors and not FSX on that PC, it shouldn't be a loading issue. But if you started with one, then two modules before the trouble started- its probably still a loading or com issue possibly. If it's not load related, I'd suggest a close review of your communication/file sharing etc access.

 

Additionally, I do not run InterfaceIT on the Jet45 PC (its on the FSX rig) as well I use a switch with some PCs into that and some directly into my router. Running WideFS and filesharing set up as *everyone* so I can share items without using the silly homegroup etc.

 

(Posted by Ron Rollo on 05-12-13)

Another good question is who, besides Alan and I are attempting to run our sims on only two computers? I know Eric and several others are using three computers.

 

I will say this, after having the sim in several pieces and O.O.C. (Out of Commission) for the past three weeks, I got it back up and running. After I worked a few unrelated bugs out, I did a 1 hour test flight around Tampa/St. Pete with zero issues relating to this topic. Of course I was running Wideview in priority HIGH.

 

Alan, I see that you have verified that you are using CAT5e Ethernet cables. For the record, I am using CAT6 cables between the two computer with a switch in the middle.

 

I know nearly nothing about this stuff but this bit of information below indicates that if your using a CAT5e cable, your limited to 100 MHz of transfer.

 

The standard defines several classes of twisted-pair copper interconnects, which differ in the maximum frequency for which a certain channel performance is required:

Class A: up to 100 kHz using elements category 1

Class B: up to 1 MHz using elements category 2

Class C: up to 16 MHz using elements category 3

Class D: up to 100 MHz using elements category 5e

Class E: up to 250 MHz using elements category 6

Class EA: up to 500 MHz using elements category 6A (Amend. 1 and 2 to ISO/IEC 11801, 2nd Ed.)

Class F: up to 600 MHz using elements category 7

Class FA: up to 1000 MHz using elements category 7A (Amend. 1 and 2 to ISO/IEC 11801, 2nd Ed.)

 

The fact that you are using CAT5e cables and I am using CAT6 cables might explain why I am experiencing little to no craziness based on this Class list above. Another thing to look into is the switch itself.

 

Additional information on the switch:

I am using a D-Link 5-Port Gigabit Ethernet Switch DGS-105.

 

There is one statement in the users manual that I find interesting.....

"NOTE: A Category5 (or higher) Ethernet cable must be used for 100Mbps or higher operation."

 

With all this being said, I think your next move is to look into getting faster cables and insuring your running a switch that is at least one Gigabit (100Mbps)

 

I just ordered two of these CAT7 cables to see if I can put my issue to rest once and for all.

http://www.newegg.com/Product/Product.aspx?Item=N82E16812119312

 

(Posted by Dave Ault on 05-12-13)

I'm running everything using two PC's although I am not running the Jet45 software. I still get problems with the gauges displaying "Not Connected" unless I raise the task priority of WideClient, then it's fine.

 

(Posted by Marco Lamanna on 05-12-13)

I'm running complete sim with two PC's. One for FSX and Opencockpit software to drive LEDs and the other one for the glass cockpit with Dave Ault Standby gauges, CWP, clock and FreeFD EADI, Eicas and ND.

 

For now, I'm fine but I made just some test and didn't try a complete flight. The max length of my test was about 30 min and didn't observe any issues.

 

My second PC is just a "normal PC" with an i5 processor and 4GB Ram connected to my home Lan through standard Cat5 cable and a switch in the middle. Both PCs are running Microsoft Windows 7 professional.

 

(Posted by Will Sasse on 05-12-13)

Hi Alan, it does sound more like comm, not hardware issues.  I run 2 PC's, same setup as yours. I am in the process of rebuilding my sim so I am not operational at the moment, but before I pulled it apart my sim would run fine once the initial comm was established at each startup. I often left it running for extended periods with autopilot in HDG/ALT mode whilst I researched/played with settings.

 

I always ran the sim whilst not connected to the network/internet. I had a separate network switch that connected only the 2 sim PC's and then to the rest of my home network. I normally left that switch disconnected from the rest of the network/internet (by unplugging the cat5 cable from the network switch) unless I needed to update/access the network on either of the sim PC's. This way I could also leave firewall/anti-virus disabled most of the time.

 

Then, when I am happy with the sim, I will connect for access to the online community - ATC/Weather etc...

 

I do this as I found that even though I only had the bare minimum programs on these PC's there was constant polling by the PC's of the interent/network for one reason or another, using up bandwidth. disconnecting solved this.

 

Also in each program settings there is usually a "check for updates" option that should be carefully considered.

 

(Posted by Ron Rollo on 05-12-13)

Hey Alan, Marco, Dave and Will are all using two PC's like us. Will had some great suggestions that we need to look into after we upgrade to the CAT7 cables. If the issues continues, we need to isolate our sim computers from the rest of the home network. In my case, I can simply pull my wireless USB plugs. Second, insure that our firewalls are wide open. I'm not going to do anything until the CAT7 cables arrive.

 

(Posted by Hurl2space on 05-13-13)

When I started to build my sim I based it all on using one computer for everything. I was told I may not be impressed with the performance but I find it a lot easier than dealing with all the issues that some of you have. I even run the Jet45AAS on this one computer. I have 6 monitors running on 3 graphics cards and honestly, my sim works fine. Maybe I just got lucky. I am not very computer savvy by any stretch. All my modules are Goflight, Saitek yoke, pedals and throttle. All USB. Simple is my motto. I am not trying to say mine is better. Just saying this option worked for me (on my budget).

 

(Posted by Will Sasse on 05-13-13)

No Alan, that is not a gigabit switch, a gigabit switch runs at theoretical 1000mbits/sec and will be called a 'gigabit' network appliance, where as your 10/100 runs at 10 or 100mbits/sec and is called such.

 

I would certainly look to upgrade your switch to gigabit before you start messing around with replacing the cables. You should also look at the network adapters in your PC's to make sure they are capable and running at gigabit speeds. No point having fast Cat7 cables if your data flow is restricted by the hardware.

 

Ron, you have similar problems. Are you running gigbit hardware - both at the Switches and PC network adapters?

 

(Posted by Alan Norris on 05-13-13)

Will, yes I did some checking and a gigabit switch is 10/100/1000. I guess I didn't look close enough when I purchased it. I'll upgrade this week and get some CAT7 cables.

 

(Posted by Eric Tomlin on 05-13-13)

Reading through all of this it dawned on me that there is one other factor that is common between Ron and Alan- the location of FDS cards + InterfaceIT. Both you and Ron have your InterfaceIT/Cards attached to a client machine.

 

Remember, I have really OLD PCs and I have ZERO problems with any thing of the sort (and no CWP problems either that you've reported). I have my InterfaceIT install (and associated FDS cards- in fact ALL my interface cards) attached to the actual FS machine.

 

I strongly recommend that you simply export your card configurations and save them over to the other PC (FSX machine) and then simply move the USB cables to the FSX machine and it should all be ready to go. I have a feeling this may help you out greatly.

 

(Posted by Alan Norris on 05-13-13)

Eric, if the new switch and cables doesn't solve the issue, I’ll try that. It's a simple job and in my case I will have to move my PCIe USB card to the Server as it won't have enough ports. I would have thought that InterfaceIT wouldn't take up much bandwidth as it only sends data when you operate a switch or receive if a light needs to go on. Also my two Pokeys cards for the RMUs and DUs is on the client machine. I guess in total that's a lot of bandwidth.

 

UPDATE:

I'm trying something that Eric suggested -- well it was a little more than a suggestion! Don't want to jump the gun and cry wolf so will withhold comment until it's proved to fix the issues.

 

(Posted by Ron Rollo on 05-13-13)

Hey Alan, between moving the InterfaceIT to your server computer, new Gigi bite switch and new cables your issues should be history!

 

For the record, I would have loved to have put everything on one computer, if I knew it could handle it.

 

(Posted by Alan Norris on 05-16-13)

Okay, here's what I have done. At Eric's urging I moved the three FDS cards as well as my two Pokeys cards from the client PC to the server PC. This has freed up the client to handle just the JET45 programs and the standby gauges which run over the network. Also, before I start any JET45 or standby gauges I run WideClient and set its priority to "1".

 

So far I have flown two sessions for 2 and 4 hours with no JET45 or standby gauge issues at all. Now it is the consensus of a few members that this is pushing the envelope and that my good fortune may not last. I will run like this for a while to see if it holds up over the long run. I think this is preferable to installing a second client PC but we will see.

 

(Posted by Eric Tomlin on 05-16-13)

Myself as well as Jason (Programmer of JET45) and others have voiced strong support for spreading the load out to more client PCs. I will be in contact with Alan over the next several days on this subject as he runs FSX more and more and hopefully he can operate in higher demand environments to see if his situation remains stable.

 

Once and for all, the OFFICIAL Recommendation for running JET45 in a Full Setup is to use a dedicated PC for FS and more than one client machine for the JET45 suite. If it performs satisfactorily with anything less, that is one-up for the builder but mileage may vary depending on a plethora of settings in hardware, software, etc.

 

(Posted by Alan Norris on 05-16-13)

I think if anyone is contemplating just one client machine, then they need to make sure it has the fastest CPU and motherboard they can get. For the record I run an Intel i7 2600 3.4 GHz and an ASUS P8Z68-V PRO motherboard for my client. These are almost two years old as I built a new machine for FSX with the latest offerings in June of 2012. The latest Intel CPU is an i7 3770K 3.5 GHz and ASUS has the Z77 motherboard. I think that the motherboard has more to do with speeding up the workload than the CPU (as Eric so rightly pointed out). My CPU never gets above 10% so in my opinion it's the motherboard architecture that has the most effect.

 

(Posted by Ron Rollo on 07-16-15)

UPDATE:

For the longest time, my standby gauges were in the "programs x86" file of the client computer. I moved them out of that file and now I do not experience dropped gauges like I had before. I do not have to override the priority nearly as much but more test flights are needed. It also helps that I have a third computer and half of the Jet45 work load is now being shared by two client computers.

 

Anyway, I'll report back if I am still in need of overriding the priority to "Above Normal".

 

(Posted by Shane Barnes on 07-16-15)

I have found better performance and reliability by keeping most everything out of the "programs X86" file. I avoid that area . .

 

(Posted by Alan Norris on 07-18-15)

I always had my standby gauges in the Programs x86 folder.

 

What saved me was going to three computers. That stopped all of the funny stuff that an overloaded bandwidth caused. As soon as JET45 was on the two client computers leaving the server computer to run FSX everything was fine.

 

I know you struggled with two PCs for a while as I did. Are you saying that you still had issues after going to three PCs and only after moving the gauges out of the Programs X86 folder fixed them?

 

(Posted by Ron Rollo on 07-21-15)

It has been a while so I can't say for sure. I think I was still having issues and I had to over ride the priority to above normal or high. As a matter of fact, I know I am still having issues with the RMUs dropping off but that is for another thread.

 

I did a 30 minute test flight without overriding any of the gauges to ABOVE NORMAL or HIGH. Everything was fine until about 20 minutes into the flight when I purposely went into over speed. The standby ASI closed down. I brought the ASI back up and went into over speed again and everything was fine. I finished the 30 minute flight with no other issues.

 

I don't think that going into over speed had anything to do with the failure but I will take a few more test flights to see what happens. I'll keep the priority in NORMAL for now.

 

The good news is if I do over ride to ABOVE NORMAL, there should be 99% less dropped gauges. I have that in my pocket!

 

Another 45 minute test flight. This time the altitude dropped off after 14 minutes and then the ASI dropped off 30 seconds later. However, I was toggling the ADI smooth graphics on and off and this may have had something to do with the two other gauges dropping off. I brought the ASI and altitude back up and they were fine until the sim crashed about 30 minutes later.

 

The next test will be with all three gauges set to ABOVE NORMAL. I'll fly for at least 45 minutes and see if I get any dropped gauges.

 

(Posted by Dave Ault on 07-21-15)

I find that when any gauges drop out it is due to wideclient.  Try leaving everything as NORMAL priority but set wideclient.exe to HIGH priority.  Since I have started doing this I have not seen any drop-outs.

 

I now run my ADI, ASI, Altimeter, RMU, CWP, Clock, AOA, FreeFD and the full P8R suite on a single PC running XP with no problems.

 

(Posted by Ron Rollo on 07-23-15)

I did a few more test flights with wideclient set to ABOVE NORMAL. That seems to do the trick. I was doing all sorts of other programming and fiddling and I did not loose any of the standby gauges. I was talking to Shane and there are a few other settings that I can check and or tweak. We are on the right track!

 

UPDATE:

Over the past few days I have been hammering out some of the issues with the sim. Thanks to Shane for the helping hand in a few of them. He saved me countless hours in just minutes. Sometimes a fresh look from a different point of view is all it takes.

 

One of the things that Shane helped with is installing a version of Simconnect. My system apparently had at least one version already but needed another one in order for my Accu Feel to work and the pressurization panel to work later today. We were thinking that this new version of Simconnect my have a good effect on other programs which is why I did the following:

 

From a cold hard start of all three computers, I brought everything up including the standby gauges. I let everything sit for two hours. When I came back I saw that the ASI was kicked off sometime during that two hour period. With this test I did not override any of the priorities of the ASI or Wide Client. Later today I will do the same exact test but this time with the Wide Client overrode to ABOVE NORMAL.

 

I feel I am getting closer to being able to put my finger on the answer for myself and anyone else that might have this problem in the future.

 

I did another two hour test today with everything up and online. The sim was just sitting on the runway with no interaction from me because I was miles away! This time I had Wide Client over ridden to HIGH. Sometime during that time period the ASI and the altimeter got kicked off.

 

I think Shane may be right, I might have an issue within home group and the network sharing information between the three computers. More testing to come.

 

UPDATE:

I'm still looking for the answer to the problem with my dropped gauges. So here is something that I want to explore. FSUIPC and WideFS

 

Pete Dowson just released or at least made an announcement on the latest versions of FSUIPC and WideFS

 

My question is: Where is the optimum place to house these two programs? In the shared Users folder, the Programs folder, directly on the "C" Drive or under the Programs 86x folder? In addition to this, where is the optimum place to have the standby gauges on the client machine? I was talking to Shane and we think we may have an answer..........I'll explore this further in the morning.

 

(Posted by Dave Simmons on 08-05-15)

I have been using FSUIPC and WideFS since FS95. Never a problem. Dave's programs use the FSUIPC offsets from either FSUIPC or WideFS to obtain the data to feed the gauges.

 

The best folder (and the one FSUIPC installs into) is the Modules folder in the FS root directory. Since WideFS is a lone stand alone program, I put it in my C: root on the client. WideFS is not needed on the server and I keep both install files in the Downloads folder.

 

As they communicate via TCPIP (Ethernet), I use a cheap router to connect the server to the clients. I do not use home group Microsoft as it is too squirlely. I use the router and Ethernet native and all is default in Network management and all shared (folders) on all machines. I ensure a common work group name not the default Microsoft WORKGROUP. I use Cat 5 or 6 cables. I set up a work ( not home group or public) to communicate. I have neither the server or clients or the router attached to the internet. That way I can shut off all security.

 

I have a FSUIPC tuning guide from Sim Samurai. Use it consistently. Whenever there is a major update to FSUIPC, I install the whole thing again (including WideFS ) but keep the .ini files for FSUIPC and WideFS that had tuning and settings already included.

 

Have not had a problem. And I use LUA programming (Linda) to drive gauges and some hardware (VRInsite).

 

(Posted by Dave Ault on 08-05-15)

On my PC, FSUIPC is in the default folder. Wideclient is in c:\Program Files.  I would try turning off windows firewall (obviously unplug the internet first). Also, have you tried a different router?

 

(Posted by Ron Rollo on 08-05-15)

I think I might have solved my issue with the dropped gauges. It has nothing to do with Dave's wonderful gauges but just where I had them on my computer. Hopefully others who know next to nothing like me about software stuff can learn from this.

 

Anyway, I did another test where I started up the sim and let everything run while still sitting on the runway for two hours. Nothing was over ridden to higher priorities. The standby gauges passed! No dropped gauges! I did have a hiccup or two with FSUIPC but I think I know what the issue is there as well.

 

What I did was uninstall the three standby gauges that I had in the USERS folders. I think this is possibly the worst place to install programs that you are looking to run in real time. USERS is a great place to put photos, files and documents that you want to share with others in the same network but you don't want others to be able to have access any further onto that computer. In other words, there are additional security settings, (hoops to jump through) for files and programs housed here. That's my take on it anyway.

 

I reinstalled the standby gauges directly onto the "C" drive of Client1. Shane and I were talking about this and he was saying that most all the sim guys who have been around for a while say that all of your sim programs should be installed directly onto the "C" drive of your computer. This seemed to do the trick!

 

As for FSUIPC and Wide Client? I think I need to uninstall them and put them on the "C" drive as well to resolve the remaining issues. Eventually I will need to move Jet45 over to the "C" drive as well.  More testing and refining to come!

 

(Posted by Eric Tomlin on 08-06-15)

It sounds like you may be onto something. I cannot imagine having an issue with JET45 if it's in some place like C/program files/JET45/PFD.exe, etc.

 

(Posted by Ron Rollo on 08-06-15)

This morning I moved all the Jet45 AAS components from the USERS folders directly onto the "C:" drive of their respective Client computers. I discovered more conformation that this is a good move.

 

Prior to this, every time I fired up the client computers I had to hit a "RUN" button in a dialog box for all the Jet45 components. This was six separate dialog boxes! And prior to the recent move of the three standby gauges, I had three additional dialog boxes to acknowledge. Basically this was the computer asking me to make sure that this outside user was allowed to access these programs which was acting as additional security. Now that Jet45 is directly on the C: drive, when I fire up the client computers everything starts up automatically. (Of course I have shortcuts to all these in the Startup menu which initiates this to happen.)

 

Next I will take a look at FSUIPC and Wide Client to make sure they are in a good place.

 

Final conclusion:

Most of the issues with dropped gauges have seemed to go away. There are a few key fundamental issues that we have to make sure we have right or there will be issues.

 

1. Placement of the programs. Place the standby gauge programs on the root directory, in other words, directly on the C drive. DO NOT put them in the USER folders or in the Programs x86 folder.

 

2. Use a “switch” and CAT6 or height cable to connect your computers.

 

3. Plan on over riding Wide Client to ABOVE NORMAL.

 

4. Set your network up in a work group and turn off as much security as possible.

 

5. If you have a lot of programs, divide up the work load on three or more computers.

 

If you have issues with dropped gauges or connectivity issues, please post here and we can help get you through your issues.