(SOLVED) Speedcurve Feature - old help improving behaviour

Moderator: Moderators

(SOLVED) Speedcurve Feature - old help improving behaviour

Postby mserrano » 21.09.2010, 21:39

Hi all (sorry for the long message),

I have recently bought a new “low cost” loco – as announced by Märklin – with a specific decoder I had never used before: 146871. According to http://decoder.x-train.de/index.php?seite=decoder/digipic/146871.php , the decoder should work fine as a MM2 protocol decoder – it also works as an MM4 and MM5.

After some tests I have found out a problem in its behaviour when sending a change direction command. Apparently the loco does not react unless I reduce the velocity to 0. Reading the wiki, I noticed that sending the v=0 command should be a standard now… so I do not know what is exactly happening. My assumption is that the loco is not receiving the v=0 command from DDX after the change direction command… or at least it is not considering it… seems like the loco actually monitors when v=0.

Just to explore I modified the code in ddx.c to force a command v=0 to be sent whenever a change direction was requested…. And the result was still the same. It is weird, because as soon as I reduce v=0 , the loco reacts to the direction command. A couple of examples:

- V=0
- CHANGE_DIR
- Loco reacts immediately

- V not 0
- Change_dir
- Loco does not react
- Change_v=0 (force a command)
- Loco does not react
- Change_v=0 (manually and waiting for the loco to stop)
- Loco reacts (v=0) and change direction

I have made several tests, sending the v=0 command before or after the change direction… but it seems the command is not considered unless the decoder detects that physically the v=0 (maybe is part of the feedback for the regulated motor).

At some point I thought the problem was similar to one I have with a TAMS LD_w-3 decoder:

With my current configuration in DDX (MM, MMLP, DCC) the change direction command is accepted with a delay of 14 seconds (!) - of course the delay is reduced to 1-2 seconds if I only activate the MM protocol.
There is some good news though: the decoder reacts immediately if I send any command with an update of the velocity… even updating to the same velocity. So, if within the 14 seconds window I send a new velocity command, the decoder changes direction and updates the velocity accordingly.

With a combination of DDW+TrainControler, both decos react perfectly: no delay in the change direction. The merit seems to be on trainControler, that has some kind of speed profile activated by default that sends a number of commands to reduce velocity before the change direction… if I turn it off (no break/acceleration delay by software)… both decos behave in the same way as in rocrail.

I have been playing around and I have done the following tests… of course is not a solution yet.

Modifying the ddx.c file –attached- , it is forced to send the required sequence by the decoders and everything seems to work fine:

Unfortunately the problems described above requires different solutions:
- (The easy one) TAMS LD_W_3: with a simply duplicated message the loco reacts immediately (no delay!)

Code: Select all
case 2:
          status_direc=get_maerklin_direction(addr);
          status_v=get_maerklin_speed(addr);
          if (status_direc!=dir){
          comp_maerklin_2(addr, dir, speed, fn0, fn1, fn2, fn3, fn4);
          }
          comp_maerklin_2(addr, dir, speed, fn0, fn1, fn2, fn3, fn4);
          break;


- (The hard one) 146871: The only way I have found to make the loco react is to implement something like a speed profile:

Code: Select all
 case 2:
          status_direc=get_maerklin_direction(addr);
          status_v=get_maerklin_speed(addr);
          delay_dir=800;
          if (status_direc!=dir){
            while (status_v>0){
              status_v--; //posible error si numeros negativos
              comp_maerklin_2(addr, dir,status_v , fn0, fn1, fn2, fn3, fn4);
              ThreadOp.sleep(delay_dir);
              }
          }
          comp_maerklin_2(addr, dir, speed, fn0, fn1, fn2, fn3, fn4);
          break;


In this way the loco receives progressively commands to stop.
Of course this is not a clean solution. First, because the solution of waiting between commands depends very much on the motor - (800 ms) seems to work with this loco but it should be a more generic solution. Second, because with my limited skills and knowledge in C, I do not know if the sleep command is the best way to stop the processes (I do not want to block rocrail and the rest of locos from receiving new commands).
I can imagine of a simple solution (pseudo-code, not tested):
Code: Select all

case 2:
          status_direc=get_maerklin_direction(addr);
          status_v=get_maerklin_speed(addr);
          speed_profile=propierty_of_loco(addr); /*necessary to store something else in the loco object definition at the xml plan:
         speed_profile<0 -> no speed profile
         speed profile>-1 [0-xxxms]->linear speed profile… reduction of 1 step each xxxms.*/

          if ((status_direc!=dir)&&(speed_profile>-1)){
            if (status_v==0){
                  comp_maerklin_2(addr, dir,status_v , fn0, fn1, fn2, fn3, fn4);
                }//one extra for tams when v=0
            else{
              while (status_v>0){
                status_v--;
                comp_maerklin_2(addr, dir,status_v , fn0, fn1, fn2, fn3, fn4);
                Wait_non_blocking(speed_profile);
              }
            }
          }
          comp_maerklin_2(addr, dir, speed, fn0, fn1, fn2, fn3, fn4);
          break;


In this way, both the TAMS and the 146871 should react.

The first because we are sending the change direction command more than once. Actually, with a speed_profile=0, even if more than one command is sent… the reaction should be immediate.

The second because we are sending the sequence with the reduction of velocity… providing some time to actually stop the loco.

This could be included in the loco dialog box easily with a check box and a text box for the speed_profile parameter. If the check box is not checked, the speed_profile=-1… if it is checked, the speed_profile is whatever is in the text box:

- Normal situation for most locos: check_box unchecked; no matter the content of the text box; speed_profile=-1; no special sequence.
- TAMS: check_box checked; text_box=0; speed_profile=0; special sequence without delay.
- 146871: check_box checked; text_box=XXXms; speed_profile=XXXms; special sequence with the delay needed by each loco (to be empirically found).

Of course, also non linear profiles could be used (wait more between commands with the higher speeds makes sense). But I have just tried the easiest approach.

Other option would be to modify the core of the ddx library, at the locpool.c or Motorola.c files. The above mentioned commands are translated to a number of packets. The cleanest solution would be to modify this translation to the right packages needed by the decoders. Thus, sending just one command – not modifying ddx.c – it would be possible to generate the requested sequence. I think that in order to maximise the compliance with some decoders, the core of the ddx already forces some special sequences…However, I think modifying this part of DDX library is always tricky – it’s easier to break something than to repair it. Even if modifying dxx.c may not be the cleanest solution, it seems to be simpler – and in this case it could be a great advantage.

Could this be something interesting to be included as a new feature of rocrail? It is a simple way to extend the compliance with two more decoders.

PS: I have checked with just MM activated in DDX and the problems are exactly the same in both cases
PS2: I know the easy solution would be to replace the decoders…but it would not be so fun. :D
You do not have the required permissions to view the files attached to this post.
Last edited by mserrano on 08.06.2011, 07:20, edited 1 time in total.
mserrano
 

Postby oscar » 21.09.2010, 23:06

Hi,

Although I did not do the ultra-exhaustive research you did, I had the same problem with one of my Maerklin locos: a speed change is only listened to if v=0.

In my case, the loc was a 29655 starter set loc, a very standard one.

The solution for me, for now, was to use the MM1 protocol for this loc, instead of the MM2 I use for all the others. That makes the direction change behave as expected. In my case at least.

Regards,

Oscar.
oscar
 

Postby mserrano » 22.09.2010, 04:07

Hi,

I also tested MM1. The problem with it is that it just stops the loco... an then of course the change direction is accepted... but the loco does not recover the speed with the new direction.

Furthermore, it only works ith the märklin decoder, and not with the tams one.

Regards,

Manolo
mserrano
 

Postby mserrano » 04.06.2011, 18:06

Finally I have had some time to implement the functionality I was requesting. I am attaching an explanation on what the motivation was, and how it can be used.

Since I am not at all an expert on C, neither on the rocrail code, it has taken me longer than expected. Moreover, there is still a problem with the code – a memory leak – I have not been able to solve. I think it is in the way I am attaching the speedcurve parameters to the loc command (loc.f file)… but I am not sure – any help, correction and suggestion for improvement is very welcome.

Basically I have modified the wrapper description file to include a new property to the loc (speedcurve). Then I have modified the loc.c file to explore if a locomotive has this property and include them in the commands sent to the stations. Finally, in DDX, this parameter is treated in MM locomotives.

The reason to address only MM is basically because DCC decoders use to have an actual speedcurve functionality. In any case, since the information is transmitted to any station, anyone could make use of it to implement the speedcurve as I have made for DDX MM.

Hope this new feature to be of interest. It needs still some refinement for the memory leak.. but hopefully someone could give me a hint on how to solve it, so it can be included in a stable release – if it is of interest of course.
I am attaching the three source code files modified, a plan example and the explanation of the functionality.
You do not have the required permissions to view the files attached to this post.
mserrano
 

SpeedCurve feature

Postby mserrano » 07.06.2011, 22:38

I think I have removed the memory leak thanks to some advice from a friend. I am attaching the new sources.

In any case, the feature has been marked in launchpad as “Won’t fix”
If I understand it right, it means that: it “confirms that a problem exists, but that no work will be done towards fixing it. Perhaps it’s a controversial issue upon which an official decision has been issued, or it’s something that is better addressed in a different way, or fixed in another software component. It is often used in association with release targeting to specify that a bug will not be fixed in that release”.

I suppose the feature has no interest enough, which is fair. If it is going to be addressed elsewhere, please let me know.

Anyway, I would appreciate some extra information if possible. I worked hard to get this solution – with my limited capabilities – and it would be nice to know the reasons to reject the feature.

Thanks in advance,
Manolo

PS: I make available a compiled Windows package based in rev. 2631, just if anyone wants to test it.
http://tren.enmicasa.net/wp-content/upl ... -win32.exe
You do not have the required permissions to view the files attached to this post.
mserrano
 

Postby rjversluis » 08.06.2011, 06:06

Hi Manolo,

there is already support for low cost decoders like Märklin Delta at a higher level like http://wiki.rocrail.net/doku.php?id=loc ... #regulated.

I know that you have put much effort in this issue.

Now days you can buy regulated decoders for less then 15 Euro which will do a much better job on its own.

Sorry, but I'm not keen to have this in the main branch.
Alternatively you can maintain a branch for your self at Lauchpad and merge changes from the main branch in yours.
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 mserrano » 08.06.2011, 07:19

Thanks a lot Rob.

I fully understand your point :D .

Since I am quite far to be a usual programmer, I am not planning to maintain my own branch – I would not even know where to start. Plus, I think it is better to keep just one official branch.

I will compile for my own use this version from time to time. If anyone wants an update, just need to contact me.

Thanks again,
Manolo
mserrano
 


Return to ddx