OlivierL

If you are interested in undertaking something larger than just PC based, I believe the new MyRIO, built around the new Zynq chip, will be available within the next month. That would give you more options to use LabVIEW to interact with the real world and develop a broader set of useful skills around LabVIEW. Not sure about the price point of the device though.

Indeed, those shortcuts are very useful. As Hoovah suggested, I was thinking of more obscure existing features that would get us one step closer from having to go through the FP of Sub VIs.

Hoovah, thanks for making my day brighter. After all these years, I still did not know about holding the Ctrl key when opening subVIs. Is there also a hot key that I am unaware of that allows one to close the FP automatically when the BD is closed?

Created a separate topic to discuss about the need for FP. We can go back to discussing about 1px bends in here. http://lavag.org/topic/17326-should-bd-be-allowed-without-fp/

Moving the discussion about the pertinence of always having a front panel for every VI to its own thread. The discussion was started here by Jordan. Nothing new of course as GregS suggested it years ago. In short, the idea popped after talking about a FP automatic clean up feature! it takes time to align the elements on the FP to make it look good and it is not useful on most sub VIs other than sometimes when troubleshooting. When delving into the code, it would be much faster to just open block diagrams as you double click on VIs (and have half the windows opened.) Icons/terminals on the Block Diagram could display the controls/indicators if need be. There is also others who think that instead of having none. having multiple FPs could be useful at times to display the information differently. I guess that if we discuss about 0 or 1, we might as well think of 0, 1, ...n So, the Front Panel, do we really always need it? Could it be removed altogether from some VIs or just hidden and put on the back seat behind the block diagram? Do we need many flavors of them in a single VI?

Because the FP can be very helpful when debugging, I wouldn't support getting rid of it altogether. However, VIs should have a property that hides the FP and only shows the block diagram (and show the connector pane on the BD screen as well). One major benefit of this would be to have only half the amount of windows opened when troubleshooting a deeply nested VI and getting to your point of interest faster than having to press "Ctrl-E" every time you open a VI. By allowing to hide FP and let a BD window open by itself, you could even have a feature that opens only the BD of a VI when the "Ctrl" key is down regardless of the VI's properties. Since the FP should stay, I still support Jack's original idea and Mark's tool to have a FP auto clean-up so that FP look clean when you need them while not t wasting time with them when you don't. Nowadays, unless you spend some time organising the controls on your FP, your programs can "look bad" even if you have the cleanest code on the BD which really is the only thing that matters. Regarding the notion of a VI being a "Virtual Instrument" and therefore requiring an interface, I think it's time to acknowledge that only a minority of VIs are actually visible to the users and to support the idea of the code be the most important part of the program instead the graphical representation of the function's I/Os which serves little purpose 95%+ of the time.

The new trend of this topic got me digging into the information from Jack's post and I'm quite happy to have found Mark Balla's "SubVI fixer". I'm still working on some LV2009 projects so the automatic 4x2x2x4 is useful on top of the FP auto-alignment. Look here if like me you've missed it 4 years ago: http://lavag.org/files/file/128-fp-subvi-fixer-ver-6-lv-2009/ I Definitely Kudo'ed Jack's idea. On the original topic, VIs available on the palettes should always be 4x2x2x4. Those 5x3x3x5 do make BD look ugly until the bends get hidden behind the "unconventional" VIs. Aligning the icons is just as important as straight wires...

Thanks to all for sharing the videos. There are very good presentations in there that I could not attend.

Hi John, Thank you for sharing this solution with us. It affected one of my clients recently and the solution has worked thus far.

Mike, I had a very similar issue this week. In my case, I had a semaphore that was created in a VI (let's call it ) and I was saving that reference in a shift register for future calls. Everything worked fine at first but every now and then, I had error 1111. After investigation, I found out that the VI might be first called from within a different thread and the reference was lot when the thread finished. That separate thread was a different GUI, running in parallel with the main application, launched with the "Run VI" "Invoke Node". In the "normal case", as long as that VI was first called from within the thread of the main application, the reference stayed in memory until the application completed. To solve my problem, I created the named semaphore in the main application during my Init state. I hope that this help.

Well, you can find the signal's baseline, mean, median and maximum over time, you can very likely adjust the threshold automatically and obtain pretty good results. Use other VI from the "waveform" palette to perform those measurements. Playing with these parameters should allow you to adjust the level automatically and get pretty good results. I've never done it with an ECG but I've had other applications before where I had dynamic threshold.

Therefore, my recommendation for drbrittain would be to use the TCP/UDP communication method. I personally use the AMC (http://zone.ni.com/devzone/cda/epd/p/id/6091) library from NI a lot within a single LabVIEW instance but there are VIs in there to communicate seamlessly accross different machines over UDP I believe. You will need to tweak the code wherever "AMC_UPD port.vi" is called to use two different ports since you are on the same IP address. Otherwise, I just did a quick test with Shared variables and they successfully communicate accross LabVIEW instances (2009-2011) and should also work between 32 and 64 bits. You can use a few variables to allow each process to know what the other processes are currently doing. You can even use those as queues if you configure them as FIFOs. (http://www.ni.com/white-paper/4679/en)

I was just reading this topic and realized the suggestion to use Notifiers across LabVIEW instances (they have to be different instances between 64bits and 32 bits). I never ran into a situation requiring this personally but does this mean that Notifiers (named) (and possibly Queues (named)) allow communication between LabVIEW instances? I looked at the Help file and under Notifier, it says: "Note If you obtain a notifier reference in one application instance, you cannot use that notifier reference in another application instance. If you attempt to use a notifier reference in another application instance, LabVIEW returns error 1492." Doesn't this imply that it is not possible? There might be something more fundamental I don't understand in this issue since I thought it was not possible to install and run both 32 and 64 bits on the same PC...

There is an easy way to open a TCP connection using the TCP interface of your choice. I can't find the code I wrote in the past using this technique but I'm 98% certain that this is right though: Use "VISA Open" and specify the Ressource Name to be: TCPIP SOCKET TCPIP[board]::host address::port::SOCKET TCP/IP Socket [board] allows you to select which interface you wish to use. You can then talk to the device using regular VISA VIs. For more information, look up "VISA Resource Name Control" in LabVIEW help files. Hope this helps. Olivier

Amila, I had to do something similar not so long ago and one of the tools I found useful was (from memory) "pattern matching". One example in NI Vision set is a rotating part (that is with Vision 6 though...) that is located, with its angle with respect to it's original position. Take a look at the examples coming with Vision to learn how to use pattern matching but it could really well offer you a good alternative and an easier way of finding your object. One of the only constraints is that the object should be the same shape, always. Hope this helps.

QUOTE (Yair @ Jan 8 2009, 12:26 PM) About the Build Array and Concat Strings, isn't LabVIEW supposed to release the memory automatically by itself after the loop is over? I can see that as taking huge amount of time in a long loop process but can memory leaks really happen from that? Olivier

Thanx NevilleD, That's really neat and faster and more compact than always going with "Index array"("Array Length" -1). I tried it and was surprised to see it working, even if you change the length of it. If you do that, without an index, it takes the "n" last elements in the array. LabVIEW Help file specifies this behavior. Neat! I'll reuse that one for sure. Olivier

Dear faisaldin, I took a quick look at your code and I don`t see anything wrong at first. You have to give us more information if you want any valuable answers. Tell us what you have done so far (for debugging it) and what is not working exactly. For example, could you clarify what happened when you shorted the TxD and RxD with another test application. Was it successful? Could you read what you were writing out on the port? Are you sure that the cable is crossed and not straight (i.e. TxD gets into Rxd of the instrument and vice-versa.) Also, what are the errors you are getting right now? Olivier

QUOTE (MJE @ Nov 12 2008, 05:12 PM) Hi MGE, to answer your question about htis one, the name inside the <> comes from the data type Label you pass to the Create User Event. As you can see on the image below. The funny behavior is that once you've set the name to something, even if you delete the "User event data type", the name stays. you need to rewire something there, change the label to what you want and then delete it again if you don't need to pass data. http://lavag.org/old_files/monthly_11_2008/post-12461-1226682034.gif' target="_blank"> Hope this helps. Olivier

I agree with you guys that is would be a really nice feature to have for multiple dimension. Also, I like the idea of the permute function and it should exist in LV. In the mean time, I can share this VI I wrote some time ago to "Transpose" a 3D array. Its input is a 3D array of double and you specify which dimension remains unchanged. Olivier

Hi Mathew, Check the code below to have an idea of how to do it. It's not too complicated. Don't be surprised with the "weird" numbers at the end, they round up to the exact initial values. Cheers, Olivier

Horatius, Other options that haven't been said so far are to use the "FirstCall?" VI. It returns TRUE only once after hitting the Run button. Using that and a case strcture afterward, you can reinitialize your indicator once per Run. Using Property node is easy and an efficient way of accessing the value of indicators and controls. Left click on the Property node to change the type of information and you can swap between Read/Write. Is it good to know that this VI will return TRUE everywhere, once per execution which means that you can use it in as many places as you want in your code. Hope this helps. Olivier

v_pan, I have done something similar recentl, with a PIC as well. The hard thing to program is definitely on the PIC side, allocating the correct ressources and Socket type for your connection. LabVIEW is really easy to use once you've been through the tutorials. About what Minh said in the last post, unfortunately PIC are not ARM microcontrollers and I doubt that NI has any compiler for those yet. You will still have to write your code in good old C! =) Best of luck! Olivier