Elvas Tower: Error Log Signal Errors - Elvas Tower

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Error Log Signal Errors What dt these errors mean & How to Correct?

#1 User is offline   vince 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,057
  • Joined: 18-June 14
  • Gender:Male
  • Location:West of the Contental Divide
  • Simulator:ORTS_Running MSTS_Editing
  • Country:

Posted 23 October 2018 - 07:45 AM

I'm having some difficulty with a part of the error log on the PRR East Region route I'm cleaning up.
If some could explain these errors and perhaps suggest a way to eliminate them I would be grateful.Here is a paste from the log:
 
Information: Signal 628 ; TC : 21079 ; NextTC : -1 ; TN : 906 Information: Signal 629 ; TC : 21079 ; NextTC : -1 ; TN : 906
Information: Signal 3878 ; TC : 22895 ; NextTC : -1 ; TN : 5898
Information: Signal 4081 ; TC : 23054 ; NextTC : -1 ; TN : 6358
Information: Signal 4082 ; TC : 23054 ; NextTC : -1 ; TN : 6358
Information: Signal 4083 ; TC : 23054 ; NextTC : -1 ; TN : 6358
Information: Signal 4601 ; TC : 23516 ; NextTC : -1 ; TN : 8094
Information: Signal 4763 ; TC : 23653 ; NextTC : -1 ; TN : 8409
Information: Signal 4953 ; TC : 23826 ; NextTC : -1 ; TN : 8628
Information: Signal 4954 ; TC : 23826 ; NextTC : -1 ; TN : 8628
Information: Signal 4955 ; TC : 23826 ; NextTC : -1 ; TN : 8628
Information: Signal 5207 ; TC : 24077 ; NextTC : -1 ; TN : 9108
Information: Signal 5218 ; TC : 24090 ; NextTC : -1 ; TN : 9113
Information: Signal 6622 ; TC : 25186 ; NextTC : -1 ; TN : 12777
Information: Signal 6716 ; TC : 25283 ; NextTC : -1 ; TN : 12889
Information: Signal 6757 ; TC : 25324 ; NextTC : -1 ; TN : 12920
Information: Signal 6758 ; TC : 25324 ; NextTC : -1 ; TN : 12920
Information: Signal 6835 ; TC : 25400 ; NextTC : -1 ; TN : 12977
Information: Signal 7955 ; TC : 26239 ; NextTC : -1 ; TN : 13656
Information: Signal 8864 ; TC : 27101 ; NextTC : -1 ; TN : 16532
Information: Signal 9102 ; TC : 27336 ; NextTC : -1 ; TN : 16933
Information: Signal 9103 ; TC : 27336 ; NextTC : -1 ; TN : 16933
Information: Signal 9104 ; TC : 27336 ; NextTC : -1 ; TN : 16933
Information: Signal 10223 ; TC : 28373 ; NextTC : -1 ; TN : 19730
Information: Signal 10225 ; TC : 28377 ; NextTC : -1 ; TN : 19751
Information: Signal 10226 ; TC : 28377 ; NextTC : -1 ; TN : 19751
Information: Signal 10250 ; TC : 28387 ; NextTC : -1 ; TN : 19781
Information: Signal 10273 ; TC : 28396 ; NextTC : -1 ; TN : 19822
Information: Signal 10303 ; TC : 28416 ; NextTC : -1 ; TN : 19876


+ Trying to eliminate bugs in this route is moving along well but an explanation of these particular errors will help me eliminate them. +These errors were present before I began reworking the route but a way to approach them or even understand them escapes me at the moment.

The Open Rails Error Log has enabled me (so far) to go a long way towards solving the route problems both the ones there when I started and the ones I introduced with the rebuild so I grateful to the Team for providing the logs. Coulden't do it without. Thanks.I'm going to crosspost this to Trainsim.com as I'm not sure if the leading players are able to access this forum after a recent dustup....
regards,vince cockeram

#2 User is online   James Ross 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 5,139
  • Joined: 30-June 10
  • Gender:Not Telling
  • Simulator:Open Rails
  • Country:

Posted 23 October 2018 - 11:44 AM

View Postvince, on 23 October 2018 - 07:45 AM, said:

I'm having some difficulty with a part of the error log on the PRR East Region route I'm cleaning up.
If some could explain these errors and perhaps suggest a way to eliminate them I would be grateful.Here is a paste from the log:

It looks like these should really be warnings, but they are not the easiest message for me to interpret. "TC" is short for "track circuit" and is the internal segmentation of the track. I believe the issue being highlighted in these messages is that the code was unable to identify the track circuit that follows the signal (NextTC), and is showing the track circuit leading up to the signal (TC) and track database node ID (TN) for reference, but it isn't clear why it might end up in this situation.

I guess the things to check would be to find one of the signals (given its ID or track node ID) and see if it is attached to some track, facing in a direction that the track continues in, and there's no unexpected discontinuities in the track database. Maybe a screenshot of the signal in a route editor showing the location of the signal and track and any nearby switches/ends would help someone figure it out.

#3 User is offline   vince 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,057
  • Joined: 18-June 14
  • Gender:Male
  • Location:West of the Contental Divide
  • Simulator:ORTS_Running MSTS_Editing
  • Country:

Posted 23 October 2018 - 02:21 PM

Thank you James. It looks like a search of the track database is in order at least to find something in the routes database files that corresponds to the numbers in the report.

regards,vince
I found one of the signals, it looked (properties) normal. I deleted it and saved.
Then replaced & relinked it. Its a PRR PosLiteGantry mount absolute signal, like thousands of others in the route.Here's the curious thing: The signal 'information' in the Log shows this:
Before signal replaced & relinked
Information: Signal 10250 ; TC : 28387 ; NextTC : -1 ; TN : 19781
Information: Signal 10273 ; TC : 28396 ; NextTC : -1 ; TN : 19822
Information: Signal 10303 ; TC : 28416 ; NextTC : -1 ; TN : 19876

After signal replace & relink
Information: Signal 10251 ; TC : 28388 ; NextTC : -1 ; TN : 19781
Information: Signal 10274 ; TC : 28397 ; NextTC : -1 ; TN : 19822
Information: Signal 10304 ; TC : 28417 ; NextTC : -1 ; TN : 19876


Signal numbers bumped up +1, TC (track circuts?) bumped +1 and TN (tracknode?) thankfully stays the same! ???

The links for the signal were straightforward, no strange linking with 3 of the available 4 links used.The signal in question has always worked so I'm gonna' chalk this one up to some obscure tdb glitch that is not visible in the Sim.Moved to back burner . . . .

btw, the first signal in the 60+ bad ones removed yesterday has been replaced without problems. (no log entries for signals (besides the 'information: I mean) but I see lots of problems with speed posts. It's a known bug that I decided what the heck, it's been over a year with this route mod so whats a few more weeks . . . .
http://www.elvastower.com/forums/public/style_emoticons/default/pleasantry.gifThey are un-selectable, crashing TSRE however removing them via manual world file edit fixes the problem. There are at least a dozen or so suffering from this but it's an ez fix.regards,vince

#4 User is offline   roeter 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,916
  • Joined: 25-October 11
  • Gender:Male
  • Country:

Posted 25 October 2018 - 12:46 PM

Hello Vince,

there's two situations which can create these problems.
First is if a NORMAL signal (i.e. a signal with at least one signalhead of type NORMAL) is placed exactly at the end of a track section, that is that the signal position is exactly equal to the end-of-track position. Clever if you can manage that in the route editor, but in itself not an error. This is possible but rather unlikely.
The second situation is that there are two (or more!) NORMAL signals at exactly the same position. Don't confuse this with a signal with multiple heads, as that is still only just one signal. The program splits the track nodes into track circuits based on signal positions, and if two signals are exactly in the same position the remaining track circuit has zero length, which is invalid. Usually this is a database error when somehow signals got duplicated (MSTS rebuild or something like that). You could check the relevant world-files to see if there are any signals with exactly the same position.

Regards,
Rob Roeterdink

#5 User is offline   vince 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,057
  • Joined: 18-June 14
  • Gender:Male
  • Location:West of the Contental Divide
  • Simulator:ORTS_Running MSTS_Editing
  • Country:

Posted 25 October 2018 - 05:09 PM

View Postroeter, on 25 October 2018 - 12:46 PM, said:

Hello Vince,

there's two situations which can create these problems.
First is if a NORMAL signal (i.e. a signal with at least one signalhead of type NORMAL) is placed exactly at the end of a track section, that is that the signal position is exactly equal to the end-of-track position. Clever if you can manage that in the route editor, but in itself not an error. This is possible but rather unlikely.
The second situation is that there are two (or more!) NORMAL signals at exactly the same position. Don't confuse this with a signal with multiple heads, as that is still only just one signal. The program splits the track nodes into track circuits based on signal positions, and if two signals are exactly in the same position the remaining track circuit has zero length, which is invalid. Usually this is a database error when somehow signals got duplicated (MSTS rebuild or something like that). You could check the relevant world-files to see if there are any signals with exactly the same position.

Regards,
Rob Roeterdink

Hi Rob,Ahh yes . . . the phantoms. If that be the case then to ole' MSTS AE shows them as I recall. Thanks for you've given me a way to correct these nagging messages. Continuing and closely monitoring the OR log, testing after a reasonable brace of signals replares on no more than two tiles. Time consuming yeah . . . but I get to run a test activity anywhere to generate a log.

Fleshing out database bugs has been given a shot -in-the-arm with Goku's latest (experimental) release of TSRE
I'm now able to select and delete TDB signal blocks. ( with a stern warning if delete is selected)
I have used it successfully in TSRE where TDBItems are viewed as a black cube but there is no corresponding signal shape in the world file.Progress. and I'm lovin' it!

regards,vince



#6 User is offline   vince 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,057
  • Joined: 18-June 14
  • Gender:Male
  • Location:West of the Contental Divide
  • Simulator:ORTS_Running MSTS_Editing
  • Country:

Posted 30 December 2018 - 05:44 PM

View Postroeter, on 25 October 2018 - 12:46 PM, said:

Hello Vince, there's two situations which can create these problems.
First is if a NORMAL signal (i.e. a signal with at least one signalhead of type NORMAL) is placed exactly at the end of a track section, that is that the signal position is exactly equal to the end-of-track position. Clever if you can manage that in the route editor, but in itself not an error. This is possible but rather unlikely.The second situation is that there are two (or more!) NORMAL signals at exactly the same position. Don't confuse this with a signal with multiple heads, as that is still only just one signal. The program splits the track nodes into track circuits based on signal positions, and if two signals are exactly in the same position the remaining track circuit has zero length, which is invalid. Usually this is a database error when somehow signals got duplicated (MSTS rebuild or something like that). You could check the relevant world-files to see if there are any signals with exactly the same position. Regards, Rob Roeterdink


More Information on this Rob.
Here's an email from Chuck Rickert who is working with me to clear the PRR-East of all database errors. The signals are the last and here's a first detailed look at one of the errors.

Quote

Regarding signals, yesterday I dug around in the TDB and world files to see if I trace numbers starting with the TN listed by OR. I traced the last one (TN 13638) because it has a lower number of TrRefs to chase down.

I found something that appears suspicious, here is what I found:
- TN 13638 is a TrVector with 11 sections
- The sections are in -11080/14332 and -11079/14332.
- Associated with them are 7 TrItemRefs (interactives).
- Four interactives are Sound Regions.
- Three interactives are Signals
- The TrItemRefs for them are 26270/13399/13417.
- SignalItem 26270 has "( 134.85522 96.681 595.40601 -11080 14332 )"
- SignalItem 13399 has "( 134.85522 96.681 595.40601 -11080 14332 )"

- SignalItem 13417 has "( -1009.41 96.681 327.38678 -11079 14332 )"

Then took a look in world files -11080/14332 and -11079/14332 for corresponding TrItemId entries of 26270, 13399, and 13417. Found 13399 and 13417, but not 26270. Oh Oh!.

Then went to TSRE where 26270 is supposed to be at "( 134.85522 96.681 595.40601 -11080 14332 )". Found "USPldwrf.s/Pl Dwrf Absolute Signal" with UiD 52566. In -11080/14332, that UiD has a "TrItemId ( 0 13399 )", which is one of the above. That one appears fine.

I don't know how signal links are handled in the databases and world files, but the duplication of location info for 26270 and 13399 looks suspicious. Found 13399 but not 26270. To me, that means that SignalItem 26270 is bogus, a phantom link.

If there is no reason for 26270, we could try to remove it. I don't know what you can do with TSRE since 26270 doesn't exist in a world file. I believe it can be done with the tool, but will take some prep at your end to isolate TN 13638 into a path by itself before removal of it. Would mean adding it back in, and repairing any involved AE paths.

You called it Rob! Duplicate signal positions.

Best Regards and a Happy New Year! http://www.elvastower.com/forums/public/style_emoticons/default/yahoo.gif
Vince Cockeram

#7 User is offline   vince 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,057
  • Joined: 18-June 14
  • Gender:Male
  • Location:West of the Contental Divide
  • Simulator:ORTS_Running MSTS_Editing
  • Country:

Posted 01 January 2019 - 07:33 PM

Hello Rob,

Could the Open Rails Log be expanded to include tile/world file coordinates for these signal "information'" logs?

In fact it would be helpful if any error dealing with a database item to have full coordinate information logged.

Also some of these errors now labeled "Information" should really be considered fatal errors as a phantom signal cannot be cleared in an activity AFAIK. I do know the Phantom at Trenton on the PRR killed activitys.
Phantom = An interactive with a TDB entry with no world file entry . . And visa versa.

Here's a link to a post at Trainsim.co. with the same problems I have (no coordinate info) on one of the Indian routes.

https://www.trainsim...953#post1943953


regards,vince cockeram


#8 User is offline   roeter 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,916
  • Joined: 25-October 11
  • Gender:Male
  • Country:

Posted 03 January 2019 - 03:18 AM

Hello Vince,

sorry to disappoint you but as you may have noticed, I am no longer activily involved in writing source code for OR.
Some time ago I took up some voluntary work but this is taking up so much time that I had to drop other things.
Maybe some day I will pick it up again but I cannot make any promises.

Regards,
Rob Roeterdink

#9 User is online   James Ross 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 5,139
  • Joined: 30-June 10
  • Gender:Not Telling
  • Simulator:Open Rails
  • Country:

Posted 03 January 2019 - 08:59 AM

View Postvince, on 01 January 2019 - 07:33 PM, said:

Could the Open Rails Log be expanded to include tile/world file coordinates for these signal "information'" logs?

If the code knows the information, sure. Generally I'd recommend that all known identifying information is logged about objects (IDs, tile X/Z, exact coordinates).

All logged items should label values for content creators (i.e. using same names and abbreviations - or not - as the file formats and existing tools) and always include one of:

  • Complete file path and line number
  • Globally unique ID (e.g. TrackNode ID)
  • Locally unique ID and scope (e.g. UiD + world file name)


View Postvince, on 01 January 2019 - 07:33 PM, said:

Also some of these errors now labeled "Information" should really be considered fatal errors as a phantom signal cannot be cleared in an activity AFAIK. I do know the Phantom at Trenton on the PRR killed activitys.
Phantom = An interactive with a TDB entry with no world file entry . . And visa versa.

They should be warnings, based on the guidelines.

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users