Event callback with active x in labview

I have an active x written by Aanderaa Instruments (makes
weather and hydrology sensors), it contain various methods and events to get
the next line of records from a sensory scanning unit. The connection is
through the COM1, so far i have wired it up only using the methods to get next
record level, but then I have found that sometimes it does not get the complete
record from the COM port. So to solve that I have to use an event in the active
x to check for new record available. So what I want to do is send the event
(when complete record available) to VI that uses the get next record method to
pick up the data from the COM1 port and then send the data back to the main VI
for processing, plotting and writing.
My problem is that when I connect the output from the GetNextRecord method to a
indicator that I then wire on the connector pane to be an output from this
VI get an error that there is a wire function conflict. I have tried to
explain a bit better in the attached pdf file with diagrams.
The reason why I want to export the data back in the main VI is because it runs
continuously collecting data every 2 min and I plot them on a graph and write
them to a file so it will no work to have all that done in the event callback
VI that will only run ever 2 min, then it will reset the graph the whole time
and I want continuous data plotting for 10 days of historic data records. I
also have a few other sensors that come in through a connector board that are
written o the same file.
hope somebody can give me some hints
Attachments:
labview question.pdf ‏721 KB

Hello!
I checked the PDF file with snippets of your code and it looks alright, no issues or comments regarding that from my side. However it is really difficult for us to troubleshoot when we don’t have the ActiveX control available and even though we had access to the control it would still be quite tricky to find the cause of the problems you are experiencing since we don’t have the hardware and so on.
I found one link only that mentioned wire conflicts when talking about COM objects and ActiveX and you can find it here:
http://digital.ni.com/public.nsf/websearch/0CED780C5D5EDCD5862569D9005AE1FA?OpenDocument
Regards,
Jimmie A.
Applications Engineer, National Instruments
Regards,
Jimmie Adolph
Systems Engineer Manager, National Instruments Northern Region
Bring Me The Horizon - Sempiternal

Similar Messages

Configure Event Callbacks in test stand using labview

Hi,
I was going through Full OI - Configure Event Callbacks.vi in the test stand example. Can you please explain me how the vi works and what is techniwue behind it?
When i open the individual VI's in the reference, I could see more that 1 control in the front panel. But Only the user parameter is wired in the vi? Why is it so?
Regards
Gopal

Hi Gopal,
When the TestStand Engine fires events, this VI specifies how your Operator Interface will respond. For example, let's examine the first event callback registered in Full OI - Configure Event Callbacks.vi , Exit Application. When the TestStand Engine receives the message to shutdown, and then finishes its neccessary shutdown procedures, it will send a message to the Operator Interface. For the Operator Interface to receive this message, it must "listen" for it. In LabVIEW, this is done by Registering an Event Callback. See the links below for details on how to implement this.
The answer to your specific question is in step 7 of the first link below. When TestStand sends the message to LabVIEW, there is information that is always passed. The other input controls contain this information. To create a VI that always includes these controls, right-click on the VI Ref input to the Reg Event Callback Property Node, and then select Create Callback VI.
Here are two references that talk about handling ActiveX callbacks in LabVIEW in general:
Registering and Handling .NET and ActiveX Events
Register Event Callback (Not in Base Package)
Cheers,
David Goldberg
National Instruments
Software R&D

Event Callback from a Reentrant VI Recursion Error

Greetings,
I am using Register Event Callback with an ActiveX object to respond to user mouse events. The problem is that when I run the VI (the main, calling vi) as reentrant, Labview gives an error that the "Callback.vi" is attempting to recursively call "Main.vi".
Is there a way around this problem? I intend to run two copies of "Main.vi", so reentrant execution seems necessary.
- Colin Holbrook

Hi Colin,
Are you placing the Register Event Callback inside of the Main VI and then wiring the same Main VI to the VI Reference terminal? If so, then that explains why you are getting an error. You cannot use the Register Event Callback to call a VI within itself. If this is not the case, then please post a simple VI that demonstrates the problem.

Active x and event callback in Labview

I have an active x written by Aanderaa Instruments (makes
weather and hydrology sensors), it contain various methods and events to get
the next line of records from a sensory scanning unit. The connection is
through the COM1, so far i have wired it up only using the methods to get next
record level, but then I have found that sometimes it does not get the complete
record from the COM port. So to solve that I have to use an event in the active
x to check for new record available. So what I want to do is send the event
(when complete record available) to VI that uses the get next record method to
pick up the data from the COM1 port and then send the data back to the main VI
for processing, plotting and writing.
My problem is that when I connect the output from the GetNextRecord method to a
indicator that I then wire on the connector pane to be an output from this
VI get an error that there is a wire function conflict. I have tried to
explain a bit better in the attached pdf file with diagrams.
The reason why I want to export the data back in the main VI is because it runs
continuously collecting data every 2 min and I plot them on a graph and write
them to a file so it will no work to have all that done in the event callback
VI that will only run ever 2 min, then it will reset the graph the whole time
and I want continuous data plotting for 10 days of historic data records. I
also have a few other sensors that come in through a connector board that are
written o the same file.
hope somebody can give me some hints
Attachments:
labview question.pdf ‏721 KB

Duplicate post, click here for the original: http://forums.ni.com/ni/board/message?board.id=170&message.id=135639#M135639
LabVIEW Champion . Do more with less code and in less time .

New LabHSM Toolkit - Agile development of complex event-driven maintainable LabVIEW applications with active objects / actors based on a universal Hierarchical State Machine / statechart template.

Dear Fellow LabVIEW programmers:
Most of the systems you deal with are reactive. It means that their
primary function is constant interaction with their environment by
sending and receiving events. But most likely, they can have something
happening inside them too, even when they are not processing messages
received from outside. So, such systems have to continuosly react to
external and internal stimuli. Right? Moreover, most likely, they
consist of subsystems that are reactive too and, in turn, can have
their own "life", to an extent independent from other parts (with
which they still communicate, of course). Reactive (event-driven)
systems are more naturally modeled with active objects. So, why then
should we try to model and code them with GOOP and its passive
("dead"!) objects?
"Flat" State Machines have been known for decades to have severe
limitations. It's been more than 20 years since Dr. Harel invented
Hierarchical State Machines (statecharts) to fight those limitations.
Then why does NI still tout the same old good Moore FSM as the
ultimate tool for event-driven programming in LabVIEW in its $995
State Diagram KIt?
The LabHSM toolkit we are happy to present, makes it possible to
easily create and then maintain complex event-driven applications in
LabVIEW as a collection of HSM-driven active object VIs using a higher
level of abstraction and agile software development methodologies.
These active object VIs are created based on a universal Hierarchical
State Machine ( HSM or statechart ) template. So. all your code looks
similar regardless of its functionality!
We all love just jump to code, right? However, to be good boys, we
need to do design first. Then implement it in code. If the logic is
modified we need to redo the design first and then redo the code. When
using LabHSM where behavior information is abstracted into a separate
HSM data file editable with a supplied editor, there is no need for
coding separate from design any more. The modified behavior becomes
code automatically as soon as the HSM file is saved. Design is code!
The implementation basically follows Dr. Samek's Quantum Programming
paradigm. (see http://www.quantum-leaps.com). However, as already
mentioned, LabHSM stores the behavior information in a file separate
from the code itself. It also adds state dependent priorities to
events, a separate queue for public events/messages, and, of course,
some LabVIEW specific code like capturing front panel user events and
putting them into the private Events queue. Communication and
instantiation functions are also rather specific for LabVIEW.
It is available for UNLIMITED PERIOD trial. Please visit
http://www.labhsm.com for details and download. The site also contains
references which you may want to check to learn more about
hierarchical state machines and active object computing.
Since this is our debut we will appreciate any comments and
suggestions. Our contact information is available on our site, of
course.
Have a G'day!

Symtx is currently hiring the following position. Please contact me if interested.
Amy Cable
Symtx, HR
[email protected]
Symtx, the leading supplier of functional test equipment, hires the brightest & most talented engineering professionals to design & manufacture complex custom electronic systems for advanced technology leaders in the defense, aerospace, communications, medical, transportation & semiconductor industries. Symtx’ challenging & dynamic work environment seeks to fill openings with highly qualified electronic engineering design professionals.The ideal candidate will be responsible for defining the requirements, software design and code development, and integration of test control software for custom functional test systems. Candidate should be familiar with data acquisition concepts, instrument control, complex test, measurement and calibration algorithm development and definition and implementation of control interfaces to hardware. Prefer familiarity with instrument control via GPIB, VXI, MXI, RS-232 desirable. Requires BS/MSEE and 3 -7+ yrs of experience in one or several of the following test applications in a Windows NT/2000/XP environment using Labwindows CVI, TestStand, Labview, Visual Basic, C++ and knowledge of RF systems is a plus. Job responsibilities will include software design, development, integration, team leadership, and interfacing with customers( includes PDR’s & CDR’s).

Problem with register event callback in use of instrument control

now, i use the register event callback to register a value change of a boolean control on the front panel, and wire the cluster's ref of the instrument control parameters to the user parameter input, then create the callback vi. In the callback vi, i select the pump-control subvi, and pass the user parameter to the subvi. The problem is that, when i press the boolean control, the instrument (here is pump) can act, but immediately, the code crashes.
I use labview 8.6
Attachments:
callback vi.png ‏8 KB
register event callback.png ‏8 KB

You would wire the event registration wire that comes out of the Register for Events node into an event structure. You will need to right click on the event structure and check off "Show Dynamic Event Terminals" and it into that. Then you can create a new Event Case that uses the dynamic event. You can place your subVI in that event in whatever way you want. (Just drop the subVI in or do a Call by Reference there, or whatever.) Look in the Example Finder for "Dynamically Register for Events.vi".

Event Callback VI with LVOOP / overhead, caveats, future

OK another exploratory post from me. To anyone who has put up with this kind of thing from yours truly many times in the past, apologies. Completely impervious to any objections, here goes:
I have discovered a new toy : Registering event callback VIs. OK, I have used them before but a previous post by James McNally about his MVC framework revealed to me a usage which I had not previously thought of. Thanks for that James.
I like LVOOP. One pattern which is quite easy to understand is the command pattern in conjunction with state machines where we essentially replace the individual states of a state machine with external VIs. This makes it far easier to customise behaviour and allows for re-use of the core state machine for differing functionalities. Cool.
We can leverage this with LVOOP by passing different "commands" to the state machine depending on the real object being utilised and thus we have a nice extensible architecture. Again, cool. If we need to change one common action, we simply update that VI and instantaneously all ancestors share the new code in that command object. Double cool.
Problem is that I love User Events. The idea of having an extensible object model gets awkward to handle when you start using Events to handle communications in and out of the object. Create a Parent, Implement the 15 Events required. Create a child, Implement the 15 Parent events and the 12 new events. Create a Grandchild, Implement the 15 Grandparent, the 12 Parent and then the 25 new Events. Armageddon occurs when you want to change the common functionality for the sixth Event of the Parent. Now you need to go to each and every ancestor which uses them and update them. Wait a second, isn't LVOOP supposed to save me from this kind of crud? Frustration ensures. Can you ever be sure you got all instances? What about those obejcts not listed in the project, maybe you forgot one of them...... Nasty testing and debugging ensues.
I think I may have (partially) found the answer. What we need to do is basically do the same thing we have done with the command pattern and extract the individual frames of the event structure and place them into external VIs so that we can 1) re-use the VIs in each level of hierarchy and 2) maintain all the other niceties of Events.
Turns out that using Callback VIs for each level of the object hierarchy can help to solve this problem. You need to have a method with a different name for each level of the hierarchy which exposes the events int his way because each method will most likely have different input values.
Has anyone else done things like this? Are there limitations as to what can and can't be done with this arrangement? Any nasty bugbears waiting for me around the corner? How to deal with events which should give some kind of return value? Do I encorporate the return value into an implementation-agnostic return channel (again Events of course) with the object in question providing one return user event for each callback function which requires a return value?
Say hello to my little friend.
RFC 2323 FHE-Compliant

Grr, I was trying to attach a file (whose contents apparently didn't match the file name?!!) when I ran out of time to edit and now I lost my text.
Here's an example.
Base class swaps out a control Caption for Label upon "Mouse Enter"
Child class swaps out a control Label for Caption on "Mouse Leave"
Grandchild increments a counter (stored in Description) for every "Mouse Enter"
Trivial but get's at what I mean.
I know I can do this in other ways but
1) I don't need a parallel process
2) I'm just having fun
Darn, I can't attach a zip. Rename this file to .zip and unpack. Sorry guys.
Say hello to my little friend.
RFC 2323 FHE-Compliant
Attachments:
LVOOP with Event callbacks.txt ‏78 KB

Event CallBack in TestStand - Labview OI

Hi everyone,
i am using the simple interface for labview of teststand, i have modified the interface what i like, now what i want to do is when the user press the control button to execute a sequence the system ask the user for something and depending of it answer execute or not the sequence, for this i have create a new event callback, modifying the configure event callback.vi, what i introduce in the Reg Event Callback is that when StartExecution event starts it run the callback vi that contains the question to the user.
It works well because when the user press the run sequence control button or the restart contorl button, the system ask the user. But the problem is when the user press the exit control button, the system ask too.
Why occurs this, and how can i fix it??
Thank you in advance

Hi Marith,
This behavior is occurring because the Application Manager automatically executes the FrontEndCallbacks sequence file when the Operator interface starts, and again as part of the shutdown. To prevent this from occurring, we'll need to check that the execution is not the FrontendCallbacks execution before launching the dialog (the other case is "FrontEndCallbacks.Seq"):
You also may want to consider a couple alternative implementations:
use the UImessage event to run the code when the UIMsg_ModelState_Initializing message is posted (when the process model begins executing)
putting this code in the process model rather than the User interface - in this case we could just add a step in the setup of the model, and terminate the execution if the user chooses.
Al B.
Staff Software Engineer - TestStand
CTA/CLD

How to find out the list of workflows with active event linkage?

Hi All,
I want to find out the list of workflows whoe event linkage is activated in the system.
Through SWU0, we can get a list of workflows attached to a particular event of a business object.
Thanks,
Sivagami

Hi,
Thanx for ur reply..
I got the list from the table...
thanks,
sivagami

Issues with windows 7 after Labview 2012 installation

Hi
I am having some issues after installing Labview 2012 on machines running Windows 7. Firstly, after installing a program on a user's machine, the machine sometimes takes 20 minutes to boot up before the user can log on. The 'Please Wait' message appears during this time. This is also the case on the development machine.
Secondly, on the development machine, I am having an issue when trying to run compiled programs created in Labview. When installing, everything works fine but when I go to open the program, it appears on the task bar for a brief period before closing. It does not appear in the task manager either. I have tried this on 2 other machines with windows 7 and Labview installed and still get the same issue.
Any help on these matters would be much appreciated. Thank you

Hi
Firstly, looking at the issue with the slow Windows 7 boot up time, as Norbert_B suggested the Windows Event Log is a good starting point to find the root of the problem. The following link describes how to launch “Event Viewer” and some common problems:
http://itexpertvoice.com/home/what%E2%80%99s-taking-so-long-how-to-fight-slow-startup-times-in-windo...
Aside from that, if your computer is part of a domain, the problem may be connected with certain Windows Services that start automatically on boot up. I recommend trying the following steps:
Open up “Control Panel” go to “System and Security” then “Administrative Tools” from here launch “Services”.
Sort the list by name and scroll down to “Network Store Interface Service” right click and select “Properties”. Under the startup type dropdown select “Automatic (Delayed Start)”.
Next scroll down to the “WebClient” service again under “Properties” this time select “Disabled” under the startup type.
As for the problem with running LabVIEW executables, I have a few questions:
Do you get any error codes when it closes automatically?
Does this occur for multiple executables or just one in particular?
Does the code run without a problem within LabVIEW?
Have you tried to update LabVIEW?
What hardware are you running?
Without this information I can only think it may be caused by the Windows Data Execution Prevention (DEP) security feature. So you can try the following steps:
Right click on “Computer” and select “Properties”.
Click on “Advanced System Settings” and select the “Advanced tab, then under the performance section click “Settings”.
Click the “Data Execution Prevention” tab.
Make sure it is activated for essential Windows programs and services only, or you have an exception for your EXE.
You may also find the following link helpful on debugging applications:
http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/debug_apps_dlls/
Let me know if these solve the problems.
Andrew.N
Applications Engineer
National Instruments

How to decide when an a "wait for event action" is activated

Hi,
In the attched example file (which is a part of my program)I have 3 basic stages, enclosed in a sequence structure:
1) I initialize the GUI buttons
2) I check the instruments in my system are opened and ready to run ("VSWR initialize vi")and issue a true/false result.
3) A case structure for normal run or abort operation (if the instruments do not
respond correctly).
4) If everything is ok the user has to scan a S/N using a bar code scanner.
The problem is that when I run the program the EVENT STRUCTURE in the FALSE part of the case is automatically activated, before the VSWR initialize vi is started!
This causes that when the user tries to scan the serial number on the GUI he can only type one character and then the screen is stuck.
If I disable the result from the VSWR initialize vi (as shown on the example) and connect a TRUE constant to the case structure, the event structure is not activated but then of course I can not use the "VSWR initialize vi".
How can I make sure the event structure is activated only after the two first parts are done? That is, in normal order - only after the "VSWR initialize vi" returns a false result.
Note, there's no need to understand each component in the attached file. The question is rather a general one about the right way to synchronize my program.
Can anyone help ?
Thank you in advance.
Attachments:
example.vi ‏34 KB

Saverio already mentione most critical points. here are a few more:
A very ugly quick fix (duct tape repair) is to configure the events to NOT lock the FP until the event completes. I recommend against this.
All your buttons should be latch action. Now you don't need to reset them at the beginning.
Set the "Board SN" string control to "limit to single line" and you don't need to remove the linefeed later. You should handle it with a "value changed event" anyway.
You have way too many sequence structures. Many times execution order is not that inportant.
Event structures need to be on a toplevel diagram loop, always ready to fire. Don't hide them inside case structures or inner loops.
Lot's of unecessary code. Let's look for example at the code in the big FALSE structure:
You have a reference and write to a value property of the message box while the message box terminal is disconnected elsewhere on the diagram. Remove all that extra baggage and place the terminal right there and wire to it.
You have a while loop containing a sequence, containing another while loop. The sequence and outer while loop have no purpose.
The while loop spins millions of times per second, just burning CPU. How fast can you possibly type??? Place a 100ms wait.
Rewritten as event structure, it could looks as follows (buttons set to latch action, string set to "limit to single line" and NOT "update while typing"). (see iamge below).
Of course the entire code should be rewritten in a similar fashion and around this single event structure. A second event case could deal with the error condition. Simplify!!!!
Message Edited by altenbach on 06-14-2009 11:49 AM
LabVIEW Champion . Do more with less code and in less time .
Attachments:
GetSN.png ‏46 KB

How to place event callback components and "main-VI" components in the same Front Panel?

What I'm trying to accomplish:
Place a .NET component, which generates events, and other standard LabVIEW components in the same Front Panel. The standard LabVIEW components should be updated when events are being generated in the .NET component.
How I tried to solve it:
Problem:
The event callback code must reside in a separate event callback VI. In order to "pass the event up" to the main VI I tried to use a global variable. The interrupt does occur:
but I was hoping that the string indicator would be updated when the event occurred, but it wasn't.
Questions:
What's the best way to solve what I try to accomplish? If I want to solve the problem on the picture above, how would I do it (it may not be the best solution, but I'm still curious what's wrong)? Please feel free to be over-explicit when replying as I am novice LabVIEW programmer. Thanks in advance for any help.

There are two bundle functions for creating clusters. The function simply called Bundle operates almost exactly like the Build Array function I showed. The type of the output cluster depends on whatever you wire in as inputs. You don't have to supply a specific type parameter.
The function called Bundle by Name takes in a specific type of cluster in the top input and allows you to fill in the values of that specific type of cluster. To create the specific type of cluster you want, you need to create a cluster of string references. Here's how to do that:
Go to the Front panel and drop down an empty cluster shell.
Go to the Refnum palette and drop down a Generic Control Refnum. Now here's a cool trick to turn that generic refnum into a string-specific refnum (a so-called strictly-typed refnum). Grab a string from the controls palette and drag it into the Generic Control Refnum. Once you drop it, you'll see the refnum change its icon to display a string picture.
Make copies of this string refnum (as many as you need) and add it to the cluster shell.
Now, if you're making specific types of clusters to work with, now is the absolute best time to learn about typedefs if you haven't already. It will save you hours and hours (if not days) of development time in the future. Trust me!
Jarrod S.
National Instruments

Recursive ActiveX register event callback VI

Hi!
I am trying to control a motor in LV2013 using the ActiveX concept. When I use a "register event callback VI" function, can I call the same VI that calls a VI (with the "stop rule" controlled be the user data terminal, of course, inside)? By default, callback Vis that one can create for this are all reentrant (preallocated clone) and synchronious (according to help). However, both when I use the "server VI reference" ("This VI") and when I create a reference and browse for the same file - "register event callback" shows me a broken wire.

_Basil_ wrote:
As far as I understood, putting a movement method in the loop will not give any result, so I tought in the direction of the recursive callback. However, I found this post. Would you in general agree that the callback VI cannot be recursive? I attach my code in LV13 (if you need me to convert, I will)
Sorry, I'm still on LabVIEW 2012 here, so can't look at your VIs. I don't understand your comments in these sentences though. What do you mean by putting a movement method in a loop will not give any result? And why would you ever want a recursive callback? The callback is called each time the event occurs. There's no sense in making it recursive, nor would you want to re-register for a callback on an event inside a callback VI. Normally a callback should contain very little logic; it should primarily pass some piece of information (through a queue, user event, etc) back to the main thread and let the main logic handle it.

Event callback insanity

Can anyone tell me what might be causing
such a serious error?
#Date: Mon, Jan 26, 2004 1:56:37 PM
#OSName: Windows NT
#OSVers: 5.0
#AppName: LabVIEW
#Version: 7.0
#AppKind: FDS
D:\lvworm\src\lvsource\eventoracle.cpp(370) : DAbort: event callback insanity
$Id: //labview/branches/Wormhole/dev/lvsource/eventoracle.cpp#112 $
0x00589B50 - LabVIEW + 0
0x0058A245 - LabVIEW + 0
0x0058CFDB - LabVIEW + 0
0x0040AF57 - LabVIEW + 0
0x0DDAA9C7 - tsui + 0
0x0DDA9FC3 - tsui + 0
0x0DDA1FEF - tsui + 0
0x581777B0 - teapi + 0
0x77E3A2D0 - USER32 EnumClipboardFormats + 76F
0x77E145E5 - USER32 GetDlgCtrlID + 1E
0x77E15B51 - USER32 wvsprintfW + 132
0x00B
84CA0 - LabVIEW + 0
0x00B3C46B - LabVIEW + 0
0x00C0813C - LabVIEW + 0
0x7C5987E7 - KERNEL32 SetLocalTime + 4FC

Hi William,
I can not off hand explain this to you beyond the obvious stuff.
If you can reproduce this error at will, I suggest you share the details on how you did this.
I also suggest you report this to NI as a possible bug. I am not sure if Win NT is still supported.
Ben
Ben Rayner
Certified LabVIEW Developer
www.DSAutomation.com
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Probing an Event Callback vi

Hi All.
Please could someone tell me why when I probe or enable tracing on the block diagram of an event callback vi nothing is indicated even after I know the vi was called because I can the the results of it being called. I am running Labview 2009.
Thanks in advance
Ian
Solved!
Go to Solution.

Hi and thanks for answering. Unfortunately I cannot post any code for security reasons. However the code I am degugging (not my code) is not using the usual event structure but uses a 'Register Event Callback' function to call a particular vi when a certain event (top level front panel control) is initiated. When I initiate the event I get the correct response on the top level vi (a user prompt pops up) so I know the vi is being called correctly. However if I pre-open the sub vi and set tracing or probes then initiate the event again I do not see anything register on tracing or in the probes (shown as not executed) even though the vi obviously ran again. The reason I want to probe the called sub vi is that a similar event is not working correctly and I was trying to see what happens with a functioning bit of code to draw comparisons. Hope I'm explaining this OK.
Thanks again
IanR

Event callback with active x in labview

Similar Messages

Maybe you are looking for