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.