zondag, 26 mei, 2019

  •   +31 180 695 777 (NL) +32 3 297 70 07 (BE) ----------Lasal Latest Version: 0074_3----------
  •   

hans vanzijpOp die manier kunnen bijvoorbeeld productieorders naar een cpu worden
gestuurd of kan gelogde data opgehaald worden.
Zelf gebruik ik vaak de VBA achter Excel om data uit een cpu te halen.

Die dll kan dus heel handig zijn maar soms leidt het gebruik ervan tot lastig te vinden problemen.
Om een server in de cpu te lezen of te schrijven moet je met de dll eerst aan de hand van de naam
van de server het adres ervan ophalen (met LslGetObject).
Met dat adres kan dan gelezen of geschreven worden (met LslReadFromSvr of LslWriteToSvr).

Om een applicatie wat overzichtelijker te maken zijn er programmeurs die bij het opstarten van hun
applicatie een lijstje met adressen aanleggen en dat dan verder gebruiken.
Voor iedere server wordt dan maar eenmaal LslGetObject aangeroepen.

Dat kan fout gaan als na het opstarten van die applicatie het Lasal Class project aangepast wordt.
De kans is dan groot dat adressen veranderen.
Het aangelegde lijstje klopt dan niet meer en de applicatie leest en schrijft dan verkeerde adressen.
Vooral dat laatste kan gevaarlijk zijn en tot ongewenst gedrag van een machine leiden, of tot bijvoorbeeld
het stoppen van de cpu met een Access Exception.

Er zijn twee oplossingen om dit probleem te voorkomen:
Ofwel geen lijstje gebruiken en de adressen bij elke lees en schrijf actie opnieuw ophalen.
Of, als zo'n lijstje toch wel handig is, moet de applicatie de status van de cpu bewaken (met LslGetCPUStatus).

Als de cpu dan uit RUN is geweest en opnieuw in RUN komt moet het adreslijstje opnieuw worden opgehaald.
Op die manier ben je er zeker van dat de adressen kloppen.

Eventuele vragen betreffende het gebruik van de dll kunnen gemaild worden naar .