[VB6] Timer event

[Verwijderd]

Ik heb een vraag over de timer event in VB

Stel je hebt een timer met een interval van 50ms en de procedures die binnen het timerevent worden gegenereerd duren 220ms, wat doet VB dan

Mogelijkheid 1:

- = idle
+ = bezig

code:

Timer event: 
----+----+----+----+----+----+
Procedures
----++++++++++++++++++++++---+++++++++++++++++++++---

Dus de events worden geblokkeerd tijdens de uitvoer van de procedures

Mogelijkheid 2:

- = idle
+ = bezig

code:

Timer event: 
----+-------------------------+
Procedures
----++++++++++++++++++++++----+++++++++++++++++++++---

De timer begint weer met tellen op het moment dat men klaar is met de procedures die in het event zijn aangeroepen


Is het 1 van deze 2 manieren of werkt het volledig ander (internet is knap onduudlijk)

[Crazy D]

je zou t gewoon kunnen proberen met wat debug messages, maar aangezien VB niet multithreaded is, zal zolang je procedure bezig is, het timerevent niet opgevangen worden.
(iig, dat is wat ik vermoed).

Maar waarom zet je de timer op 50ms als je weet dat de procedure langer duurt

[.oisyn]

geen idee wat de werkelijke implementatie van de VB Timer is, maar als het overeen komt met de WM_TIMER message van windows dan kan er ten alle tijden maar 1 WM_TIMER message in de messagequeue staan.

Oftewel, jouw app krijgt die message, jij haalt die message uit de queue en doet daar wat mee. Tijdens jouw 'werk' wordt er nog een WM_TIMER message verstuurd, maar die wordt pas opgehaald als jij klaar bent. Zolang deze message in de queue blijft staan wordt er geen nieuwe gestuurd

Gevolg is dus dat als jij klaar bent met je werk je gelijk weer opnieuw moet beginnen omdat er nog een message staat te wachten, dus het kan zo zijn dat die message niet precies op het juiste tijdstip binnen komt

code:

Timer:
----+----+---------------+-----
Proc:
----++++++++++++++++++|++++++++

bij de | wordt er op de 2e timer message gereageerd, zodra die daaraan begint kan er dus weer een nieuwe timer message de queue in komen

[Verwijderd]

Waarom niet:

code:

Timer:
-------------------
Timer.enabled=False
Proc
Timer.enabled=True
--------------------

[Verwijderd]

Crazy_D schreef op 08 oktober 2002 @ 13:19:
Maar waarom zet je de timer op 50ms als je weet dat de procedure langer duurt

Ik wil weten wat er gebeurt indien de procedure langer duurt, dit is voor mijn software wel degelijk van belang

[Verwijderd]

Verwijderd schreef op 08 oktober 2002 @ 13:25:
Waarom niet:

code:

Timer:
-------------------
Timer.enabled=False
Proc
Timer.enabled=True
--------------------

Dat is correct, maar...

voor mijn programma lees ik een apparaat periodiek uit, het apparaat heeft een register en zal periodiek data ontvangen en daar vervolgens bewerkingen op uitvoeren, ik zal dus minstens zo vaak (liever vaker) moeten pollen voor data als er periodiek data ontvangen zal worden. Daarvoor wil ik de interval van de timer zo klein mogelijk maken en daarbij vroeg ik datgene af wat er zou gebeuren indien het timerinterval te klein zou worden

[.oisyn]

KlukKluk: het pollen van die data zal niet zo lang duren. Je moet het gewoon nog niet meteen verwerken. Je kan bijvoorbeeld de gepollde data in een soort van queue stoppen... het is alleen wel kut dat je in VB6 niet meerdere threads kan starten. Een worker thread was nu erg handig geweest. Nu zul je de verwerking continu moeten laten lopen, met om de zoveel tijd even een DoEvents oid

[farlane]

.oisyn schreef op 08 oktober 2002 @ 13:37:
met om de zoveel tijd even een DoEvents oid

Dat is een mogelijkheid, maar denk wel goed na over de structuur van je app in dit geval.

Men beseft vaak niet dat functies in dat geval reentrant worden. ( Ik spreek uit ervaring ) Dit kan de meest vreemde situaties opleveren.

Wat ook een mogelijkheid is :

Maak een ActiveX control in C oid die de communicatie in een aparte thread afhandelt. Deze kan dan events genereren als er nieuwe data binnen is gekomen.

Nog een mogelijkheid is om gebruik te maken van asynchrone communicatie.

Ik ben er persoonlijk voorstander van om dit soort dingen naar een aparte module ( liefst in C of C++ ) te verhuizen en VB niet met protocollen en communicatie bezig te laten prutsen. Voor VB is dit te veel bitgepiel.

[Verwijderd]

Oisyn:

Ik zal het proberen uit te leggen.

Een industriele 486 PC die draait over een SMP-bus heeft allerlei I/O kaarten voor het aansturen van allerlei vermogenselectronica (hoogvermogen pulsvoeding). Daarvoor is een door mijn stagebedrijf ontwikkeld VBDOS programma die het geheel via buttons & een touchscreen locaal kan bedienen.

Het programma bestaat uit een initialisatieprocedure waarin de HW wordt ingesteld. Na deze procedure wordt een timer gestart die periodiek de IO leest (1). Dit wordt op het scherm getoverd.

Ik heb om het geheel over IP te bedienen een netwerkkaart voor de SMP-bus aangeschaft die ik via de registers in C aanstuur. Daarbovenop heb ik een zelf in C ontwikkelde UDP/IP protocolstack "geplakt", dit heb ik naar een library gecompiled zodat die in VBDOS toegankelijk is. Om nu te zorgen dat data ontvangen wordt moet er periodiek gepollt worden naar een functie die kijkt of er "correcte" data op de kaart staat. Duurt het pollen te lang, dan zal ik informatie missen (frames kunnen niet meer ontvangen worden).

Dit pollen mag alleen maar in de hoofdlus gebeuren (1). Ik moet dus testen hoe snel ik dit kan krijgen, daarom was ik dus ook nieuwsgierig wat er zou gebeuren indien ik het pollen te snel zou laten gaan.

Ik hoop dat je nu een beetje de achtergrond snapt

[farlane]

Ik begrijp dat je niet VB6 gebruikt ?

[Verwijderd]

farlane schreef op 08 oktober 2002 @ 13:58:
Ik begrijp dat je niet VB6 gebruikt ?

Klopt, maar ik wou het geheel eerst simuleren. Het leek mij niet waarschijnlijk dat het gedrag van de timer in VB6 wezenlijk anders is dan in VBDOS (correct me if I'm wrong)

Ik wou de situatie dus eerst nabootsen op een gewone PC en indien dit een bevredigend resultaat gaf de boel implementeren op de industriele PC (netwerkkaart kan ik simuleren)

[.oisyn]

* .oisyn snapt nog steeds niet waarom er zoveel VB wordt gebruikt bij industriele processen

heeft vast te maken met al die bedrijfskundige informaticussen die VB gehad hebben op school (no offence voor degene die BI studeren )

[Verwijderd]

.oisyn schreef op 08 oktober 2002 @ 14:06:
* .oisyn snapt nog steeds niet waarom er zoveel VB wordt gebruikt bij industriele processen

heeft vast te maken met al die bedrijfskundige informaticussen die VB gehad hebben op school (no offence voor degene die BI studeren )

Het was niet mijn keuze , programma was er al en na onderzoek bleek dat middels "mixed language routines" het probleem van netwerken in VBDOS te tacklen was

[johnwoo]

Verwijderd schreef op 08 oktober 2002 @ 14:03:
Klopt, maar ik wou het geheel eerst simuleren. Het leek mij niet waarschijnlijk dat het gedrag van de timer in VB6 wezenlijk anders is dan in VBDOS (correct me if I'm wrong)

Ik moet bekennen dat ik geen ervaring heb met VBDOS, maar het lijkt me dat die timers behoorlijk Win32-only zijn en niet gaan functioneren onder DOS... Je zult onder DOS zelf voor je timing moeten zorgen, en aangezien DOS sowieso niet multithreaded is zal dat compleet anders werken dan in Windows. Ik weet niet of er op die polling machine nog veel aan UI gedaan moet worden, maar anders zou je een delay kunnen gebruiken in je polling loop.

code:

Do
   NextPoll = Timer + 3   ' om de 3 secs
   PollHardware
   SendFrame
   While Timer > NextPoll: Wend  ' rest van de 3 secs opvullen
Loop                  ' eventueel in het delay-loopje wat UI-zut

Deze constructie zal eens in de 3 seconden pollen en data versturen, behalve als het pollen langer duurt dan 3 seconden: dan gaat ie gelijk door aan de volgende sample.
_{En ja, ik weet dat je met Timer in de knoop komt om middernacht als ie weer naar 0 springt, maar het gaat even om het idee}

[farlane]

.oisyn schreef op 08 oktober 2002 @ 14:06:
* .oisyn snapt nog steeds niet waarom er zoveel VB wordt gebruikt bij industriele processen

heeft vast te maken met al die bedrijfskundige informaticussen die VB gehad hebben op school (no offence voor degene die BI studeren )

Dat heeft te maken met het feit dat bijna niemand de ( virtueel ) extra ontwikkeltijd wil betalen als je iets anders gebruikt. ( Het zijn die strings in VB die zo makkelijk te misbruiken zijn he )

( In de praktijk is het zo dat je met VB vaak net zo lang bezig bent als met een andere taal magoed .... wie ben ik )

[Verwijderd]

johnwoo schreef op 08 oktober 2002 @ 16:58:
[...]
...maar het lijkt me dat die timers behoorlijk Win32-only zijn en niet gaan functioneren onder DOS... Je zult onder DOS zelf voor je timing moeten zorgen...

VBDOS heeft ook de beschikking over een Timer Control

[Verwijderd]

Ik gok zomaar dat de timers onder VBDOS anders functioneren (interrupt based gok ik maar ik ken het product verder niet dus i'm guessing here).

[Demo]

johnwoo schreef op 08 oktober 2002 @ 16:58:
Je zult onder DOS zelf voor je timing moeten zorgen, en aangezien DOS sowieso niet multithreaded is zal dat compleet anders werken dan in Windows.

VB6 is ook niet multithreaded, dus wat dat betreft maakt het volgens mij niet veel uit...

[johnwoo]

Demoniac schreef op 09 oktober 2002 @ 09:03:
[...]

VB6 is ook niet multithreaded, dus wat dat betreft maakt het volgens mij niet veel uit...

Voor de programmeur niet nee, maar onderhuids gebruiken VB programma's gewoon meerdere threads hoor (sommige ActiveX controls maken daar gretig gebruik van). WinBar bijvoorbeeld gebruikt er 6... Dus de timer implementatie zou best threads kunnen gebruiken (het is niet zo, maar het zou kunnen )

[farlane]

Voor strakke timing zou je dan ( met VB6 iig ) ook naar multimediatimers kunnen kijken.

Onder DOS heb ik het idee dat de timing strakker zou moeten zijn dan onder Win32, vandaar.

Qua constructie mag je er denk ik helemaal niet van uitgaan dat de timers hetzelfde werken, maar ook ik ben een beetje aan het guessen..

[Verwijderd]

Ok zal m'n vermoeden iets verder uitkouwen, in windows heb je je messagequeu waar messages in gepost worden voor je timer events, ik heb nooit vbdos gedaan maar vroeger wel veel in dos geprogrammeerd met andere talen waar je de timer functionaliteit vrijwel altijd met 'n interrupt regelde.. vandaar..

[DukeMan]

johnwoo schreef op 09 oktober 2002 @ 09:11:
[...]

Voor de programmeur niet nee, maar onderhuids gebruiken VB programma's gewoon meerdere threads hoor (sommige ActiveX controls maken daar gretig gebruik van). WinBar bijvoorbeeld gebruikt er 6...

Hoe kan ik dat voor elkaar krijgen, dat ik dus meerdere threads heb?

[johnwoo]

NTGiant schreef op 09 oktober 2002 @ 10:11:
[...]


Hoe kan ik dat voor elkaar krijgen, dat ik dus meerdere threads heb?

'Vieze' methode: je kunt in VB ook gewoon de CreateThread API gebruiken om een procedure in een aparte thread te laten lopen. Je moet de hele meuk dan wel goed synchroniseren; ik geloof dat er onder VB een aantal vreemde effecten kan optreden als je zelf threads gaat zitten bouwen.

'Normale' methode: een ActiveX object of DLL maken in C/C++/whatever, waarin je worker threads maakt en alle synchronisatie afhandelt, en waarvan je dan de functies gebruikt in VB.

[Verwijderd]

Ik heb nu een test toegepast in VBDOS, het blijkt dat indien je de het timerinterval te kort maakt tov. de tijd die de procedures in beslag nemen, er onmidddelijk (binnen 1 ms) een nieuw timerevent plaatsvindt.

Ook heb ik getest wat er gebeurt indien je tijdens de procedures op een knop drukt op het scherm (scherm heeft dan dus niet de focus). Het blijkt dat het op dezelfde manier werkt.

event timer->Procedures start->op knop drukken( event knop in wachtrij)->event timer in wachtrij->procedures klaar->event knop->event timer

De manier die Oisyn in z'n eerste post beschrijft klopt dus ongeveer.

Events worden in een queue gezet die van elk type event maximaal 1 element kan bevatten (wordt er tijdens de procedureverwerking op 2 knoppen gedrukt werkt alleen de 1e knop als event)