sensor state update

Moderator: Moderators

sensor state update

Postby anam » 30.12.2008, 23:54

Hi friends

I installed SVN 4185 and noted a problem regarding the feedback sensors refresh. In version I used before (SVN 3975) the S88 bus reports quikly the feedback state change. With 4185 this refresh becomes very slowly (and, of course, trains can t move in automatic mode)
As hardware I use the NanoX-S88 and occupancy detectors
I tried again with 3975 and everything was ok.

Thanks in advance

Best Regards and happy new year to all Rocrailers

Daniel
anam
 

Postby cwichmann » 31.12.2008, 00:13

Hi,
are you really shure that this doesn't occur with svn3975? I tested NanoX with a 39xx release and found the S88 Bus already slow.
Paco rated this issue as a firmware bug. There is an update availible at paco's page.
http://www.tinet.org/~fmco/whatsupdoc_en.html
cwichmann
 

Postby anam » 31.12.2008, 15:00

Hi Christian,

I have both version in my pc and I made many tests. The only difference is in rocrail.ini : fboffset = 0 (3975) and fboffset=1 (4185).
I uploaded in pic new Paco's routine when it was released, but I must come back to the first one(to be honest I dont remember in that case which SVN I used)

In next days I will made new tests, and I will report here my results.


Thanks
Regards

Daniel
anam
 

Postby anam » 05.01.2009, 00:36

Hi,

I tested again and had same results.

I updated the NanoX firmware, but, may be, there is a bug
http://boards4.melodysoft.com/app?ID=fo ... 057&DOC=41
so I come back to old version

I also checked with other software and sensor update was quickly (like snv 3975)

With svn 4185 refresh remains slow

I also noted this: in both version the server reports the same sensor address (example 519); in GUI svn 4185 highlights sensor with address 519, in svn 3975 sensor with address 520. In other words, it seems snv 3975 adds +1 to sensor address (both examples with fboffset=0)
And it seems 3975 made correct action. Because the first feedback sensor reported by server has address 512, instead of 513 corresponding to 65.1 (if I made correct conversion...Feedback Decoder Address - 1 * 8 + Port. Example: 65 – 1 * 8 + 1 = 513 )

May be I forget to set something in RocRail? I think so because it seems no other people report problem like this.....

Thanks in advance

Regards
Daniel
anam
 

Postby rjversluis » 05.01.2009, 08:17

Hi Daniel,

If you are using the lenz library we have to ask JeanMichel if there has been some changes made in timings and offsets.
Best Regards, Rob.
:!: PS: Do not forget to attach the usual files.
:!: PS: Nicht vergessen die übliche Dateien an zu hängen.
[ macOS - Linux] - [ N: CBus - CAN-GCA ] - [ 0: RocNetNode - GCA-Pi ]
rjversluis
Site Admin
 

Postby rjversluis » 05.01.2009, 08:20

The SVN logging reports the same as you:

Revision 4007 - (view) (download) (annotate) - [select for diffs]
Modified Mon Dec 1 21:41:18 2008 UTC (4 weeks, 6 days ago) by jmfischer
Original Path: Rocrail/rocdigs/impl/lenz.c
File length: 42758 byte(s)
Diff to previous 3976

slow down the whole thing (lenz.c) a little bit.

Revision 3976 - (view) (download) (annotate) - [select for diffs]
Modified Tue Nov 25 19:47:51 2008 UTC (5 weeks, 5 days ago) by jmfischer
Original Path: Rocrail/rocdigs/impl/lenz.c
File length: 42700 byte(s)
Diff to previous 3955

Lenz Sensor adressing shifted by 1.


So the Q remains: Why are those changes made to the library?
Best Regards, Rob.
:!: PS: Do not forget to attach the usual files.
:!: PS: Nicht vergessen die übliche Dateien an zu hängen.
[ macOS - Linux] - [ N: CBus - CAN-GCA ] - [ 0: RocNetNode - GCA-Pi ]
rjversluis
Site Admin
 

Postby jeanmichel » 05.01.2009, 11:56

slow down the whole thing (lenz.c) a little bit.

Sometimes not all commands reached the cs. This is only a wait problem.

Lenz Sensor adressing shifted by 1.

Now I'm confused ... There are several oppinions how the sensors should be adressed.

From svn3804 there is a attribute fboffset=“X” for the ini which allows you to shift the addresses of the sensors up or down. http://wiki.rocrail.net/doku.php?id=lenz-en

The promlem with the lenz.c is that wide range of CS using XpressNet. It is very difficult to finetune it to work with all devices.

Jean-Michel
jeanmichel
 

Postby rjversluis » 05.01.2009, 12:46

Hi jeanMichel,

OK, to make it work for all CS's we should make the sleep also optional and sizable.
If you have no time to implement it I will do this in the evening.
Best Regards, Rob.
:!: PS: Do not forget to attach the usual files.
:!: PS: Nicht vergessen die übliche Dateien an zu hängen.
[ macOS - Linux] - [ N: CBus - CAN-GCA ] - [ 0: RocNetNode - GCA-Pi ]
rjversluis
Site Admin
 

Postby jeanmichel » 05.01.2009, 13:07

in the ini I added sensordebounce="xxx" where xxx is default 100. A smaller number will lead to faster debounce. Maybe this helps. http://wiki.rocrail.net/doku.php?id=lenz-en

Jean-Michel
jeanmichel
 

Postby rjversluis » 05.01.2009, 18:05

Thanks Jean-Michel,

at the next opportunity I will create a dedicated Lenz-Setup Dialog.
Best Regards, Rob.
:!: PS: Do not forget to attach the usual files.
:!: PS: Nicht vergessen die übliche Dateien an zu hängen.
[ macOS - Linux] - [ N: CBus - CAN-GCA ] - [ 0: RocNetNode - GCA-Pi ]
rjversluis
Site Admin
 

Postby anam » 05.01.2009, 18:23

Hi JeanMichel and Rob

Sometimes not all commands reached the cs. This is only a wait problem.

Yes, sometimes in automode, loco does not start, even if at screen I can see correct command is sended by rocrail (in this case I simply send a light on/light off command and loco starts)

Now I'm confused ... There are several oppinions how the sensors should be adressed.
From svn3804 there is a attribute fboffset=“X” for the ini which allows you to shift the addresses of the sensors up or down. http://wiki.rocrail.net/doku.php?id=lenz-en

In that wiki page there is explained sensor address: 65.1->513

fboffset parameter may be a good choice to let everyone to adapt their system. What I think must be fixed is the same address in both Server and Gui (see what I said above regarding two different svn). fboffset should shift both, because the address is one (I think to action linked to sensor)

Regards,

Daniel
anam
 

Postby rjversluis » 05.01.2009, 18:38

anam wrote:What I think must be fixed is the same address in both Server and Gui (see what I said above regarding two different svn). fboffset should shift both, because the address is one (I think to action linked to sensor)

Their is no diff between addresses in server and GUI. The GUI works with objects, not addresses.
Best Regards, Rob.
:!: PS: Do not forget to attach the usual files.
:!: PS: Nicht vergessen die übliche Dateien an zu hängen.
[ macOS - Linux] - [ N: CBus - CAN-GCA ] - [ 0: RocNetNode - GCA-Pi ]
rjversluis
Site Admin
 

Postby jeanmichel » 05.01.2009, 20:10

Mhh, this lenz stuff is a real PITA. What I can say is that the current lib is absolutly working with an *original* Lenz CS and RS Sensors connected. It is as well working with the OpenDCC in lenz mode and some ORF connected.

Regards
Jean-Michel
jeanmichel
 

Postby anam » 06.01.2009, 14:29

Hi

at this stage I think the discussion about sensor addressing is over. We use fboffset to make a fine tuning of our systems. The addressing procedure in svn 4185 (server=gui) it's ok.

Regarding the slow refresh I should try to solve it with setting sensordebounce with a value smaller than 100 (if I correct understand)

In next days I will do some test, and will report here my results.

Thanks


@ JeanMichel
Mhh, this lenz stuff is a real PITA


what is PITA? :?

Regards
Daniel
anam
 

Postby dadolphs » 06.01.2009, 14:35

Hi Daniel,

anam wrote:what is PITA? :?


See http://www.urbandictionary.com/define.php?term=PITA :lol:

Best regards,
Dirk :rr_cap:
H0 - IB - LocoBuffer (MGV) - Ubuntu (Server) - Vista (Client) - iRoc - andRoc - Fredi

http://blog.moba-keller.de/
dadolphs
 

Next

Return to Lenz