Om os
1985-86: Starten.
Startede som et 2 personers hobby-projekt til en hjemmecomputer. G. Petersen (forfatteren til denne tekst) og P. Jacobsen havde studeret (og spillet) videospil til Sinclairs ZX-Spectrum.
G. Petersen arbejdede desuden til dagligt med assembler-programmering af 8085 CPU-er – det drejede sig om industrielle styresystemer, hvor specielt hastigheden var vigtig.
Vi havde fundet en måde at udnytte CPU-tiden på, der var mere effektiv end dem, vi havde set i spillene (dem vi havde undersøgt i hvert fald).
Den nye måde byggede på den såkaldte ”pop-only” stack, som teknisk interesserede kan læse mere om sidst i teksten.
Vi lavede nogle værktøjsprogrammer der brugte dette princip til fremstilling af små tegnefilm. Miljøet var dog for ufleksibelt til særlig avancerede spil eller ligefrem simulationer. Dette blev der i høj grad rådet bod på senere.
1987: Fra Spectrum til PC.
I takt med at de IBM-kompatible PC-er blev billigere, blev det relevant at flytte systemet fra den 8-bit Z80 baserede hjemmecomputer til den 8/16 bit 8088 baserede IBM-PC.
Sidst på året kom den 3-die person – G.B. Jensen – med på holdet. Herved fandt personkredsen bag udviklingen af selve kernen (copyright indehaverne) sin endelige form: G.Petersen, P.Jacobsen, G.B.Jensen.
1988: Tilløb til erhverv.
I løbet af 1988 skete der en lang række optimeringer og forbedringer. Systemet blev optimeret for simulation, og udnyttelsen af CPU-tiden nåede et niveau, hvor en Olivetti M24 PC (8 Mhz 8086 CPU) kunne opdatere hele skærmens areal 20 gange i sekundet (i CGA, 320×200 4 farver vel at mærke).
Det var et godt stykke over datidens standard for spil. I 1988 var computerspil til IBM-PC endnu ikke blevet til noget væsenligt forretningsområde, men sammen med en gammel skolekammerat til G.Petersen (J. Hjelme) fandt vi på at lave interaktive simulationsprogrammer til undervisningsbrug.
PC-er havde endnu ikke vundet indpas i folkeskolerne, men et stigende antal tekniske skoler og AMU-centre var begyndt at få lokaler med et mindre antal IBM-kompatible PC-er. Det var typisk 2 eller 3 elever pr. PC.
Ved udgangen af året etablerede G.Petersen, J. Hjelme og en 3-die person: J.Carlson, der til dagligt arbejdede som lærer ved en teknisk skole, firmaet SIMCAD aps, der skulle lave interaktive simulationsprogrammer til brug for undervisning ved tekniske skoler.
1989-91: Undervisningsprogram (SIMCAD perioden).
Denne periode var udviklingsmæssigt meget frugtbar. Programmerne fik en betydelig udbredelse på både skoler, AMU-centre o.lign., og vi fik masser af feed-back, som var med til at højne brugervenligheden. Et vigtigt træk ved programmerne sammenlignet med egentlige undervisningsprogrammer var foruden den hurtige grafik, at det var tidstro og realistiske simulationer. F.eks. virkede det mest udbredte – pneumatik-simulatoren – på den måde, at man kunne sammenbygge en opstilling på skærmen og derefter afprøve funktionen. Programmet blandede sig således ikke i den pædagogiske metode, og var derfor let at passe ind.
En medarbejder hos en af kunderne (det daværende Jysk Teknologisk) undrede sig i 1989 over, at vi brugte dette system til det lidet lukrative undervisningsområde, når det syntes at besidde mange af de egenskaber han selv mente bestående systemer til automatisering af industrianlæg manglede, f.eks. tidstro skærmvisning af signaler.
Det førte til udviklingen af en række ”mekaniske” programmeringssprog, som i modsætning til traditionelle PLC-sprog ikke krævede, at programmøren havde kendskab til elektriske systemer.
Det var en gammel kongstanke, at god automatisering af mekaniske systemer burde bygge på mekanisk – ikke elektrisk – viden.
Meget længere kom automatiseringstanken ikke i denne omgang. Der syntes ikke at være prisbillige systemer på markedet til effektivt interface mellem el-tavler og IBM-PC – i hvert fald ikke sammenlignet med de veletablerede hard-PLCer.
Simcad-perioden havde – skønt teknisk set frugtbar – ikke givet smør på brødet. Skolerne havde hele tiden haft svært ved at skaffe penge – der kunne være måneders salgsarbejde i at sælge en enkelt skolelicens til kr. 3000.
Da så skolerne i 1991 oven i hatten blev ramt af massive nedskæringer med mange fyringer (de små elev-årgange) måtte vi i realiteten lukke ned.
1992-1995: Optakten til industristyring.
I denne periode kørte GOPA-udviklingen for nedsat kraft, der var mest tale om interne ajourføringer, f.eks. at få grafik-modes opgraderet fra EGA til VGA (640×480 16 farver) og få kodegenerator ændret fra at være optimeret for 386 CPU til 486 (og siden Pentium).
G. Petersen blev i 1992 ansat i Danvægt a/s, som rent faktisk brugte PC til industriel automation. Problemet med effektivt interface til eltavler, havde man klaret på en ganske simpel måde: Man fremstillede selv input/output boxe. Programmerne blev i første omgang skrevet i Pascal, senere C men i begge tilfælde kørte programmerne under en traditionel hver-proces-sin-stak realtidskerne.
I 1995 blev der indgået en samarbejdsaftale mellem Danvægt og copyright-haverne om i fællesskab at videreudvikle det bestående system til brug for industriel automation. Det omfattede såvel selve værktøjsprogrammerne som brugen af dette, d.v.s. færdigsyede løsninger til slutkunder.
1996-2000: Industriperiode 1
Præcis et år efter aftalens indgåelse, kommer den første version af et kundetilpasset program ud at køre. Herefter går det relativt hurtigt. Det går faktisk så stærkt med at få færdige programmer over disken (i alt 2 fastansatte plus en lejlighedsvis free-lancer laver kundetilpassede programmer under handelsnavnet Factview ) at udviklingen af selve værktøjsprogrammet halter bagefter – særlig hvad angår brugervenlighed overfor nybegynderen.
Bl. a for at råde bod på dette bliver G.Petersen i 2000 selvstændig og samarbejdsaftalen med Danvægt ændres så rettigheder og pligter i forhold til udvikling og brug af værktøjsprogrammerne går tilbage til de oprindelige rettighedshavere, mens det tilsvarende i forhold til færdige programmer – herunder service, support og videreudvikling nærmest udvides.
G. Petersen fortsætter derfor som underleverandør til Danvægt.
2000-2005: Industriperiode 2
Allerede i 2001 var det udviklingsmæssige efterslæb på værktøjssiden indhentet, og i løbet af 2002 og 2003 blev brugervenligheden afprøvet på nogle elevhold på en teknisk skole.
I 2002 påbegyndtes udviklingen af næste version – 32-bit versionen (som planlægningsmæssigt havde været i støbeskeen siden 1996).
Første version af et færdigt program med 32-bit runtime søsattes i efteråret 2005.
2005- og fremefter, Open Source:
For at lette tilpasninger til nyere standarder for PC, bliver der lukket op for, at 32-bit versionen af GOPA kan blive en del af ”Open source” verdenen, d.v.s. enhver kunde, der får en 32-bit løsning – enten som nyanskaffelse eller som opgradering af 16-bit version, kan få udleveret kildemateriale til sit eget program (forudsat konsekvenser i forhold til garanti og support accepteres) plus at de ikke-kundespecifikke dele af systemet kan blive en del af ”Open Source” verdenen.
På den juridiske side skete det ved at ændre samarbejdsaftalen i forhold til Danvægt til en klassisk kundeklausul i forhold til de kundetilpassede projekter. På den tekniske side sker det ved at sikre, at al ny 32-bit kode fra start er kompatibelt med Linux.
Totalt skal dette tjene 3 formål:
1) At sikre kundernes investeringer i det tilfælde, at både Danvægt og alle øvrige involverede personer i GOPA-projektet pludselig forsvandt.
2) At lette tilpasning til nye hardware-standarder (at man kan bruge en device-driver skrevet til Linux).
3) På sigt at arbejde hen imod at GOPA-32 fra at være et stand-alone operativsystem kan integreres i andre operativsystemer – først og fremmest selvfølgelig Linux, men i princippet alle, der enten vil tilpasse sig åbne standarder, eller (om muligt efter tvang fra EU-kommisionen) vil åbne deres egne standarder (ingen nævnt – ingen glemt).
Om pop-only stakken – for teknisk interesserede.
Et vigtigt element i den nye fremgangsmåde var den såkaldte ”pop-only stack”. Kort fortalt er det en form for multitasking, hvor man dels dropper princippet om, at hver proces har sin egen stack, dels bruger instruktionen RETurn som et superhurtigt trådskifte. Et GOPA-program har masser af RET instruktioner, men ikke en eneste CALL instruktion.
Når udgiften til at administrere en tråd (=minimal proces) bliver meget lille, ændres måden programmerne opbygges på. Brug af ”tilstandsmaskiner” der udveksler meddelelser, bliver en fordelagtig måde at løse opgaver på, og programmerne bliver dejligt nemme at fejlrette, fordi man ved at kigge på sekvenserne ikke blot kan se, hvad der sker lige nu, men også hvad der tidligere er sket !
Et halvstort program kan indeholde 2-3000 af sådanne tråde, og disse er organiseret i et stort lineært array.
Princippet bruges både ved automatisk opdatering af grafik, og ved eksekvering af det soft-PLC program brugeren selv har lavet
Den røde mursten i sekvenseren symboliserer direkte et word i pop-only stakken. Dens placering i sekvenseren viser direkte det aktuelle indhold af dette word, d.v.s. det sted i kodebufferen cpu-en vil hoppe hen til næste gang en RETurn instruktion får stackpointeren til at læse dette word.
Denne kode vil meget ofte blot være en test af, om en betingelse er opfyldt. Dette vil som oftest ikke være tilfældet, så en ny RET instruktion vil sende CPU-en ind i næste sekvenser (tråd).
Når det så en dag sker, at betingelsen er opfyldt, vil der blive eksekveret noget nytte-kode hvorefter næste ”vente-step” etableres ved at der loades en ny konstant ind i murstenens word (nemlig adressen på næste step) hvorefter en RET instruktion sender CPU-en ind i næste tråd.
Det oprindelige formål med pop-only stakken var at få et hurtigt trådskifte, men den helt store gevinst viste sig på anden vis. Ved at samle alle tråde i systemet i et sammenhængende lineært array, opstår de samme fordele som kendes fra data-manipulation i f.eks. et c-program. Uanset hvilket hierarki af records og dimensioner der findes på kildetekst-niveau, vil c-compileren konvertere det til en offset i et lineært array. Man behøver ikke ”lede efter” data – lokationen kan langt hen ad vejen beregnes på compileringstidspunktet. Hvis en ”chef-tråd” f.eks. kan se, at 8 af dens ”medhjælper-tråde” ikke behøver køre i dette scan, kan den blot eksekvere en enkelt instruktion:
ADD ESP,32 før den skifter tråd med den obligatoriske RET instruktion. Så hopper CPU-en ikke til den første af de 8 hjælpe-tråde, men til den første tråd, der kommer efter de 8 hjælpe-tråde.