Hvad er det største projekt (målt i MB), der kan uploades til controlleren?

[Jakob Barfod]

Hej -

Jeg bøvler med at få koblet flere controllere sammen.

1. De medfølgende funktionsblokke kan kun overføre 16 binære værdier mellem to controllere
2. ...så jeg har programmeret min egne funktionsblokke, der bruger 6 af bit'ene som adresser + nogle bit til signalering. Det giver mulighed for overførsel af 128 binære værdier.
3. Så kan man koble 128 indgande og 128 udgange på en anden controller, mens man stadig bruger "hovedcontrolleren" til at styre al logik
   (den sekundære controller bruges kun til at forbinde de ekstra ind- og udgange)
4. Mine funktionsblokke virker ved simulering i IHC visual, men de er ret store (bl.a. har jeg implementeret en cirkulær kø for at undgå at miste signaler, mens der sendes)
5. ...og nu kan jeg ikke uploade projektet til controlleren. Den fejler her under "sender projekt til controller"...

Har nogen en idé om den øvre grænse for, hvor stort et projekt V3-controlleren kan håndtere? Mit projekt er nu ~8MB, hvis jeg kigger på den rå .vis-fil. Eller er der fx en grænse for, hvor mange interne variable etc., controlleren kan håndtere i alt?

-- 
Jakob

[Lars1]

Jeg kender ikke grænserne for hvor stort et LK IHC program må være, eller grænserne for interne variabler m.m. Men V3 controlleren har det med at dø (jeg er nu på min trejde V3 controller), og et af de første tegn er fejl på netværks interfacet, som bl.a. betyder at man mister forbindelsen fra tid til anden.
Får du samme fejl, hvis du oploader et mindre program?
Inden jeg uploader et nyt program til mine LK IHC controller, genstarter jeg dem altid via adminview. Det løser problemet på V2 controlleren, som ellers har det med at genstartet under program upload. På V3 controlleren har jeg ikke set dette problem, men jeg har heller ikke set proceduren skade noget.

Omkring brug af I/O porte til bit overførsel af binære værdier, så skal du være opmærksom på at LK IHC er event basert, hvilket vil sige at du får en event hvergang en bit eller indgang ændre sig. Man kan selvfølgelig udnytte at LK IHC controlleren normalt afvikler hændelser i den rækkefølge afsendes i programmet. Hvilket vil sige at hvis din FB først sætter bit 1, derefter bit 2 o.s.v. så er det normalt den rækkefølge de vil blive modtaget i den anden controller, hvilket gør at man kan bruge sidste bit til at trigger aflæsning af værdien. Men der er ikke nogen garanti for at der ikke har været en interrupt på afsender controlleren, som gør at bit'sne bliver afsendt i en anden rækkefølge.

I steddet vil jeg anbefale at du sender dine binære værdier som bit pulser på en enkelt I/O forbindelse. Det kræver lidt timing, men det er mere sikkert end parallel bits på I/O forbindelserne, og det er den måde som I/O modulerne og temp/lux/fugt sensorne kommuniker med controlleren. Interrupts på afsender controlleren, kan også her give problemer, men med start/stop og paritets bits, samt et OK/resend signal tilbage, bør kunne løse dette.