DGBuss
DGBuss
Velkommen
VELKOMMEN
Velkommen som bruker av DGBuss - et system for vedlikhold av ruter og planer for kollektivtrafikk.
Denne hjelpefil er en foreløpig utgave for WDGBuss og intensjonen er å bygge inn mest mulig nyttig informasjon.
Lykke til og ring eller ta kontakt på annen måte om du har problemer eller spørsmål!
Tlf +47 55 11 25 00
www.datagrafikk.no
Support
Har du spørsmål eller problemer, anbefaler vi å sende en epost med henvendelsen til [email protected]. Beskriv problemet, dokumenter gjerne med skjermbilder, eller vedlegg f.eks. form av eksportfiler. Om du samtidig beskriver graden av hastverk, hjelper du oss!
F.eks. slik:
Der vil du få en kvittering med saksnummer:
Dersom du har ytterligere opplysninger eller skal svare på våre henvendelser i saken, trykk på svar eller sørg for at vår support-tag følger med i emne-feltet; F.eks. "[#DG07765] DGBuss: Trenger hjelp til å logge på". Derved blir alle henvendelser i saken samlet under dette saksnummeret og det er enklere for oss å sørge for riktig oppfølging.
Om saken løser seg av seg selv, eller evt etter tips fra oss, setter vi pris på en ekstra epost der du beskriver om saken er løst, uaktuell el.l. - så kan vi avslutte saken i supportsystemet.
Hovedmeny
Hovedmenyen i DGBuss gir tilgang til alle funksjoner. Gruppen Programmoduler gir tilgang til Ruteredigering, skift/vakt, vognplaner, turnus, samt vedlikehold tjenesteplan. De modulene som ikke er aktuelle for den aktuelle bruker og lisens, er grå og ikke valgbare.
Programmoduler
Classic
Daglig drift
MS-SQL
Grunnregistre
Kalenderfunksjoner
Kalenderfunksjonalitet i DGBuss 4.x:
DGBuss er basert på et Versjon/Periode og Dagtype – prinsipp, hvilket betyr at hver eneste dato er tilordnet en kombinasjon av produksjonsversjon (‘V’) og dagtype (‘5’) , evt med en ekstra egenskap der man kan aktivere skolefridag (‘-‘). Dette prinsippet har ligget fast siden en eller annen gang på (19)90-tallet - tiden flyr!
Med det menes f.eks. at vinterruter 2019 kobles mot versjon V, (eller f.eks D). Via relativt fleksible definisjoner i periodekalender kan man da definere ulike perioder der V blir aktivert. Man kan også overstyre enkeltdatoer i unntakskalendere. Derved er det enkelt å overstyre en uke og sette den til f.eks. P, man kan aktivere søndagsruter på 1. mai ved å definere 1. mai som en dagtype 7 i unntakskalenderen. Man kan også for perioder eller enkeldatoer definere at det er skolefri (vises med ‘-‘) og derved vil turer i rutene som er merket «S» for skolekjøring, innstilles og turer som er merket «I» for skolefr«I» (evt-. «I»kke skolekjøring), aktiveres ekstra.
Sett at perioderegisteret er fyllt ut på følgende måte:
10 J Jul 24.12.13 02.01.14
20 P Påske 94 16.04.14 21.04.14
30 S Sommer 93 20.06.13 15.08.13
40 S Sommer 94 22.06.14 18.08.14
50 V Hele året 01.01.13 31.12.14
Alle data som skal behandles i systemet sjekkes fra toppen av perioderegisteret.
Resultatet kan illustreres på følgende vis:
Totalkalenderen viser oversikt over kjøretypene for hver enkelt dato:
Denne kjørekalenderen viser skolefri i perioden 1.-7. samt at 17. oktober kjøres som en søndag i periode ‘A’.
Andre muligheter for å begrense gyldigheten innenfor kalenderdefinisjonene man har i kalenderdefinisjonene: Ved å fra ruten gå via Tabell og Ruteinformasjon, kan man begrense gyldigheten, f.eks. i det tilfellet en sommerrute starter senere enn normal overgang mellom skolekjøring og sommerkjøring:
Det finnes dessuten en mulighet til å begrense enkeltturers evt. modellers gyldighet ved å sette FOM og eller TOM dato:
I all hovedsak har dette fungert etter hensikten og dekket de fleste behov.
Spesielt for kollektivselskaper som dekker et større område, kan det bli avvikende overgang mellom sommer og vinter, avvikende skoleferieavvikling etc og derved må man opprette og vedlikeholde ganske mange versjoner for å dekke alle avvikene. Derfor har brukerne både på samlinger og via enkelthenvendelser ønsket forbedringer på denne funksjonaliteten.
FynBus-modellen: En mulighet kanskje ikke alle er klar over: I Fynbus (regionsselskapet på Fyn), har man lenge hatt et annet verktøy som har gitt mulighet for detaljstyring på turnivå. Innenfor hver kommune har de ulike koder som aktiverer en kjøring. Derved kan de dato for dato bestemme om en avgang skal gå eller ikke, dessuten har de valgt at man innenfor hver kommune skal kunne ha inntil 10 ulike kalendermønstre.
Mandag 4.januar 2016 skal f.eks. turene i Assens som er merket AS1,AS2,AS3 og AS6 kjøre, mens andre turer er deaktivert. Dette har vist seg hensiktsmessig for Fyn og alle eksporter tar hensyn til denne kodingen. Kanskje kunne dette være nyttig også for øvrige kunder?
Sikre historikk:
For å sikre at man har korrekt historikk for senere utskrift av produksjonsoppgaver, anbefales ved mindre endringer at man korrigerer i avgangskolonnene og evt setter en TOM-dato på gammel kolonne og FOM på ny og korrigert kolonne. Ved større endringer anbefales å kopiere hele produksjonsversjonen (rimelig kjapp rutine under vedlikehold og reorganiser - menyen) og aktivere den nye produksjonsversjonen fra endringsdatoen. Slik sikrer man at man alltid kan ta ut en rapport som viser korrekt produksjon over tid.
Planlagt utvidelse av kalenderfunksjonene i DGBuss 5.x:
I hovedtrekk: Det utvides til å definere flere versjoner/dagtyper pr dato.
Vi har lenge ønsket å gjøre standard kalendersystem mer fleksibelt slik at man f.eks. kan definere helårsruter innunder versjon A. Ett område, det vi i definisjonene vil kalle «Kalender-sone» kan kjøre P om vinteren og S om sommeren med skolefri (Q) i uke 8. Et annet område kan kjøre D om vinteren med innstilling av skoleturene (D-) i uke 9.
Det betinger at vi må endre den opprinnelige forutsetningen om at hver dato kun har én versjon og dagtype til at det må være mulig å registrere og behandle flere versjoner / dagtyper pr dato. Denne endringen må gjennomføres i både Periode- og Unntaks-kalenderen.
Derved resulterer dette i at man kan aktivere 1,2 eller flere dagtyper pr dato og dette må også komme fram av kjørekalenderen (som i prinsippet også styrer alle eksporter, rapporter osv. (Det er neppe hensiktsmessig å definere for mange pr dag).
Et komplett eksempel kan se slik ut:
Figur: Eksempelet viser at man for sone 0 har definert P som vinterversjon, men bryter av med Q i uke 8. Parallelt har man innenfor definisjonen: Sone 1, definert en helårsversjon: D. I denne har man definert en ekskludering av skolerutene i uke 9. Mandag – onsdag i Påsken har man aktivert en ekstra kjøring som er lagt inn i versjon Y. Man kan også se at man har mulighet for å definere dagavvik for både sone 1 og sone 2 for f.eks. 1. mai. Dette vil medføre at man bruker flere produksjonsversjoner, men samtidig vil det kunne bli færre ruter som er identiske i de ulike produksjonsversjonene. (I dag må man splitte opp en rute i f.eks. S og V – versjon selv om kjøringen er helt lik – fordi andre ruter har forskjell på sommer og vinter-ruter.) I stedet kan man ha kun en versjon av helårsrutene og eksempelvis kalle disse versjon ‘D’. På samme måte kan man da enklere definere inn at ulike områder har vinterferie i uke 8, andre i uke 9, tilsvarende for høstferier osv.
Det er ikke tenkt at de enkelte rutene skal kobles mot sone, kun at f.eks. 16. april, vil alle ruter i versjonene Q, D og Y og deres avganger som er merket dagtype 2 blir avviklet (i alle sammenhenger). Ut fra problemstillinger vi har blitt forelagt tidligere, har vi tro på at dette vil forenkle versjons-oppbyggingen vesentlig.
Status i utviklingen pr februar 19, er at (som man kan se: Definisjonene er på plass,) men man må gjennomgå rapporter, eksporter etc for å åpne for at man ikke lenger kun skal sjekke opp mot en versjon og dagtype pr dato, men alle de som er definert inn. Dvs et moderat arbeid å gjennomføre i det øyeblikk prinsippene bak utvidelsen er fastlagt.
Vedlikehold
Eksport-rutiner
Eksportfunksjonene ligger under Vedlikeholdsmenyen. Alle eksporter er bygget opp etter samme prinsipp: Man kan utføre eksport for hele datasettet eller kun en (test?) eksport for de rutene som er marked av.
Man har oppsettsparametre der man kan sette eksportens gyldighet, samt en del andre parametre, man kan dessuten se på log-filen fra siste eksport.
RegTopp-eksport
Huskeliste for RegTopp-eksport (men denne gir gode tips til hva man bør huske også ved f.eks. NeTEx-eksport.)
Figuren illistrerer en del av punktene man må huske på når man skal kode en rute med RegTopp (RT)-eksport.
Ruteendringsbildet.
1. Alle holdeplasser man benytter må ha riktig RegTopp HPL-nr.
2. Alle linjer (destinasjoner) i tabellen som skal eksporteres i RT - overføringen må ha et tall i km-kolonnen. Isolert sett betyr det ingenting hva som står i kolonnen, bare det er et tall. Har mn riktig km-angivelse er dette å foretrekke, bl.a. pga bruk av RuteGrafikk. Korrespondansehenvisninger (Tog til Oslo etc) skal ikke eksporteres og man utelater derfor km foran denne linjen.
3. Husk at passeringstidfontnote skal ligge i 5. posisjon i tid-feltet. Kun en fotnote leses. I RT-1.1d - eksport ignoreres passeringstidfontnoter.
4. Klokkeslett etter midnatt skal skrives som (23:45,) 24:05, 24:45, 25:00 etc Ved utskrifter trekker systemet automatisk fra 24 timer. Det er slik systemet klarer å skille mellom avganger i dag tidlig og i morgen tidlig. Eks. Om en avgang kjøres i dagtype 2 og passeringstiden i stasjon C er 26:10, betyr dette kl. 02:10 onsdag morgen)
5. Alle Dagtyper noteres som Dx67 etc.
RegTopp-oppysninger: (Menypunkt under Endre)
Alle opplysningene legges inn i tur og retur-retning.
1. Publikumsnummer må legges inn: Eks rute/linje 11. I enkelte fylker har man valgt å bruke nummerering etter "NRI-metoden": 19-110 der 19 er fylke osv.
2. Linjenavnet bør tilsvare rutenavnet i et rutehefte
3. RegTopp-linjenummer MÅ fylles ut. Det er samtidig et signal til eksportmodulen om at ruten skal eksporteres (dvs kun ruter der denne opplysningen er fyllt ut blir eksportert). Vi anbefaler at man benytter lokalt rutenummer og legger til 1000 i tur-retning og 2000 i retur-retningen. Vi vet ikke om anvendelser av RegTopp-formatet der dette nummeret blir synlig for publikum så man står relativt fritt vedr system funt nummerering. Vi anbefaler imidlertid at man benytter samme RT-linjenummer for forskjellige sesongvariasjoner fordi dette sikrer en komprimering av data under eksport.
5. Trafikkart må fylles ut (Lokalbuss er 2 osv, Se egen forklaring på Trafikkart)
6. Destinasjonsskilt kreves av enkelte anvendelser. Tips: Skriver du -1, får du en liste over de definerte destinasjonsskiltene og kan velge inn ønsket skilt.
7. Om man ikke har koblet ruten i Koblingsbildet, har man anledning til å fylle ut Versjon (sesongvariant).
Husk at alt man fyller ut av opplysninger i disse 2 bildene, følger med om man kopierer fra en vinter til en sommer-rute. Derved vil det lønne seg å gjennomarbeide den mest omfattende versjonen før man kopierer til en ny versjon. Da slipper man med minimalt arbeid å kode den nye versjonen for RT-eksport.
Selve eksport-rutinen:
Sørg for at rutene og kjørekalender er riktig utfyllt.
Gå via Vedlikehold til Eksport og Eksport RegTopp (5,6,3) - menyen.
Se og evt korriger i Oppsett / alternativer:
Pass på at start og slutt-dato stemmer og at stien man registrerer eksisterer. (Om man angir en sti, sørg for å aslutte med '\' (Eks. 'C:\RegTopp\'))
Start eksport (1.1d og 1.2). Etter eksport er ferdig, er det en veldig god regel å sjekke "Utskrift av log-fil til skjerm". Denne log-filen gir mange muligheter for å avsløre feil i en eksport før man sender et datasett fra seg. Her kan man bl.a. merke seg at en advarsel om at en rute har negativ paseringstid kun er ment som en advarsel om at en avgang kan være defekt pga feilinntasting, men dette kan også være tilsiktet. Evt negative avgangstider blir ortert omm automatisk.
Om man ikke har angitt sti, vil man finne eksportfilene igjen i samme katalog som dataene ligger (ofte C:\dg\pcp50).
Pakk ned alle filene av typen R1510.* til en fil og mail dem til din driftsoperatør. Gi samtidig beskjed om hvilket datointervall sendingen er gyldig for.
Spesialfunksjoner for system som ikke er koblet med Plan
Om rutemodulen ikke er koblet med plan, har man større frihet til å spesialkode gyldighet for enkeltkolonner uten at dette gir negative konsekvenser for r.eks. skiftplaner. Systemet må evt settes opp spesielt for dette formålet (Tabellype:62).
Man har 2 spesialfunksjoner som kan utnyttes:
1. Overstyring av gyldighet på tabell og tur.
En tidtabell kan gies et gyldighetsintervall (Endre, Ruteinformasjon i tabellen) som da kan innskrenke øvrig periode definert gjennom kjørekalender. Om f.eks. tabellversjon B kjøres hele vinteren, kan man i rute 10B som er koblet mot preiode B overstyre denne til å avslutte 1. februar 04. Det samme gjelder enkeltkolonner innen tabellen (gå via Kolonne og sPesifikasjon i en tidtabell og legg begrensningene i TOM dato og FOM dato.
2. Automatikk for skolefri.
I hver enkelt tabellkolonne (under Kolonne og sPesifikasjon) kan man sette en "S" i Skolfeltet for å markere at turen går kun på skoledager.
I både periode og kalender - definisjonene lan man i Type-feltet sette en '-' (bindestrek) for å markere at skolekjøring utgår. Resultatet kan sjekkes ved å kikke på kjørekalenderen der det vil framkomme en '-' etter hver dato der skolekjøring utgår.
RegTopp-eksporten samordner dette slik at turene merket 'S' i skol-feltet utgår på datoer der skolekjøringen er kodet som innstilt. NB! Denne funksjonaliteten gjelder kun RegTopp-eksport.
Rapporter
Optimalisering
Ruteproduksjon
Hjelp
Andre emner
Avansert dagtypekoding
Det finnes 2 alternative dagtypekodinger. Avansert dagtypekoding som for de fleste vil bety en vesentlig forenkling i arbeidet med kobling av rutedata mot skift, samt vedlikehold av dette.
Tradisjonelt har koblingen mellom ruter og plan fungert slik at hver kolonne i PC-Ruter blir tilordnet til et skift ved å skrive inn et skiftnummer i skift-linjen over kolonnen. Det oppstår da en "1 til 1" - kobling slik at turen vil forekomme som en linje i tilsvarende plan Pga. tariffbestemmelsene, må turer som går både hverdager, lørdag og/eller søndag, splittes i separate P-kolonner som kobles mot tilsvarende skift. Dette fungerer og blir ryddig og oversiktlig. Dersom man så får et avvik fra "standarden" på f.eks. torsdag, blir det straks mer komplisert. Alle turer som inngår i et slikt skift, må splittes (også P-kolonner). Dette har tendensen til å forplante seg til andre ruter og skift og derved resultere i et omfattende og omstendig arbeid.
Dersom man har regulær kjøring alle dager uten unntak enkelte dager, vil standard dagkode-kobling være å foretrekke, men de fleste selskap vil nok ha stor glede av å gå over til avansert dagtype-koding.
Avansert dagtype-koding aktiveres ved å velge 5. Vedlikehold/Utskrifter i Hovedmenyen, og deretter 5. Systemoppsett, 3. Brukerdefinerte valg PC-Plan og 5. Spesial-parameter.
Ved å svare 'N' til 4 posisjoner signifikant i skift, aktiveres Avansert dagtype-koding.
NB! Husk å kjøre 1. Sortere fra Vedlikeholdsmenyen under punkt 1. Reorganisering før arbeidet startes opp.
Denne omleggingen kan påvirke eksisterende data. Vi anbefaler derfor at omleggingen foretas i forbindelse med versjons-skifte, og at man tar en komplett kopi av hele installasjonen til et nytt område og fortsetter planleggingen på den nye kopien.
Først av alt bør man venne seg til å tenke på de første 3 siffer i skift-nummeret som skift-gruppe f.eks. 100L = skiftgruppe 100 i Lørdag-versjonen. Det 4. siffer angir dag-typen.
Anbefaling:
Sett av L til lørdag, S til søndag og A, B, C, D og E til evt. spesial versjoner av skift for en enkelt ukedag mandag - fredag. Dersom skiftet går helt uten unntak fra mandag - fredag, settes 4. bokstav blank. Et skift som går ma, ti, to og fr, kan kalles 100G osv.
De første 3. sifrene velges ut fra område/stasjoneringssted e.l.
På denne måten vil alle kunne lese en rekke viktig informasjon ut fra skiftets navn.
En tur i Rute-modulen kobles mot et skift i Plan-modulen ved å angi skift-nummer i 2. hodelinje. I dette tilfellet kan vi tenke oss at vi har 4 turer som er koblet til samme skiftnummer, og kjører daglig med avvik på onsdag. Vi kaller skiftet 100G og legger skiftnummeret inn i 2. hodelinje over hver av de fire turene som skal være med i dette skiftet. OBS. det er i dette tilfellet ikke nødvendig å bruke Type kol feltet over disse turene til annet enn evt. mal-kolonner.
I Plan-modulen vil du nå kunne hente opp skift nr. 100G, og skiftet kommer opp med en linje for hver tur som har fått dette skiftnummer i PC-Ruter. Stå ute i skift oversikten marker skiftnr. 100G, trykk [insert] tasten og det kommer opp en ny meny hvor det står: Opprett: vakt. Markøren står nå å blinker i et grått felt, vi skal opprette et skift for onsdag og skriver inn 100C [Enter] skiftoversikten kommer opp igjen med det nye skiftet. Opprett skift for lørdag og søndag (100L og 100S) på samme måte.
Ta opp skift 100G. Velg End menyen (Endre Vakt-opplysninger) Du får nå tilgang til feltet for dager. Sett inn bokstaver for dagene som skiftplanen gjelder for med blankt felt for dager som ikke skal være med. I dette tilfellet MT TF. Avslutt med [Enter] i siste felt eller [F2].
Velg nå Lin menyen (Endre Linjeopplysninger). Legg inn f.eks. posisjonskjøring på 10 min. i første linje. Legges det inn en D for daglig i kolonnen for dager vil denne grønne linjen også komme opp i skiftnr. 100C, 100L og 100S. Legges det inn Dx67 vil linjen bare komme opp i skift 100C i tillegg til skiftnr. 100G.
Ta opp de tre andre skiftene og sett inn hvilke dager de gjelder. Du vil nå se alle fire skiftene i skiftoversikten og hvilke dager det enkelte skiftet gjelder for, både ved hjelp av skiftnummer og i kolonnen for ukedager.
Ved å benytte denne framgangsmåten, vil man altså kunne legge inn spisepause fra kl. 11.00 til 11.30, for alle 100-skiftene en gang, og dette vil komme fram på alle skiftene hvis dagkoden er gyldig.
Man bør imidlertid også være oppmerksom på at det også er mulig at skift i samme skiftgruppe kan være definert for samme dag. Ved at det f.eks. opprettes et skift i en skiftgruppe for ma, ti, to og fr, og et annet skift i samme skiftgruppe for on og fr. Denne fellen kan lettere oppdages ved at man bruker bokstavene M, T, O osv. når man definerer hvilke dager skiftet gjelder for, skift-oversikten gir et godt overblikk over hvilke dager en skift gruppe er definert for.
En annen feilmulighet er at det kan opprettes en tur som ikke faller innenfor noen av skiftene i en skiftgruppe. Hvis det f.eks. er opprettet et skift for ma, ti, to og fr, og et skift for on, vil en tur som går bare fredag i samme skiftgruppe falle utenfor.
For å unngå slike feilmuligheter er det laget en sjekke-rutine som ligger under PC-Plan menyen punkt 9. Integritetssjekk turer (-) Vakt. Denne sjekkerutinen går igjennom sammenhengen mellom turer og vakter, for den versjon som er ibruk. Rutinen vil først gi en oversikt over vakter som er dobbelt definert på minimum en ukedag.
¦DataGrafikk a.s Dato: 02.11.18 Klokken: 14:49:53
¦Integritetsjekk for 3 pos. Vakt-behandling
¦Produksjonsversjon: H
¦
¦Følgende Vakt er dobbelt-definert på minimum en ukedag:
¦------------------------------------------------------------------
¦Vakt MTOTFLS
¦
¦72 A MTOTF
¦72 B MT TF
¦72 L L
¦72 S S
Denne utskriften viser at skift nr 72 er delt opp i fire skift, men 72 A og B er dobbelt definert på mandag, tirsdag, torsdag og fredag. Tar man opp skiftnr. 72A og setter inn at dette skiftet bare gjelder for onsdag vil denne skiftgruppen ikke komme opp som feilmelding i neste integritetssjekk.
Daglig drifts-modul skal bygge videre på all informasjon som ligger i trafikkdatabasen til Ruter- og -Plan. I dette inngår ruter, skift-(vakt-planer, vogn-planer, turnus-(rotasjons-)planer, mannskapslister, kjørekalender, tariff- og kode-register.
Ut fra denne trafikkdatabasen skapes Dagplaner som er en samling av aktiviteter. En aktivitet kjennetegnes ved at den skal utføres av en sjåfør og en buss. Aktiviteten har et planlagt start- og slutt-tidspunkt og en lengde og kan også beskrives gjennom en merknad. Første del av et skift, er et eksempel på en aktivitet.
1. Alle turer i Rute-modulen skal være koblet mot skift. Husk at «null-skiftet» bør være tomt!
2. Man får i så fall en meget god indikasjon på at man ikke har glemt å koble enkelte turer.
3. Kjører man avansert dagtypekoding, bør man dessuten kjøre integritetssjekk - slik at man er sikker på at turen er disponert én, men bare én gang pr ukedag den skal kjøre.
4. Ruteturer som ikke er koblet mot skift, vil ikke bli hensyntatt i Daglig drift.
5. Alle skift bør være disponert mot turnus. Ikke koblede skift vil komme fram av dagplanen uten tilordnet sjåfør.
6. Kjørekalenderen må være utfyllt.
7. Lønnsperiodene må være utfyllt.
1. Opprett en dag. Sjekk dagplanen og gjør evt. endringer i skftene, vogntildeling på turer, koderegister, splittarter e.l. Endrer du en av disse, må du opprette dagen på nytt for for at dagplanen skal endres.
2. Når dagplanen for test-dagen stemmer, kan man opprette en hel lønns-periode.
Utgangspunktet ved oppretting av dag, er registrene for skift, turer i skift, kjørekalender, turnus, personell osv.
Dagplanen er en liste over aktiviteter: Eksempler på aktiviteter kan være: 1. del av et skift, 2. del av et skift, en spisepause, en turbuss-tur osv. Man kan også sette opp systemet slik at et skift blir splittet i en ny aktivitet når sjåføren skifter vogn.
På denne måten vil man få en liste over aktiviteter der listen kan sorteres avhengig av bruksområde:
Sorteringen velges ved å trykke [F2] i dagplanen.
Beregningsfunksjoner
Type (kolonner):
M: Modell(mal),
R: Repeterende mal
m: Henviser til modellkolonne,
r: Henviser til repeterende mal
O: Kun til publikums informasjon (Out-put)
P: Planlegging
S: Supplement; Vises i tidtabell, men stammer fra annen rute
F: ?
Beregningsfunksjoner:
Vanlige maler:
Ved å opprette egne kolonner først i tabellen og merke disse med en 'M' i 1. pos. 1. linje, vil dette være en mal-kolonne for beregning av andre kolonner. Fyll ut med tiden '9999 ' i første vanlige tid-kolonne.
Repeterende maler:
Opprettes egne kolonner først i tabellen som merkes med f.eks. R01, vil denne danne mal for andre kolonner. Om man fyller ut start-tidspunkt i hodelinje 2, siste mulige avgangstid i hodelinje 3 og intervallet i linje 4: Eks. I30 for en avgang hvert 30. minutt. Kan man via Kolonne-menyen starte en beregning av Repeterende kolonner
Atribut-feltet
Attributt-feltets virkninger:
1. posisjon: Horisontale streker
f; strek før avgang, e; strek etter avgang, b; begge,
2. posisjon: Piler i til/fra-feltet og kommentar etc.
n; pil ned, o; pil opp t; Til, f; Fra, k; kommentar,
S; Skrå, U; Uthevet i tidkolonner,
X; fjerner horisontal strek
V; Vanlig tekst i tid- og ikke utpunktering i sted-feltet
3. posisjon: Korrespondanser etc.
k: Kursiv, h : Halvfet, o: Rød markering
x: utelat ved utskrift av tidtabell
4. posisjon:
X: utelat hpl. ved Bybuss-utskrift
5. posisjon: Billett-system
x: utelat ved eksport (billett-system)?
