hooovahh

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

I've never tried it but I think there is a LabVIEW.exe call that can do this called MoveBlock https://decibel.ni.com/content/docs/DOC-9091 Still I've seen that XNode mentioned by NI and it should work.

I've never tried this but here is apparently a way to decrease compile time drastically by using TurboBoost. http://forums.ni.com/t5/LabVIEW-FPGA-Idea-Exchange/Multi-core-Compiling/idc-p/2301338#M297 This should really get more visibility. As for the OP sorry no clue.

If you want to over complicate things sure you can use Classes or Variants. But seriously what is wrong with just ignoring the data that isn't needed for that type of DIO? It is quite easy from a developer perspective to see that you are just ignoring control values if the DIO is an input. Dynamic Dispatch can do this work for you, but with no extra VIs, and a single type def you can have the same functionality. Variants could be used with a convert from one type to the other if it is an input, or output, or PWM output too but there we possible type conversion errors to worry about which might not be that big of a deal depending on how it is written. I'd KISS in this case. If we are talking about any larger of a design, where a channel could also be a counter, with PWM in or out, or an analog with in or out, or output wave etc. Then yeah classes would probably be what I suggest.

Set a timeout in the event structure, and drop down an Elapsed Timer express VI. This will tell you if some amount of time has gone by. If it has get the next image which should be the next index in an array of file paths.

Well the idea is to use a publisher subscriber design. So this means you can communicate 1 to 1, or 1 to N from the parent, but only 1 to 1 from the child. So you could send out a single global event that all children get. This would then be acted on at more or less the same time on all children at once. Just like how you send the Quit and they all quit at once, no child is waiting for another child to quit. As for the response. Because the design is 1 to 1 from the child perspective, I'd say you could send out a global out, from the parent, then each child can generate the same event back to the parent, with different data identifying which child it came from. Looking at my code I feel bad for not completing this part which was in my head but not in my code. Notice that again there are 3 events made which is unique for each child. Set Settings, Get Settings, and then Get Settings.Reply. The intent was the parent could send 1 to 1 using Set Settings. And the parent could get data by sending a 1 to 1 on Get Settings, which would cause the child to send back data on Get Settings.Reply which the parent would register for. I also can't believe how many subVIs don't have icons, such a shame.

At my previous company I was "upgraded" to a 64GB SSD drive. This was when standard sized SATA SSDs were quite expensive. That puppy was always on the brink of being full. I had something like 6 different versions of LabVIEW installed at once, and for fun I wrote a batch file that would launch them all at once. It was something like 4 seconds to be at the getting started screen on all versions. It was glorious. Later I was upgraded to a hybrid drive and enjoyed the extra space. The job market has been going towards laptop only for a while now. I think the last work desktop I used for my main development work was 2006. Now you get a laptop and you install all you need on that HDD. That is unless you have a mini-PCI slot like some elitists. EDIT: No SSD now but I have been touting a I7 with 16GB of ram for the last 2 years. The power brick is huge.