hooovahh

Yup this is a big one for me. Our internal spin on Actor doesn't have the issue of launching and destroying actors. Just calling all the actors in parallel just like you would any other subVI. Then debugging tools, and techniques don't need to change. You always have the same number of actors running, and getting references to them or knowing their state is quite easy from run-time or development.

You can formally request topic moderation by using the Report to Moderator button. But in this case I would rather we leave the topic as is. Even if your issue was solved, others may look for help on this subject, and finding what you have already done helps the community.

Wow, okay well you are opening that serial port over and over again as fast as Windows will allow. Now luckily the resource will be locked and you will generate an error the second time that loop runs. Unfortunately you aren't looking at the error, and the error isn't stopping your loop so you won't know there is an error until you stop it your self. Go to the Help >> Find Examples and search for Serial. In newer versions of LabVIEW the example is called Continuous Serial Write and Read. Older ones had a similar example but it has been re-written. This should perform basic serial I/O and assuming it works, you can takes pieces out and make your own application with it.

Yup Brown is private, Blue is scripting, Pink is deprecated.

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.