Konfigureringsverktyg till modem
Westermo Teleindustri AB
Mälardalens Högskola
Av: Pontus Timlöv
ptv00001@student.mdh.se Mälardalens Högskola, IDT
Handledare: Joakim Zetterling, Westermo Teleindustri AB Jonas Neander, Mälardalens Högskola IDT
Sammanfattning
Westermo Teleindustri tillverkar och säljer telefonmodem för industritillämpningar och ska erbjuda ett konfigureringsverktyg till dessa. Verktyget ska konfigurera Westermos modem med Hayes
AT-kommandon genom ett PC program som ska vara enkelt att använda så att deras supportavdelning blir avlastad från en del konfigureringssupport. Min uppgift i detta examensarbete var att ta fram en kravspecifikation och implementera en lösning utifrån denna.
Kravspecifikation togs fram genom att skicka ut förfrågningar om önskemål till dotterbolag,
distributörer och andra som har nära kontakt med slutkunderna. I kravspecifikationen beskrivs vilken funktionalitet programvaran skall innehålla.
Att göra en design av en programvara kräver att man har kunskaper om språket och verktygen som ska användas för implementationen. Verktyget som Westermo tillhandahåller för att implementera
Windows applikationer är MFC(Microsoft Foundation Class) som är en instans i Microsoft Visual Studio 6.0. MFC är ett bibliotek av klasser som underlättar Windows API användningen för programmeraren. Det är alltså som ett skal för programmeraren vilket gör att implementationen går snabbare.
En design gjordes innan implementeringen av verktyget började. En viktig detalj i programmet är att nya produkter ska kunna utnyttja programvaran, dvs. den ska vara utvecklingsbar och kunna
uppdateras för nya modem. Detta görs genom att läsa in hur modemet ska konfigureras genom vanliga textfiler som beskriver hur modemet ska konfigureras. Detta innebär att ett nytt modem endast kräver ett par nya textfiler och medför ingen omkompilering av programmet.
Förord
Ett stort tack till Westermo Teleindustri och alla medarbetare som varit till min hjälp i mitt examensarbete. Det är inte bara en person utan de flesta jag har varit i kontakt med på Westermo Teleindustri har bidragit med någon del till mig även om det kanske inte har varit till hjälp i mitt examensarbete.
Speciellt vill jag tacka Utvecklingschefen, Hans Levin som har stått för framtagandet av
examensarbetet, mina handledare Joakim Zetterling, Westermo Teleindustri AB och Jonas Neander, Mälardalens Högskola IDT, som gett mig stöd och varit mitt bollplank. På Westermo Teleindustri har även support- och säljavdelningen varit till stor hjälp och då främst Tomas Malmqvist och Tomas Mårtensson som bistått med synpunkter och kritik under resans gång.
Innehållsförteckning
Konfigureringsverktyg till modem ______________________________________________ 1
Sammanfattning ________________________________________________________________ 2 Förord ________________________________________________________________________ 3 Innehållsförteckning ____________________________________________________________ 4 Bakgrund _____________________________________________________________________ 5 Problembeskrivning _____________________________________________________________ 6 Problemanalys _________________________________________________________________ 7 Resultat _______________________________________________________________________ 8 Kravspecifikationen ____________________________________________________________________ 8 Intro till Westermos modem______________________________________________________________ 9 Design _____________________________________________________________________________ 10 Implementation_______________________________________________________________________ 12 Kritisk analys ________________________________________________________________________ 21 Litteraturförteckning___________________________________________________________ 23 Bilaga 1 ______________________________________________________________________ 24 Bilaga 2 ______________________________________________________________________ 25 Bilaga 3 ______________________________________________________________________ 26 Bilaga 4 ______________________________________________________________________ 27 Bilaga 5 ______________________________________________________________________ 28 Bilaga 6 ______________________________________________________________________ 29 Bilaga 7 ______________________________________________________________________ 30 Bilaga 8 ______________________________________________________________________ 31 Bilaga 9 ______________________________________________________________________ 32 Bilaga 10 _____________________________________________________________________ 32
Bakgrund
Idag används mycket av Supportavdelningens tid till att hjälpa kunder att ställa in (konfigurera) främst telefonmodemen som Westermo säljer. Modemen kan konfigureras genom att koppla in modemet till en terminal och därigenom ställa in modemets parametrar genom att skicka några av Hayes AT-kommandon till modemet. De modem som Westermo gör och säljer används till största delen i industritillämpningar tillsammans med olika PLCer.
Hayes AT-kommandon är en standard som används i de flesta telefonmodem för att kommunicera med modemet på ett användarvänligt sätt. Eftersom många kommandon finns att tillgå i modemen krävs det en manual och även lite känsla och kunskap i ämnet för att hitta rätt kommando för det önskade ändamålet. Westermos telefonmodem innehåller Hayes AT-kommandon med några tillägg vilka då också finns beskrivet i manualerna. För att kunna konfigurera telefonmodemen på ett enklare sätt har förfrågningar om ett verktyg för att göra detta enklare vuxit hos kunderna. Om ett sådant verktyg skulle finnas skulle det i sin tur också lätta arbetstrycket på Supportavdelningen där konfigureringsfrågor utgör en stor del av deras arbete.
Målet är att göra ett verktyg för att underlätta för kunderna att konfigurera sina Westermo
telefonmodem och på så vis också ge Westermos supportavdelning mer tid över till övriga produkter och frågor.
Westermo Teleindustri har som ambition att tillhandahålla ett verktyg som fungerar till Westermos egen tillverkade telefonmodem. Inget konkurrerande företag ska kunna använda sig av verktyget till sina modem, dvs. det ska vara låst till Westermos modem.
Problembeskrivning
Examensarbetet kommer att bedrivas i projektform. Den första uppgiften blir att ta fram en kravspecifikation enligt Westermos kravspecifikationsmall.
Underlag, krav från markanden, för att kunna göra en kravspecifikation finns inte dokumenterat utan de finns mest i form av tankar och idéer. Dessa ska samlas ihop och ska utgöra grunden för en kravspecifikation. Kravspecifikation skall sedan bli godkänd av projektdeltagarna så att den återspeglar kundernas krav och vad som är möjligt att göra.
När kravspecifikationen är godkänd ska den följas och alla krav ska implementeras och fungera. Det kan i kravspecifikationen finnas ”mjuka krav”, vilket betyder att de inte behöver implementeras men om det finns möjlighet och tid att implementera dessa så ska det göras. Layoutdesignen, det grafiska gränssnittet till användaren, bör finnas med redan i kravspecifikations så att synpunkter på utseendet av programmet kan komma redan i den fasen så att det inte behöver ändras senare. Designen av hur programmet är uppbyggt behöver dock inte finnas i kravspecifikation om det inte finns några direkta krav på en viss metod eller modell som behöver vara med i kravspecifikationsfasen.
I Westermos produktframtagningsmodell ställs det inga krav på att en design ska finnas dokumenterad men för att undvika större misstag bör en grov design göras innan implementeringen påbörjas. Konfigureringsverktyget skall efter att det är implementerat testas så att det fungerar enligt kravspecifikationen.
Problemanalys
Problemet, framtagandet av verktyget, kan delas upp i några mindre delproblem som är lättare att angripa.
• Det första delproblemet är att skapa en kravspecifikation, vilket är av undersökande karaktär, och kommer att kräva en del bollande av idéer och frågor till handledaren och
supportavdelningen som vet vad kunderna oftast har problem med. Det innefattar även att sätta sig in i vad en kravspecifikation bör innehålla. Eftersom Westermo inte har någon speciell mall för mjukvaruprojekt får jag följa mallen för hårdvaruprojekt i den mån det fungerar för detta projekt.
• Det andra delproblemet är kunskapen om nuvarande telefonmodems gränssnitt som ska kunna konfigureras med verktyget, dvs. hur gränssnittet ser ut mellan värden(modemet) och
gästen(PCn). Ett stadium av testande och utforskande av några av de telefonmodem som ska fungera med konfigureringsverktyget är därför ett måste eftersom dessa kunskaper inte finns hos undertecknad.
• Därefter kommer designen av programvaran. Denna del kommer att bli uppdelad i flera delproblem utifrån de stora beståndsdelarna.
o T.ex. kan kommunikationen med telefonmodemet vara en stor beståndsdel som vid vidare eftertanke blir uppdelat i flera smådelar.
§ Mottagning av strängar § Sändning av strängar § Signalering av statussignaler
o Grafiska gränssnittet mot användaren kan vara en del av designen.
Genom att sätta upp en grundläggande design med de stora, och i dessa även de mindre beståndsdelarna, kan stora misstag upptäckas i tid för undvika en felaktig/dålig
implementation som inte fungerar tillfredställande. Även om designen har gjorts och inga fel har hittats kan det komma upp saker som inte blivit upptäckta, men då är det förhoppningsvis inga större förändringar som behöver göras och på så vis kan man enkelt återföra dessa till designspecifikationen.
• Implementationen är det som följer designspecifikationen. Det är den del som kan komma att ställa till med förseningar av projektet eftersom det är först nu som man ser om designen som man arbetat fram verkligen fungerar som man har tänkt sig. Om så inte är fallet får man gå tillbaka och se över designen och göra en korrigering för att komma på rätt spår igen.
• Ett stort och viktigt moment som kommer att fortskrida jämsides med implementationen är att kontrollera så att programmet inte har några fel(buggar) som gör programmet ostabilt. Detta är mycket viktigt men också ett mycket svårt arbete eftersom det är väldigt svårt att kontrollera alla möjliga fall som finns och kan uppstå i ett program. De flesta av fallen har man
förmodligen kontroll över redan när man gör designen eftersom en bra design minskar antalet buggar.
• När dessa moment är färdiga kommer verktyget att packas ihop till ett installationspaket som kunderna kan använda i sitt konfigureringsarbete med Westermos telefonmodem.
Resultat
Resultaten av vad jag gjort under mitt examensarbete presenteras i följande delar: Kravspecifikation
Intro till Westermos modem Design
Implementation
En kritisk analys kommer också att göras på det arbete som gjorts för att ta upp problem som uppstått under vägen och andra, till problemet, relevanta synpunkter som kan vara av värde att ta upp.
Kravspecifikationen
Kravspecifikationen på Westermo arbetas oftast fram av ansvarig utvecklare tillsammans med någon eller några från marknadsavdelningen för att på så sätt få fram en produkt som är möjlig att göra samtidigt som det finns en efterfrågan på en sådan produkt. Marknadsavdelningen kan i det här fallet bistå med vissa krav som de antar eller vet att kunderna vill ha med i konfigureringsverktyget. En liten efterfrågan på ett verktyg för konfigurering av Westermos telefonmodem har funnits men det har inte sparats några underlag utifrån dessa, utan det har bara setts som lösa förfrågningar.
Eftersom Westermo har dotterbolag i England, Tyskland och Frankrike och dessa ska vara med och hjälpa till vid kravspecifikationsfasen ställdes en fråga till lämpliga personer i varje dotterbolag om de hade några önskemål och synpunkter på vad som ska finnas med och kanske också vad som inte behöver finnas med.
I och med att denna fråga hade lämnat Westermo Sverige började önskelistorna ta form hos
dotterbolagen. Några veckor senare hade det kommit in underlag för kravspecifikationen från samtliga dotterbolag.
Dessa underlag sammanställdes till en kravspecifikation som granskades av marknadsavdelningen. Efter några små justeringar av kravspecifikationen godkändes den av marknadsavdelningen och även min handledare. Kravspecifikationen finns bifogad att läsas i bilaga 10.
Intro till Westermos modem
För att kunna gå vidare och göra en bra design utifrån kravspecifikationen behövde undertecknad inhämta information om hur Westermos modem fungerar och vilka fallgropar som kan finnas för en oerfaren modemanvändare. Med hjälp av manualer och min handledare kom jag fram till följande. Westermos telefonmodem använder Hayes AT-kommandon för konfigurering genom en serieport som består av antingen en 9-polig eller 25-polig D-sub. Inställningar av telefonmodemet görs genom att skicka en vanlig ASCII sträng till modemet som består av ”at”(attention) följt av ett eller flera kommandon med parametrar, t.ex. ”atm0”, där ”m0” är kommandot som stänger av högtalaren. När modemet tar emot kommandon som kommandotolken i telefonmodemet känner igen sätts någon eller några bitar i modemets S-register till rätt värde för det inlästa kommandot. När rätt bit eller rätt bitar har blivit satta i S-registret skickas ett svar tillbaka ut på serieporten.
Telefonmodemen har ett par kommandon som är viktiga för verktyget som ska tas fram. Kommandot ”atq0” ställer in telefonmodemet att svara på kommandon och ”atv0” eller ”atv1” bestämmer om telefonmodemet svarar med numeriska svarskoder eller verbala svarssträngar. ”atq0” måste vara konfigurerat i telefonmodemet för att verktyget ska kunna få svar på kommandon som skickas till telefonmodemet och på så vis veta om de godtogs eller inte.
Strängarna som används vid kommunikationen mellan användare och telefonmodemen är vanliga ASCII strängar och dessa avslutas med ett i telefonmodemet konfigurerat värde för Carriage Return, CR(ASCII värdet 13). Om telefonmodemet har något annat värde än CR kommer kommunikationen med telefonmodemet bli komplicerat även för terminalprogrammen som finns för PC redan idag. Om ett annat tecken används som CR i modemet kan det bli konflikt med tecken som används vid
konfigurering av modemet. Alltså bör modemet vara så inställt att det har ASCII värde 13 som CR och att det returnerar svar, ”atq0” för att man ska få en bekräftelse på att kommandot gjordes i modem.
Design
Designproblemet angreps genom att först och främst lägga upp en översiktlig design över vilka större delar som programmet skall bestå av.
Kommunikationen
Kommunikationen mellan telefonmodemet och PCn som programvaran körs på kommer att ske genom en RS-232 port på PCn vilken också brukar kallas COM port.
Till MFC kan man importera en komponent som hanterar seriekommunikation genom RS-232 porten på PCn. Denna klass heter MSComm och det är den klass som används för att göra all kommunikation med telefonmodemet. MSComm klassen har ett antal variabler vilka möjliggör inställningar av COM portens hastighet, antal bitar, paritet mm. Den har en buffert för att ta emot data från COM porten och en för att skicka data till COM porten.
Funktionerna i denna komponent skall användas från flera klasser i mitt program och därför måste den här klassen vara global på något sätt. Därför skapas en klass som heter CCom vilken innehåller en pekare till en instans av MSComm klassen.
Alla klasser har en konstruktor som anropas när man deklarerar klassen. När CCom klassens
konstruktor anropas första gången skapas en instans av klassen och en pekare till denna returneras. När samma konstruktor anropas igen från en annan klass skapas ingen ny instans utan då returneras bara pekaren till instansen som skapades första gången konstruktorn anropades. På så vis får man en global klass som alla kommer åt men som anropas genom konstruktorn. Denna metod att göra en instans av en klass som flera klasser kan anropa kallas Singleton Pattern.
Användargränssnittet
Utseendet på programmet skall vara enkelt och lättöverskådligt och kunna se annorlunda ut för olika telefonmodem, beroende på att de kan ha olika inställningsmöjligheter. Hur det ser ut grafiskt har nog varje enskild individ ett eget tycke för så därför var ett förslag tvunget att finnas med redan i
kravspecifikationen. Detta för att det skall bli lättöverskådligt enligt alla och inte bara enligt mig. Eftersom telefonmodemen har lite olika inställningsmöjligheter så måste programmets
konfigureringssida kunna se annorlunda ut beroende på modemtypen.
Ett sätt att lösa detta på är att hårdkoda in vad de olika telefonmodem ska kunna göra för inställningar, men detta kan ge problem om eller rättare sagt när telefonmodem uppdateras med ny funktionalitet. Ett annat sätt är att skriva detta i en fil som läses av programmet. Dessa kan enkelt bytas ut om något telefonmodem förändras eller till och med om det kanske tillkommer telefonmodem som skall fungera i verktyget. Eftersom nästa krav handlar om expansion fick det bli att skriva en fil som beskriver hur just det telefonmodemet kan konfigureras.
Expansion
Ett av kraven i kravspecifikationen var att verktyget ska kunna expandera och kunna användas till nya telefonmodem som inte är ett krav att de fungerar med programvaran för tillfället. Detta gjorde att det var ett bra val att läsa in hur telefonmodemet skall konfigureras, eller hur verktygets konfigureringsflik skall se ut, från en fil som då är specifik för varje modemtyp. Modemets typ kan man utläsa av ett AT-kommando, ”ati9”, vilket returnerar ett programvarunummer, t.ex. ”4100-4300”, som gör att
programvaran kan avgöra vilket modem som är anslutet och med hjälp av detta visa rätt konfigureringsflik.
Design översikt
En enkel översikt över designen på programmet kommer nedan:
M o d e m C O M p o r t C C o m T D T o o lD lg C P r o p S h e e t C S e r ia l C A d va n ce d C C o n fig C T e r m in a l
T D -T o o l
Hur klasserna till slut blev efter att implementationen hade återfört några ändringar på någon klass och att några små klasser som inte var med i första designspecifikationen hade tillkommit kan ni se i
bilagorna 1-9. Där kan ni också se hur några av de viktigaste klassmetoderna agerar med varandra vid
Implementation
Verktyget för programmeringen
Verktyget som kommer att användas är MFC, Microsoft Foundation Class, vilket är ett objekt
orienterat programpaket som förenklar Windows API programmering. Detta verktyg finns i Microsoft Visual Studio 6.0 som är verktyget för implementeringen. Ett fönster i MFC kallas dialog, att skapa en dialog med MFC kan göras genom att rita upp utseendet i en ”resource” hanterare eller genom att skriva egen kod. Genom att använda sig av MS Visual Studio med MFC programpaketet får man det mesta med den grafiska återgivningen till användaren gratis.
Programmet består av ett antal klasser som jag nedan beskriver funktionen av. Om ni vill se hur klasserna agerar tillsammans vid någon händelse i programmet kan ni se det i bilagorna 1-9, där det finns UML schema på alla klasser och även interaktionsdiagram på de vanligaste händelserna.
CTDtoolDlg
En klass som skapas av MFC när man gör en ny MFC applikation och det blir då själva huvudklassen som gör initieringar av andra klasser som ska användas av programmet.
Denna klass skapade jag i Visual Studio 6.0 genom att rita upp ett fönster i ”resource” hanteraren. Jag har lagt in en händelsestyrd hantering av COM portens händelser vilka kan vara mottagen data, ändringar på statussignalerna osv. Dessa händelser gör i sin tur anrop från denna klass till berörda metoder i andra klasser.
De händelser från COM porten som denna klass hanterar är följande:
• CTS statussignal
• DCD statussignal
• RX data
CCom
Denna klass hanterar kommunikationen med modemet genom COM porten på PCn.
Kommunikationen sker med hjälp av en ActiveX komponent, MSComm, som har kapslat in metoder för att öppna, stänga, skicka och ta emot på COM porten. Det är runt MSComm komponenten som jag bygger CCom klassens parametrar och metoder. Det är i denna komponent som händelserna på COM porten kommer in i programmet. Dessa skickas vidare och hanteras dock i CTDtoolDlg klassen som beskrevs ovan för att anropa rätt metoder att skicka vidare signalerna till.
Den här klassen skapas med hjälp av Singleton Pattern vilket gör att den bara kan skapas en gång och alla kommer åt samma instans av detta objekt, d.v.s. den blir som en global klass.
Klassen innehåller metoderna Connect, Disconnect, Send, Receive, SendGetAnswer och
ReadModemSreg vilka är viktiga metoder för programmets funktionalitet och namnet på metoderna återspeglar funktionen.
Instanser av klasserna CTerminal och CConnection ingår i klassen.
CTerminal
CTerminal hanterar funktionaliteten av en terminal där användaren kan skicka och ta emot data genom den öppna COM porten som då är kopplad mot ett telefonmodem.
Klassen innehåller en Textbox som presenterar det som kommer in på COM porten och en Editbox där man kan skriva in ett kommando man vill skicka. När knappen Send trycks in skickas det kommando som står i Editboxen, med hjälp av CCom klassens Send metod, till modemet.
Om data sedan skulle komma in på COM porten kommer en signal att trigga CCom klassen att ta emot datat och sedan anropas en uppdateringsmetod i CTerminal klassen som skickar datat till terminalfönstret.
Terminal fönstret innehåller också ett fält med textvariabler som skall visa information om
uppkopplingen mellan modemet och värden. Detta fält uppdateras också med en metod i CTerminal som anropas vid en lyckad Connect i CCom klassen samt förstås även när en Disconnect görs i CCom.
CConnection
En klass som inte har några metoder utan som jag gjort för att hålla information om en uppkoppling och dess parametrar. Fungerar som en vanlig struct i C.
CAutoconnect
Klassen hanterar funktionaliteten att testa igenom alla möjliga uppkopplings alternativ genom COM porten till modemet när användaren väljer att trycka på knappen Autoconnect.
Eftersom det kan ta ganska lång tid när programmet ska söka efter ett modem på alla möjliga COM ports, baud rates, databits, parity och stopbits, kan man välja att göra Abort vilket denna klass hanterar med ett dialog fönster som har all fokus. När fönstret har all fokus riktad mot sig kan inte något annat fönster i programmet ta emot någon mushantering eller tangentbordstryckning. Detta gör att programmet inte tillåter användaren att göra något annat än att trycka Abort eller vänta till uppkoppling lyckas.
Klassen kör en FOR loop som provar att göra en uppkoppling genom CCom klassens Connect metod för alla möjliga fall, t.ex. COM1,115200,None,8,1 eller COM2,2400,7,Even,2.
Om en uppkoppling lyckas, Abort trycks eller om alla möjliga fall är provade avslutas loopen.
CBusy
Klassen innehåller en dialogruta som tar all fokus och ligger längst fram av dialogerna i programmet när den skapas. Den skapas då programmet gör något som inte får störas och ligger kvar tills metoden som skapade instansen har arbetat klart.
När denna dialog skapas skickas ett meddelande med, som sedan visas i dialogrutan för användaren, t.ex. texten ”Connecting…”.
CPropSheet
CPropSheet sköter hanteringen av de olika flikar som programmet har. Denna klass är tillagd genom ”resource” hanteraren i MFC för att sköta hanteringen av flikarna. Jag har endast modifierat att den ska lägga till fliken för Serial vid initiering.
Det finns 3 flikar i programmet och det är Serial, Configuration och Advanced. Dessa klasser är beskrivna nedan och klassen CPropSheet hanterar aktivering och fokusering av dessa flikar.
Cserial
Denna klass är en flik som visas när programmet startas och finns alltid kvar som en flik. De andra två flikarna som finns, Cconfig och Cadvanced, visas endast när ett modem är uppkopplat mot programmet. Allt på Serial fliken är statiskt ritat i ”resource” hanteraren, så den här sidan kommer alltid att se likadan ut oberoende av modemtyp.
Fliken har ett antal DroplistBoxar för att användaren skall kunna välja hur han vill koppla upp sig mot modemet, d.v.s. port, baud rate, databits, parity och stopbits. Här har jag också valt att implementera 3 knappar som gör följande.
Autoconnect skapar ett CAutoconnect objekt, vilket loopar igenom alla uppkopplingsalternativ och försöker göra en uppkoppling, den väntar tills detta objekt returnerat. Om CAutoconnect objektet inte lyckas skapa en uppkoppling mot ett Westermo modem visas det i en meddelandedialog, annars uppdateras terminalfönstrets information om den lyckade uppkopplingen.
Connect tar in parametrarna som användaren valt i på Serial fliken och anropar CComs Connect metod med dessa parametrar. När Connect metoden körs kommer COM porten att öppnas med de valda parametrarna och sedan kommer ”ati9” skickas för att se om det är ett Westermo modem som svarar. Om det är ett Westermo modem kommer det att svara med ett mjukvarunummer, t.ex. ”4100-4300”, detta kontrolleras då mot mjukvarunummer i en fil. Om mjukvarunumret finns med returnerar denna metod att den lyckades med en uppkoppling. Även denna metod visar genom en meddelandedialog om det inte blev en uppkoppling och annars uppdateras terminalfönstrets information om uppkopplingen. Disconnect gör bara ett enkelt anrop till CComs Disconnect metod vilken i sin tur stänger porten och uppdaterar terminalfönstrets information om uppkopplingen samt tar bort flikarna som eventuellt fanns med för modemkonfigureringen.
Cconfig
Cconfig är liksom Cserial en flik och denna heter Configuration i programmet. När denna flik sätts att vara aktiv sker en inläsning av vad som ska finnas med på den från en fil. Filen har ett specifikt namn för varje modemmodell eller om flera modemmodeller fungerar på samma sätt sätter man ett
samlingsnamn. Till det specifika filnamnet lägger man till ”cfg.ini” för Configuration flikens utseende och funktion.
I filen som jag beskriver senare kan det stå att man vill ha en DroplistBox eller en EditBox samt olika egenskaper för den valda optionen. T.ex. måste en DroplistBox ha en överskrift som beskriver vilken option det är man kan ändra, olika val i dropplisten i textform samt vilka kommando som skall skickas beroende på vilket val användaren gör. Syntaxen för hur dessa filer ska skrivas beskrivs även dessa lite senare i rapporten.
Klassen har 3 knappar som är hårdkodade på fliken, dvs. de finns alltid med och behöver inte beskrivas i filen.
Read knappen gör att PCn skickar iväg frågor till modemet på vad som står i modemets minne, som kallas S-registerna, där modemet har sina inställningar sparade. Svaren från dessa översätts sedan till AT-kommandon genom en fil med det specifika namnet, som beskrevs tidigare i detta avsnitt, samt med filtillägget ”cmd.ini”. Denna fil är en översättningsfil mellan S-register och AT-kommandon eftersom AT-kommandon används för att sätta kommandon men man kan inte fråga modemet hur ett AT-kommando är inställt.
När detta är gjort jämförs dessa kommandon med alla Options på Configuration fliken och presenterar därefter de inställda värdena på fliken.
Configure läser in de av användaren valda kommandona från alla Options på Configuration fliken och sänder därefter iväg AT-kommandona till modemet genom att använda CCom klassens Send metod. Om modemet inte returnerar ”OK” eller ”0” på ett
AT-kommando, vilket indikerar på att kommandot godtogs av modemet, visas detta för användaren genom en meddelandedialog.
Factory är en enkel knapp som endast skickar AT-kommandot ”at&f” till telefonmodemet och där efter läser in alla Options värden på Configuration fliken på nytt. Då är inställningarna i modemet och som presenteras på Configuration fliken fabriksåterställda.
Cadvanced
Denna flik fungerar som föregående klass med olika Options som initieras från fil men här med filtillägget ”adv.ini”. På den här fliken läggs lite mer avancerade optioner som inte passar på Configuration fliken där de vanligaste inställningarna i modemet kan göras. Här finns bara en
hårdkodad knapp Store, som sparar kommandona som användaren väljer genom de Options som finns på Advanced fliken.
COption
Denna klass innehåller metoder för att skapa, initiera, hämta och sätta options. Klassen definierar upp metoderna initOption, getValue och setValue som rent virtuella metoder, alltså utan kod i denna klass, vilket gör att de klasser som ärver COption måste implementera dessa. Funktionaliteten för dessa metoder kommer alltså implementeras i följande klasser för att man på ett enkelt sätt ska kunna hantera optionerna på samma sätt i alla olika optionsklasser.
Klassen har en statisk metod som skapar olika options utifrån fil. Denna statiska metod, createOption, anropas med en parameter som är ett tecken från vilket man skapar en option, t.ex. D är en Droplist, E är en EditBox o.s.v. Metoden anropar sedan initOption för den skapade Optionen och returnerar en pekare till Optionen som skapades och denna läggs i en länkad lista som är enkel att gå igenom då man vill göra en getValue eller setValue, som hämtar optionens värde respektive sätter optionens värde i modemet.
Följande klasser ärver från COption:
CComboBoxOption
Klassen har en ComboBox, droplist, och en statisk text som överskrift, vilken står över droplisten och beskriver vad det är som kan konfigureras. Denna Option initieras med placering, överskrift och val som användaren kan göra samt vilka kommandon som skall skickas beroende på val. Dessa initeringsvärden skall stå i filen som beskriver fliken.
CEditBoxOption
I den här klassen finns som i CComboBoxOption en statisk text som överskrift och en EditBox, textfält, för att kunna skriva in numeriska värden i. Dessa är dock inte låsta till ett visst värde eftersom olika kommandon kan ta olika intervall och även enskilda värden. Om ett felaktigt värde, t.ex en bokstav, skrivs in kommer en meddelandedialog visa detta för användaren.
CPass_number
Klassen är till för att kunna spara Callback nummer och Password, vilket är en option i vissa av Westermos telefonmodem. Den har två överskrifter med typen statisk text och två EditBoxar som initieras från fil. Kommandot som skall skickas står med i filen som klassen initieras ifrån. Till kommandot läggs givetvis också värdena som står i EditBoxarna om de är korrekta.
När klassens getValue anropas kommer metoden att kontrollera så att telefonnumret har mellan 1-34 siffror och om ett password finns. Password måste vara mellan 6-12 tecken för att vara godkänt. Denna kontroll gör att klassen bara kan användas till denna modemfunktion och inte som någon generell klass som används till någon annan option.
CDialBack
Även den här klassen är låst för användning av modemfunktionen att spara dialback och dess optioner. En dialback har tre överskrifter, en för telefonnumret som skall ringas upp, en för hur många
uppringningsförsök som modemet skall göra innan dialbacken körs och en för hur lång tid modemet skall vänta innan det försöker att göra en återuppringning. Dessa tre EditBoxar kontrolleras när getValue körs så att ett godkänt värde finns i EditBoxen.
Kommunikationsdelen av programmet sattes ihop genom att implementera klassen CCom, CConnection och CTerminal för att få kontakt med modemet. Dessa klasser användes först bara genom en enkel knapp i programmets huvuddialog där CCom metoden connect anropades med hårdkodade parametrar för port, baud, data bits, parity och stopbits. När detta fungerade byttes den enkla knappen ut mot Cserial fliken så att man kunde välja själv vilken COM port och andra parametrar för kommunikationen med modemet eller att göra en Autoconnect.
Sedan utökades programmet till att kunna hantera flikarna som ska konfigurera modemet. Här var inläsningen av hur flikarna skall se ut det som inbar det tyngsta arbetet. COption blev mallen för hur optionerna skulle arbeta. Genom att skapa optionerna genom COptions statiska metod kan pekare till de olika optionerna läggas i en Array av COptions pekare. Dessa har därigenom samma metoder som behövs för att sköta hanteringen av dom på flikarna, eftersom COption har de viktiga metoderna som rent virtuella och dessa då implementeras i underklasserna. Arrayen med COptions pekare är sedan enkel att bearbeta beroende på vad användaren vill göra på fliken, t.ex. Read eller Configure, då är det bara att loopa igenom Arrayen med COptions pekare.
Modemfilerna
Varje modem modell har ett programvarunummer lagrat i modemet och det kan man läsa ut om man skickar kommandot ”ati4” eller kommandot ”ati9” till modemet. Anledningen till att man behöver använda sig av både ”ati4” och ”ati9” är för att de olika modemen har mjukvarunumret lagrat på olika kommandon. Då Westermo nu har bestämt sig för att svara med mjukvarunummer på ”ati9” borde det inte bli några problem med framtida modem, men för att stödja gamla modemen måste man alltså också läsa ur kommandot ”ati4”.
Eftersom modemen har lite olika funktionalitet beskrivs hur programmets Configuration och Advanced flik ska se ut genom en fil som följer med programmet. Varje modem har en fil för Configuration fliken och en fil för Advanced fliken.
En annan fil med namnet ”modem.ini” beskriver vilken fil programmet ska använda för att rita upp Configuration fliken respektive Advanced fliken. Detta görs genom att programmet matchar programvarunumret i modemet mot ett programvarunummer på en rad i filen och där står då också filnamnen på de filer som beskriver Configuration och Advanced fliken för just den modemtypen. Om programvarunumret inte finns med i ”modem.ini” filen kopplas inte modemet upp mot programmet. Filen ”modem.ini” gör alltså så att man kan styra vilka modem programmet ska kunna hantera genom modemens mjukvarunummer, vilket då leder till att konkurrenter inte kan använda sig av verktyget till sina modem.
Filerna som beskriver hur flikarna Configuration och Advanced ska se ut är vanliga textfiler som beskriver vad det skall vara för option, Droplist, Editbox eller något annat, och på vilken plats den skall placeras på fliken.
Om det är en hel kolumn med options som ska befinna sig på samma placering i X-led behövs det bara skrivas placeringskoordinater på den första optionen.
Westermos modem tar emot AT-kommandon men sparar sedan denna information i register i modemet. I modemen finns ett kommando ”at&v” som presenterar modemets inställningar, men där presenteras dock inte alla inställningar utan bara en delmängd av alla inställningar. P.g.a. detta har jag valt att läsa ur modemens register, vilka kallas S-register, för att på så sätt kunna läsa ur alla
inställningar i modemet på ett gemensamt sätt. Däremot vill jag presentera Configuration och Advanced fliken baserat på AT-kommandon som användaren enklare kan koppla mot manual och funktionalitet vilket är svårt med S-registerna.
För att få ett gränssnitt mellan S-registerna och AT-kommandon används en fil som beskriver detta kopplingen mellan At-kommandon och S-register. Denna fil, en för varje modemtyp, används sedan för att översätta hur modemet är inställt med hjälp av att läsa ur modemets register och därefter visas detta för användaren på Configuration och Advanced fliken.
Configuration flikens modemfil
Fliken Configuration är indelad i 3 kolumner som grupperar olika inställningar i modemet till ”Serial”, ”Call” och ”Line”. I filen börjar Serial gruppens inställningar med #SERIAL# och avslutas sedan med en #, de andra 2 grupperingarna beskrivs på samma vis i filen.
Optionerna(inställningarna) har följande syntax:
<optiontyp(rubrik)[droplistval]{kommando}> om Droplist Option. <optiontyp(rubrik){kommando}> om Editbox Option.
optiontyp = D för Droplist och E för Editbox
Här nedan visas ett exempel på hur en fil för Configuration fliken ser ut till en TD-32B med filnamnet ”td32b_0_cfg.ini”. I filen skrivs mina kommentarer med kursiv text.
#SERIAL# max 9 st boxar
(25,25) position på början av blocket med olika options
<D betyder att det är en droplistbox (Command Echo[En])max 23 st tecken på överskriften
[Disable,Enable,]max 22 tecken per option {E0|E1} detta är kommandon som skickas till modemet> <D (Connect message ctrl[Wn]) [DTE speed,Line speed & protocol,DCE speed,] {W0|W1|W2}> <D (Result code form[Vn]) [Short(terse),Long(verbose),] {V0|V1}>
<D (Extended result codes[Xn]) [X0,X1,X2,X3,X4,] {X0|X1|X2|X3|X4}> <D (DSR override [&&Sn]) [ON,ON after answer tone,] {&S0|&S1}>
<D (DTR option[&&Dn]) [Ignored,ESC sequense,Hang up,Soft reset,] {&D0|&D1|&D2|&D3}> <D (RLSD option[&&Cn]) [ON,Follow carrier,] {&C0|&C1}>
<D (Flow control[&&Kn]) [Disable,RTS/CTS,XON/XOFF,Transparent XON/XOFF,] {&K0|&K3|&K4|&K5}>#
#CALL# max 5st boxar (184,25)
<D (Speaker Option[Mn]) [OFF,ON when calling,ON,OFF when calling,] {M0|M1|M2|M3}> <D (Speaker volume[Ln]) [Lowest,Low,Medium,High,] {L0|L1|L2|L3}>
<D (Single line mess[\Vn]) [Enable,Disable,] {\V0|\V1}>
<D (Dial abort option[&&An]) [Enable abort,Disable abort,] {&A0|&A1}>
<E betyder att det är en EditBox (Rings to auto-answer[S00]) överskrift {S00=} kommando som skickas ># #LINE# max 5st boxar
(343,25)
<D (Line modulation[+MS=]) [V21,V22,V22B,V23C,V32,V32B,V34,B103,B212,]
{+MS=V21;|+MS=V22;|+MS=V22B;|+MS=V23C;|+MS=V32;|+MS=V32B;|+MS=V34;|+MS=B103;|+MS=B21 2;}>
<D (Data compression[%Cn]) [Disable,Enable MNP5,Enable v.42,Enable v.42 and MNP5,] {%C0|%C1|%C2|%C3}>
<D (Operating mode[\Nn]) [No error correction,Direct mode,Reliable mode,Auto reliable mode,LAPM error correction,MNP error correction,]
{\N0|\N1|\N2|\N3|\N4|\N5}>
<D (Line quality, Retrain[%En]) [Disable Auto,Enable Auto,Enable Fallback/Fallforward,] {%E0|%E1|%E2}> #
---
Advanced flikens modemfil
Filen för Advanced fliken ser i stort sett likadan ut med lite andra options men de är också beskrivna när de uppkommer för första gången i filen.
AT-Hayes vs. S-register mappningsfilen
Filen som beskriver vilka S-register som ändras vid ett kommando visas på nästa sida och det är för samma modemtyp som ovan och den filen heter ”td32b_0_cmd.ini”, där ”cmd” säger att den är till för att visa AT-kommandomappningen mot S-register:
Överst kommer alla S-register samt de +kommandon som är aktuella vid konfigurering av detta modem. Det kan skilja sig lite mellan olika modemtyper och modeller. Därefter kommer alla kommandon som finns till gängliga på detta modem samt vilka S-register som är satta när det kommandot är aktiverat. Sist i filen kommer de S-register och +kommandon som inte sätts av något kommando utan av själva S-registernumret eller själva +kommandot. Filen är här uppdelad i tre spalter för att det ska vara lättare att överblicka filen. I filen skrivs mina kommentarer med kursiv text.
S-register samt +kommandon S00,S02,S03,S04,S05,S06,S07,S0 8,S10,S11,S12,S13,S14,S21,S22,S 23,S25,S27,S29,S30,S31,S36,S38, S39,S40,S41,S48,S91,+MS Kommandomappning mot S-register \A0 S40:6=0,7=0 \A1 S40:6=1,7=0 \A2 S40:6=0,7=1 \A3 S40:6=1,7=1 B0 S27:6=0 B1 S27:6=1 &B0 S27:7=0 &B1 S27:7=1 &C0 S21:5=0 &C1 S21:5=1 %C0 S41:0=0,1=0 %C1 S41:0=1,1=0 %C2 S41:0=0,1=1 %C3 S41:0=1,1=1 &D0 S21:3=0,4=0 &D1 S21:3=1,4=0 &D2 S21:3=0,4=1 &D3 S21:3=1,4=1 E0 S14:1=0 E1 S14:1=1 %E0 S41:2=0,6=0 %E1 S41:2=1,6=0 %E2 S41:2=0,6=1 &G0 S23:6=0,7=0 &G1 S23:6=1,7=0 &G2 S23:6=0,7=1 \K0 S40:3=0,4=0,5=0 \K1 S40:3=1,4=0,5=0 \K2 S40:3=0,4=1,5=0 \K3 S40:3=1,4=1,5=0 \K4 S40:3=0,4=0,5=1 \K5 S40:3=1,4=0,5=1 &K0 S39:0=0,1=0,2=0 &K3 S39:0=1,1=1,2=0 &K4 S39:0=0,1=0,2=1 &K5 S39:0=1,1=0,2=1 -K0; S40:0=0,1=0 -K1; S40:0=1,1=0 -K2; S40:0=0,1=1 L0 S22:0=0,1=0 L1 S22:0=1,1=0 L2 S22:0=0,1=1 L3 S22:0=1,1=1 M0 S22:2=0,3=0 M1 S22:2=1,3=0 M2 S22:2=0,3=1 M3 S22:2=1,3=1 &M0 S27:0=0,1=0,3=0 &M1 S27:0=1,1=0,3=0 &M2 S27:0=0,1=1,3=0 &M3 S27:0=1,1=1,3=0 \N0 S27:0=0,1=1,3=1 \N1 S27:0=0,1=0,3=0 \N2 S27:0=1,1=0,3=1; S36=4;S48=7 \N3 S27:0=1,1=0,3=1; S36=7;S48=7 \N4 S27:0=1,1=0,3=1; S48=0 \N5 S27:0=1,1=0,3=1; S36=4;S48=128 Q0 S14:2=0 Q1 S14:2=1 &Q0 S27:0=0,1=0,3=0 &Q5 S27:0=1,1=0,3=1 &Q6 S27:0=0,1=1,3=1 &R0 S21:2=0 &R1 S21:2=1 &S0 S21:6=0 &S1 S21:6=1 V0 S14:3=0 V1 S14:3=1 \V0 S31:0=0 \V1 S31:0=1 W0 S31:2=0,3=0 W1 S31:2=1,3=0 W2 S31:2=0,3=1 X0 S22:4=0,5=0,6=0 X1 S22:4=0,5=0,6=1 X2 S22:4=1,5=0,6=1 X3 S22:4=0,5=1,6=1 X4 S22:4=1,5=1,6=1 S-register samt +kommandon som inte sätts av något AT-kommando
S00 S02 S03 S04 S05 S06 S07 S08 S10 S11 S12 S13 S25 S29 S30 S38 S91 +MS
Filerna som beskriver modemets olika egenskaper och hur programmets flikar ska se ut ligger i en mapp som heter ”ini” som finns i samma mapp som programmet. Dessa filer är gjorda för att det skall vara enkelt att uppdatera så att programvaran stödjer nya och nyuppdaterade modemtyper och
modeller. Detta gör man genom att byta ut filen som kopplar ihop modemets programvarunummer med modemfiler och samt lägga till nya filer för det uppdaterade eller nya modemet.
Kritisk analys
Många problem kan uppkomma under ett projekt som är mer eller mindre lätta att lösa. Här nedan redogörs lite snabbt och enkelt några av de problem som ag råkade stöta på i samband med det här projektet.
De två första faserna var att ta fram en kravspecifikation med hjälp av inblandade på Westermo. Den delen var inte något som satte käppar i hjulet för projektet. Designdelen, vilken beskriver hur
programmet ska vara uppbyggt, fortlöpte också utan några större problem. När implementationen började kom också problemen. Om det finns problem som man kanske inte har tänkt på när designen gjordes kommer dessa att visa sig i implementationsfasen. Men även om man tänkt på det mesta så finns det problem som har med själva implementeringen att göra och dessa måste bearbetas oavsett hur bra designen är gjord. Det första problemet som beskrivs härnäst är ett rent
implementeringsproblem som ställde till det lite.
Det första problemet kom när kommunikationsdelen byggdes ihop och det inte triggades några händelser på när ett tecken kom i på COM porten. Eftersom hela designen byggde på att
händelsesignaler skickades när något hände på COM porten vara det något som måste lösas. Många timmar passerade och i och med det ökade stressen och även mitt tålamod började minska.
Dokumentationen till ActiveX komponenten MSComm är väldigt sparsam och om det finns, så är det dokumenterat för Visual Basic. Alltså måste man utforska lite själv för att få det att funka som man vill. Problemet löstes tillslut med hjälp av en tråd på något diskussionsforum för programmerare, vilket det var exakt kommer jag inte ihåg. Problemet var i alla fall enkelt fixat. En parameter till MSComm komponenten, RThreshold, var initialt satt till 0 och skickade därmed inga händelsesignaler när tecken kom in på COM porten. Värdet skulle sättas till hur många tecken man ville skulle komma in på porten innan en signal skickades. RThreshold sattes enkelt till 1 vid initieringen av komponenten och då triggades händelserna direkt. Ett enkelt fel att lösa men inte så lätt hitta i en, från min sida sett, alldeles för tunn dokumentation. Därefter flöt implementationen av kommunikationsdelen på utan större problem.
Nästa felspår som jag kom in på var när all kod var färdig skriven och programmet fungerade på PCn där programmet utvecklats samt med de modem som var med som test objekt. Dessa var ju dock inte alla modem som skulle fungera med programmet. Manualer till de modem som jag inte hade tillgång till hade använts för att ta fram funktioner även för dessa modem.
I metoden som kopplar upp modemen gjordes en kontroll som kontrollerade att det var ett Westermo modem som höll på att ansluta sig till programmet. Den läste av resultatet av ”ati4” där det skulle stå ”Westermo Teleindustri AB” i de modem som programmet skulle stödja. Så var dock inte fallet och det fanns inte dokumenterat i några manualer utan kunde endast utläsas ifrån programkoden i
modemet eller förmodligen också från Design Specifikationen på dessa modem. Det hade jag i alla fall inte gjort och det upptäcktes inte förrän programvaran hade lämnats till Supportavdelningen för att de skulle testa programmet och ge tillbaka synpunkter på hur det fungerade. Det var inte svårt att lösa det här problemet heller, utan den kontrollen kunde tas bort eftersom programmet ändå läser av ett unikt programvarunummer som Westermo har specificerat upp för den produkten och modemet kan på så vis verifieras vara ett Westermo modem. Det fanns alltså en dubbel kontroll som nu försvann vilket gör programmet något men inte obetydligt snabbare vid uppkopplingen. Det här var ett enkelt och inte alls ett tidsförödande problem men jag ville ändå påvisa det.
Därefter kom ännu ett problem som inte uppstod när programmet kördes på utvecklings PCn med de modem som fanns som testobjekt. PCn hade Win2000 installerat och när föregående problem var löst ville jag testa igenom programvaran lite extra innan jag skickade det åter till Supportavdelningen, vilket inte var till fullo gjort förra gången. Programmet fungerade inte alls på Win98 vilket var ett tungt arbete att lösa eftersom Visual Studio inte var installerat på någon Win98 PC och därför fick jag använda mig av spårutskrifter i koden för att se var programmet gick fel. Dessa gjordes genom att kasta upp dialogrutor där en feltext presenterades. Efter en del sökande insåg jag att det var MSComm
komponenten som inte fungerade korrekt utan kraschade programmet. Jag blev lite orolig att den kanske inte fungerade likadant på alla operativsystem men det stod inget sådant i den lilla
dokumentationen som fanns. Min handledare fick nu bistå mig med idéer med vad jag kunde göra för att få det att fungera. Ett lite program som min handledare hade skrivit och som använde MSComm komponenten provades på den Win98 PC som jag körde på och det fungerade. Det betydde att det skulle vara fel på min kod som skapade MSComm komponenten. Hans inställningar på MSComm komponenten jämfördes med mina utan att hitta något annorlunda. Det enda som skilda dessa åt var att i min applikation skapades MSComm komponenten med kod, eftersom den låg i en vanlig klass och inte direkt i en dialogruta vilket den gjorde i min handledares där den alltså skapades som en direkt resurs genom dialogen. Jag försökte att få igång den genom att sätta alla möjliga parametrar på
komponenten men fick inte igång den på Win98 PCn. Efter att jag försökt alldeles för länge enligt min mening stoppade jag in den i Cserial som var den närmaste dialog som jag kunde stoppa den i, d.v.s. jag skapade den automatiskt i ”resource” hanteraren och ställde dess parametrar där, utan att behöva skriva en massa kod för den. Det var så som min handledares MSComm komponent var skapad. När sedan CCom objektet skapades, där MSComm komponenten var skapad från början, gjorde jag en pekare till MSComm objektet i Cserial som jag använde på samma sätt som tidigare.
Ett större fel på designen hittades uppdagades när implementationen började. I designen beskrivs att programmet ska läsa ur konfigureringen utav ett AT-kommando, ”at&v”. Detta kommando skulle returnera alla de kommandon som behövdes, men så var inte fallet när det skulle implementeras. ”at&v” kommandot svarade med en ganska lång svarssträng vilket resulterade i att det tog en lång tid läsa in detta kommando, vilket inte är roligt för användaren. Detta insåg jag inte att det skulle vara något större problem förrän det var implementerat och jag själv satt och testade det. Om modemet då kör på en seriell hastighet på 300 baud så tar det ca 30 sekunder innan man fått tillbaka hela
kommandosträngen. S-registerna i modemet håller nästan all information om modemets konfigurering men på ett lite komplext sätt. Även att ta in alla S-register från modemet tar lång tid men då har man all information tillgänglig därigenom och behöver inte komplettera något som jag hade behövt om jag använde mig av ”at&v”. Att läsa in S-registerna blev alltså mitt val att implementera detta och alltså fick jag sätta mig ner och göra om en liten del av designen. Det jag hade gjort redan var inte så
komplicerat men hur jag skulle begripa problemet med att sätta ihop S-registerna till kommandon blev det lite funderande på. Med stöd av min handledare fick jag lov att inse att jag blev tvungen att skapa en fil som beskriver hur kommandona är knutna till S-registerna. Men alla modem fungerar inte likadant med AT-kommadona och dess S-register, därför blev det en modemkommandofil för varje modemtyp som har gemensam funktionalitet och samma struktur i S-registerna.
Ifrån min synvinkel sett kan jag förstå hur projekt kan bli försenade om stöter på lite större och mer komplicerade problem än de som jag hade. Jag klarade av mina svåraste problem på ett par dagar, vilket ändå stressade på mig rejält, men jag klarade min deadline om ändå ganska precis.
Litteraturförteckning
Kruglinski, Shepherd, Wingo(August 1998), Programming Microsoft Visual C++ Fifth Edition, Microsoft Press
The MSDN online help, WWW, http://msdn.microsoft.com/, (2003)
Developer.com, WWW, http://www.developer.com/, (2003)
Objektorienterad programutveckling i C++ med Daniel Flemström, WWW,
http://www.idt.mdh.se/kurser/cd5250/dfm03/index.html, (2003)
Bilaga 1
+Instance() : static CCom* wchar_t +Connect() : bool
+Disconnect() : bool +Send() : CString bool +Receive() : CString wchar_t +SendGetAnswer() : bool +FindModem() : bool +CalcSreg() : bool +ReadModemSreg() : bool +DisablePage() : void
+m_comm : CMSComm* wchar_t +m_connection : CConnection wchar_t +m_terminal : CTerminal wchar_t +busy : bool
+connecting : bool +m_timer : int -time : int
+m_modemfile : CString wchar_t +programdir : CString wchar_t -p_comm : static CCom* wchar_t -p_parent : static CWnd* wchar_t
CCom
Skapas av TDtoolDlg och det blir dess förälder.
Klassen kommer att kunna användas av alla andra klasser, dvs den blir som en global klass.
+onSendButton() : void +UpdatePrompt() : bool +UpdateConnection() : bool -m_prompt : CEdit wchar_t -m_command : CEdit wchar_t -m_status : CStatic wchar_t -m_port : CStatic wchar_t -m_baud : CStatic wchar_t -m_parity : CStatic wchar_t -m_data : CStatic wchar_t -m_stop : CStatic wchar_t -m_software : CStatic wchar_t -m_modem : CStatic wchar_t
CTerminal:public CDialog
1
1
+connected : bool +port : CString wchar_t +baud : CString wchar_t +parity : char
+data : CString wchar_t +stop : CString wchar_t +modem : CString wchar_t +software : CString wchar_t
CConnection
1
1
Bilaga 2
+OnSetActive()() : wchar_t +OnInitDialog() : wchar_t +OnConnect() : void +OnDisconnect() : wchar_t +OnAutoconnect() : wchar_t -m_port : CComboBox wchar_t -m_baud : CComboBox wchar_t -m_data : CComboBox wchar_t -m_parity : CComboBox wchar_t -m_stop : CComboBox wchar_tCserial:public CPropertyPage +onTimer() : void
+onCommEvent() : void
+m_pSheet : CPropertySheet* wchar_t -m_comctrl : CMSComm wchar_t
CTDtoolDlg:public CDialog +OnSetActive() : wchar_t +OnKillActive() : wchar_t +OnConfigure() : void +OnRead() : void +OnClear() : void
-m_options : CArray<COption*> wchar_t -m_buttons : CArray<CDialog*> wchar_t
Cconfig:public CPropertyPage
+OnStore() : void +OnSetActive() : wchar_t +OnKillActive() : wchar_t
-m_options : CArrar<COption*> wchar_t -m_buttons : CArrar<CDialog*> wchar_t Cadvanced:public CPropertyPage
-m_serial : CSerialPage wchar_t -m_configure : CSerialPage wchar_t -m_advance : CSerialPage wchar_t -m_profile : CSerialPage wchar_t CPropSheet:public CPropertySheet 1 1 1 1 1 1 1 1 +OnLoadbutton() : void +Except() : void
-p_parent : CConfig* wchar_t CLoadButton:public CDialog
+OnSavebutton() : void +Except() : void
-p_parent : CConfig* wchar_t CSaveButton:public CDialog 1 1 1 1 +OnAbort() : void +OnInitDialog() : bool -m_message : CStatic wchar_t -m_messagestr : CString wchar_t -p_parent : CSerial* wchar_t -m_abort : bool
CWaiting:public CDialog
+OnPaint() : void
-m_message : CStaticwchar_t CBusy
Bilaga 3
+optionInit() : bool +getValue() : CString wchar_t +setValue() : bool -m_number : CEdit wchar_t -m_retries : CEdit wchar_t -m_reconnect : CEdit wchar_t -m_headline1 : CStatic wchar_t -m_headline1 : CStatic wchar_t -m_headline2 : CStatic wchar_t -m_value : CString wchar_t
CDialBack:public CDialog,public COption
+optionInit() : bool +getValue() : CString wchar_t +setValue() : bool -m_number : CEdit wchar_t -m_password : CEdit wchar_t -m_headline1 : CStatic wchar_t -m_headline1 : CStatic wchar_t -m_value : CString wchar_t
CPass_number:public CDialog,public COption +createOption() : static COption* wchar_t
+optionInit() : virtual bool +getValue() : virtual CString wchar_t +setValue() : virtual bool
COption
+optionInit() : bool +OnOption() : void -m_value : CString wchar_t -m_text : CString wchar_t -m_buttontext : CButton wchar_t CButtonOption:public CDialog +optionInit() : bool
+getValue() : CString wchar_t +setValue() : bool
-m_index : CComboBox wchar_t -m_headline : CStatic wchar_t -m_value : CStringArray wchar_t
CComboBoxOption:public CDialog, public COption
+optionInit() : bool +getValue() : CString wchar_t +setValue() : bool -m_index : CEdit wchar_t -m_headline : CStatic wchar_t -m_value : CString wchar_t
CEditBoxOption:public CDialog, public COption
UML class structur
Bilaga 4
Interaction class diagram
When user press Connect
Cserial::OnConnect() CCom::Connect CCom::SendGetAnswer()
Return retval
CCom::Send() MSComm
Returns true
CCom::Receive()
Wait for a time depending on baud rate
Returns the value
Sets the output buffer with the command
Reads the input buffer Saves buffer in value
Returns the value
If value=="OK" or "0" retval=true else retval=false If an exception has occured Return false MessageBox that connection failed Save connection parameters CCom::CTerminal::UpdateConnection() Save connection in CStatic variables that shows the connection in dialog Open port with
chosen values throws exception if something goes wrong
Sends "atq" and waits for
answer Sends "atq"
Adds pages for configuration and advanced
Bilaga 5
Cserial::OnAutoconnect() CWaiting::DoModal CWaiting::OnInitDialog
FOR loop calls CCom::Connect() until retval==true or all ports,baud, databits,parity and stopbis are checked Returns true if retval==true
EndModalLoop=1 if retval==tru e else EndModalLoop=0 If Waiting ends with endvalue==0 then messageBox that connection failed
Interaction class diagram
When user press Autoconnect
Interaction class diagram
When user press Disconnect
Cserial::OnDisconnect() CCom::Disconnect()
Return true
CCom::CTerminal::UpdateConnection()
Save connection in CStatic variables that sho ws the connection in dialog and close the port Sets all the connection
parameters to "-" in the CCom class connection variable
Bilaga 6
C co nfig ::OnSetActive() C Op tion ::createOption()
Interaction class diagram
W hen user press the Config page
O p en s th e co nn e cte d mo d em s c fg .in i file a n d re a ds wh at o ption s ho u ld be in c on fig u re p ag e .
W h ile cfg .in i file no t at EO F
An o ption tha t inh e rits fro m CO ption is cre ated d e pe nd in g on w ha t th e file s ays it sh uo ld b e. in itO ption is ca lle d fo r th e rig ht cla ss
Re tu rn *CO p tion If op tio n ==D ro plis t sa ve in CO p tion s array e lse if ==Bu tto n sa ve in CBu tton a rra y
Cadvanced ::OnSetActive() C Op tion::createOption
Interaction class diagram
W hen user press the Advance page
O pe n s the c on n ec te d m o de m s a dv .in i file a n d re a ds wh at o ption sh o uld b e in co n fig ure pa g e.
W hile a d v.in i file no t a t EOF
An o ption tha t inh e rits fro m CO ption is cre ated d e pe nd in g on w ha t th e file s ays it sh uo ld b e. in itO ption is ca lle d fo r th e rig ht cla ss
Re tu rn *CO p tion If op tio n ==D ro plis t sa ve in CO p tion s array e lse if ==Bu tto n sa ve in CBu tton a rra y
Bilaga 7
Cconfig::OnConfigure() COption::getValue()
Interaction class diagram
When user press the Configure button
Calls the method getValue for the current COption* in the Array.
While Arrayen with COption* not at end. Get the next in the Array.
Gets the current selection and returns the command to be sent to the modem. Return str
Adds the string to command string that will be sent to modem. If the command string is longer than 30 chars a new command string is added.
CCom::SendGetAnswer()
Calls the method SendGetAnswer with the current command string
Sends the string and returns the answer. Return answer
If not "OK" or "0" was the answer then messageBox to inform user that error.
While Arrayen with command strings not at end. Get the next string in the Array.
Bilaga 8
Cconfig::OnRead() CCom::ReadModemSreg()
Interaction class diagram
When user press the Read button
Sends questions about the S-register to the modem. Stores them in an S-reg Array. Return S-register Array
Puts the returned Array of strings to one long string.
CCom::CalcSreg()
Return Array of command strings
Calculates the S-registers Array to an string of commands that are set according to the S-register values.
COption::setValue()
FOR loop that goes through the options Array.
If the options value is in the long command string then set to that value else sets the "" v alue.
Cconfig::OnClear() COption::setValue()
Interaction class diagram
When user press the Clear button
Why the command string is empty the value will be set to "". FOR loop that goes
through the options Array.
Bilaga 9
CButton::OnOption() CCom::SendGetAnswer()
Interaction class diagram
W hen user press an CButton button
Sends the string from CButton and retruns the answer. Gets the command
string from CButton.
Return answer
If not "OK" or "0" was the answer then messageBox to inform user that error.
Cadvanced::OnStore() COption::getValue()
Interaction class diagram
When user press the Store button
Return str Calls the method getValue for the current COption* in the Array.
While Arrayen with COption* not at end. Get the next in the Array.
Gets the current selection and returns the command to be sent to the modem.
CCom::SendGetAnswer()
Calls the method SendGetAnswer with the current command string
Sends the string and returns the answer. Return answer
If not "OK" or "0" was the answer then messageBox to inform user that error.
Distribution Ärende/Item Datum/Date Reg nr/Reg no Rev Sida/Page
R&D Westermo TD-tool 2003-06-30 Examworker 1 33(41)
Utfärdad av/Issued by Godk/Appr PTI
Scope
Product overview
This project intends to design a tool to make the configuration of telephone modems more simple.
Document overview
The purpose of this document is to describe the software requirements of the TD-tool and the documents intended readers are the development department.
Bilaga 10
Datum/Date Reg.nr/Reg.No. Rev Godk/Appr Sida/Page 2003-06-30 Examworker 1 34(41)
Contents
1
Scope
33
1.1 Product overview 33 1.2 Document overview 332
Contents
34
3
References
35
3.1 Project documents 35 3.2 Other documents 35 3.3 Other sources 354
Product
36
4.1 General 36 4.2 Requirements 36 4.2.1 Hard Requirements 364.2.1.1 Graphic user interface 36
4.2.1.2 Supported platforms 36
4.2.1.3 Supported modems 36
4.2.1.4 Future expansion 37
4.2.1.5 Configuration 37
4.2.1.6 Store the current configuration 37
4.2.1.7 Restore a stored configuration 37
4.2.1.8 Restore to factory settings 37
4.2.1.9 Show configurations 37
4.2.2 Soft Requirements 37
4.2.2.1 Auto detection of modem 37
4.2.2.2 Print configuration 38 4.2.2.3 Direct communication 38 4.2.2.4 PLC settings configuration 38 4.2.3 Other requirements 38 4.3 Design 38 4.3.1 General 38 4.3.2 Interface 39 4.3.2.1 User interface 39 4.3.2.2 Communication interface 39 4.3.2.3 Other interface 39
5
Revision
40
6
Definitions and abbreviations
41
Datum/Date Reg.nr/Reg.No. Rev Godk/Appr Sida/Page
2003-06-30 Examworker 1 35(41)
References
Project documents
Ref Document Rev Date Resp/Appr
1 AT-commands for modem type 2 TD-toolLayout
Other documents
Ref Document Rev Date Resp/Appr
Other sources
Datum/Date Reg.nr/Reg.No. Rev Godk/Appr Sida/Page
2003-06-30 Examworker 1 36(41)
Product
General
The TD-tool shall help the support department to decrease their work to help the consumers to configure their telephone modems with AT-commands. It is often a lot of reading in the manual before you can get it right. Therefore, a software product for PC shall be made to make this easier. The software will only be in English version.
Requirements
Hard Requirements
The TD-tool software shall have the following hard requirements:
• Graphic user interface
• Supported platforms
• Support different modems
• Future expansion
• Configure the modem
• Store/restore the current configuration
• Restore to factory settings
• Show configurations
Graphic user interface
The user interface shall be simple and easy to understand. There shall be buttons and other smart choices to configure the modem with the wanted values.
Supported platforms
The software shall work on PC stations that have a COM port and a OS from Microsoft from version 95-2000 and XP.
Supported modems
Modems that shall be supported by the TD-tool are
• TD-32B family
• TD-33 family
Modems that may be supported by the TD-tool in the first version are
• TD-34 family
Datum/Date Reg.nr/Reg.No. Rev Godk/Appr Sida/Page
2003-06-30 Examworker 1 37(41)
Future expansion
The TD-tool shall be designed for a future expansion of supported modems. This may be done without have to recompile the source code. This could be done by having files for a specific modem that the software reads from. In this files you may specify how the interface to the user will look like and there follow also what options you could do to configure the modem.
Configuration
The program shall send ASCII strings to the modem over the RS-232 interface. AT-commands that are available in the program may difference depending on what modem it is connected to. To see these dependencies see ref.[1].
Store the current configuration
A function to store current configuration shall be available in the program. It shall be possible to store the configuration in one of the profiles in the modem or in a file on the PC.
Restore a stored configuration
Stored configurations shall also be able to restore to the modem. Either you can restore a stored configuration from one of the profiles in the modem or from a file in the PC.
Restore to factory settings
A simple function shall be to restore the modems configuration to the factory settings.
Show configurations
The modems current and stored profiles shall be able to be shown in the window in some format that is easy to read.
Soft Requirements
The TD-tool software may have the following soft requirements:
• Auto detection of modem
• Print configuration
• Direct communication
• PLC settings configuration
Auto detection of modem
There may be an implementation of an auto detection of the modem type when the software is started. This may also be done when the program is already started.
Datum/Date Reg.nr/Reg.No. Rev Godk/Appr Sida/Page
2003-06-30 Examworker 1 38(41)
Print configuration
This feature should print the current configuration of the modem directly to an attached printer.
Direct communication
The direct communication should be like a function where you could send any AT-command by writing the AT-command in yourself in a sort of terminal.
PLC settings configuration
A function to configure the modem with PLC settings may be a implemented for some modemtypes.
Other requirements
None.
Design
The design for TD-tool have to be general so it can fit for different kind of modems that may be imported in the program in the future.
General
Datum/Date Reg.nr/Reg.No. Rev Godk/Appr Sida/Page
2003-06-30 Examworker 1 39(41)
Interface
User interface
The users interface shall be a simple-to-use interface with buttons and value-fields. It is good if it look and feel like the other Westermo tools. Typical designed like below.
For more design drawings see ref.[2].
Communication interface
The communication with the modem shall be over the RS-232 interface on the modem and then you need a COM port in your PC. A auto detection of modem type is desirable. The speed of the connection shall be auto if the modem has fixed it serial speed with the dipswitches. Otherwise you shall be able to set the settings you want to have on the connection.
Other interface
None
TD-tool
Serial Configure Profiles
At ok Connection Status: TD-33 Connected Baud: 9600 Parity: None DataBits: 8 StopBits: 1 Send command Line option V90 Disable V.42 and MNP 5 MNP
Enable and fallback/fallforward
Modulation
Flow control
Data compression
Error correcting option
Line quality and Auto-retrain
Modem Interface Commands
Enable command echo
Enable results to DTE
DTE speed
Long(Verbose)
Echo
Quiet result
Connect message option
Result code form
Enable, send all messages Extended Result code
Enable abort
No. Of rings to auto answer
Dial abort option
DSR always ON DTR ignored DSR override DTR option DCD follows carrier DCD option Send configuration Call Control
ON, during establishment
Low volume Speaker option Speaker volume Telephone numbers 1= 2= Low volume
Datum/Date Reg.nr/Reg.No. Rev Godk/Appr Sida/Page
2003-06-30 Examworker 1 40(41)
Revision
Rev NR Date Resp Description
1 2003-06-30 First approved specification
Datum/Date Reg.nr/Reg.No. Rev Godk/Appr Sida/Page
2003-06-30 Examworker 1 41(41)
Definitions and abbreviations
Definitions
Name Definition
Hard requirement Mandatory requirements
May May is used when it is a desirable requirement but not mandatory requirement
Must (must not) Performance constraint
Shall Shall is used when it is a mandatory requirement Soft requirement Desirable but not a mandatory requirements
