Reversing bug

[TekyTeky]

There seems to be a bug when a train reverses in Random mode or non One-way mode.
Train is asked to go from A to B via C
Train starts at A and moves along 1 - 2 & 3 to C
Train reverses and then stops at red arrow, between the red and blue physical sensor and gives the Red Error.
It does not proceed to B.
I have tried with separate Prior sensors D and E but made no difference.
When set to Random it works for a while then stops in that position.
I have tried to change colors, add remove sensors but nothing works.
I tried to go from B to A via C and the same happens.
It is fine in One-way mode.

[Novakasa]

This error means that the train sees a different color than it is expecting. I see you have set your sensor colors tto red and blue colors, does that reflect the real colors of the markers or are you still using orange markers?

If you set all marker colors to "None" the real color shouldn't matter and hopefully the issue should go away?

[Novakasa]

But there might indeed be an issue with this when not setting the colors to "None", I haven't tested this case in a long while now.

[TekyTeky]

I removed the Orange the colors are only Blue or Red now.

[Novakasa]

I just tested this same situation, and I currently can't reproduce the issue, even with the same color configuration as you.

Can you check that after the train arrives in C that it never actually reaches the red marker with its sensor? It is supposed to change direction without reaching the red marker, and thus the next marker it expects is the blue marker again.

You may need to make your block bigger or add the prior sensor more distant to the block, so the train is slower when it arrives at the blue marker, and doesn't overshoot until the red marker.

[TekyTeky]

It reaches the Red C from yellow arrow 3, then reverses and stops immediately at the Red down arrow, before getting to Blue, so it is part way through a block.
I will try again tomorrow with the colors set to None.

[Novakasa]

The starting position and facing direction of the train in your screenshot is correct? According to your screenshot, when going from A to C the train should be going backwards, is that the case for your physical train as well? The black circle on each train should always represent where the sensor of the train is.

[Novakasa]

Is the route from A to C to B one continuous route or do you tell the train separately with one route to first go to C, and then with another route to go to B?

If the full action is one continuous route, the train should actually already reverse after the sensor sees the blue marker (because the train is already driving backwards) and then go at normal speed forward toward B (the sensor should never reach C).

If the full action is two separate "instructions" the train sensor still never should reach C, the train is supposed to reverse already at the blue marker, then go forward slowly until the sensor passes the blue marker again, then stop. Then you should be able to start the train toward B.

[Novakasa]

Also, the initial position of a train should always satisfy the condition that the sensor should be in front of the marker. If in brickrail the train occupies a block, looking to the left, then in your layout the train sensor needs to be to the left of the left marker in your layout.

I just added a new section to the wiki explaining what brickrail expects the initial positions of the trains to be:
https://github.com/Novakasa/brickrail/wiki/6-Operate-your-physical-layout#validate-train-positions

[Novakasa]

As I can't reproduce the issue, these are the two things that might cause the error for you:

• If your train is indeed going backwards from A to C, the sensor should never "see" the red marker at C, because the train should already reverse at the blue marker. So in that case, the train might have "overshot" the block and sees the red marker at C because it couldn't stop fast enough. In this case, a prior sensor properly setup should fix the issue because the train will arive at the blue marker quite slowly.

• If your train is going forwards from A to C, your setup doesn't reflect how brickrail sees the situation according to your screenshot. In your screenshot, the sensor is initially on the right side of train, so you should make sure that your train is also at the correct position. However, thinking about this scenario this would already cause your train to go in the completely wrong direction. So if usually your train usually does do the right thing, you might have also the opposite motor direction than brickrail expects? I am guessing this would cause a lot more problems though. But an easy test whether that is your problem is just to check whether your initial position for the train corresponds to the way it is written here and see if your train goes in the correct direction: https://github.com/Novakasa/brickrail/wiki/6-Operate-your-physical-layout#validate-train-positions
  The default assumption for brickrail for forward movement is the same as when building a normal LEGO City train according to the instructions.

If both of these don't seem to cause your issue, I would be interested in a video to really try to narrow down what is going on.

[Novakasa]

Looking closely at your screenshot it looks like there are two sensor on top of each other? It seems like there is a red and a blue marker on the same spot. Did you edit the marker color in the image? Or there might be a bug with setting up markers. In that case, you might be able to fix it by deleting the block and the tracks and setting up that part of the layout again. Select elements and press delete on the keybard to remove them. removing blocks only works if there is no train inside, in edit mode you can right click drag the train to a different block to teleport it.

[TekyTeky]

Yes I changed the pic after I had changed the layout.
I tried using all red or all blue for a block, then realised you used 2 different colors for a block in your video... but neither worked.
I figured out how to delete blocks and tried it also.
I may try longer blocks, at the moment I am using the dining table.

It's 9:30pm, so time for bed ;-)

[TekyTeky]

Ok.. I did another test which is more simple. But will do a video later. It kind of worked so maybe needs a Prior .. where would I put it?

I removed some track to force reverse
I removed the Prior blue sensor both physical and virtual
Renamed the 2 color sensors to None in the starting bottom block
The train is facing fwd and is at the bottom block forward of the sensor as you describe
I make it go to the broken line block in the middle and stop, so train is at B and goes just beyond as you describe
Then I make it go back to its starting place.

It goes backwards and goes to C, past the end sensor then creeps forward but doesn't go past it again see below screenshots of where it finished.
It doesn't go to the starting place.
When I retry and move it then it fails.

When I tried in Virtual, it goes to the start, not to C then to the start.

This is where it finished.. behind where it started.

The orange lego tool shows where the sensor is and the blue plate where the sensor is... it looks like a blue plate under the train but it is the lego sensor shining down.

So this is the starting place:

This is where it goes to

[Novakasa]

Thanks for the detailed description, this definitely helps me a bit.

Your blocks are really small, do you have more track at hand to make the blocks longer and increase the distance between markers to as far as you can?
Currently my theory still is that the train doesn't have enough space for turning around after seeing the blue marker, it then sees the red marker and thinks it is the blue marker because it just expects color "None", and then stops.

You can also try to increase the deceleration of the train. In ble_server-windows/hub_programs/smart_train.py you can modify line 35:

_MOTOR_DEC          = const(90)

and change 90 to something like 150. Then restart brickrail and the trains should brake much faster, hopefully eliminating the problem.

You could also try to decrease _MOTOR_CRUISE_SPEED in line 37 to something like 60 and see if that helps.

Prior sensors could also help if slow deceleration is the problem. I would add the prior sensors right behind the switches, but make sure that the train can properly see them because of the curve, maybe make the marker 3-4 studs wide along the inner side of the curve. Also make sure that if you set the prior sensor for one "direction" of the block, the according prior sensor should be before this block. So if you select the "+" and "-" logical blocks, they need a different placement for the prior sensor, always before the train would arrive in this +/- block. Does that make sense?

If extending the distance between markers or prior sensors don't help, it would also help if you copy the contents of the terminal window, that would help me a bit. (I definitely should make it create log files in the future). Also a video would help a lot as well.

[TekyTeky]

Ok, I will try a few things, I am limited with track, but placed a Bricklink order today for 40. Tues is a public holiday here so I can try the changes then.. but it is pretty great even in forward mode.

[Novakasa]

I think already with the track you have you could just try moving the markers farther away

[TekyTeky]

Good news... mostly
I extended the track and Blocks/Sensors and added Prior's.. but still wasn't clear from your post where they should be... check out the pic as to where I have them placed.
It seemed better but on reverse it still got stuck sometimes.

I made the code changes and that seems to have resolved it for random and reverse.
As a side note it is good to know where the speed is set in which .py file, as when the batteries are low the Slow is too slow and when the batteries are new the Fast is too fast, so I changed them a bit.

The thing that is strange is when removing a Prior and saving the layout, the prior kept coming back.. weird but not major.

But all in all a great day of testing. :-)

The Prior on the bottom right just won't delete.

When I forget to delete it then weird things happen to the reverse actions and the train has the dot in the middle of a block instead of end and often goes the wrong way.

[Novakasa]

Thanks for the report! Yeah then indeed the problem seemed to be that the train just couldn't stop fast enough. I never tested with these tight blocks, and especially with trains reversing without prior sensors, so in the future I should probably add configurable speeds and deceleration in the GUI to make very small layouts possible.

For correct placement of the prior sensors, I just now added some screenshots to the wiki to hopefully clarify what I mean:
https://github.com/Novakasa/brickrail/wiki/3-Create-a-virtual-layout#prior-sensors

Regarding the deletion bug, I'm pretty sure I know what is going on, so I will be able to fix that pretty quickly. Thanks for the report!

[TekyTeky]

Ok, thanks!
It would be good if you could fix that bug as a priority as I have to create a new layout each time if the Prior is in the wrong place.. and others may get confused too.

[Novakasa]

It's already fixed in the master branch, you can get a build here: https://github.com/Novakasa/brickrail/actions/runs/4797652253 (scroll down to "artifacts")

After a bit more testing I will then do another alpha release soon

[TekyTeky]

Thanks a lot for that. I'll play around tomorrow.

[TekyTeky]

I increased the track length but had to reduce the cruise speed as it over ran all the sensors.. but that's fine.. I prefer slower.

But one thing that happened last night, I was using the normal drag and drop to move the train, in both directions it went into reverse a few times, but then seems to get stuck in reverse.
EG I moved it back to my normal starting place and when I dragged it to the next block (fwd) it went backwards.
I ended up clicking stop and disconnecting it and re connecting.
Today I will try using Random... this is what the track looks like, I have only added the Priors now.

Start is where the train was.. looking normal with the front facing left and should have gone to Finish, but went right instead and got confused with the sensor collars.

[Novakasa]

Was that with the more recent version I linked here ? In this version I added the possibility to invert the motor polarity, but that wasn't tested that much. I am planning to revisit that now that I have an approach to store configuration on the hubs dynamically.

Unfortunately I don't have a layout at home currently, so my testing is limited to the setup seen in the "minimal guide" video on youtube with just 2 hubs, 2 motors and one sensor (and no trains or tracks).

[TekyTeky]

It was from the previous version, and is the same in the new one today.
It seems that it goes fwd, but sees the Prior and stops, I clear the error and then it always goes backwards, I have to restart the app.
I removed the prior and it does the same going to the next Block, gets the marker error and then runs in reverse.
If I invert the motor everything is ok.
Have I added the train incorrectly.?
this is the train:.. it moves fwd and gets the marker error.

I removed the first prior . When it goes here it also gets the marker error.

[Novakasa]

There might be something wrong with polarity when a error happens. What is the error displayed when it stops at the prior?

I'll take a look at this more closely over the weekend.

[TekyTeky]

It is the same error, see below...

Once you invert the motor it all works ok.. even the initial prior is ok.
I thought removing that Prior would make a difference, but it doesn't.

[TekyTeky]

The other thing that has happened is that the Random generator gets stuck.
e.g. if it is on the top left block and I hit random it will go to the top right, and back and forth 5 times or so... then maybe top right to middle left, then between middle left and middle right 5 times etc.
This is kind of minor for me but would affect you more with your layout.

[TekyTeky]

OK... so something weird has happened... for about 5 consecutive times yesterday the reversing issue happened.
This morning it is all ok. I did start the first time by using the Run Train command to move the train, then did my usual moves and it didn't fail.
So, I restarted 2 more times, without using Run first and it worked... weird... nothing worse than an intermittent bug you can't replicate.

Any Ideas?

[TekyTeky]

I have added another train, risky I know, and now the Random works better... it's great to see them go around and stop and start.. BAP does that also but not as reliably. Having a timetable would be great. ;-)

I still haven't had the issue with reversing again, maybe the hub was a bit weird.

[TekyTeky]

Just had the issue again... there were issues again with connection timeout with 4 hubs. Then a derailment of the green train... then the reversing issue... it sees a Prior (any Prior) and then goes into reverse. I might swap the hub. If I swap it and call the new replacement the same name will that be ok?

[TekyTeky]

I deleted the Green train and re-added it and it's ok again... reversing stopped. I think this is the best and fastest workaround, the train doesn't even need to be disconnected. Weird!

But it seems, like switches, once you add a train to a layout then it must always be on or the Control complains. They are all Hubs I guess so act the same.
Probably need to have different layouts for different connected hubs.

[TekyTeky]

It seems to do a lot of polling for battery and current.. often many lines in the terminal and seems to cause it to stop some things.

[Novakasa]

The timeout thing is definitely more likely when you have more hubs, since the connection will be slowed down with multiple hubs. (pybricks/support#1009)

I guess I'll increase the timeout time again

[TekyTeky]

I have decided to start from Scratch.
I have created a template layout with no Hubs... so I can then use it for any future tests and add or remove Hubs.... easy.
I have a newer Hub for the Green Train and am in the process of flashing it with your Pybricks. I had an accident and dropped the train so have to rebuild it.
Hopefully doing all this may kill off some gremlins.
I think maybe more restarts of the PC may help too. I notice with BAP that it helps. Like most SW, when in doubt reboot the PC. Esp with BLE.

[Novakasa]

For the issue with reversing after issues with prior:

It seems to be an annoying bug because it can't be replicated consistently, but could you try to give me a step-by-step (also with pictures/screenshots of what orientations the trains are, physical and virtual) of how it leads to the reversing bug? Please also send me the layout file for a layout that had the issue. A video would help a lot as well.

I think the reversing itself is probably quite easy to fix, I will have to have absolute direction instructions instead of just relative "flip heading" as I do now. They seem to get desynced when unexpected stops happen.

But what is more difficult for me is understanding why the issue with a prior (stopping train with marker error) happens in the first place.

Like I said before, I unfortunately never really tested a real layout with reversing trains (always had "only forward" enabled, so disabling "only forward" currently should be considered experimental. Your tests however help a lot, since I currently can't setup a layout.

[TekyTeky]

Yep, will do.
I thought it was all fixed with the new layout and Green train hub then while doing a normal move, the red train just stopped over a switch... very weird then when it came back it was in reverse.
As you say as it is random, I can't force a replication.

[Novakasa]

One thing that I noticed on your layout pictures is that you were using brown tile as sleepers. I never tested my layout with brown decorations, so there might be a possibility that these colors trigger a false marker detection. You could try removing the brown sleepers to see if that causes the problems. If it turns out that was the problem, for that reason I added the "chroma threshold" setting for trains in the recent versions. If you increase that to maybe 4000, it might not get triggered erroneously for the brown sleepers anymore.

[Novakasa]

I just changed the motor invert setting to a new system on master, so it might be worth testing again if your train still goes the wrong direction after the issue happens.
Edit: with increased timeout time: https://github.com/Novakasa/brickrail/actions/runs/4838084957

[Novakasa]

The newest master build shouldn't need timeout finetuning anymore:
https://github.com/Novakasa/brickrail/actions/runs/4838220103

[TekyTeky]

Ok, will check all these tomorrow.. thanks 😊

[TekyTeky]

Ok, it was going really well then, the app crashed while on a Random run with 2 trains... the Green train was going from top left block to top right and physically it got there, but on the app it got to the same switch that aused an issue last time (top left) then the system crashed and the screen closed. I have attached the terminal output txt

CWINDOWSSYSTEM32CMD.exe.txt

[TekyTeky]

Been running for 15 mins on Random and no issues... the failure above could have been a one off?

[TekyTeky]

Ok, now another 15 mins on Random... with 3 trains... until batteries ran out.
I can see why you have yours so complex.... it is mesmerizing to watch.
What's next.. lol

[Novakasa]

Ok, it was going really well then, the app crashed while on a Random run with 2 trains...

Unfortunately that log doesn't have any particular info what might have gone wrong, it's probably on the GUI side. For things like this I should probably think about creating log files for gui internal state so I can know what is going on... So many things to do lol

Ok, now another 15 mins on Random... with 3 trains... until batteries ran out.
I can see why you have yours so complex.... it is mesmerizing to watch.

Nice! Was that with trains also reversing? Did you use prior sensors?

[TekyTeky]

Yes reverse and Priors. I assigned a Color to them.
So I'm pretty impressed, it's exciting to see.

[TekyTeky]

I've had a few reversing issues with the Switch version, so am going to redo the layout and re add the hubs.
Do I need to redo the FW on the hubs, only 1 is 73, the others are the original?

[TekyTeky]

It seems that every few loads it needs a clean install of the hubs etc.. eg re add the hubs as new.
I just couldn't get the Switch version to run after I had played with the Switch only option... trains always got the marker error.
Now it all runs ok. It runs better on Random.
It seems sometimes when you drag a train it doesn't go directly to the right end of a block.. then it often gets the error.
I know you can move it from either end of the block, Alpha one was ok, but now it seems to accumulate issues.

Sorry for being so vague... not very Teky eh?
I will do some better analysis tomorrow.

[Novakasa]

I am currently working on adding automatic log files, so in the future hopefully you can send me some logs when the issue appears.

[Novakasa]

I might have a theory what might be going wrong when you have the reversing bug, partly, at least.

Internally, every train has a "facing" value which is 1 if the train is going forwards, and -1 if it is going backwards.

A train that has the facing value 1 has the black marker and the Arrow on the same side, like this:

A train that has the facing value -1 has the black marker and Arrow on opposite sides, like this:

Normally, when making a train go from block to block, at the end, the train always wants to end up with a facing value of 1. This is why, after reversing into a block, it will at the end slowly go forwards again to be at the correct "side" of the marker.

However, internally Brickrail also can keep track of stationary trains with facing value of -1, but I made the decision not to make this really obvious to the user.

My theory is that, once you have a "marker error", the trains can end up stationary with a facing value of -1. However, for facing value -1, the correct position of the train is such that the sensor is on the opposite side of the marker, which is opposite of what I described in the wiki.

So, when you have for some reason ended up in a state where the train ends up with facing -1, the train does behave a bit differently than what you are used to (because it will try to stay with facing -1). And because you might adjust the train positions as described in the wiki, the trains are not in the correct position for facing -1, leading to further marker errors.

I did observe that trains can be stuck in facing -1 when a error stops the trains. However, it is not yet clear how your layout produces the initial marker error in the first place.

So I think for now I will try to make sure that trains will never be stuck with facing -1, and users should always expect the train positions to be as described in the wiki.

Also, for you to test, there is a "hidden" feature to switch the facing value of a train. While dragging a train (with right click) you can left click to flip the facing value. This works both in edit as well as run trains mode. So technically, if a marker error happens and you observe that your train has facing -1 (as seen in the second screenshot above), you can use this in edit mode to switch the train facing to +1 again.

[Novakasa]

In newest master build I now added better logs for internal state for trains and routes. Please use master build in case the issue comes up.
Then, the next time you see that the issue comes up, please head to %APPDATA%\Roaming\Godot\app_userdata\brickrail-gui\logs to find the newest log file and post it along with a description what exactly the virtual layout trains and the physical lego trains were doing.

[TekyTeky]

Ah, this sounds exactly like what is happening. But, as you say, what is causing the marker errors. I still think it is the speeds and length of the blocks.
When I re-added the hubs again the speeds went back to default values and the trains over ran the sensors and Priors immediately.
And once it fails once it usually keeps failing.
I changed the deceleration to 150 and cruise to 55 (just varies depending on battery level) otherwise one could over shoot the corner, speaking from experience, Green train needed a rebuild anyway 😳 I'll play around some more at lunchtime with block lengths, I WFH, so can then test more tonight and post the logs etc.

[Novakasa]

Also the "stop routes" or "emergency stop" buttons can lead to a train left in facing -1. I am thinking of just adding a section to the wiki to make users aware of this state so they can position the trains correctly if the trains were in this state.

[TekyTeky]

Marker error.
I updated to the latest Master.
Opened the new file from yesterday.
All trains were pointing correctly.. little arrow at the front.
I dragged the City train (FW73) from A to B, and it physically stopped with the error just past the Prior C.

brickrail.log

[TekyTeky]

From the logs it does indeed look like the train only saw a blue marker, nothing else. If the train stopped after the red marker, this can only mean that maybe the sensor measured the wrong color, or that the train started on or before the blue marker (the proper position would have been after the blue marker)

Yeah, hence my comeback, I thought that may have been the case... sorry to waste your time.

BTW your prior marker is very close to the block, If you put it a bit further from the blocks, the trains should be able to stop more quickly once they are in the block.

While the track is about 3 mt long on that side it has 2 switches and the 3 trains I have with sensors some have fixes carriages... as they have wired internal lights from the locomotive. I add an older PF hub in the locomotive to power lights separately.
So, space is limited with the back of the train and the switch. A reversing train from the right siding reversed into the back of a train on the top right block... so I had to move the sensors.

Have you experienced more issues when the blinds aren't closed?

No, it's probably more about sun on the Lego and me seeing where the sensors are in the sunlight.

In my testing I have never seen issues due to ambient lighting. The sensor mostly should use the reflection of its own light to measure the colors.

It was when you said about the Reddish-brown plates on the track. But I haven't seen it happen... but in my layout I have 1stud round plates as ballast in the track and also plants... so they would all have to be removed.

[Novakasa]

So, space is limited with the back of the train and the switch. A reversing train from the right siding reversed into the back of a train on the top right block... so I had to move the sensors.

Yes, but I meant mostly the prior "C" is quite close, I think I would move it to after the curve (if there is a straight section after 90 degrees)

[Novakasa]

But of course, it all depends on what speeds and decelerations you use, so might be fine normally.

[TekyTeky]

ah, I hadn't thought about going that far away. Ok will try.
Is there any relationship with what's on the virtual layout and what is actual, regarding spacing of sensor bricks.

[Novakasa]

Is there any relationship with what's on the virtual layout and what is actual, regarding spacing of sensor bricks.

No, not at all. The layout is only a "schematic"

ah, I hadn't thought about going that far away. Ok will try.
This will probably enable you to use slower deceleration again, if you want, and if you increase the distance of all your priors.

[TekyTeky]

Zipped the layout .brl file.
Layout - 6 Blocks - 2 Ends - Switch - Copy.zip

[TekyTeky]

Well, my friend, (if I may) I have had several sessions today and all were successful.
All hubs are running FW 2730.
Connecting and disconnecting is really fast.
No errors.
All Hubs disconnected correctly, then powered off.
Lots of fun.
The great thing, when manually moving trains, they will move to the next block but if they are then stuck, no forward free block, I clear than block and they continue. Like real life.

I have added track plates on the outside so I can see where the first sensor is. So, if during some reversing I see that a train has stopped on the wrong side then I do the secret switcheroo trick and it then relocates to the correct side of the sensor.... which is very cool.

So, what's next boss...lol

[Novakasa]

That's great to hear! Really glad to see that Brickrail seems to work as it should with the distributed versions (not guaranteed when for years you only tested it on developer environment for years)

So, what's next boss...lol

Since I've been spending a lot of time on this project the past weeks, I'll probably take a break from going as fast. After a bit more testing on my part, I might make another alpha release with all the changes from the past 2 weeks.

[TekyTeky]

Ok, cool. I totally understand, I will watch my emails for your updates, as I have been for 2 years.
Yell out if you also want some Mac testing too.
And please don't forget the Level Crossings and Timetables but I realise they are a little way off :-)

I am really grateful of your promptness in fixing the bugs and request I have made.

[Novakasa]

I'll probably take a break from going as fast.

I did say that, however I did just push a few more commits. I added the concept of train "home positions". In the future there will be a button to tell every train to go to their home position again, for now it is available only for each train separately.

But even in case trains don't go back to their home positions after a session, the positions are still saved as a local setting (not in the layout .brl file) so next time you start brickrail and load the same layout you should not need to readjust the train positions again.

I also added "reversing behavior" for trains. This replaces the "Only forward" setting. It now has a new "reversing discouraged" option which makes a train only go reverse if there is no other route available.

The next time you run your trains, it would be great if you could test the new master version!

[TekyTeky]

Yes, I saw the few extra items.
So the setup of a Home would be saved when you save the layout.. as it is now? But not in the layout.py? Trains are in the positions you saved it, which by the way, you should save them with arrows pointing the right way.
It would be good if the whole train was the color of what you have picked. Sometime the little dot is hard to define.

The next time you run your trains, it would be great if you could test the new master version!

OK, will do, I don't work Friday's so can do it this morning.

[TekyTeky]

OMG.. the home function is sooo great. Same as the Reversing setting.
I had to printout my home layout as I would never remember where they were set to and worse with more trains.

Maybe a pop-out or link to a png file so you can see. But it was great to see it in action.

(I revisited and realised that in Edit mode you can tell a train to go home and it just appears Home. So you can do that when you start up.

The reversing option was great too, I set it to Discouraged and the train took the long way from bottom right to top right and when it was set to Allowed it reversed to it... perfect.

[TekyTeky]

Also, on your layout, do you use R40 or R56 curves and switches for the top layer loop with the Y switch and the others? I really like it and want to order something like it.

[Novakasa]

I only use R40 curves on that layout. Here's the bluebrick file with which I planned that layout:
layers_schattenbahnhof_umkehren_final.zip
(you probably need to zoom out to see where the layout is)

[TekyTeky]

Thanks, that's really helpful, and interesting.
So, why not use the same Shift Click to move the layout on Brickrail, the same as BlueBrick? It would be an easy option, but still have the option to reverse the mouse buttons, although I must admit I am getting more used to it. But moving back to BAP I was using the wrong buttons.

[TekyTeky]

I'm not sure if this was the correct discussion.
But the reversing issue is while running Random, and something happens causing an error.
I replaced and added Yellow Priors to all blocks. But one registered Blue when it was expecting Yellow seems as it was on a siding it wasn't big enough, now it sees yellow.
So, the train was facing the wrong way when the error occurred and is now stuck in reverse.
I will do more tests in Random then selecting Stop Routes. Then restarting and see what happens to trains facing the other way.

Second time there was an impasse on Random, so nothing moved, I've not seen it before. So I selected Stop routes, but some seemed to still move so I hit Emergency stop. One train was going backwards, it didn't recover and got stuck in reverse.
I'm sure you will see this on your layout. I just disconnected and restarted the hub. Not something you would like to do on your lower layer though.

[TekyTeky]

Also, weirdly, I've had 2 HeadOn collisions while in Random mode.
To be honest I've tried all day to get Random to run successfully, there are still issues with plate colors, which could be me, I added full width colors when a train has a marker error. I also increased the chroma to 4000 as you suggested, but I still had issues after that.
But I haven't had issues when not in Random Mode. eg normal running seems too be fine.

Going from A to B and C to B, both trains going forward, crashed at B.
The first time was kinda funny, but the second was concerning.

I have attached logs and Layout.
Head On Logs.zip
Layout-HeadOn.zip

[TekyTeky]

As most of my trains have been setup specific for BAP and going fwd only I've decided purchased a new City Express Passenger Train 60337 I get tomorrow. (on sale at Amazon for 107euro)
I think they sometimes get stuck and don't run well backwards. My City train is the other newest. Plus, when you do the station timetable, I can use these 2 passenger trains for it.

[Novakasa]

Thanks for the logs, I'll have a look. Unfortunately I won't have a lot of time the next few days for it, but if I can spot an issue that is easily fixed, I might be able to do it.

[TekyTeky]

All good.. I'm having lots of fun intermixing both systems... to be honest once using Brickrail it is hard to go back to BAP. Once you get programable routes (timetables) that will be the clincher. As that's the pro for BAP.

[TekyTeky]

This maybe related to the above I'm not sure.
I changed the Yellow Priors back to Red as I was getting too many errors. (maybe I should just have Blue sensors everywhere.)
But this error I can replicate at anytime.. so that should help.
C is the Prior to B (I have never had any issues going fwd. I have also removed and re added, just in case)
Train starts at A and goes fwd to D via B & C... all good.
Then select the train to go back from C to A or to B (going in reverse)
Each time it fails as it goes past C and gets a Marker error saying Expecting Blue, but measured Red. Stops at the X.

I did this about 3 times.
Logs and Layout file attached.

ErrorLogs_Reverse_Prior.zip

[TekyTeky]

Sorry to hit you up for more errors.... all related to the above.
I changed the offending red prior to blue, but no change, increased Chroma to 5000 also, then changed the prior to none for color.
But it seems to be this reverse loop, on the above pic.
If I tell it to go from D to B, but arrive with the front dot facing towards A.. then it goes around the loop to face the right way, but then as it goes into B past the NONE Prior (which is Blue) it gets an error on the B block when it hits the blue sensor, as it is going forward and has already gone past a Blue, it is expecting the Red sensor of the block... and I get the error sees Blue expecting Red.
THEN, it is stuck in reverse after I clear the error. See attached logs for more light reading ;-)

ReverseLoop_Issue_Logs.zip

[Novakasa]

If you still have the log from the session where you took the video, I would still be interested (to confirm the timing of the markers)

[TekyTeky]

Mmmm... the issue is that it never fails going forward over it. (this error is forwad but the wrong way.. enters the block forward but the back door)
It is a piece of flexitrack, so has that weird shape of studs... I have always had that as a Prior and that shape.
But it seems clear that it sees blue (as the error says) then sees the next blue , the first of the block.. but as it is going fwd it expects the red of the block.
I'll try changing the sensor.. and it may help reversing even if it doesn't help going around the loop.

Logs.zip

[Novakasa]

In these new logs the train also detects two markers within the same second when it first sees C, so I am pretty sure this is the problem at least in this case. For some reason in all the logs it only seems to detect it twice if the train goes from left to right, never when going from right to left.

[Novakasa]

I just pushed a change in master (build should be available in a few minutes) to make the log message timing way more accurate. This makes it unambiguous whether the same marker is detected twice. Please use this version if the problem still happens and upload a new log.

[TekyTeky]

Ok, you are clearly the master.. 👍

This worked.. although I have only done one test.. time for bed.
I'll test more tomorrow.
Thanks !!

[TekyTeky]

Can you explain why I get this crash.. because I haven't changed the track to specifically for BrickRail the sensors kind of need to be where they are to use this siding.
See video

Normally the train goes in front first with no issues and stops just after the Blue Block Sensor.
But if it is on Random or you force it to go in backwards it doesn't stop.

Warning no mini figs were damaged in this crash !!

PS.. I haven't opened the logs before, is it easy to see what has happened?

EOLCrash.mov.zip
EOL_Crash_Logs.zip

[TekyTeky]

Yes, it was the last trip. But the train starts going forward, then reverses.

So, when it is going in reverse the train sensor needs to go past the blue sensor before it stops... is that correct? And does the length, in how many wagons, in the Inspector, have any bearing on where it stops?

Normally it goes fwd into that block as that is it's home location. This all started when I put it into Random mode.

Also, when I stop the route or emergency stop, the train gets stuck in reverse and I have to turn it off and disconnect from the layout.

[Novakasa]

No, the train sensor needs to only go past the second red marker when it goes backwards. But still it looks like that is too far for for your train to fit.

The length in wagons on the virtual train does not have any effect currently.

Still, in the logs it looked like the train was going forwards, which confuses me. Did you make sure the sensor and the black circle on the virtual train are consistent?

[Novakasa]

Btw, it looks like you can just drag and drop a video in github like this:
https://github.com/Novakasa/brickrail/assets/59559612/6089b47a-fcdb-4088-8f6d-eed6725f8b29

[Novakasa]

It does look like you might have sent me the wrong log, in the log the train starts from this position:

And goes to this position:

So, in the end it will arrive forwards in the siding.

The reason for the crash in the video still seems to me that the train just doesn't have enough space to stop at the red marker when going backwards.

[TekyTeky]

Ok, 2nd red sensor… I’ll try tomorrow. That makes sense as the reason it crashed.
Normally I leave the the vids at 720p and they are too big to drag and drop. That video was exported to 480, with the sound taken off. So I could have.
With the logs, it has a time inside of 17:54 but the video is 17:51. I zipped the one called just BrickRail.log. Previously I have added that and the previous one with the longer name. After it crashes I can’t use it and have to restart.. let me check tomorrow as I haven’t run it since.
Regardless it is because of the lack of length of the block. So that’s ok now I know. Thanks.

[TekyTeky]

Hi, did you get to do any reverse testing and random reverse running on your layout at your parents?
Also I have added a distance monitor to use, it's great.

[Novakasa]

So it kinda works, If I uncheck the Random targets for the train in the siding (in the inspector) I wasn't expecting it to want to come out, plus as I made that first piece of track one way forward, it can't come out during Random?

if you uncheck random targets for a train, the train should never automatically set a route in random targets mode.

If you set that piece of track (arrow pointing to siding block) to "one-way", that means that the train can only enter the siding, and never leave.

If you limit the train orientation to "only forward" for the same track (arrow pointing to siding block), then the train can enter and leave, but only if it enters forward. You should not use the "one-way" setting in this case, since the train can never leave.

[TekyTeky]

Ok, definitely need to study this and have a play.
So you are saying if I make a siding track or the track to say a layer one way, pointing away from the block/layer… and towards the switch (kind of exit only) No train will enter in Random mode, but can enter in manual mode.
So effectively stop Random trains going in and only in normal mode when I drag the mouse or click go home?

[Novakasa]

To achieve what you are describing, you should not use the "one-way" setting for track, but rather use the "random target" setting for a block. On that block, in both directions (+/-), disable the "random target" checkbox. Then, no train will ever enter this block from any direction in random mode, but you should still be able to select it as a target manually.

[Novakasa]

I probably should write some extensive explanations on the wiki soon

[TekyTeky]

It all makes sense, and I understand why you have two bits on each.. you can see which you have chose at the top of the inspector where the block or track name is.

Could you have little symbols show on the track or block when it is in edit mode?

Brickrail is no more complex than BAP or Rocrail and you need to be able to offer a good range of options. I’m sure you have lots of ideas spinning around in you head 😎

Also your future plans could be added to the Wiki eg layout controllable features like crossings etc. then people know it’s a WIP.

But please, take a rest again from it if you should be studying. I’m guessing it is something pretty heavy from you name Novakasa. So BrickRail is probably a nice relief.
My work is IT and my other hobby is astrophotography, but it is on hold at the moment as I need something less complex to do, like playing trains.. that have intricate programming systems 😁🤓