Forum Navigation
Please or Register to create posts and topics.

RMUs responding Slowly Investigation

(Original thread started on 03-13-12 by Will Sasse)

I have been trying to solve an issue on my setup with the RMU's and Vince's RMU panels. I have found some sort of solution, so I thought I'd run it by more knowledgeable people than myself. There is a big question regarding the solution.

 

The problem:

RMU1 (captains side): Using Marks software, the buttons worked but the encoder for frequency change just caused the displayed freq to flicker and barely move. Then lately it caused the Jet45 RMUs to freeze (go non-responsive). RMU2 (co-pilot) worked well, very slow but as it should. During programming Marks software, I would get spontaneous pin firing on RMU1 - often pin 1 but also other pins

 

The Investigation:

Swapped pins for encoders between RMU panels 1 and 2 - no change, the problem stayed on the captains side.

Swapped out the encoder - no change, not the encoder.

Connected a spare encoder directly to the pokeys board, no change.

I swapped Vince's RMU panels (easy as I use DB37 connectors), so it wasn't Vince's boards.

I replaced the connector cable harness on the RMU1 side with a new one I made up. Made no difference.

I swapped out the PoKeys55 card with another - No change to problem, so it wasn't the I/O card.

Separated the panels on separate PoKeys cards, each running on the same pins for encoders using the same encoder number in pokeys setup, and each running a separate copy of Marks software - no change.

Updated/reset (FSUIPC, WideFS, Jet45, Marks Utility, windows, etc), firmware, and setting - no change

Connected the PoKeys card directly to the Jet45 PC, not through a USB hub - no change.

Cutting a long story short, most of the above was done with only WideFS, Jet45RMU's and Marks software running, apart from my antivirus and basic windows utilities.

I isolated every bit of hardware in the chain back to the PC and all to no avail.

I checked every setting a several times - no change.

 

That is a summary of over a months investigation, and is considerably abbreviated!:

 

The Solution:

Whilst trying to shut down frozen RMU's, I left Windows Task Manager open when I re-started the RMU's, and bugger-me if things now work perfectly!  As long as I keep task-manage open, things work. Close task-manager and both RMU's freeze.  What is going on with this?

 

An Aside:

One thing Mark found whilst helping me, and I confirm, is that with the full suite of Jet45, and Dave Ault's standby gauges running, the RMU encoder function slows down drastically on my system. Probable a symptom of my PC, but something to note if you experience similar slowness.

 

When I had the solution I opened each Jet45 DU panel one at a time and the encoder response slowed with each one collectively.  When I opened Dave's gauges, things slowed down drastically but with task-manager open, the encoders still worked!

 

(Posted by Alan Norris on 03-14-12)

Will, I see that you are running WIN 7. Have you by any chance disabled SuperFetch by mistake? Not sure why leaving Task Manager open speeds things up but maybe it re-enables it.

 

You may also want to try this:

Set processor affinity for specific applications

 

If you have a dual or a multi-core CPU, you can set processor affinity for specific applications. Depending on your CPU, you can significantly speed up the performance of some programs. The speed increase may vary, but getting use out of your secondary processors is definitely worthwhile.

 

Setting processor affinity is very easy and can be done from the Task Manager:

1. Start the Windows Task Manager by pressing Ctrl+Shift+Esc

2. Now go to the Applications tab, right-click the application you want to assign to a different processor and select Go to Process

3. You will then be taken to the Processes tab and the process related to the application will be highlighted

4. Right-click on it and select Set Affinity

5. Select the processors you want to associate with the application in the pop-up window

6. Click OK and close the Task Manager

 

Just a few thoughts.

 

(Posted by Will Sasse on 03-14-12)

Alan, all thoughts welcome. I'm about out of thoughts on this one. Found the task manager partial-fix only by accident! Mark also mentioned Affinity & I'd never heard of it! I will see if it helps.

 

Superfetch? I have disabled a few startup items in the quest for a cure of this problem. I will have to see if Superfetch is one of them and then work out how to re-enable it.

 

(Posted by Mark L. on 03-15-12)

One really curious question I have, is anyone besides Will, running my utility on Windows 7 64?

 

If they are and not having issues, then it has to be something in Will's PC config. If you are having issues, which I haven't heard any other than from Will, then it would be something in my software maybe. I'm looking into making the app run in either 32 or 64 native mode, but not getting it to behave for me. When compiling, I can specify x86 so it will always run on x64, but when I set it to 'Any CPU', it runs on XP Pro for example and crashes on x64, so I'm trying to figure out why. I'd like the next version of this to be 64bit enabled.

 

UPDATE:

Okay, I've found out that FSUIPCClient.dll that I use in my programming to talk to FSUIPC is a 32bit dll because a 64 bit version would not be able to talk to FSUIPC. This means, our utilities that we write will never be '64bit', but can certainly run on a 64bit machine. So, I still don't know what's causing Wills' problem, but it seems to run fine on my system. Hopefully I'll have the new interface board and software done before long. Have my prototype now made and will be starting the coding in between building TQ's.

 

(Posted by Will Sasse on 03-27-12)

Problem solved!

I tried the RMU, Marks Utility, & Dave's standby gauges on another PC on the network (slightly lesser spec than my Jet45 PC but one with all my daily programs running, same OS - Win7-64bit) and everything worked as it was meant to, I didn't need win task manager open.

 

The only difference I could find was that I was in a hurry and I installed Daves standby gauges in the 'Program Files (x86)" folder. The Jet45 RMU's, WideFS, and Marks Utility were all installed in a folder in my desktop

 

Willing to try anything, I uninstalled the standby gauges on my Jet45 PC and re-installed in "C:\Program Files (x86)\LJ45Sim\..." folder and sure enough everything works without Task Manager open. It even reduced the button/encoder lag on the RMU's to a level that is almost acceptable.

 

So, Dave's standby gauges need to run in the 'Program Files (x86)' folder (if using 64Bit OS).

 

For information, before this I was running all sim related programs (Jet45, Standby Gauges, and FSUIPC/WideFS) in "C:\LJ45Sim\.." folder to make it easy to trouble shoot and find. Now, I have moved the Standby Gauges, and am wondering if I should move Jet45 as well?

 

The only difference is I can no longer find the standby gauge '.ini' files. I'm not sure where they now reside.

 

I still intend to move the RMU's & standby gauges (center screen) to their own separate PC to eliminate the button/encoder lag, but for now I am happy!


Comments are closed, but trackbacks and pingbacks are open.