Plug-IN Delay

[trevor]

I'm having issues with the plug-in I am writing. I send a command to toggle a control switch but it seems to take a long time to set.

Here is my trace. I send a command to set the controller at 42619.3779997062 seconds and it sends me a message it was actually set at 42619.557000068 seconds.
That is a 0.179 second difference.... Might not seem much.. but in the mean time the engine has passed the brake zone and is entering the stop point... all too late.
Train ends up crashing into the points at higher sim rates.. 

I realize my event handler is doing a bunch of stuff in between. 
Is there some sort of sequencing I should know about that delays the execution of the command I sent?
When the controller is actually set, the EV seems to take care of it in the expected time scales...

What's going on?

Regards

Trevor.


 

<< 42619.3489997881 46484 150;ER_20_Eurorunner_Siemens-1;Join2_Brake_Section_2;0;Track1_Section_2;0
Train Train_3 entered brake section Section_2 @ Join 2
   > 42619.3779997062 453;Switch_Entered_Brake_Section_3;1

42619.3800000474 Switch_Requesting_3-1
42619.3800000474 Switch_Stop_4-1
42619.3829999305 Switch_Entered_Stop_Section_4-0
42619.3840001011 Navigator_Start-1
150;Diesel_locomotive_V60_blue_1;Join2_Section_3A;0;Join2_Stop_Section_3A;0
<< 42619.3840001011 46492 150;Diesel_locomotive_V60_blue_1;Join2_Section_3A;0;Join2_Stop_Section_3A;0

42619.3850002717 Switch_Brake_4-0
42619.3850002717 Switch_Cruise_4-0
42619.3850002717 Navigator_Do_Checks-1
150;Adler-Lok-1;Join1_Stop_Section_1C;0;Join1_Section_1C;0
<<  42619.3850002717 46507 150;Adler-Lok-1;Join1_Stop_Section_1C;0;Join1_Section_1C;0

150;SBB_RAe_TEE_At-1;Track1_Section_5;0;Track2_Section_5;0
42619.3859998137 Navigator_Do_Checks-0
42619.3859998137 Switch_Request_Refused_4-1
42619.3859998137 Navigator_Start-0
42619.3869999843 Section_1C-0
42619.3880001549 Switch_Requesting_4-0
42619.3880001549 Switch_Request_Refused_4-0
<< 42619.3889996968 46545 151;BR_50_001_1;Join2_Section_6A;0;PS5-3;0
Train Train_2 left section Section_6A @ Join 2
   > 42619.4119998487 453;Switch_Reserved_Section_6A;0
   > 42619.4449998206 453;Section_6A;1

150;SBB_RAe_TEE_At-1;Join1_Brake_Section_5;0;Track1_Section_5;0
<< 42619.4459999911 46546 150;SBB_RAe_TEE_At-1;Join1_Brake_Section_5;0;Track1_Section_5;0
Train Train_5 entered brake section Section_5 @ Join 1
   > 42619.478999963 453;Switch_Entered_Brake_Section_5;1

<< 42619.4800001336 46547 151;SBB_RAe_TEE_At-1;Join2_Section_5;0;Join2_Stop_Section_5;0
Train Train_5 cleared entry Section_5 @ Join 2
   > 42619.5119999349 62;PS6-1.Locked;0
   > 42619.5130001055 453;Switch_Locked_PS6_PP1;0
   > 42619.5449999068 453;Switch_Cleared_Entry_5;1

42619.5460000774 Switch_Requesting_4-1
42619.547000248 Navigator_Start-1
42619.5479997899 Navigator_Start-0
42619.5479997899 Navigator_Start-0
42619.5479997899 Switch_Entered_Section_1-1
42619.5510003017 Switch_Navigating_1-1
42619.5510003017 Switch_Entered_Section_1-0
42619.5510003017 Navigator_Start-1
42619.5519998437 Switch_Request_Granted_1-0
42619.5519998437 Switch_Navigating_1-0
42619.5519998437 Switch_Navigating_1-0
42619.5519998437 Navigator_Start-0
42619.5519998437 Switch_Reserved_Section_6B-0
42619.5530000143 Section_6B-1
42619.5530000143 Switch_Speed_Limit_Changed_1-1
42619.5530000143 Switch_Speed_Limit_Changed_1-1
42619.5540001849 Switch_Locked_PS4_PP1-0
150;Adler-Lok-1;Join1_Brake_Section_1C;0;Join1_Stop_Section_1C;0
<< 42619.5540001849 46589 150;Adler-Lok-1;Join1_Brake_Section_1C;0;Join1_Stop_Section_1C;0

150;BR_50_001_1;Track2_Section_7;0;Join1_Brake_Section_7;0
42619.5549997268 Navigator_Start-1
42619.5559998974 Switch_Cleared_Entry_3-1
42619.5559998974 Navigator_Start-0
42619.5559998974 Switch_Cleared_Entry_3-0
42619.557000068 Switch_Entered_Brake_Section_3-1

[Curt84328]

What are you writing the plug-in in?   Suggest you talk to Easy and ask for a bit of help/

 

[EASY]

Hi trevor,

... as far as i know the interface is also "synchronisized" with the frame rate (like the event manager).
An exception is the "group command" which runs in a "asynchron state"... see wiki "Gruppenkommando" (in German)... but there are somme "special features" with the answer of a command...

EASY   

[trevor]

18 hours ago, EASY said:

Hi trevor,

... as far as i know the interface is also "synchronisized" with the frame rate (like the event manager).
An exception is the "group command" which runs in a "asynchron state"... see wiki "Gruppenkommando" (in German)... but there are somme "special features" with the answer of a command...

EASY   

Yes I know of that Easy, but I am only sending one command... and it gets responded to immediately but not acted upon till much later.

 

[EASY]

Hi trevor,

... what do you want to do?
Can you give an example (3D Train Studio project and programm)?

EASY

[trevor]

I am trying to write a plug-in train navigator and control program.... my end seems to be fast enough to run the layout, but the delays at the MBS end make it impractical. Even just sending a train STOP immediate takes far too long to be executed at the MBS end. I can do it with more control in the EV handler, but I have another string manipulation issue with that end..... sigh. I keep hitting walls.

 

 

Bearbeitet 16. Oktober 2016 von trevor

[Neo]

Hi Trevor,

the command interface can process thousands of commands per seconds, but as EASY said, the application is bound to the FPS of your current layout. If you have 60 FPS, commands should be processed within 1/60 second. Can you provide a small sample which demonstrates the delay?

Kind regards,

Neo

[trevor]

Neo, it depends on your definition of processed.

If I send a command to set a control switch that the EV uses to stop a train, the command itself IS responded to by the plug-in interface in the order of magnitude of time you mention... however, if I watch for the report through the interface of when the control switch actually gets toggled, that happens MUCH MUCH later.

Now that could just be a reporting thing...but the events that get driven in the EV as a result of that switch being toggled all get reported through the channel as I would expect them to be. That is, in the order and speeds that I would expect.

So.. from the resulting behaviour, it seems like either...

1. the command is being accepted by the plug-in interface and somehow queued up till after other events, procedures, etc. are completed. or
2. The switch is being set immediately, but that change is not recognized till much later. Presumably for the same reasons.

Item 2 is hard to believe though, since the actions the EV does in response to the switch being set include further switch changes which all seem to be recognized and handled almost immediately. Furthermore.. I can tell from the above debug log that the EV handled two or more NAVIGATOR -START cycles between when I sent the command and when the switch change was registered and reported. Those navigator functions are timer driven so there is a long time in there, with some dead time too. Now that particular set of EV code is pretty lengthy so I removed it in the next revision of the layout.. but it made ZERO difference.

Now I will grant you my EV is still doing quite a lot and numerous variables and switches are changing all the time... but since I can not guarantee whomever decides to  use my pug-in wont do the same thing... I need to figure out if there is something else strange going on before I give up.

 

 

 

 

[trevor]

Here is my "plug-in" source and the latest associated layout.

You need to load and run the plug-in first, either as a plug in or better, directly in vb.net.
Then load the layout.

If the VB is running it will recognize the project has been loaded and read the contents into structures then begin monitoring and trying to control the two trains.

Un-pause the layout, the trains should travel around the figure 8 in different directions holding at appropriate points to let the other pass.

Even at low speed simulation you will see the trains often stop past the underlying STOP tracks or the points will not be positioned in time.

At higher speeds.... meh... it all goes nuts.

It will quickly get messed up either way, so u need to reload the layout a lot.

MBS-Controller.zip

Test_35.mbp

[trevor]

BTW: We really need  pause / run simulation commands....

 

[EASY]

Hi trevor,

Zitat

vor 5 Stunden schrieb trevor:

We really need  pause / run simulation commands....

... this is not clearly written in the wiki (-> "activate / deaktivate Animation in studio"). This (also) pause / run simulation.

EASY

Bearbeitet 17. Oktober 2016 von EASY

[trevor]

1 minute ago, EASY said:

Hi trevor,

... this is not clearly written in the wiki (-> "activate / deaktivate Animation in studio").

EASY

that's what I thought too... but according to NEW that just switches from Edit View to Simulation view.... the little train icon up top/

[EASY]

Hi trevor,

the simulation in 3D TS runs in Edit view () and in Simulation view () and you can pause() / run () simulation in both views.

EASY

[trevor]

3 minutes ago, EASY said:

Hi trevor,

the simulation in 3D TS runs in Edit view () and in Simulation view () and you can pause() / run () simulation in both views.

EASY

sigh... so it does... confusing.... nvm

[trevor]

HMM... turns out I had an issue with the cross threading on the event receiver that was causing the events to pile up in the buffer..

Thanks to EASY !

When I implemented the pause, I noticed the debug window kept churning away for a while after I send the off command, even though the sim had stopped. 

A little tweaking and asyncing stuff and my trains are now flying round at 4X sim... well 2 of them are... will check out all 5 later.

I have a feeling I may need to do some throttling with more stuff moving around.