hooovahh

I'm sure you have it in a specific format, but if you want to go with the ISO standard for having time as a string. http://lavag.org/topic/15034-timestamp-support-for-format-into-string-scan-variant-from-string-string-package/#entry90605

It does depend, but generally I read the event data in the event structure, and in it some information says what case in the state machine it needs to go to. There it can perform the steps, or go to other states in the state machine to do the steps, associated with the event requested to be done. After the QMH states are empty it comes back around to the event structure, to look for user events (or other events) to perform that may or may not have been generated while it was performing the Do steps from the last event. Events are a lossless queue (for the most part) and so I don't really see a need to pull event requests, just to send them to another loop when they could just be handled in that loop, and have the events pile up. Assuming events can be handled as fast as they are added. But even if they couldn't, sending it to another loop wouldn't fix that. Of course in 2013 there are new tools to detect if events have piled up to the point that there isn't hope of processing them fast enough. A pros and cons list might be based on how it is implemented, and how it is used. I list a con, but that might be contingent on the fact that the architecture is used in a certain way. I think this would be a good subject to discuss either here or the dark side.

Correct. You can't set the behavior of locking or not locking the front panel from a user event. If you wired a control reference to the register for events, and picked something like Mouse Enter then you can right click and choose to lock or not the front panel. As for a user event locking the front panel. I've never had this be a problem because very little happens in the event structure. For me the event structure is in a state machine, and after getting an event will go and o what it needs to. During this time the UI is no longer locked and will respond. So one solution is to make the code in the event structure very minimal so it locks the UI but only for a fraction of a millisecond.

Oh sorry I was confused. If the selected object is under the class "Node" then you can use the property node to read the terminals on it. Then for each terminal you can find the wire. Have you looked at the other shipped QuickDrop functions? It helps to see how others have done similar tasks if you haven't already.

Use the Traverse for GObjects function on the palette. Provide it a reference to the VI and tell it to search on the block diagram. As for the class to search for enter "Wire". It will return all the references of that class type on the block diagram but it will be returned on generic GObjects. You'll need to use the "More Specific Class" to turn it into a wire reference.

On each terminal you can use the "Is Source" property node and it will tell you if it is the source, or sink of a wire. By the way I believe index 0 is always a source and the last element is always a sink.

Sure. So parts of the vision toolkit are free. Basically any image manipulation is what the extra cost is, but I'm pretty sure you can acquire without needing anything extra. I'm not certain but I think these links will help. http://www.ni.com/example/30030/en/ https://forums.ni.com/t5/LabVIEW/Capturing-live-image-from-integrated-Webcam-using-Labview/td-p/2066668 I think the free part of the vision toolkit is called VAS, Vision Acquisition Software. There was a thread on LAVA at one point talking about it but I can't seem to find it.

That's the one thanks.

Is this a UK thing? I searched google and all that came up were tips on how to get your dog to not bark. In any case I haven't used 2014 much but haven't seen this behavior yet. I'd need to see more evidence in the form of a VI that could be ran which demonstrated this. NI would likely be very interested in this VI too if it can help them create better performing releases in the future.

I suspect it is. Of course you can make your own installer using something like Inno Setup. But even then you may have difficulty because I suspect Windows does this on purpose. Just tell the customer Mr. Gates doesn't want you to. Do they have a reason for wanting this application in that directory?

Wait, are you trying to install a 32 bit application, in a 64 bit environment...and put the 32 bit application in the directory designed for holding 64 bit applications? If so I suggest informing your customer the purpose of these directories. I'd suspect this is partially Window doing strangeness. Just like when you write to the registry from a 32 bit program. Windows will put it in a separate place in the registry, and it is transparent to the application. Reading and writing looks like it is going to the normal places, but instead Windows makes a separate place for 32 bit applications to do their own stuff. If you mean you are in a 32 bit windows, and installing a 32 bit program puts it in the (x86) folder, which normally shouldn't be there, then yeah that's an issue. I've never seen this issue before.

Ahh I guess that makes sense. Any transport layer that relies on a reference, and is asynchronous, could have the potential problem of destroying the reference before all consumers have consumed the data. I don't know how your application is structured, but would it be possible to create this reference before any actors start, and destroy it after all actors have been stopped. That is if you must rely on a DVR. What was the reason you were interested in using DVRs in a user event? Instead of just use the user event which is lossless (more or less) as we've mentioned.

Again I'd like to stress that this has never been done with this design pattern but could be done, and could be done a multitude of ways. Let yoru DAQ actors start up, and then have it publish to a functional global (or something) an array of signal names that the actor is currently reading, and an array of user events for each signal. Then have a way for your child window to select a signal from an actor. Maybe a right click option, or use the same menu for renaming the window. Once a signal is selected that window could then register for the user event that corresponds to that signal selected. Then back at the DAQ actor, generate a user event for each of the signals being measured when there is new data. This way the actor is publishing, and the children are subscribing. The publisher doesn't know how many subscribers there are and it doesn't really matter. Unless this is done on RT I'd suggest not generating an event for each new sample of a signal, but instead generate an event and send over N samples either in an array or a waveform. Then when the child gets new data, you can append this N samples to the end of the graph currently being displayed. This isn't perfect and needs some through about the different supported data types, but it could scale well if done right. This technique could be applies to non synchronous communication too. Lets say you are looking for a CAN bus signal that is sent by another device. You could subscribe to the data in the child window in a similar way, and then when no new data comes in, you know that signal hasn't been seen.

Well my suggestion with who kills the DVR comes from who makes it? Does any one actor create the DVR? or is it created before the actors startup? If it is created before the actors, then my suggestion is to destroy it after all actors stop. As for your other issue with reregistering events. In the past instead of having one event for a giant cluster that I knew I would need parts of. Instead of registering them as a cluster, you can register them as an array, but only if all the data types are of the same type. So I choose to make N user events, all of the data type Variant. Then if you register for the array, any event within the array will cause that case in the event structure to be called. Then you detect which of the user events were generated, and cast the data from a variant back to the type of that specific event. A bit of a pain but with typed data is is quite easy to update and manage.

Again added in 2013. http://zone.ni.com/reference/en-XX/help/371361K-01/lvdialog/edit_events_dialog_box/ http://zone.ni.com/reference/en-XX/help/371361K-01/lvupgrade/labview_features/ Very handy for handling things like window resize where 100 events can pile up quickly and you really just care about the last event so you limit it to 1. Same with a scrollbar that is set to double.

Yeah I guess the technical answer is the better one. That is odd that dynamic events can't be limited like non-dynamic, to make them lossy. You can invoke the Flush Event Queue which I've never used but I assume it...well flushes the events in the queue. That could make it lossy sorta. I mean you won't really be lossing any event, just ignoring them. EDIT: Oh 2013 and newer which is when new event stuff came around.

Events are Queues from everything I've heard, loss less and all. Now there are some interesting issues that can be seen, like if you generate an event, before being subscribed for it, then that event will be lost. Jack had a neat presentation at NI Week 2013 that demonstrated a few memory issues and pitfalls but I can't seem to find it at the moment. I have used User Events for messaging between actors with large amounts of data and I've not seen any issues other than the fact that copies need to be made under certain conditions. File I/O, high speed DAQ, real-time FIFO, FPGA FIFO, communication data, sequence control, UI updating data, no problem with the transport layer it self. You can shoot your self in the foot but that isn't really the User Events fault. I've never used a DVR with a User Event, but I see no reason it wouldn't work.

FYI there isn't a reason to crosspost into another sub-forum. Just another forum, like if you posted this at Forums.NI.com. Still thanks for being courteous.

I'm not aware of any intentional race conditions in my code. The race conditions you describe can be hard to isolate and debug, but hopefully this just means developers will learn the right way of doing things. One thing that comes to mind is performing a floating point "Is Equal" function. This is one of those mistakes just about every developer makes once, then they are aware of it and write code in a more stable manor. This example is different from a race condition because it is easy to debug and test but the outcome in my mind is the same. Developers learning from their mistakes and write better code. I'm not sure I need LabVIEW to do more hand holding so developers don't learn these important life lessons. Is this going to become a form of LabVIEW coddling? I worry about this too, but AQ made it clear this will never happen... I wouldn't trust that the compiler would never make a mistake in detecting this type of issue. For this reason I would also be in favor of not breaking the VI, but informing the developer with some other means, like a warning.

I will not be posting pictures. A picture is worth a thousand words, but a VI is worth a thousand pictures. Post the code not screen shots of the code. I realize this is some times difficult especially when all kinds of VIs for reading the messages are needed so I can understand why you didn't post the code in the first post. You have shown zero effort in trying anything other than running a pre-made example VI. How many of those training links did you go through? Please do yourself a favor and learn the basics by going through them. Attached is an example of some of the things I already have said to try. It looks at the ID and the payload and makes pass fail based on the rules described on the front panel. CAN Message Parsing.vi

Where is it mentioning PlanAhead licensing? Can you take a screenshot? I've just been compiling NI FPGA for years and never seen anything with an error due to Xilinx licensing.

Not just RAM limited in the single process, but RAM limited in the whole OS. So lets say your application takes up 2GB of memory when running which is a lot no doubt. But if your system can only see 4GB of the 8GB installed because it is a 32 bit Windows, then that means you only have 2GB for all other process running. And Windows will start paging RAM to disk way whenever it feels like it, and if it sees one application using half the RAM usable it will start paging to disk, and performance will be impacted. Only a real world test will be able to say if you are fine with a 32 bit OS.

http://zone.ni.com/reference/en-XX/help/371361J-01/glang/unbundle_by_name/ Just search your palette for Unbundle By Name it is a very commonly used function to pull out data from a cluster which is what the frame is returned as.

Using Intrepid hu? Well that Get Messages subVI returns an array of frames. It then goes through each frame one at a time. It does this by using the Auto Index feature of the for loop which pulls each frame one at a time. You can use the unbundle by name and you'll be able to pull out the ID which will be a U32. You can then wire a case structure around the concatenate string function, and wire your ID to the selector terminal. Then when your ID is equal to 0x180 perform the concatenate, and for all other values (Default) don't concatenate. If you are new to LabVIEW check out these free training links. NI Learning Center NI Getting Started -Hardware Basics -LabVEW Basics -DAQ Application Tutorials 3 Hour LabVIEW Introduction 6 Hour LabVIEW Introduction Self Paced training for students Self Paced training beginner to advanced, SSP Required LabVIEW Wiki on Training

I'm guessing English isn't your first language but could you try to explain what you want again? Your VI doesn't seem to make much sense. You should probably be using the event structure since you are looking for a value change, instead of polling the change every second. Also your color scheme is hard on the eyes. EDIT: Crosspost