Callback Event VB6 -> Labview

[dcarrco]

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?

[aledain]

Don't know anything about VB's callback, but the way I have done this in the past is to pass a reference to an occurrence into the DLL. The DLL code sets the occurrence and the LV code sits waiting for the occurrence to fire. Using the new custom events I bet you could get the setting of the occurrence to trigger a user event.

// Note in pseudocode only, I cannot remember the real details

eg. Public Event CallBack(stimer As Integer, occ As UnsignedInt32)

...

Do While CSng(Timer) < (Start + Duration)

If CSng(Timer) > (Start + Threshold) Then

occ=1

...

BTW, all the code in the DLL could be more easily in LV without the pain. Is there any real reason to do it in VB instead

Depending on what you want to do you could use loop timers, implement a QDSM, implement an event loop or ...

cheers, Alex.

[dcarrco]

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.

Don't know anything about VB's callback, but the way I have done this in the past is to pass a reference to an occurrence into the DLL. The DLL code sets the occurrence and the LV code sits waiting for the occurrence to fire. Using the new custom events I bet you could get the setting of the occurrence to trigger a user event.

// Note in pseudocode only, I cannot remember the real details

eg. Public Event CallBack(stimer As Integer, occ As UnsignedInt32)

...

Do While CSng(Timer) < (Start + Duration)

If CSng(Timer) > (Start + Threshold) Then

occ=1

...

BTW, all the code in the DLL could be more easily in LV without the pain. Is there any real reason to do it in VB instead   

Depending on what you want to do you could use loop timers, implement a QDSM, implement an event loop or ...

cheers, Alex.

1621[/snapback]

[aledain]

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

1650[/snapback]

Didn't realise remote panels did this. An alternative would be to use something like VNC. However, ...

and slows down everything to non-functioning and error prone speed

1650[/snapback]

Hmmm, error prone? I think we need some more information about what you're trying to do in LabVIEW itself. The CPU usage should be close to zero (or ~10% say) with any normal LV application, especially one written using events. So this may mean you're not doing the LV part as efficiently as you can. Are you doing DAQ, some sort of PID or something? Remember LV was written for clunky 486 machines (my LV irrigation system at home runs on one!).

Another first time mistake is to not put a wait in your main application loop. Even a wait timer with 0ms is better than a loop with no timer. The wait is importantbecause ...

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.

1650[/snapback]

Can you tell me why you need more processing speed? NI can be a little unhelpful with respect to solving problems, but that's why great groups such as LAVA and other NI Alliance members exist

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.

1650[/snapback]

But native LV could do this as well, open the tcpip connection, wait for the "event" to arrive on the connection ID and then fire a user event. Alternatively, load the tcpip event into a queue and have the queue handled in another parallel process. N.B. you could put KILL into the queue to get it to shutdown the parallel process and have the application using 0% cpu (with a timeout of -1ms) as input. When you're vent arrives, your application would awaken and do its stuff.

BTW if the lan event is sent via UDP, it is even easier as you can listen for the UDP packet directly without opening a connection to the "server" event sender!

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.

1650[/snapback]

I don't think this is necessarily the case, there is a WAIT_ON_AXEVENT VI that can wait for any ActiveX interrupt event. From memory, you need to register the event first, and then watch for it. Since you can set a timeout on the WAIT_ON_AXEVENT, the while loop is really only needed if you want to catch that event more than once. ie a re-arm.

So how fast do the events come in and how quickly must you respond to them?

cheers, Alex.

[dcarrco]

Didn't realise remote panels did this. An alternative would be to use something like VNC. However, ...

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.

Hmmm, error prone? I think we need some more information about what you're trying to do in LabVIEW itself. The CPU usage should be close to zero (or ~10% say) with any normal LV application, especially one written using events.

So this may mean you're not doing the LV part as efficiently as you can. Are you doing DAQ, some sort of PID or something? Remember LV was written for clunky 486 machines (my LV irrigation system at home runs on one!).

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.

Can you tell me why you need more processing speed? NI can be a little unhelpful with respect to solving problems, but that's why great groups such as LAVA and other NI Alliance members exist 

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.

But native LV could do this as well, open the tcpip connection, wait for the "event" to arrive on the connection ID and then fire a user event. Alternatively, load the tcpip event into a queue and have the queue handled in another parallel process. N.B. you could put KILL into the queue to get it to shutdown the parallel process and have the application using 0% cpu (with a timeout of -1ms) as input. When you're vent arrives, your application would awaken and do its stuff.

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.

BTW if the lan event is sent via UDP, it is even easier as you can listen for the UDP packet directly without opening a connection to the "server" event sender!

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 don't think this is necessarily the case, there is a WAIT_ON_AXEVENT VI that can wait for any ActiveX interrupt event. From memory, you need to register the event first, and then watch for it. Since you can set a timeout on the WAIT_ON_AXEVENT, the while loop is really only needed if you want to catch that event more than once. ie a re-arm.

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.

So how fast do the events come in and how quickly must you respond to them?

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.

[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.

[aledain]

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.

1666[/snapback]

OK you need to look hard at what he's doing here. I think he's probably got a wait until next multiple timer timing this loop. You really need to look at buffered image acquitision. IOW, get the card acquiring using it's own clock, and every now and again pull all the images abck from it, selecting the appropriate one) ie if you acquire a frame evey 20ms, take the 5th one. I'd definitely change the WaitUntilNextMultiple (looks like a metronone, WUNM) to the Wait (looks like a watch). The difference here is subtle. If the WUNM is set to 1000 and the CPU is full throttle, then you might see a result at 2000 or 3000 or 4000 ms, it can miss iterations!

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. 

1666[/snapback]

Too true. However, good programmers (and some of them are scientists) adopt good programming styles and follow standard development methodologies including OO. There are books out there that you might recommend to your scientists about getting on top of it all. The problem with LV is that it is too easy, and most apps are built from the ground up without any design. Doens't mean I haven't seen sphagetti in text based code either.

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

1666[/snapback]

This will be your problem then

(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. 

1666[/snapback]

I just don't think this is right. However I would instead redesign your app to send (control message) and receive (status message) a datapacket via datasocket or tcpip to get round this. You can programatically control the datasocket send/receive and use different channels (sockets) to do this very efficiently.

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). 

1666[/snapback]

Hmm wrong platform right there. Look at implementing the critical stuff in LabVIEW-RT. However, make sure that parts of the application (ie VI's) haven't been set time critical. This would also give you the sort of results you are seeing because of thread blocking.

well, a lot is happening, so we have to handle everything in 100ms. 

1666[/snapback]

Should be no problem at all. So I suspect program design.

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.

1666[/snapback]

You can always come here for help. It takes a while to "get" LabVIEW but once you do you'll see that for hardware interfacing, LV is the best language there is (provided you wrestle it away from the scientists that is).

BTW, if you want to chat online my Messenger address is labview_australia at the usual microsoft moniker.

cheers, Alex.