dcarrco

actually, thought i would add this extra info. the cpu usage is not for event structures in remote panels, its for event structures on remote FRONT panels, i.e. indiciator lights, button presses, etc. it has no effect with hidden event structures.

yes, using events structures over remote panels makes a huge difference on cpu usage, so much so that essentially timed DAQ tasks (such as grabbing a frame from a framegrabber and analyzing it) within 30ms of a target voltage waveform fail intermittently. by removing the event structures and changing them to polling loops, the cpu usage drops dramatically (from 100% to 62%) and the intermittent errors failures cease. it may be that the LV code is not written efficiently, and i suspect that that is part of the problem. my main gripe with labview is that its a language built for scientists, which is fine, but that also means that they arent trained as programmers. all sorts of strange methods could be the problem in our current scenario but im having to learn labview to try to find them. our programmer is really a physicist and not only does he not have a programming background but he always thinks hes right (as well as knowing the speed of sound in air, etc). so... i search.using event structures, you would think that the cpu usage would be minimal, but once again, using them with remote panels generates some huge network communication need (we think?) which chews up processor speed. we are currently automating a complex manufacturing process which uses multiple machines, over two hundred channels of DAQ information, several framegrabbers, and multiple channels of UDP video broadcasting. the need for a centralized control interface with these multiple control computers means that a lot of panels have to be routed to one computer. cpu usage is at 95% right now on the operator console which is JUST running remote panels from three other machines. we need to speed up our process by 10x and LV just doesnt work that fast right now. a 80ms loop in one VI is actually running at 200ms. i dont know why this isnt being tried. i will forward this suggestion to the Labview programmer. i have also been given the task of picking up labview so that i can help him, so any suggestions you have are doing a lot of good. i read the subject on wait loops and understand the basic principal. as i understand it, UDP is a non-guaranteed-arrival protocol and we just cant afford to miss a signal, otherwise dire things could happen (explosions, flames, etc). also, UDP packets dont contain any sequence information so we would have to build error checking and sequencing into them anyway, which then saves us only having to connect to a TCP server, which isnt enough of a gain to go that route. i didnt see that option in the ActiveX pallete but i will go further afield and look. i have pored pretty extensively (prior to posting my question here) over NIs documentation on the ActiveX event queue capability but might have missed it. well, a lot is happening, so we have to handle everything in 100ms. that includes image acqusition and analysis, gathering channels of input, broadcasting some video, and firing some output lines. im limited by our NDA in my description of our needs, unfortunately. alex, i appreciate your further comments and apologize for any inaccuracies in my labview knowledge. as i said before, i am NOT a LV programmer but im trying to grok it. they may soon need me as our lone programmer is starting to look pretty peaked. thanks d.

alex we are using a lot of remote panels in our control software apparently using events with remote panels shoots the cpu usage through the roof and slows down everything to non-functioning and error prone speed right now we are working around it with a polling loop and a panel indicator tied through socketserver to remotely signal an event through the lan (local loop watches the panel light and waits for its state to change). the problem is that the pooling loop is kludgy and wont work as we need more processing speed. it seems that NIs solution is just to throw more CPU power at it, but we are actually trying to be efficient about the whole thing. my task as the vb and .net programmer was to find a way OUTSIDE labview to signal events on the lan. my idea was to use basic tcp/ip via an ActiveX object, that way Labview wouldnt be polling and the event structure problem could be sidestepped. the ActiveX module would be doing the signalling (or triggering) and then call the Labview VI when the event fired. i have since solved the actual problem i posted by simply putting the link to the activex in a while loop which is apparently necessary for the event to call a LV VI. any ideas of a better way to do any of this would of course be much appreciated, and thanks for your response. d.

i created a test class in VB6, created a .DLL. class code is : Public Event CallBack(stimer As Integer)Public Sub LongTask(ByVal Duration As Single, ByVal MinimumInterval As Single) Dim Threshold As Single Dim Start As Single Dim blnCancel As Boolean ' The Timer property of the DateAndTime object returns the seconds ' and milliseconds that have passed since midnight. Start = CSng(Timer) Threshold = MinimumInterval Do While CSng(Timer) < (Start + Duration) ' In a real application, some unit of work would ' be done here each time through the loop. If CSng(Timer) > (Start + Threshold) Then RaiseEvent CallBack(Int(Timer - Start)) Threshold = Threshold + MinimumInterval End If LoopEnd Sub which simply loops for a period (duration) and raises an event every interval (minimuminterval). I created a .DLL, went into Labview 7.1 and created a test panel which runs the .dll and then let Labview create the callback VI for me and simply added a dialog box. Now, the .dll function does run correctly but it never sees the event. i tested this dll in VB and the event fired fine. any ideas?