what is in Update 350 - April/May 2017 - "Weekend" items | User Updates | Forum

Welcome to the ProTrak User Community Support Forum . The forum is designed around the chapters in The Manual. Please post your questions in the appropriate subforums. You may "Subscribe" to topics and reply by email.

A A A
Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —






— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Feed Topic RSS sp_Print sp_TopicIcon
what is in Update 350 - April/May 2017 - "Weekend" items
May 22, 2017
8:50 am
Avatar
Jim Moir
Admin
Forum Posts: 489
Member Since:
December 23, 2014
sp_UserOfflineSmall Offline

1)   Workorder - noted that order of cars on the Workorder was not the same on the subsequent Train-Consist ("switchlist")

One issue was that the program had an assumption of "one Yd yard".  If the train was at another Yd yard, the Workorder would be blocked in the context of the train's location, rather than the Workorder's location.   Now the workorder "knows" that the train may be at another Yd yard.

Another issue was the circumstances under which the yard-pickups were blocked; now pickups are blocked properly.

 

2)  Changing the conductor for a train - from the "Preview" train consist.

The issue was an interaction with the locomotive consist number.   Conductor data is now save properly.

 

3)  Annulled trains - at the Daily Summary are now reset properly.   

4)  For trains run "job extra", the symbol is reset properly.

 

5)  Train consist - ordering of blocks-of-cars after reporting at a new location were being flipped.   This has to do with train-consists printed (post caboose) style, in locomotive -> EOT (caboose) order.   The "classification" routines now know to classify the cars remaining in the train in "locomotive -> caboose" order.

 

6)  "Held setoffs"    When a train is reported at a Yd yard there is an option to hold the setoffs to be worked later, allowing the train to advance immediately.   (This is different from the "Hold train" option.)   The noted problem was that not all cars in the setoff block would appear on the subsequent Cut List.

There were 3 issues: cars re-assigned to the same train, cars that would be assigned to a (local service train that had run) and cars with no valid route of any sort - cars with no routing of some sort would be not assigned to the cut-list data.    The cutlist needed a valid routing for assignment.

The first case - assigned to same train - required a minor change.

The second case - local service train has run - required a significant modification, in that the cars are now assigned as extra cars to the local service train - a routing is now found.   This change affects both Held Setoffs and >and< any car that would be assigned to a local service train that has run.   

The third case - no valid routing of any sort - the car is assigned to the Cut List data as a "Held" car (no ConnXns) for the yardmaster to figure out what to do.

       

                        Jim

May 23, 2017
12:16 pm
Avatar
Fred
Member
Members
Forum Posts: 43
Member Since:
April 26, 2015
sp_UserOfflineSmall Offline

For Jim M

I have installed the latest update 350 and have a problem. In operations I have my yard trains set as (BVL-BVL) etc. When I click on train list for these trains the word "Block" appears and the screen freezes. On my other trains that continue (BVL-JCT-SCM), when I click on train list everything is working correctly. Thanks for fixing the job extra symbols that wouldn't go away. The train list was getting pretty confusing.

Fred Kaser

May 23, 2017
5:03 pm
Avatar
Jim Moir
Admin
Forum Posts: 489
Member Since:
December 23, 2014
sp_UserOfflineSmall Offline

Fred,

Any chance I could get  a copy of your data?

Thanks,

                  Jim

May 24, 2017
8:07 am
Avatar
Jim Moir
Admin
Forum Posts: 489
Member Since:
December 23, 2014
sp_UserOfflineSmall Offline

Fred,

On looking through the "blocking" routines I see that, if an error was thrown in one routine, then an "infinite loop" could occur (in a debugging routine).   In usual operation this debugging routine would not be called/used.  However I have changed the code to eliminate any chance of an infinite loop.

However the question remains as to why the error.... If you could email me your data, that would be quite helpful.  Thanks.

                Jim

 

P.S.  I am working through the entire program to make this same bug is not found elsewhere.

May 24, 2017
3:55 pm
Avatar
Jim Moir
Admin
Forum Posts: 489
Member Since:
December 23, 2014
sp_UserOfflineSmall Offline

Fred,

Posted a corrected version.  Well, at least I think it is corrected if the issue is what I am assuming it is (as above).

Please let me know how it works.

Thanks,

                   Jim

May 25, 2017
5:33 pm
Avatar
Fred
Member
Members
Forum Posts: 43
Member Since:
April 26, 2015
sp_UserOfflineSmall Offline

Jim

That corrected the problem that I was having

Fred

Forum Timezone: America/Chicago

Most Users Ever Online: 189

Currently Online:
9 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

Nashville: 248

Joe-SVL: 243

casowest: 95

Jim Brewer: 92

Mark Stafflrd: 58

Bob: 53

Fred: 43

John V: 43

jjoyce1: 32

Peter Jackson: 27

Member Stats:

Guest Posters: 0

Members: 259

Moderators: 0

Admins: 5

Forum Stats:

Groups: 3

Forums: 13

Topics: 432

Posts: 1815

Newest Members:

Fred52, ferretjack, Frank, bcole_-8@rogers.com, frich1230, waffle2@mac.com, innovativerc@gmail.com, KRFARRINGTON, George Giles, NandWSRY55

Administrators: earlyrail: 71, friscomike: 130, webmaster: 1, hunter48820: 23, Jim Moir: 489