Grafiskt verktyg för service av diskmaskiner för professionella kök

Grafiskt verktyg för service av diskmaskiner för professionella kök Student: Daniel Kjellin, dkn02002@student.mdh.se Wexiödisk, Mälardalens högskola, Ide Handledare: Daniel Svensson, Dan Levin Examinator: Andreas Ermedahl Sida 1 av 16

Sammanfattning Wexiödisk har utvecklat en ny typ av styrkort till sina diskmaskiner. Dessa nya styrkort ger en mängd möjligheter till programmering och finjustering. Då styrkortet har en serie-port är det möjligt att via en dator och terminalprogramvara ändra inställningarna på kortet. Då många användare anser att terminalprogramvara är svårt att använda önskade Wexiödisk ett program med grafiskt gränssnitt som underlättade programmeringen. Detta examensarbete gick ut på att skriva en sådan applikation. Detta inkluderade intervjuer med de tekniker som skulle använda programmet samt att skriva kod som översätter från den grafiska miljön till de kommandon som styrkortet kan använda. Av många olika skäl valdes Java som programspråk. Resultatet blev en applikation som låter användaren justera inställningar, titta på händelseloggen, få händelseloggen färgmarkerad och med förklaringar till vad raderna betyder, programmet möjliggör också att rita temperaturhistorik i form av grafer. Wexiödisk är mycket nöjda med resultatet, och har visat stor uppskattning under arbetes gång. Figur 1. WD4 diskmaskin Figur 2. WD7 diskmaskin Sida 2 av 16

Innehållsförteckning Sammanfattning... 2 Introduktion...4 Bakgrund & Syfte...4 Definitioner... 5 Relevant teori... 5 Seriell kommunikation... 5 Seriell kommunikation i Java...5 Problembeskrivning och analys... 6 Modell/Metod...6 Lösning...7 Språk...7 Maskinspecifikationer... 7 Trafikminimering... 8 Eventlog...8 Trådsäkerhet... 9 Diagnosvärden/Är-värdesrepresentation... 10 Grafer...11 Hjälp... 12 Resultat...13 Resultatanalys...13 Framtida arbete...15 Slutsats... 15 Referenser... 16 Sida 3 av 16

1 Introduktion Det här kapitlet ger en kort introduktion till bakgrund och syfte med det här examensarbetet. Det kommer också att ge förklaringar till de förkortningar som används, samt förklara vissa begrepp. 1.1 Bakgrund & Syfte Då Wexiödisk har tagit fram en ny typ av strykort till sina diskmaskiner som tillåter programmering uppkom behovet att på ett enkelt sätt kunna programmera dessa kort. Innan detta examensarbete påbörjades var ett terminalprogram enda möjligheten att programmera korten. Då användare ofta finner att terminalprogram är svåra att använda och/eller svåra att konfigurera beslutades att det vore bra med ett program som lät användaren på ett enkelt och naturligt sätt programmera kortet. Figur 3. Skärmbild på programmet Sida 4 av 16

1.2 Definitioner Bps Baud Bör-värde Jvm Noll-modem Singelton Är-värde Bits per second hastighetsangivelse vid seriell kommunikation Hastighetsangivelse vid seriellkommunikation, är för alla utom de riktigt insatta samma sak som Bps. Anger egentligen antalet elektriska svängningar per sekund. Höga hastigheter överför mer än en bit per sekund. [1] Önskad värde, tex temperatur Förkortning för Java Virtual Machine En abstrakt dator, eller virtuell maskin, JVM är en plattformsoberoende miljö som översätter Javas bytecode till maskinspråk och sedan kör den. [2] En speciell kabel som används vid seriellkommunikation. Den är byggd så att de båda parterna kan kommunicera direkt utan extra hjälpmedel. Ett sätt att designa en klass i objektorienteradprogrammering så att det aldrig finns mer än en instans av denna klass. Det faktiska värdet, tex temperatur 2. Relevant teori Detta kapitel syftar till att ge en grundläggande förståelse för de tekniker som används samt ge läsaren en stabil grund för vidare läsning av rapporten. 2.1 Seriell kommunikation All kommunikation som sker mellan dator och diskmaskin sker idag med hjälp av noll-modem och seriell kommunikation. För att någon kommunikation ska kunna äga rum måste först båda parter vara överens om hur kommunikationen ska gå till. Exempel på saker som måste stämma är hastighet. Om maskinen använder 38400 baud och datorn 19200 baud kommer de inte kunna förstå varandra. Andra saker som måste bestämmas är hur datat som skickas är kodat. Allt detta är i det här examensarbetet redan gjort, den specifikation som finns att tillgå säger att hastigheten skall vara 38400 bps, antal databitar skall vara 8, ingen paritet ska användas. Antalet stoppbitar skall vara 1 och ingen flödeskontroll skall ske. 2.2 Seriell kommunikation i Java Då Java är plattformsoberoende och seriell kommunikation är plattformsberoende, t.ex. hanteras seriellkommunikation olika under Windows och Linux, så behövde den JVM som används utökas med ett paket som gör att den kan hantera serie-portar och seriell kommunikation. Detta paket tillhandahåller SUN gratis för Windows och Solaris[3]. IBM och andra tillverkare tillhandahåller det Sida 5 av 16

för andra operativsystem, t.ex. Linux[3]. För att programmet ska kunna fungera måste därför detta paket installeras på datorn. När paketet är installeras hanteras serie-porten som två strömmar, en för att läsa och en för att skriva, och programmet är omedvetet om att det går via seriell kommunikation. För att förenkla ytterligare lades all kommunikation i en klass Comm som är en singelton. På det viset kan man enkelt komma åt och utföra kommandon oavsett var man befinner sig i koden. Programmeraren behöver aldrig instansiera mer än en Comm instans, och därmed blir det enklare att garantera att ingen öppnar en redan öppen-port. I och med singelton egenskapen behöver aldrig Comm-klassen skickas som parameter utan den kan via en statisk factory-metod kommas åt var som helst (några begränsningar föreligger dock). 3. Problembeskrivning och analys Huvuduppgiften i det här examensarbetet var att göra ett grafiskt gränssnitt för att kunna uppdatera och och inspektera bör- och är värden för diskmaskiner. För att kommunicera med diskmaskinen används noll-modem och seriell kommunikation. 3.1 Modell/Metod På grund av problemets karaktär och den informella kravspecifikationen valdes 'Fast Protoyping' som modell. Det gör att man så fort som möjligt gör en prototyp som inte kan så mycket, visar upp den och får tillbaka feedback. Med den feedbacken ändrar man sin prototyp samtidigt som man lägger till funktionalitet. På det viset kunde produkten som växte fram ligga nära det som företaget i fråga önskade. Nya funktioner Reviderade krav Prototyp Färdigprodukt Krav Figur 4. Prototypmodellen Sida 6 av 16

4. Lösning Efter att ha skrivit en mycket trivial prototyp fattades beslut om hur den huvudsakliga layouten skulle se ut. Det beslutades att programmet skulle bestå av ett antal flikar och att varje flik skulle representera en viss funktion eller grupp av värden, som angivits i den börvärdestabell som fanns tillgänglig. När en grundläggande prototyp fanns klar infördes seriell kommunikation i programmet. Med en begränsad version utfördes den första demonstrationen för tänkta användare och då inhämtades också tankar och idéer om vad programmet saknar, hur saker borde se ut, samt vad som behöver förbättras. Då önskemål fanns att på ett enkelt sätt kunna byta språk på programmet lades den funktionaliteten in. Vidare önskade företaget att de på ett enkelt sätt kunde ändra, lägga till, eller ta bort maskinspecifikationer. 4.1 Språk Att få programmet att stödja flera språk var egentligen inget problem, då Java lagrar allt i Unicode och därmed har stöd för åäö eller andra nationella symboler. För att det skulle vara enkelt att byta språk utan att behöva ändra i källkoden, skapades två filer. En fil 'language.txt' innehåller definitioner av de språk programmet ska stödja. En definition består av 1. Namn på språket, det som visas för användaren 2. Sökväg till den fil som innehåller alla texter 3. Sökväg till hjälpfiler Genom att lägga språk definitionerna i en extern fil är det möjligt att på ett enkelt sätt lägga till ett språk. Filen med texter måste följa en given specifikation, samt givetvis innehålla de texter programmet använder. För att göra det enkelt att skilja på text och uppslagsord (dvs det ord programmet använder för att hitta given text) börjar alla uppslagsord på @ och följs sedan av texten inom citat tecken t.ex. @cancel Avbryt Om programmet inte hittar den text det letar efter kommer det via en dialogruta informera användaren om det, och sedan fortsätta, dock med den saknade texten satt till null. 4.2. Maskinspecifikationer För att göra det enkelt att lägga till, ta bort, eller förändra maskinspecifikationer lades också denna funktionalitet i en externfil. I filen listas alla värden som är tillämpbara på den givna maskinen, samt de gränser inom vilka värdena kan existera. Således är det enkelt att lägga till en ny maskin, det är bara att lägga till maskinen i specifikationsfilen. Programmet läser in filen när programmet startar och efter det går det inte att ändra specifikationerna. Skulle filen innehålla fel kommer programmet att hoppa över den maskinen och försöka läsa in alla andra maskiner. När alla maskiner är inlästa informerar programmet användaren om att det uppstod ett fel med inläsningen, sedan kan användaren fortsätta använda programmet utan den maskin vars specifikation var felaktig. Sida 7 av 16

4.3 Trafikminimering Då seriell kommunikation är ett ganska så långsamt sätt att överföra information behövde programmet vara sparsamt med sin trafik till diskmaskinen. Det löstes genom att låta maskinen göra väldigt lite automatiskt. Det enda som programmet gör är att det varannan sekund kollar om man har kontakt, och i så fall om man är inloggad. I övrigt gör programmet ingenting utan att användaren säger åt det. När användaren använder en spinner, eller annan grafisk komponent för att ändra ett bör-värde sparar programmet undan det i en mängd. När användaren sedan klickar på knappen för att ladda upp till maskinen går programmet igenom mängden och tar bort komponenterna ur mängden allt eftersom de har behandlats. En mängd valdes då flera förändringar av samma rad inte ska resultera i annat än att den raden ändras till det senast satta värdet. Vad som sparas är delat i två delar. Varje panel implementerar ett interface som säger att de har komponenter som kan förändras. Varje sådan panel ansvarar för att hålla reda på vilken komponent som är förändrad. De ansvarar också för att meddela huvudfönstret att de har förändrade komponenter. När användaren klickar på knappen för att ladda upp data till maskinen, frågar huvudfönstret alla paneler som sagt att de har förändrade värden om just deras förändrade värden. De ska då svara med en map, där key är raden och value är det nya värdet. På det viset skickas bara rad- förändringar en gång. 4.4. Eventlog Då maskinen för en log över händelser som anses signifikanta var programmet tvunget att kunna hämta denna log. Att hämta loggen visade sig vara ett större problem än man först skulle kunna tro. Då UARTen på datorn oftast bara har 4096 byte (4k) buffer utrymme kunde inte programmet förlita sig på att den klarade att buffra hela loggen, utan var tvungen att hämta in en del, och sedan vänta medan resten lästes in. När all data hämtas från styrkortet har användaren två alternativ. Det ena är att visa loggen precis som den var när den togs emot. Detta ger fördelen att det går så fort som bara går att få upp loggen. Nackdelen är att den kan vara lite svårläst. Det andra alternativet är att utnyttja reguljära uttryck och med hjälp av dessa matcha vissa typer av rader. De rader programmet klarar av att matcha är START ALARM och förändringsrader. Genom att på ett enkelt sätt kunna matcha dessa rader kan vi utföra ytterligare arbete på dem. T.ex. Räknas antalet START som setts. Detta är önskvärt ur service synvinkel. Då, om maskinen används Figur 5. Eventloggen färgmarkerad Sida 8 av 16

som det är tänkt, kommer en START per dag. Därmed anger START en avgränsning i loggen och man kan räkna baklänges och få en uppfattning om när en viss händelse inträffade. Också genom att matcha vissa uttryck kan programmet markera dem med färg. Vilken färg som används får användaren själv välja. I fallet med ALARM slår programmet upp vilket alarm det var och lägger till betydelsen av felkoden. Vid förändringar av börvärden läggs en förklaring till som talar om vad den förändrade raden avser. 4.5 Trådsäkerhet Eftersom programmet är grafiskt så faller det naturligt att använda mer än en tråd. En tråd används för att fånga knapp-tryckningar menyval etc, den tråden kallas för Event Dispatch Thread, eller EDT. Om programmet skulle göra ett jobb som tar lång tid (t.ex. Hämta eventloggen) så skulle det grafiska gränssnittet frysa, användaren skulle inte kunna stänga det, eller förstora/förminska fönstret etc. För att undvika det så låter man sådana saker som tar lång tid köra i en egen tråd. På det viset kan den tråden göra jobbet medan EDT fortsätter att fungera. Dock uppkommer problemet med trådsäkerhet. Om programmet har två eller fler trådar som vill förändra någon delad datastruktur måste det göras på ett sådant sätt att datastrukturen inte lämnas i ett inkonsistent läge. I princip alla Swing komponenter (dvs grafiska komponenter) är osäkra. Av den anledningen finns en regel som kallas Single Thread Rule [4] den säger att endast EDT får göra förändringar av grafiska komponenter. Genom att följa den regeln garanteras att de grafiska komponenterna inte skrivs sönder av externa trådar i programmet. Java som språk har några funktioner för att uppnå trådsäkerhet. En funktion är att vid metoddeklarationerna av de metoder som har åtkomst till den datastrukturen använda ordet 'synchronized'. Genom att göra det kommer alla trådar som anropar den metoden att blockeras till den som kör metoden är klar med exekveringen av den metoden. Genom att använda den funktionaliteten på alla metoder som kan tänkas användas av flera trådar garanteras trådsäkerhet. Sida 9 av 16

4.6 Diagnosvärden/Är-värdesrepresentation Eftersom diskmaskinen har ett antal givare anslutna var det givet att ett grafisktverktyg skulle kunna representera dessa värden på ett bra sätt. Då de flesta av dessa är-värden är av digital natur, dvs antingen är de på eller av kändes någon form av digital komponent nödvändig för att representera dem. En lysdiod skapades i ett grafiskt program. Lysdioden skapades så att den var På, Av eller Svartvit för att representera de tillstånden. En grafisk komponent skapades sedan som laddade de bilderna och via metoder låter programmeraren och därmed indirekt maskinen att sätta tillståndet. Är komponenten inte enabled så ritas den svartvita bilden. Är komponenten enabled men inte active ritas den släckta lysdioden, slutligen om komponenten är enabled och active ritas den påslagna lysdioden. Klassen designades så att alla bilder lades i statiska variabler eftersom alla instanser ändå skulle rita samma bild. Med undantag för en Figur 6. Ärvärdesrepresentation rad (enligt specifikation från Wexiödisk) så betraktar programmet alla värden som inte är noll(00) som ett aktivt värde. Om maskinen inte ger en siffra (d.v.s. svarar med - ) sätter programmet komponenten som not enabled. Sida 10 av 16

4.7 Grafer Då styrkortet lagarar temperaturer för de senaste 14 dagarna samt ger möjlighet att få aktuella temperaturer verkade det naturligt att låta programmet rita grafer av den datan. Eftersom programspråket inte har några färdiga klasser för att rita grafer konstruerades dessa. Då Wexiödisk hade vissa begränsningar på när temperaturer får visas så implementerades dessa begränsningar. Wexiödisk hade också synpunkter på hur grafen skulle ritas, så därför är bl.a. Y- axeln till höger istället för som brukligt till vänster. I det nedre fältet ritas de temperaturer som maskinen sparat. För att få data att rita ut måste användaren antingen välja Download data eller välja att ladda ned data direkt vid inloggning. Då hämtas all data som har att göra med grafen för de senaste 14 dagarna, samt diskräknare och de andra mätvärdena som Figur 7. Graf-fliken presenteras högst upp på fliken. För att få data till den andra grafen, måste användaren använda auto update på diagnosvärdesfliken. Vid varje sampling meddelar då diagnosfliken graffliken att det finns data och graffliken får fatta beslut om diskmaskinen är i ett sådant läge att den ska ta temperaturen och rita ut den. Sida 11 av 16

4.7 Hjälp För att göra det enklare för användaren ansågs det att det vore bra att ha möjlighet till Hjälp som användare är vana vid med grafiska applikationer. Java har inget direkt stöd för hjälp men med en tilläggsmodul kallad JavaHelp kommer den funktionaliteten. JavaHelp är ett komplett hjälpsystem med möjligheter att bl.a. söka efter ett ord eller fras i hjälpsidorna. JavaHelp kräver att alla hjälpsidor är skrivna i HTML 3.X. Det medför att det är enkelt att underhålla och uppdatera information då HTML är ett så vanligt format idag. Indexering för t.ex. innehållsförteckning sker med hjälp av XML så även där används ett vanligt och relativt enkelt format. För att ge användaren möjlighet att söka måste JavaHelp först skapa ett index. Program för att skapa sådana index följer med JavaHelp modulen samt instruktioner om hur det går till. Alla hjälpsidor samlas tillsammans med bilder, index, innehållsförteckning ihop till vad som kallas ett HelpSet. Genom språkfilen specificeras vilket HelpSet som ska användas och därmed kan programmet visa hjälp på det valda språket. Skulle ingen hjälp finnas för det valda språket händer ingenting ifall användaren använder hjälpmenyn. Genom att Figur 8. Hjälpsidor många program idag stödjer HTML direkt så är det inga problem med att t.ex. få in betydelser för alla alarm. JavaHelp ger all funktionalitet för att visa HTML och följa länkar. Många program finns på Internet som gör författandet av ett HelpSet enklare. Sida 12 av 16

5 Resultat Genom att låta en student skriva ett program gavs möjlighet att styra exakt vad användaren ser och vilka värden användaren kan ställa in. Det gick också på ett enkelt sätt att verifiera att de givna värdena var korrekta och inom de gränsvärden som är satta av Wexiödisk. Genom att ge användaren en grafiskmiljö med välkända symboler och ett beteende som användaren förväntar sig, minskar risken för fel. Genom att låta programmet göra viss begränsning av vad användaren kan göra så minskar man risken för fel ytterligare. T.ex tillåter inte användaren att sätta en temperatur som ligger över det givna max-värdet. Samtidigt som en grafisk miljö ger användaren och maskinen skydd för fel gör det också användaren mer villig att använda många av de möjligheter som ges med den här typen av programvara. Användaren känner också en ökad trygghet genom att hon kan se vilka värden som kommer laddas upp till maskinen. Alla dessa fördelar gjorde att Wexiödisk önskade få en applikation utvecklad. Lösningen att skriva ett grafiskt skal runt ett terminalprotokoll gav vissa svårigheter men rent generellt så är det få kommandon som behöver utföras och de var lika i sin karaktär. Till exempel är ju alla raduppdateringar i princip identiska. Att skriva ett grafiskt gränsitt är tidskrävande och kräver alltid feedback från tänkta användare. Detta har skötts via e-post och telefonsamtal med Wexiödisk. 5.1 Resultatanalys Ett problem som uppstod tidigt var att installationsinstruktionerna till javax.comm (serie-ports tillägget till Java) innehöll ett fel. Instruktionerna hävdade att comm.jar skulle läggas i lib mappen för den JVM som används. Lägger man filen där kommer inte program som kräver javax.comm att fungera. Efter samtal med personer som använt sig av javax.comm tidigare (via newsgroups) framkom att comm.jar ska ligga i ext mappen i lib katalogen. För att bespara användaren bekymmer med detta skrevs ett mycket enkelt installationsprogram för javax.comm. Ett problem är att en dator är mycket snabbare än vad en människa någonsin kan komma att vara, denna snabbhet gjorde att programmet i tidiga stadier skickade sina kommandon för fort. Om kommandon skickades för fort till styrkortet kunde kortet inte utföra kommandona utan valde istället att helt strunta i kommandot. Genom att tvinga programmet att sova på lämpliga ställen löstes det problemet. Ett annat problem som alltid uppkommer vid kommunikation är kodningen av bokstäver. Java använder t.ex. Unicode-16 som standard. Det orsakade först inga problem men ibland kunde kortet svara med? på vanliga kommandon. Efter att förändrat koden så att alla kommunikation som går ut på serieporten går i 7-bitars ASCII löstes även det problemet. Även inkommande data tolkas som 7- bitars ASCII. Även om in och ut strömmar var trådsäkra så var det nödvändigt att koppla ihop utgående kommando med inkommande data. För att komma runt det problemet lades all kod som skickade data på serie-porten i en trådsäker (blockerande) metod. Denna metod skickade kommandot och väntade sedan en given tid på att data ska komma tillbaka och läser sedan in data. Den väntar sedan en stund igen, läser sedan mer data om det finns, och när det inte längre finns mer data att läsa kombinerar den ihop alla fragment den läst till ett block och returnerar det. På det viset kan kommando och svar enkelt kopplas ihop. För att göra exekveringen mer effektiv vid t.ex. uppdatering av flera rader, som ju resulterar i fler kommandon, kan metoden utföra flera kommandon vid ett anrop, och den returnerar då Sida 13 av 16

en array med resultaten. Index för reslutat motsvarar index för det kommando som gavs i den lista med kommandon som skulle utföras. Problem uppstod också med i och med att programmet försökte läsa så sällan som möjligt från serieporten. Genom att bara kolla om mängden tillgänglig data inte hade förändrats och då läsa all data i ett svep uppnåddes bra prestanda på seriekommunikationen. Dock uppkom det problem med att UART bara har en buffer för 4096 byte. Så t.ex. eventloggen gick inte att få i sin helhet. Genom att istället för att undersöka mängden data och sedan inte göra något, läsa så mycket det gick och sedan lägga det i en länkad lista kunde programmet ta emot data som var större än 4096 byte. Dock krävdes då att programmet efter att all data var läst byggde ihop lästa delar till en enda del. Den extra tiden var dock så liten att det inte påverkade prestanda nämnvärt. Sida 14 av 16

6 Framtida arbete Även om programmet nu är väldigt nära den produkt som Wexiödisk förväntade sig finns det mer intressanta saker att göra. Till exempel finns intresse att få in modemstöd i programmet. På det viset vore det möjligt att ha gsm-modem i diskmaskinen och från servicestället ringa upp maskinen och få status och andra data. Det vore också intressant att kunna ladda samplade data (spara går idag) och kunna jämföra gammal data med ny data. 7. Slutsats Min uppgift var att skriva ett program med grafiskt gränsnitt för att kommunicera med diskmaskiner. Programmet skulle vara enkelt att använda och presentera data på ett lättöverskådligt sätt. Ett problem som uppstod var kodningen av tecken. Genom att strikt använda 7-bitars ASCII löstes dock det problemet enkelt. Flera problem kom i och med att en dator är många gånger snabbare än en människa på att skicka kommandon. Till exempel kan en dator skicka flera kommandon i sekunden medan en människa knappast klarar mer än kanske ett kommando i sekunden. Genom att lägga in väntetider kunde de problemen också lösas. Sammanfattningsvis kan jag säga att jag tycker att uppgiften har lösts. Det finns nu ett grafiskt verktyg för att programmera diskmaskiner med. Verktyget presenterar data på ett överskådligt sätt och använder i stor utökning kända komponenter vilket gör att användaren känner igen sig och kan räkna med att saker beter sig som förväntat. Sida 15 av 16

8 Referenser [1] http://www.webopedia.com/term/b/baud.html 15:28 21 mars 2005 [2] http://www.webopedia.com/term/j/jvm.html 15:56 21 mars 2005 (full text) [3] För Windows och Solaris http://java.sun.com/products/javacomm/ För Linux och andra operativsystem http://www.rxtx.org/ [4] Cay S. Horstmann och Gary Cornell, (2005), Core Java 2 Volume II Advanced Features, Sun Microsystems Press,Santa Clara Sida 16 av 16