Well I have just had a quick play with Railroad & Co Traincontroller 5.8D with the CS, using the settings for the ESU Ecos as the "Connected Digital System" and I can confirm that Traincontroller 5.8D does work with the CS. The limited test I performed involved setting up my BR45 (the 2002 Insider version) as a loco, with functions, and then controlling the loco from the computer, and trying out the functions. Everything worked as normal.

I was testing with the demo version of Traincontroller - I don't own the full version.

Next, I'll have to try some mfx locos, and some solenoid devices.


I also tried the latest version of Rocrail, which supposedly supports the Ecos, however it did not want to connect to my CS.

Thanks for your replies. Interesting.

What I am wondering



will the ECos remain 'in sync' software wise or will they eventually diverge? M* hasn't made there protocol public yet so I don't want to run the risk that the software won't connect with the CS when the systems go their own way.

I think it is a bad thing M* isn't more open on this.

René

I went to the Eurospoor 2007 exhibition today, and to my suprise the Central Station was for sale there for €399 (the updated version!) and the ECoS for €499.

If M* was more open about the computer interface protocol and preferably the roadmap they have regarding updates and new feautures the choice would have been easy.

René

I've had another play with TC controlling the CS. I can read the list of locos defined in the CS into TC. I cannot, however, control any of the mfx locos. I can control (turn on / off) any of the functions on an mfx loco, but I cannot actually drive one. TC doesn't seem to disconnect from the CS when driving a mfx loco, but TC just stops being able to do anything at all with the CS. Controlling non mfx locos is fine.

I guess that stands to reason, as the Ecos is not meant to know anything about mfx, so maybe this version of TC doesn't know anything about mfx either. I guess that will come in a later version.

Hi,

the mfx-protocol has nothing to do with the interface-protocol so that I guess that's not the reason for mfx-engines not being controllable through TC.

Might merely have something to do with the fact that mfx-engines in the ECoS-system is run with 28 speedsteps instead of 128 in CS-environment. The RailNet BETA-phase is soon ended and it'll run mfx-engines with 128 speedsteps (already does...).

Hi to all,

software should be able to control all vehicles at 128, inependently from protocol on the tracks and no matter what device is connected. The following devices REQUIRES 128 speedstep-programming for the developer: IB, TC, EC and compatible. The following devices are supporting 128-speeds programming for developers: CS, ECoS, Dynamis.

So for a developer it is more than easy to support the 128-speed access to the device. Plz notice: the access to the device has NOTHING to do what happens on the user interface or what happens on the tracks.

Sadly to say the ECoS and the CS offers a way to access speed by the "speedstep" format. This format is not recommendable for simple programs. It requires to know how many speeds a vehicle offers.

Look into the documentation offered by Uhlenbrock to see what I mean (it is in English). The ECoS protocol appears later ...<further text removed by internal zensorship before publishing>...

PS: edited later:
and even the Pros are using this way:
http://www.windigipet.de.../index.php?topic=55387.0
reporting that WinDigipet is accessing all vehicles via 128 speeds when connecting to CS/ECoS...

Mafi

Interesting.
So internally, the ECoS recalculates this to the 28 MMII speedsteps, the CS to 128 steps.



Which explains the problem Bigdaddynz is experiencing with MFX locos.

René

So now I have to hope my favorite software ignores the speedindicator in its implementation for the ECoS... Maybe I should give the developer a hint (or maybe not, his moods seems to be anti-Marklin, for not opening up to protocol).

René

Hi Stephan,

this is in line with my findings as well. Since the ECoS doesn't support mfx, that SW-part has been disabled/left off and the protocol value (for example in a "queryobjects(10..." command) will be converted to MM28 instead. likewise, specifying "mfx" in a "create(10..." command won't work either.

When using Windigipet with the CS, what is the (tcpip) port number setting that should be used?

BTW, I downloaded MJ-Teknik's Railnet Beta software and installed it. Unfortunately, upon startup the program terminates with a Windows exception error. I tried it on 2 different Windows machines, both with the same error.

It appears the database does not get created, but I'm not sure whether the program abends because there is no database, or due to something else.

Thanks Fredrik, I've enabled my email address, so that you can do that. Much appreciated. One thing I should ask about your software is whether there are any dependancies, such as java or .net versions?

BTW, I've answered my own question re the tcpip port number. I found on Stummi's forum a reference to the Ecos using port 15471, and I've confirmed that by running the netstat command in windows while TC is connected to the CS. Netstat shows all active (established) and listening tcpip connections on your computer.

Good luck, Rene.

Well yes that thought crossed my mind, Rene. I haven't as yet had a chance to go back and check it. I'll report back as soon as I do.