Testing against old ECoS and CS1 Firmware ? Topic is solved

Lichtleiter

Testing against old ECoS and CS1 Firmware ?

Post by Lichtleiter » 13.05.2009, 20:32

Hi all,

I have pushed a first version of the ECoS 3.0.0 railcom accessory decoder feedback implementation to launchpad.

Unfortunately I cannot test the new ecos lib against "old" firmware versions (for compatibility purpose) because there is no way back if ecos is updated to 3.0.0. Especially the CS1 2.0.4 is more like the old ecos version and may be, not every CS1 user will spend the bucks for the ESU 3.0.0 update...

Can anyone help me and test against old firmware?

Thanks for advance, Joern

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

Post by rjversluis » 14.05.2009, 16:50

Hi,

maybe a switch is better, so the old firmware can be supported with the same library.

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

Post by rjversluis » 14.05.2009, 17:10

Or rename it in ecos3.so/dll.

Lichtleiter

Post by Lichtleiter » 14.05.2009, 23:05

Hi,

...oh well ...the architectur of the new ecos lib extension is allready desiged to be compatible to all old versions... I think it's not so hard, because the requests to the ecos are all from the "old" style and function set and only if ecos replys "new" events, rocrail will be informed about the railcom feedbacks.

The only reason that I ask is, that I'll never say never to make a mistake ;-)

greets, Joern

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

Post by rjversluis » 15.05.2009, 15:33

Hi Joern,

if you can list up the files you touched I can merge it into the main branch and ask Onno to test the new library if he did not jet upgraded to version 3.

Lichtleiter

Post by Lichtleiter » 15.05.2009, 23:14

Hi Rob,

for the complete functionality I have touched a lot of files, because I have additionally implemented switch retrys, but for pure RailCom it is only "ecos.c" which is version critical (and stand alone inheritable in the trunk). RailCom feedback addresses are bus=4 and addresses=0-4095, even addresses for red and uneven for green.

greets, Joern

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

Post by rjversluis » 16.05.2009, 17:28

Hi Joern,
Lichtleiter wrote: for the complete functionality I have touched a lot of files, because I have additionally implemented switch retrys,
Can you give me more information on "switch retries"; In software you can not force a poorly functioning switch motor to come alive again...
Lichtleiter wrote: but for pure RailCom it is only "ecos.c" which is version critical (and stand alone inheritable in the trunk). RailCom feedback addresses are bus=4 and addresses=0-4095, even addresses for red and uneven for green.
Red/Green for even/uneven addresses? Can you explain this to me; Red/Green gates are for switches, not for sensors.

Lichtleiter

Post by Lichtleiter » 17.05.2009, 09:01

Hi Rob,
rjversluis wrote:Hi Joern,
Lichtleiter wrote: for the complete functionality I have touched a lot of files, because I have additionally implemented switch retrys,
Can you give me more information on "switch retries"; In software you can not force a poorly functioning switch motor to come alive again...
you are absolutely right! ...the "retrys" are not for suffering switch engines. There are at least three cases where the engines are basicly ok, but the command does'nt come to the decoder:

1. ECoS and CS1 firmware suffers since a long time from "missing switch commands" on logical level and the new (and more cpu speed consumpting) version 3.0.0 does'nt prevent but forces the ECoS/CS1 in this problem.

2. If users use the same booster for switches and locos, current short cuts fro running locos can destroy switch commands

3. As like 2. some old digital converted locos have "functions" with only one function pin of the decoder is wired to the function, but the other is directely wired to the tracksignal (light and steam of old Maerklin locos). This current, or more in detail, the current of the Motor over this "bypass wire", can allso destroy switch commands
rjversluis wrote:
Lichtleiter wrote: but for pure RailCom it is only "ecos.c" which is version critical (and stand alone inheritable in the trunk). RailCom feedback addresses are bus=4 and addresses=0-4095, even addresses for red and uneven for green.
Red/Green for even/uneven addresses? Can you explain this to me; Red/Green gates are for switches, not for sensors.
You are right and therefore the addressing model of the RailCom feedback sensors is "plain" in rocrail implementation.
But ESU SwitchPilot and Lenz LS100 (are there any more accessory decoder with RailCom on the market?) have defined two feedback pins for every switch output and even they can used independently, in the "natural way" they are associated with the green and the red position of the switch.

E.g. the first RailCom accessory decoder on accessory address 1-4 has the RailCom feedbacks 1-8 and if used in the "natural way" 1,3,5,7 are feedbacks for the green positions and 2,4,6,8 for the red.

greets Joern

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

Post by rjversluis » 17.05.2009, 09:09

Hi Joern,

Can you list up all touched files so I can check if it is merge able.

Lichtleiter

Post by Lichtleiter » 17.05.2009, 13:49

Hi Rob,

let me make some more fixes into my code and push them... I'll inform you, if things are right... ;-)

greets, Joern

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

Post by rjversluis » 17.05.2009, 13:52

Hi Joern,

don not forget to merge the trunk into your branch.

Lichtleiter

Post by Lichtleiter » 17.05.2009, 17:55

Hi Rob,

I have merged the trunk in my branch and committed the (tested) result. May be this version is fine for a first shoot to trunk ;-)
Touched files are:

=== modified file 'common/version.h'
=== modified file 'rocdigs/impl/ecos.c'
=== modified file 'rocdigs/rocdigs.xml'
=== modified file 'rocgui/dialogs/locdialog.cpp'
=== modified file 'rocgui/dialogs/locdialog.h'
=== modified file 'rocgui/dialogs/rocgui-dialogs.pjd'
=== modified file 'rocgui/dialogs/rocrailinidialog.cpp'
=== modified file 'rocgui/dialogs/rocrailinidialog.h'
=== modified file 'rocgui/res/messages.xml'
=== modified file 'roclcdr/impl/status/enter.c'
=== modified file 'rocrail/impl/action.c'
=== modified file 'rocrail/impl/control.c'
=== modified file 'rocrail/impl/model.c'
=== modified file 'rocrail/impl/pclient.c'
=== modified file 'rocrail/impl/route.c'
=== modified file 'rocrail/impl/switch.c'
=== modified file 'rocrail/public/wrapper.xml'
=== modified file 'rocrail/rocrail.xml'

greets, Joern

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

Post by rjversluis » 17.05.2009, 18:26

Hi Joern,

the railcom issue concerns ecos.c only I suppose.
The rest is for supporting bad hardware support?

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

Post by rjversluis » 17.05.2009, 18:51

Hi Joern,

the build process for your branch is not very successful:

Code: Select all

gcc -c -fPIC -g -ansi -I.. -I../unxgen impl/switch.c -o ../unxgen/rocrail/bin/switch.o
impl/switch.c: In function ‘_cmd’:
impl/switch.c:518: error: expected expression before ‘/’ token
make[2]: *** [../unxgen/rocrail/bin/switch.o] Error 1
make[2]: Leaving directory `/home/rob/lp/ecos-railcom/rocrail'
make[1]: *** [rocrail] Error 2
make[1]: Leaving directory `/home/rob/lp/ecos-railcom/rocrail'
make: *** [offlineall] Error 2

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

lesson for developers?

Post by ron&bram » 17.05.2009, 20:09

Hi Rob, Joern,

I hope it does not come as a surprise that I follow this thread also.

Maybe this is a lesson for the developers in general. It appears that the GCC compiler for Windows is less strict on syntax checking then the Linux original.
Joerns code compiles without error under Windows, but not under Linux. The Windows compiler accepts the comment in line 518:
// comment
whereas the Linux complier requires
/* comment */
It looks that a succesfull compile under Windows does not garantee the same under Linux (and vice versa??).

Any comments or suggestions anybody?

Best regards,
Ronald

Post Reply

Return to “ECoS - Marklin CS1”