jgcode

I want to access the color palette as a custom Shortcut RTM event in a control e.g. listbox. I just need to know the color chosen by the user and the cell that was right clicked. Any ideas? Cheers JG

same here :thumbup:

QUOTE (Aristos Queue @ May 22 2008, 10:50 PM) Great point! IMHO I would consider a GOOP VI as a Mutex (shared resource) and therefore it would definately be an issue with creating determinstic code (esp wrt a time critical loop!!). I guess to understand the inner workings then all the authors of GOOP need to answer that question though... (hint hint ) However to quote The Good Book: QUOTE (LabVIEW for Everyone) Semaphores having data is the fundamental concept of GOOP So at the end of the day if all GOOP uses semaphores (??) then the sempahores themselves are defined as inherently non-deterministic. Right now I want to firstly know if GOOP works with LV8.5 RT for its embedded properties. Knowing about creating deterministic code would be good also.

QUOTE (MikaelH @ May 20 2008, 05:17 AM) Thanks Mikael Anyone else out there tried it? :ninja:

QUOTE (fuzzycontrolfreak @ May 22 2008, 03:08 PM) Hi fuzzycontrolfreak The following may help (or may be overkill) If you need multiple GUI interfaces e.g. standard 4:3 for some users and also for other users to take advantage of widescreen or a massive display then you can use a technique to seperate the GUI from the main VI engine. You code one engine VI that handles all the guts of the program. And you code up multiple VIs to handle the GUI. All GUI's contain the same controls but you can manipulate them natively for your desired resolution. The GUI VIs are quite simple. The engine is the same so you minimise code maintaince but gain the advantage of different screens. Use a config or monitor display property node etc.. to call the desired res GUI. To implement it code wise - one way to do it is to use dynamically registered events to subscribe to the GUI (the other I have seen is to use queues). Then just run the GUI and keep it's FP in memory as it has no code (it doesn't need it) that allows it to continue run. I have played with this design a little bit. I like the concept. Props to VI Engineeing as I personally saw it first in their course manual. :worship: [

Well done AQ Cheers :beer: for the great posts

QUOTE (Jim Kring @ May 21 2008, 01:55 AM) Can Jim or anyone recommend such a system from first hand use? Cheers

QUOTE (Gavin Burnell @ May 22 2008, 02:45 AM) Its kinda hard to answer the question with limited detail but if you need the dynamically flexibility of an array coupled with the flexibility of handling different datatypes try the Named Funcitonal Global Variable structure. Someone showed me this structure once and it is really handy as a tagged dynamic store. You assign names to each data element in a store then access them using this name. If a data element exists in a named location it will replace that element, if not it will add it to the array. Even if you are only going to use one datatype this can be handy to track elements by name rather than by index. If you do only use one datatype I would place the NFGV in a wrapper VI so I would not have to handle the variant conversions each time. [

Maybe try index array?

For your menu questions. Yes you need to handle the event. Using the Event structure is one way way to handle FP RTSM selections and it is quite easy. Add a case called Shortcut Menu Selection (User) or Shortcut Menu Selection (App) for the control and handle the Item-Tag string in a case structure. Use (User) for custom items, use (App) for Application items (you cannot edit item name/tag of application items) Also I prefer not to execute code in the Event Structure but to queue it out to a consumer loop.

Before this thread is highjacked by great sayings.... Thanks Jim, I thought as much that spilling the beans would be a problem on people discussing such a issue who have implemented it as a custom solution. As a young'n I created a psuedo setup whereby I could statically (in code) link a user(s) to the application and I also have a time expiry whereby it blocks out a user. Of course they can wind the OS clock back but I covered that by creating a file (hidden somewhere) on the first time out to know if this occurs. Of course if they did a fresh install with and set the clock back it would work. If they could be bothered I thought good on them. At the end of the day it was cheap and nasty. But it worked for what I needed (small volume), I did it ages ago and I still use it now and then. Now I am hunting for something a little more professional.

I am trying to find the best method to license custom software written in LV [not a hardware key -dongle - method, just software]. Following on from this thread, which is a little old, I was wondering if anybody has any new methods they can share (without them feeling like they are giving away their gameplan). I was hoping the VIPM team might be able to chip in as they have a nice license setup. Is everything done over the web with a authentication license server nowdays for easy management? Regards JG

QUOTE (orko @ May 20 2008, 04:51 PM) SZ Series - Nice! I am running the older S Series, still going strong, but eye off the SZ all the time! I rate your workplace if the company PC is VAIOs! For me last place was Levono, current work PCs are Dells. Even though spec-to-price ratio isn't that great - there is some sexy about the VAIOs and you can't beat those screens.... (mmm VAIOs) QUOTE (Jeffrey Habets @ May 20 2008, 05:34 PM) I noticed there are some 15,4" notebooks on the market today with resolutions up to 1920x1200.. Does someone have experience with coding on these? It seems to me you would need a magnifying glass to distinguish the various functions and VI's on your BD. The lead programmer at work has a new Dell with the above specs. When he points stuff out on the BD i can't see it unless I stick my face right up to the screen. He loves it though! I wish he would drop the res when he is showing me stuff. The only thing I have seen its great for is if we have a massive cluster (like the application's status cluster) we pass around. You can see the whole thing easily, you can probe it etc... But I don't know if its worth it as it makes my eyes go

QUOTE (Michael_Aivaliotis @ May 20 2008, 09:20 AM) Most likely the TZ? - its the smallest at 11.1" - a friend had one, I can't see the damn screen its so small! Would hate to LV on it. I love VAIOs, the off putting thing is the price for what you get. One problem I had with a VGN-S18GP model was that it could not recognise PCMCIA E series card: 6036E. This gave me endless grief over installing drivers. Anyone else anyone else had this problem with any VAIOs?

QUOTE (MicrochipHo @ May 20 2008, 10:43 AM) By the way you need to include all subVIs if you post a top level vi (try a zip file). I don't think the above is too hard to do and I won't be doing you homework assignment for you, but subVIs are great to abstract code, create modular code, create reuseable code, make debugging easier, make the BD neater etc.. It would be a good idea to encapsulte the function generator in a subVI (whether you are required to write your own or use LV's). Have a go at making it run, at this stage overkill on the connector panes shouldn't be a higher priority than getting it to work. Remember to have fun!

Posting an example will help here.... But if I understand you (?) then to pass data to and from subVIs you will have to wire up the connector pane of the icon to enable passing data to and from a top level VI. Also the System Clock on a desktop OS has a 1ms resolution.

LabVIEW Object-Oriented Programming FAQ: How to Use LabVIEW Object-Oriented Programming: Item 4 - if link is current then LVOOP is not supported in LV8.5 RT. Does anyone know first hand if OOP, whether it be Endevo GOOP, Sciware or dqGOOP (or other ?) will work under LV8.5 on embedded targets - in particular NI's real-time OS (Vxworks) We have previously used Sciware in LV8.2 RT so I know that works however, I have been told that Endevo GOOP is not compatiable with LV8.5 and wanted to check the truth of this comment. Regards JG

QUOTE (marp84 @ May 19 2008, 10:34 AM) If you don't have LV Professional or the Developer Suite you will have to contact an Alliance Partner or NI FSE and purchase it.

For a while I used to program solely on a 13.3" with 1280X800 res. It is extremely portable and works well enough at that res. At home I have a 1680x1050 20" to connect to. At work we also use 1680x1050 20" as well. I try to make sure I don't abuse the extra space on the BD by keeping my code neat and compact so switching between the two is normally fine. But I am down with MA on this one as I don't think overall screen size is that important compared to screen res - so if you need portability, make sure you go for a high res screen. Having the same res as your workstation is going to be the most efficent to go between if you are out of the office and need to be programming either on a plane or on-site for a client/project.

QUOTE (tcplomp @ May 15 2008, 06:02 PM) I am not embarrased to say I had this in my room as a kid ...ok wait... maybe I am! PS - for some strange reason I just couldn't throw it out - the force of chuck?

The National Instruments Product Compatibility for Microsoft Windows Vista explicity states that 8.2.1 works with Vista. I believes this means 8.2.0 does not, but I can not confirm first hand.

Chuck Norris can kill two stones with one bird

There may be some helpful info here: Preston Johnson writes: "Finally, you may note that the DMA buffer read is a blocking operation. In other words, when you call read DMA buffer read, the call blocks all other RT LabVIEW code from executing until the read completes. This means that if you are waiting for data to arrive, nothing else in LabVIEW happens. I normally use a read DMA of 0 bytes and use the backlog number to compare with my desired read. Once the backlog is big enough for the read to execute, I then execute the read. Of course I have a sleep (metranome) in my check the buffer loop. This allows your other calculation functions and data storage functions to work while the DMA buffer is filling." You could also try using Shared Variable with a RT FIFO (static configure) or the RT FIFO queues (dynamic configure) to buffer data for interthread communication rathar than use locals or globals which are prone to being overwritten.

I am lurker turned poster (as of yesterday) so I thought I would say hi! I lurked unregistered before joining. My name is JG and quit my last job and took up a full time programming position in LabVIEW because LabVIEW is so much fun damnitt!! I was exposed to LabVIEW in academia. My current goal is to obtain CLA! The company I work for does a fair bit of work with NI PAC so I am having a ball in learning the correct techniques to program in RT and FPGA!! Learning LabVIEW never ends, which is another reason I love it. I love discoving new and better ways to program! And in that regard LAVA is kickass!

QUOTE (brianafischer @ May 13 2008, 07:56 AM) I know what you mean, I used to do what you did or I would unbundle the cluster then make an indicator from the elements just so I could get a reference! But it was one of those a-ha! moments when we found it. I have been playing with VI server and refs a fair bit lately - I am constantly amazed at all the things you can do. Thats why I love LabVIEW