I've looked at both the Shared Memory Export and EECH CommServer pages on EECH Central, as well as Dick Dastardly's UDPSpeed Installation guide, and I can't get EECH to operate networked. Here are the steps I took:

Client PC

1. Install UDPSpeed for each cockpit available
2. Set UDPSpeed.ini to host IP (left port at 10000)

Host PC

1. Set MEMEXPORT=1 in EECH.ini (and save file)
2. Run EECH
3. At menu, alt-tab out and run "eechcommudpserver 10000" from command line

Client PC

1. Run UDPSpeed (cockpit of choice)

I realize I skipped modifying the MFD Extract lines and using MaxiVista; I wanted to get the gauges working first before worrying about the MFDs. Problem is that when I run things in this order I get the UDPSpeed dialog box '"INVALID VERSION" is not a valid floating point value.' If I run UDPSpeed first before loading EECH, the gauges load fine, but never update when in-game.

Also, is there any "one-stop shop" that can walk me through how to set this up with the latest builds (I'm assuming we no longer need to use different EXEs, since eechcommudpserver is now included in 1.14)?

Thanks in advance,

EECHCommUDPServer.exe is a part of EECH mod installation. It's specific for every version (otherwise Invalid version message will appear).
Older tools don't work with newer EECH exes.

Thanks, FireBird.

I should clarify that I am using the EECHCommUDPServer.exe that was bundled with 1.14.0. The only "old" software I am using is UDPSpeed.

Hi HomeFries,

I think you've missread Dick Dasdardly's instructions:

According to what I read there you should launch the UDPSpeed set on the client BEFORE you you start EECH on the host. You then alt+tab and run EECHCommserver which should then connect to UDPSpeed.

Finally, alt+tab back to EECH and enjoy !

I use EECHCommserver over a 2 machine network to send the data to SIOC which controls my interface cards. If SIOC is not running when I launch EECHCommserver it doesn't start.

Hope this helps,

Andy

I'm assuming that you have the machines connected with a crossover cable or via a network switch and that they are both on the same subnet.

SIOC and UDP are different. SIOC really needs to connect the external server to run, UDP is different.

I don't have UDPSpeed to test, could you please give me your exe and the configuration? I'll check it.

Gents,

Thanks again for the help.

AndyB, I did try to run UDPSpeed on the client before running EECH and then EECHCommServer on the host. I was unable to get any gauge updates.

I did not include SIOC in my write up because it was not referenced as necessary in DD's instructions, though I did play with it earlier. No matter what I tried, I always got the following message

FireBird, here is a link to the Comanche pit (which includes UDPSpeed).

Also, what exactly does SIOC do, and is it something I would find useful given my current ambitions?

Hi,

Didn't mean to imply that you should have SIOC installed, that's just what I use in my pit.

SIOC is a control language. It allows you to switch outputs in response to IF...THEN type statements. It works best with Opencockpits interface boards (they wrote it), but I believe it also works with others.

IN EECH if I overtorque the engines the light would come on. This data is also exported via EECHCommclient to SIOC.

In SIOC I have a bit of code that says "If variable xx goes to 1 then switch output yy on. As the program is event driven ( nothing happens until a variable changes) it doesn't sit continually polling the inputs and slowing your machine down.

There's obviously more that you can do with it, but that's the basic function.

It's pretty simple once you get the hang of the syntax.

Cheers,

Andy

HomeFries - While both UDP Speed and SIOC utilize the data coming from EECH's shared memory, they serve different masters.

- UDP Speed takes the data and uses it to control virtual guages/panels, on a networked PC's monitor.
- SIOC takes the data and uses it to control "real" guages, indicators, warning lights, etc, via boards from Opencockpits, on a networked PC.
(And of course MaxiVista is used to port the MFDs, to a networked PC.)

So, if you want your MFDs on another monitor and the various lamps and indicators to surround them, on a virtual dash....then it's UDP Speed and Maxivista.
If you want your MFDs on another monitor and you want to invest in additional controllers and have actual working indicators and such....then it's SIOC and Maxivista.
I don't know of anyone that has a setup using all 3. (Although, I don't really see why you couldn't?)

My setup uses the latter, so I won't be much help. Sorry!

Thanks again, guys.

Since I have a networked PC with two auxiliary monitors on each side of my pit, UDP Speed looks like the way to go for me.

Is there a central location that explains how to set everything up with the most recent releases? EECH Central links to SimHQ threads that now come up 404.

I made some tests.

EECH and EECHCommUDPServer work exactly as requested.

UDPSpeed with the supplied configuration incorrectly requests variable "1" for MFDs - and gets answer "INVALID COMMAND":


Changing it to "20" get rids of such replies


But UDPSpeed becomes to show message box something like ". invalid float".
Its log shows "06.12.2011 XX:21:04 Error in data". Very informative.

I removed all of "XX XXXX" folders except IAS, VS, BALT, RALT, TIME and run UDPSpeed again.
The values appeared and changed according to Comanche movements.

Thus, there is a problem in UDPSpeed or in the configuration.

Happy bug hunting! If you find that EECHCommUDPServer sends something unexpected - feel free to inform me about this.

I doubt it. The initial shared memory setup and UPD port was done quite awhile ago. Over several releases it became broken and neglected.
Firebird gratiously repaired and expanded it and helped Andy and I get SIOC talking to it, too.
But I don't know of anyone recently that's tried UDP Speed with it?.... You may well be the new guinea pig?

If, as Firebird says, the issue is with the UDP Speed configuration, you may want to PM DickDastardly (if he's even still around?) and see if he has any insight.
That was his baby, afterall.

Roger all. I don't know how much time I have to dedicate to the project, but knowing that the problem is on the UDPSpeed end of things should help some. Since FireBird was able to get proper data from some of the gauges, it looks to be fixable at the data level.

Thanks again, guys.