smenjoulet

I can echo that. I'm looking at an app right now (not written by me and which I hope to never inherit, no pun intended) that follows the 80/20 rule in a BAD way! Probably 80% of the data is passed around using references. Top that by having all the references being stored in global variables for "easy" access throughout the program. Then some of the data is dumped into global variables as well, just for good measure. I'm not a global variable basher. I believe they are a tool that can be used effectively when done properly on a limited basis by someone who knows how and when to use them, but this is crazy. This program is begging for OOP techniques and you can bet if it ever lands in my lap, it will be rewritten. Anyway, I look forward to viewing this presentation and the follow-on in January. Thanks!

I think you're confusing waveform chart with the waveform graph. Waveform charts don't have cursors and he really is using a waveform chart. Hova2010, 1) To do what you want would require a bunch of math on click point, plot area size, xscale, history data, etc. I'm not sure it would give you the results you want and I sure wouldn't want to do it that way. 2) You are asking a bunch of small, very specific questions about how to do this or that on a waveform chart. I noticed you haven't gotten a lot of responses lately. Perhaps you should try to describe your overall objectives and then ask your questions following it. That way people can respond in the context of your design goals. 3) It may be time to consider switching from the chart to the graph (either waveform or XY). You can simulate the function of a chart with a graph. It takes a little extra programming, but from all your questions about the chart, you're ending up doing that any way. You get more flexibility with the graph in my opinion and you get to use cursors. I suggest you follow up with another post outling your goals and listing your questions if you can and see if you get more responses. Along with that, be sure to describe your data timing... Are your points equally spaced in time (waveform) or unequally spaced (XY)? I'll do my best to respond and give you what ideas or help I can. -Scott

Fantastic! So is she the first of many instantiations, last of the child classes, or somewhere in between? -Scott

1) From the "Tools" menu, select "Options..." 2) In the Options window, choose the "Environment" category 3) Uncheck the "Lock automatic tool selection" checkbox You may also need to turn off automatic tool selection in the Tools palette itself. Scott

And in addition to that I suspect you'll want to be using build path instead of the "Path to String" and "Concat strings" functions. Much easier.

Are you sure it isn't and the problem isn't with your DAQ loop Try moving the boolean outside the case structure and disbaling DAQ code. I think you'll find that the dequeue is working fine just as it is for me. There is a problem with your DAQ loop. Scott

I was going to tell you that is exactly what you needed to do, so I'm glad you were able to find it and get it resolved. As an additional note, you can do this all within the code of your app instead of putting it in the ini. It can help somewhat with security of your app if you're at all worried about that and it gives yiou the benefit of cahanging the settings on the fly. Scott

Works for me too. LV2009, 32-bit, WinXP. What have you tried to resolve it? Have you tried renaming your ini and letting LabVIEW recreate it and then copying over your desired settings?

I don't think you're going to be able to get anything other than the base SI Units using variants. The original units information seems only to be tagged with the control. That makes sense as it is only needed to convert from the SI unit that is on the wire for display purposes. Doesn't make it any easier on you when you actually want the original unit and value for some other purpose. The only additional thing I can think of that may help (and you may have thought of this already) is doing the conversion to original when using the variant method. Basically, you'd have to map the base SI units on the wire to your desired unit and do the conversion. This would only be a 1 to 1 relationship. Therefore you couldn't have temperature units being converted from K to both degC and degF. So it limits what end units could go into your XML. Maybe it's an option to help you get closer to your desired goal. Out of curiosity, what is the bug that requires the use of "To Variant" in some situations? I didn't run across that scenario. If I think of anything else, I'll send you a PM Scott

I think what he means is he wants to get references to the controls on VIs in his built application from another built app or the IDE. He already can get access to the VIs according to his statement, so he just needs to take it a step further. Thang, If you can get access to a VI in the app, then you need to open a reference to it. Then work down to get references to the Front Panel and then Controls[]. From there you'll be able to access the control you want. Attached is an example of what you need to do. Scott Get Control refs in exe.vi

Here are examples of both methods. Of course, in your real program you would want to make sure you do proper error handling and disposal of user events using "Destroy User Event" Scott Sorry, those were in LV 2009. Here they are in LV 8.6 if needed. Trigger Event - Value Signaling.vi Trigger Event - User Events.vi Trigger Event - Value Signaling_LV86.vi Trigger Event - User Events_LV86.vi

Paul, Don't know if this will fit your requirements, but I worked this up. It does use some OpenG VI's, but I don't think you're getting around that. Sorry if it's a little sloppy. There are a couple different methods contained within this one VI, and both outputs work well with the JKI EasyXML toolkit. Just wire up a Number with Units wire the outpust to your EasyXML VI's. I'll try and post some additional comments later. {additional comments below} A few caveats: - You'll need the OpenG LabVIEW Data VIs, which I assume you already have. I didn't include them. - As I said, it's a little sloppy, especially with two solutions in one VI The top solution (variant in/variant out) will give you results in SI base units. You can see that there are two unit attributes: one with the unit names, and one with the symbols. You could use whichever suits you best. Also, I used [ ] as delimiters for each base unit. The bottom solution (refnum in/variant out) will keep your original units, but you have to use a reference to a control that contains the data. That is so you can get the units. You'll also need to provide a conversion from the base units back to your desired unit. Not ideal, but right now I can't think of another way to do it. I included your example of degrees/radians. If the variety of units you use are limited, it should be manageable. Why don't you post your workaround and see if we can collaborate. Scott physical number to variant with units attribute.vi

QUOTE (crelf @ Jul 28 2008, 04:35 PM) :laugh: You never can tell where life will lead you, but right now I'm happy in Texas. If anything changes, I'll let you know.

QUOTE (neB @ Jul 28 2008, 02:50 PM) Now Ben, you're not comparing me to a scruffy little terrier, are you? It's not really my place to reveal anything (other than making vague references ), so all I will say is, be patient. All will be revealed in time.

As usual, I'm way behind on both finding and responding to this post... So, what level constitutes a lurker? When is one no longer considered a lurker? Can a premium member be a lurker? Does that make you a Premium Lurker? Maybe I just like a high SNR...(Not that theres anything wrong with a low SNR, Norm! I can say that 'cause I work with him.) On to the specifics: Using LabVIEW since 1992 (2.2 on a Mac, 2.5 on Win) Tours of duty in Michigan (born and raised)...I remember when VIEng was just a 4 or 5 man shop! Don't quote me on the numbers, crelf. Florida (4 years) Dallas, TX (5 years and counting) -Scott

Congratulations on that and other yet to be revealed items!!! And generally, I think you have a good SNR. Scott

QUOTE Post #11. I better slow down or I'll hit 1000 by 2399! QUOTE (Daklu @ Jul 24 2008, 08:39 AM) Couple questions: Is there any particular reason you create the user event and generate it in the same vi? Since I am implementing this in a class is there anything preventing me from exposing a public Register Event vi and have a private Generate Event vi? Rather than have Main.vi register for the event at program start, I need to have the ability to Register and Unregister at runtime. Are there any gotchas if I were to implement it this way? To me it provides some simplification, compactness and a kind of encapsulation. I don't see why you couldn't have two distinct methods, one public and one private. The only gothca if not registering at start (before your dynamic VI has any chance to run) is to make sure the event is registered first. You are essentially creating an API for your VI, application, exe,... What we do is create GUIs for device communication. These are LabVIEW built exe's. The exe has these exported VI's (API) as we call them and we can automate the GUI operation from the LabVIEW IDE, TestStand, another LabVIEW exe, etc. It's kind of like a pure G based ActiveX. It's not strictly just for communication/data passing/synchronization within the development environment or one built exe. It can span across multiples of these. So it provides a common interface for a user to debug a device using the GUI manually, but also to automate testing of the device after the debug cycle is complete (or even as part of the debug work). I'm always looking to improve it (Norm's OO wrapping is one avenue), so comments & suggestions are always welcome. Scott

As normandinf mentioned, User Events will work well for you here. I've attached a simple example based off a technique we've been using sucessfully for a few years. It is the LVx technique mentioned by Norm Kirchner above but without Object Orientation. The concept is this: 1) Your main VI ("Test.vi" in my example) registers an event by running a VI (in this case "Export Test.vi") that creates a user event on the first call. The data type of the event can be whatever you choose (numeric, string, variant, etc.) 2) The main VI calls the dynamic VI (Dynamic.vi in my example). I like to use a Static VI ref for this, but it doesn't really matter. 3) The dynamic VI runs and generates its data. Upon completion it calls "Export Test.vi", which on subsequent calls generates the previously registered user event. It passes the data it generated through the user event. 4) The user event fires in the main VI and gets the data from the user event. You then operate on the data in whichever way you choose. 5) Wash, rinse, repeat 2-4 as needed. To try it out just extract the zip and open/run "Test.vi". This is a basic example that can be very powerful and extended in any number of ways (i.e. wrapping it with OO like Norm has worked on). Hopefully, this will help you get started. If not, I still needed a 10th post. Regards, Scott Menjoulet

QUOTE(Gavin Burnell @ Mar 29 2007, 03:37 PM) Yes, that is correct. This allows you to directly access properties/methods without having to cast the reference to the specific type after the "New VI Object" primitve. As for Expression Node, it looks like this is a hole in the VI scripting capability. The Expression Node is of class Node and there aren't any properties or methods for setting expresssions at that class level, as you would guess. You can see this by getting the ClassName directly after "New VI Object" (even when using Generic or GObject as the class type). I'd suggest using a formula node in this case. It's not the solution you're exactly looking for, but it does work and should accomplish what you need. I've attached an example. Regards, Scott

I can verify that Rolf is correct. I have used the LuaVIEW toolkit under 7.1, 8.0, and 8.2 and across mutilple platforms(Win\Linux). The only thing that was required was to recompile the VI's for the new version. Well, I had to do a little more to get the mutiplatform support working the way I needed, but that's a different subject. So, I haven't programmed in C in a long time and don't know the secret (if there is one) to creating a mutil-version CIN for use with 8.x, but it is possible. Perhaps Rolf can put you in contact with Albert-Jan. Regards, Scott

I wonder if this is not an 8.0 vs 8.0.1 issue in your case. I tried it in 8.0.1 and 8.2, but not 8.0. Though obviuosly still a bug, maybe it was "cleaned" up enough in 8.0.1 to get it to work in the project scenario. What ver are you using? Then again, I guess you could just wait 'til you get your 8.2 CD's. Regards, Scott

We've also received our Developer Suite update for August, but we haven't received any individual upgrades to LabVIEW yet. Scott

Right you are! Nice catch. :thumbup: It also works in 8.0. You don't need to start from scratch either. Just put the existing files into a project. Scott

Dave, Sorry to report that the behavior is unchanged in 8.20. What I've seen (both in 8.0 and 8.20) is that the typedef does retain the customizations, but you only see them if you open the typedef while a containing VI is in memory. If you open only the typedef itself (or open it first) you won't see the customizations. Very weird... Regards, Scott

Well, I thought I'd take a few minutes and see what I could find. It doesn't appear to be doable via scripting in the way you would think, i.e. the "SelStrings" property of the Case Selector. The "SelStrings" property is read-only as I'm sure you're aware, and there doesn't seem to be any other proprty or method that allows setting of the strings. So I don't think it's directly possible in 7.1 (at least not without additional unknown "superSecret" help). Having said that I coded up this little beast just for fun that will accomplish the task. Certainly nothing revolutionary, it just just a scripting version of Pat's 2 VI method. Download File:post-415-1128637686.vi BTW, it will be possible in LabVIEW8. We just need to figure out how to get scriptig exposed again. Regards, Scott Menjoulet