shoneill

QUOTE (gmart @ Jun 8 2009, 02:22 PM) Maybe a stupid Q but what's the practical difference when using the two providers. I've been using the SCM up till now, I assumed one was a command-line version whereas the other was a GUI version. Silly me. Shane.

QUOTE (crelf @ Jun 5 2009, 06:15 PM) The bit about all brights being atheists. It's possible for somebody to believe in a god which does not involve superstition. A Deist for example. A bright could theoretically also be a Deist. Shane.

QUOTE (crelf @ Jun 4 2009, 10:25 PM) Not neccessarily, but true. Shane.

QUOTE (Cool-LV @ Jun 5 2009, 07:00 AM) Funny, works for me each time. Did you actually remove and re-attach the device after uninstalling? What OS are you using? Shane.

QUOTE (crelf @ Jun 3 2009, 10:19 PM) But then you have the problem that a lot of brights are Atheists which, according to Alfa are low-level..... Why oh why did I let myself get drawin into this thread again...... Shane.

QUOTE (Cool-LV @ Jun 4 2009, 05:43 AM) Hi, you referred to my USB nugget on the NI site.... There's an easier way to restore the "normal" functionality of your device without going into Regedit. Go to the hardware manager and find your device. Right click on it and choose "uninstall". That should do it. Remove and re-attach the device and it should work as "normal" again. Shane.

QUOTE (Ic3Knight @ Jun 2 2009, 06:09 PM) Just to stick my nose it.... I recently installed Perforce and if you stay within the "demo" requirements : five workspaces and I think 3 users, then it's free. It has LabVIEW project integration (You can configure SCC on a per-project basis) and it's pretty fast. I like it a lot, I'll be sticking with it. Shane.

QUOTE (Aristos Queue @ May 19 2009, 10:31 PM) Not depressing at all. In fact it's not even surprising. I know just enough about the "under the hood" aspects to have already guessed this would be a rather large fix. I just have to re-think my usage of my brand-new XControls (I've only implemented two so far!). Either way, I'm enjoying the new possibilities offered by LVOOP and XControls (Albeit less intimately intertwined than I originally thought). Shane.

QUOTE (Aristos Queue @ May 19 2009, 07:31 PM) Thanks for the info on that. I THOUGHT I read something on the topic before. Could you give me a link, I can't seem to find it. I wasn't certain if I HAD actually read something because with such a good memory, sometimes I remember things which didn't even happen! So XControls are for visualisation OUTSIDE of the class? Shame since it would seriously help debugging if we were able to replace the standard LVOOP terminals with XControls. That would be so nifty. I suppose I'll have to work another way around my problem. I have exactly the circular link you are referring to. I don't have a broken arrow, but I have several uneditable VIs. :headbang: Now where's notepad again.....? Shane.

QUOTE (Gavin Burnell @ Dec 22 2008, 12:41 AM) I just ran into a similar problem. I wanted to replace the default LVOOP controls and indicators in my classes with some simple XControls to give some visual feedback (especially when debugging) on the FP of my LVOOP VIs. I created the XControl (which uses some of the VIs of the class it is displaying) but when I wanted to place it on the FP of one of my LVOOP VIs, it locked the entire class (actually the entire class hierarchy!)...... I was able to right-click the XControl and select "unlöock for editing" but I still couldn't edit the VIs which were being used in the XControl. If anyone wonders why XControls haven't been used more extensively in conjunction with LVOOP well there's a pretty clear answer for you. It doesn't seem to work. I tried in 8.2.1 and 8.6. The result was the same in both. Note that I did not incldue the XControl IN the class as it seems this is not possible. If I was able to add the XControl to the class, I could access the data of the class directly without having to use any of my LVOOP Accessor VIs. This might get aroung the locking problem. Has this been fined as a bug? I see it as a major problem as it makes LVOOP and XControls almost mutually exclusive whereas they shoiuld really be a perfect match. Shane.

QUOTE (ShaunR @ May 15 2009, 11:05 PM) Thanks for that! Should have been less lazy and typed it out instead of using an acronym..... Shane.

QUOTE (ShaunR @ May 15 2009, 05:02 PM) Well with a series of "fire-and-forget" devices, the Re-usability of LVOOP is kinda wasted I agree. Different scopes, different solutions. Shane.

QUOTE (ShaunR @ May 15 2009, 04:34 PM) I guess I got stuck on the QUOTE But my particular read-write "tool" also supports CAN, FIP, MVB and STANAG. Once the read write has been "upgraded" you can support any device on those interfaces. part. Sounded like code changes in a central Read/Write funciton to me. I didn't realise you were dynamically loading the Read/Write functions using a LUT. You realise you're re-inventing the wheel of Dynamic dispatch right? If you really wanted you could combine your approach with LVOOP and have LV do all the LUT managing for you. I don't see how it could be more efficient doing all the administration yourself. So you could have a RS-232 class, a GPIB class and so on with their own read and write functions taking commands from a file. Quite simple really. But where exactly does the enhanced functionality come into things? How do you get above the basic I/O level and get to do something USEUFL with the data being returned? Shane.

QUOTE (Michael Aivaliotis @ May 15 2009, 10:48 AM) Yeah, but how long before the old and new generations of Trekkies go to war? Shane.

QUOTE (ShaunR @ May 15 2009, 08:40 AM) No problem. QUOTE (ShaunR @ May 15 2009, 08:40 AM) Actually, its instrument independent. And "hopefully" your instruments have a pre-defined protocol otherwise it really shouldn't be on the market. The idea is not to replace Daklus approach. It's a way I've used over and over again on many projects with many comapnies with many different instruments to alleviate the "Driver Wrapping" which I always see as the ball-ache of not only classes, but programming in general around instruments. It's just a very quick way of incorporating an instrument and configuring it with a minimal amount of coding and total re-use. Of course they have defined protocols. Wouldn't work otherwise would it now? What I meant is that in your example EVERY command for the device must work with a single type of WRITE and READ function. There's no part DIO, part RS-232 if I understood correctly. Unless you code the differences into your ReadZ/Write VI which sounds like a major pain to me. But maybe you don't need functionality like that, in which case it won't be a problem. QUOTE (ShaunR @ May 15 2009, 08:40 AM) This is what I see too. The abstraction can be a functional abstraction of the task rather than abstraction of the devices. Exactly. One implementation is INDEPENDENT of the protocols used with the instrument(s) whereas the other is not. With LVOOP ALL protocol-specific information and code is encapsulated within the class. With LVOOP I can release plug-in modules which will work seamlessly with the parent VI without having to change a bit of code in the parent VI. This is post-release flexibility which can be pretty cool. Shane.

I'm arriving late at this discussion, but I've been doing a bit of LVOOP programming recently and I just wanted to share my thoughts.... The version suggested by ShaunR is suitable for a pre-defined set of instruments with more or less pre-defined protocols. Where is gets messy is if a "device" (an abstracted device) is actually composed of more than one physical device (see example below). This is something which cannot (unless I misunderstood the idea) be accomplished with this approach. There are situations where I could use some functionality of one instrument and some functionality of another instrument to create a new "virtual" device. LVOOP can do this, "polyconfigurism" (Cool word) can't. The step of designing the class structure for such a project is probably the hardest part. I recently had a project where I started implementing functionality and soon realised that (with a bit more work) I could incorporate 75% of my functionality into the base class. I then spent a few days moving most of the code into the base class while writing some extra code to make it adaptable to a common "interface" within the child classes. In the end I ended up with only a fraction of the code required to create a new child class for a new function. If I had a good enough crystal ball, I could have saved myself a lot of time..... Now most of the work is done by code which is int he base class (no dynamic dispatch) and takes a whole lot of work away from me in the future. I have also realised a LVOOP driver for a spectrometer which, while it has a LVOOP Backend running in a parallel process provides an interface via User Events. A spectrometer is pretty much like any other so defining the classes was not too hard. In order to incorporate a new Spectrometer I simply create a new class and feed this into my background process (which thanks to LVOOP runs with the new class without any code changes). Daklu's Idea takes this a step further. If I have understood correctly, you do something similar but then provide a way for broadcasting which Interfaces are available for a device. So I could have my Spectrometer servicing both a Spectrometer and a Colorimeter and a Temperature sensor interface. Is that correct? Is that the idea behind the examples posted? I have to confess I've read the document but not tried out the code. In addition I could jerry-rig a filter wheel (RS-232), a monochromator (GPIB) and a Photomultiplier (DAQ) together to create an Interface for a Spectrometer using three different devices witht hree different protocols. My top-level software doesn't care, it just calls the "Get Spectrum" method and (after a little while for a scanning spectrometer) delivers the data. Just my thoughts. I've done both approaches and I'd rarely consider the "polyconfigurism" approach again. The extra flexibility of the LVOOP approach causes more work initially, but the need for maintenance is less (in my experience). Shane.

QUOTE (rolfk @ May 7 2009, 08:38 PM) Wow. It works. I got around the valid path problem by simply giving a string with the name for the VI. this worked in 8.6.1 for Mac OSX. Funnily enough, choosing MacOS as the target was not supported but everything ran fine with the target set to Windows (under MAC OSX this is not intended behaviour). Cool tool. Shane.

QUOTE (rolfk @ May 7 2009, 04:12 PM) Example? Shane.

QUOTE (RalcoBe @ May 6 2009, 01:24 PM) The problem lies partly in the question formulation and partly on the definition of the "right" answer. The certification os geared towards fuelling the NI certification program. There, you learn the "correct" answers. If I wanted to be nasty I'd say it reminds me of scientology..... Shane.

QUOTE (Paul_at_Lowell @ May 5 2009, 06:27 PM) ^^^^^^ ¦ ¦ ¦ ¦ ¦ ¦ See what I mean: "composite relationship" and "Strategy pattern". Cool. Shane.

QUOTE (jgcode @ May 5 2009, 05:47 PM) No i don't think this can be done like that. Both sibling classes could have totally different member data and methods so there's no way for the compiler to automatically know how to convert one to another, if it's even possible. You'll need to write a converter VI to do the work for you. I don't think this can be automated in the way you want. Casting down (towards parent) is fine but casting across or forward is not possible. Bear in mind the ACTUAL class type is important here, not the "assumed" type. Man I wish I knew the proper syntax to explain what I mean.... I'll leave it up to somebody else with more accurate terminology to avoid confusion. Shane. Ps You can have classes IN classes (as member objects: "File format" as an object and "Operations" as an object) so you could use one class to load the file and another class to perform the operations. This way you can mix to your heart's content. You'll soon realise the flexibility of this and start converting EVERYTHING to classes.....

QUOTE (Gary Rubin @ May 5 2009, 03:09 AM) I can confirm that on the MAC in LV 8.6 that selecting User Interface makes the whole thing a LOT slower. Funnily enough on LV 8.2.1 and WinXP, it got faster..... The QUEUE is still a good bit slower than the LV2 on the Mac with 8.6..... Wierd. Shane.

QUOTE (Gary Rubin @ May 4 2009, 10:51 PM) I changed the "preferred Execution System" of your benchmarking VI to "User Interface" and I got much faster results for the Queues..... (Still slower then LV2 global though) Discuss Performed in 8.2.1. Shane.

QUOTE (crelf @ Apr 23 2009, 04:07 PM)

QUOTE (ShaunR @ Apr 29 2009, 02:06 PM) If you have registered for an event and the event fires one of the parameters passed at the left-side of the event structure is the actual event refnum. In my mind this does not belong there but you could theoretically close this reference and kill all other processes "listening" to the event in other places. Shane.