Testing against old ECoS and CS1 Firmware ? Topic is solved

Lichtleiter

Post by Lichtleiter » 17.05.2009, 20:21

Hi,

...hmmm, I'm working every day with gcc for Linux (developing the Fritz!Box firmware) ...and had not heard since more then 10 years about gcc problems with the C++ style double-slash comments...

...and by the way ...the lenz.c is full of this sort of comments...

Are the compiler options for "rocrail" and "rocdigs" different under Linux but not under Windows? And if so, why?

greets, Joern

ron&bram
Posts: 2460
Joined: 11.06.2008, 19:34
Location: Heemskerk, Netherlands

Post by ron&bram » 17.05.2009, 20:51

Hi Joern,

I know that the lenz.c is full of // comments (I put several there myself), but they are behind a line with code. The simple fact remains that I could compile without errors under windows but under linux I had to change two occurences of //comment into /* comment */ to get the source to compile (once in rocrail/impl/switch and once in rocdigs/status/event). Maybe the unicode (windows) against ansi (linux) may have a magic influence. Yet I wished that all the compiler errors I have run into in the past were that easy to solve.

Best regards,
Ronald

Lichtleiter

Post by Lichtleiter » 17.05.2009, 21:14

Hi Ronald,

...thats a good point and I'll change my code to standard :-)

greets, Joern

ron&bram
Posts: 2460
Joined: 11.06.2008, 19:34
Location: Heemskerk, Netherlands

Post by ron&bram » 17.05.2009, 21:22

Hi Joern,

I really have no idea wether or not // comment is standard or not, I certainly do not consider myself a programming expert. My motto is simple, when you find an easy and quick solution for a simple problem, apply the solution and do wonder about the how and why, but go on and go for the next BIG one, that's the one that needs the energy, thought and attention. :wink:

Cheerio,
Ronald

ron&bram
Posts: 2460
Joined: 11.06.2008, 19:34
Location: Heemskerk, Netherlands

Post by ron&bram » 17.05.2009, 21:45

Hi Joern,

Sometimes I overlook things, in this case with regard to your previous post of switch commands getting lost. I can not confirm switch commands getting lost due to disturbance on the track from loc decoders, but only because I have taken measures to prevent this.
I have attached my switch decoders to a seperate booster, home build around a LMD18200 H-bridge circuit, connected to the booster output of my twincenter. Since the switch decoders themselve do not consume a lot of power, the cooling and power supply requirements are quit modest. I also have the nasty habit of not trusting suppliers statements about short circuit resistant outputs of switch decoders. Having to drive LGB size switch motors, my switchdecoder outputs are all connected to relays (I buy 18V relays with 5+ amp contacts in my local electronic dump for almost nothing). The power for the switch motors, coming from a BIG seperate 16V transformer, go through the relay contacts and a ptc resistor type fuse and does not come from the switchdecoder itself. When something goes wrong with a switch motor I smoke off a €0,50 or so relay when the ptc safety fails, not a €26 switchpilot.

Having described all things I undertook to seperate switch commands and loc commands I can only say that I think you are right about switch commands getting lost due to interactions from other devices.

Best regards,
Ronald

rjversluis
Site Admin
Posts: 41187
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Post by rjversluis » 18.05.2009, 10:19

Hi Joern,

I have discussed the switch retry issue with some of the project members and we did come to the conclusion not to merge this option into the main Trunk of development; Hardware problems should be solved at hardware level.

The ECoS RailCom support will be merged into the main Trunk as soon the test is successful with previous ECoS firmware versions.

Lichtleiter

Post by Lichtleiter » 18.05.2009, 11:27

rjversluis wrote:Hi Joern,

I have discussed the switch retry issue with some of the project members and we did come to the conclusion not to merge this option into the main Trunk of development; Hardware problems should be solved at hardware level.

The ECoS RailCom support will be merged into the main Trunk as soon the test is successful with previous ECoS firmware versions.
Hi Rob,

I agree with you for hardware problems like the short cut current and other such thinks every user can fix if he want to.

But unfortunately the problem, that ECoS and CS1 loose switch commands on logical level between TCP PC-Interface and track signal, isn't fixable for the user.

The ESU problem is in the comand station since product start, but comes more and more present, as more cpu consumption is taken. A lot of ESU user are touched from this bug!

ESU-Support (in person ESU boss Mr. Lindner) has confirmd the problem, but it seems to be very complicated to fix it. The time to search for the bug ist scheduled at ESU for Version 3.2.X (ESU posting in ESU forum) and realistic time up from now is at least half a year or more...

...so I feel that it is not to handle for me, if every new feature of rocrail trunk may be incompatible with my strongly needed code. (source conflicts and so on)

Before answer this post, please read ESU forum (NOT my postings there, instead all the other postings)

greets, Joern

rjversluis
Site Admin
Posts: 41187
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Post by rjversluis » 18.05.2009, 11:48

Hi Joern,

I will have no problem if you do the reties in the ecos.c.

BTW: how many times must you send the switch command to the ecos before it will finally accept it?

Lichtleiter

Post by Lichtleiter » 18.05.2009, 12:07

rjversluis wrote:Hi Joern,

I will have no problem if you do the reties in the ecos.c.

BTW: how many times must you send the switch command to the ecos before it will finally accept it?
Hi Rob,

"inside ECoS" works for originary RailCom switch decoders but it doesn't for other switch decoders, where other feedback contact are used to implement the "OSI layer 2 switch retry loop". E.g. I use 4/8 * servodecoders from JoKa-Tech and HSI88 contacts to prevent the servodecoders from missing switch commands. I cannot detect HSI88 contacts in ecos.c and it is very complicated to configure the association of HSI88 addresses to switch addresses inside ecos.c

My defaults for retry are in this moment 10 times with a 3 second interval. It is configurable in rocrail config and can be switched completely off.

The ESU bug looks like dependencies between loc accelleration commands and switch commands ...but nobody knows exact!

greets, Joern

...and by the way ...Märklin CS1 has, even if with ESU Firmware 3.0.X, NO RailCom detector on the main Booster. So the only way for CS1 user is to protect switches via external contacts against missing command on the track-signal.

rjversluis
Site Admin
Posts: 41187
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Post by rjversluis » 18.05.2009, 12:33

Hi Joern,

to be honest: I would send the ECoS back to ESU and demand for refunding the money you paid for this piece of not reliable hardware.

If you must send the switch command 10 times you will get other communication problems with bigger layouts. Even the auto mode of Rocrail will suffer of bad response times from the command station.

Lichtleiter

Post by Lichtleiter » 18.05.2009, 12:53

rjversluis wrote:Hi Joern,

to be honest: I would send the ECoS back to ESU and demand for refunding the money you paid for this piece of not reliable hardware.

If you must send the switch command 10 times you will get other communication problems with bigger layouts. Even the auto mode of Rocrail will suffer of bad response times from the command station.
Hi Rob,

you are right, but the situation is the situation and no way out ;-)

Statistically from 10 switch commands one is missing and most times the second try is successfull. Only if three or more locos are started (or speed is changed) simultanously to switch commands, it needs a third or forth try.

ESU suffers completely from all the requests of users, who ask more for bells and whistles like "Gleis Bild Stellwerk", etc., than for core code quality... and the focus of ESU is not on the PC-Interface, but on the interactive touch display user... and this user presses only one button per time...

greets, Joern

rjversluis
Site Admin
Posts: 41187
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Post by rjversluis » 18.05.2009, 12:59

Hi Joern,

if you see no way out I would suggest to do the same as Ronald did: use a separate command station for the stationary decoders; a simple booster and DDX will do.

ron&bram
Posts: 2460
Joined: 11.06.2008, 19:34
Location: Heemskerk, Netherlands

Post by ron&bram » 18.05.2009, 13:05

Since I can not stay out of a discussion, my two cents:

There are two different things to consider here:

1. Unreliable turnout operation.
When a command to set a turnout is send by Rocrail and it has been received and processed by the Ecos and the turnout decoder, the turnout should be in the position that Rocrail wants it. When it has not reached this position and the turnout is equiped with position feedback, Rocrail wil detect this mismatch and signal it.
In general, a turnout that does not switch reliable has to be fixed and not by doing several commands in the software.

2. Lost commands.
I do not know a lot about the Ecos, but from what I have read in the protocol description that can be found in the wiki, there is a command (get 11 switch) to ask for the position the Ecos thinks the turnout has. When a command is lost, the Ecos would (I think) still report the original position. This can be checked inside ecos.c and when here a mismatch occurs the turnout command could be repeated until the Ecos reports the position as changed.

Just my idea,
Best regards,
Ronald

Lichtleiter

Post by Lichtleiter » 18.05.2009, 14:04

Hi Ronald,
ron&bram wrote: ...in the protocol description that can be found in the wiki, there is a command (get 11 switch) to ask for the position the Ecos thinks the turnout has. When a command is lost, the Ecos would (I think) still report the original position...
...definitely NO!

ECoS reports the switched position because it thinks internally that everythinkg is fine and the command has been send via the booster to the track signal ...but it has not!

The only mechnism, to see that noting is fine, is the missing RailCom feedback from RailCom compatible switch decoders. For every other decoder you have no chance to find out what has happend.

The "missing" is only visible in absence from the track signal.

greets, Joern

ron&bram
Posts: 2460
Joined: 11.06.2008, 19:34
Location: Heemskerk, Netherlands

Post by ron&bram » 18.05.2009, 14:52

Hi Joern,

That would mean that the problem is not in the pc interface, since the Ecos has heard the command, but that is in the internal Ecos prioritizing in putting commands into the dcc queue. The Ecos has gotten the command from the pc, it thinks it has processed the command since it reports the changed position upon inquiry, but did not actually send out the command (yet). When you never have this problem when operating a turnout from the Ecos display, it looks that commands from the pc interface are given low priority in the Ecos.

Without railcom you can always use S88 feedbacks to check on turnout position (you need the switch on the turnout to sense its position anyway, also with railcom decoders), Rocrail has a mechanism to link a feedback to a turnout position and to indicate mismatch between wanted en measured postion.

Best regards,
Ronald

Post Reply

Return to “ECoS - Marklin CS1”