Versions Compared

Old Version 26

changes.mady.by.user M Husam Badenjki

Saved on

compared with

New Version Current

changes.mady.by.user Josef Noel Møgster

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

PLS -

CODESYS

Kode planlegging

Visualisering

Ressurser

I starten ble det viktig å legge inn de forskjellige variablene som skulle kommuniseres over de forskjellige feltbussene, slik at det ble enklere for gruppemedlemmene å jobbe hver for seg.

Vi startet med en rask skisse av hvordan selve kommunikasjonen skulle funke mellom enhetene:



Videre ble de forskjellige variablene som trengte for MQTT opprettet for å kunne starte logikken til selve SFC programmet som hadde blitt opprettet.

  • Konvertering av sjakknotasjon bevegelse til robotkoordinater var en essensiell del av programmet fra start. Derfor ble disse funksjonene laget før koden i programmet.
Funksjoner

moveFromCoord funksjonen tar de to første tallene/bokstavene fra sjakkbevegelsesnotasjonen i formatet "h8h4", og gir ut et korresponderende koordinat for roboten som er lagret i en array.

Image Removed

moveToCoord var satt opp på akkurat samme måte som funksjonen over, men at den tar de to siste verdiene fra formatet "h8h4". På denne måten kan den ene kalles i en sekvensblokk for robotbevegelsen fra der brikken skal beveges og den andre til koordinatene den skal beveges til.

Inputs og output til moveFromCoord og moveToCoord har disse input-/output- og funksjonsvariabler:

Image Removed

Den siste funksjonen i hovedkoden var pieceHeight som brukes for å finne riktige z-koordinater for roboten, ut ifra hvilke brikker som skal flyttes. En brikke type blir satt som input, og den får en output av korresponderende høyde fra en array med brikkehøyder. En array med brikkenavn har samme indeks som hver brikkes høyde.

Image Removed

capturePlace var funksjonsblokken som lagret hvilke brikker som har blitt tatt. Denne ble implementert etter at hovedprogrammet viste at det kunne bevege delene. Ettersom det ikke var noen plass å legge brikkene fra capture sekvensen, måtte roboten ha en plass å lagre verdiene.

Image RemovedFunksjonsblokken over ble initalisert i ST men vises her med inputs og outputs. Denne returnerer posisjonen til brikketypen ut ifra en fast designert plass til hver type på siden av brettet, se brettet. Den lagrer hvilke plasser som er fylt opp og sender ut lokasjonen på brikkene ut ifra typen, dersom plassen skal bli tømt eller fylt men en brikke. Place og take inputs blir brukt til å gi angi om piecePos skal gi ut en fylt  posisjon eller en tom en.

Måten den blir satt opp, var ved hjelp av to-dimensjonale arrays, som er beskrevet i CODESYS dokumentasjon. De blir brukt til å skape to matriser på . En for BOOL verdier, for å lagre om plassen er opptatt, og en for strings, som lagrer hvilken type brikke plassen er designert til.

Image Removed

SFC

Til slutt ble sekvensen laget for robotbevegelsen laget i SFC. Det ble igjen brukt mye tid for å få kommunikasjonen som planlagt, men etter mye prøving og feiling ble det satt opp riktig i både TM Flow og CODESYS, se Modbus side.

Sekvensen for selve spillingen endte opp med å se slik ut:

Image RemovedImage Removed
Med denne sekvensen ville den være avhengig av feedback fra roboten over Modbus for å gå til neste sekvensblokk etter moveState. Siden hver av sekvensene kjører individuelt måtte oppdateringen til denne feedbacken og kommandoene tilbake til roboten oppdateres i hver blokk. Koden på bildet over viser generelt oppsettet til alle blokker med robotbevegelse. Der blir de eneste forandringene hva som blir satt til x-,y- og z-koordinater, i tillegg til aktivering og deaktivering av den magnetiske griperen, se griper.

Det generelle oppsettet til hver kodeblokk i robotspillingen var veldig likt, bortsett fra forandinger i hvordan koordinatene ble satt. For å kunne ta motspilleren sine brikker måtte en gameState for "capture" bli lagt til, som hopper tilbake til vanlig bevegelse når motstanderen kommer i kontakt med flere.

På bilde under viser tre forskjellige tabell:

Den første tabellen merket "FromPos" representere den startposisjoner til sjakkbrikkene på brettet. Denne tabellen viser hvor hver brikke er plassert før et trekk gjøres. Brikkene er plassert i standard startposisjoner for et sjakkspill. Både store og små bokstaver brukes for å skille mellom hvit og svart brikkene. De hvite brikkene representeres av store bokstaver, mens de svarte brikkene representeres av små bokstaver.

Den andre tabellen merket "ToPos" den nye posisjonen til sjakkbrikkene etter at et trekk er gjort. Denne tabellen viser hvordan brikkene vil være plassert på brettet etter at trekket er utført. 

Den siste tabellen merket "UpdatedPiecePos" representere den kombinerte og oppdaterte posisjonen til alle sjakkbrikkene etter å ha trekkene Fra "FromPos" til "ToPos". Den gir komplett oversikt over sjakkbrettet etter at trekkene er utført.

Tekstfeltene merket "WhitePiecePos" og "BlackPiecePos" viser fra og til posisjoner for hvite og svarte brikker.

  • SFC programmet var omfattende å lage men startet simpelt ved å integrere bevegelse med sjakknotasjon.
  • Etter hvert ble funksjonsblokken for lagring av brikker lagt til.
  • TM-FLOW programmet ble laget underveis for både å teste Modbus of for å få inn bevegelsen.


CODESYS program

AIS2104MainPLCCode.project


CODESYS

Image Removed