Kurt Friday

I'm all too familiar with that kind of system failure.

We had a beer together last week and realized that we had both come to the same solution. Perhaps we can put our heads together again on this one.

Cool, I'm interested in catching up and getting to know the Sydney LabVIEW people, PM me if you want to catch up for a sometime.

Hey Jim That's a good point that I haven't explored deeply. My first thought is that class Bike has its own DVR to it's datamembers and the child Racer has its own so they are separate and shouldn't interfere with each other. I'll do some tests and see what is involved in breaking it or causing it to lock.

My apologies, it looks like you can. I'd never played with this before, I'll check it out.

Nice!! I don't think you can communicate between LabVIEW exe's with ActiveX as this would involve writing your own ActiveX server.

Hi Bujjin Just looking through the cFP-AI-100 manual on page 10 it mentions Update rate (all channels) ................. 360 Hz (2.8 ms) So it looks like you can read all 8 channels at 360Hz The best place to go with this type of query is to call your local NI rep, they would be more than happy to help you, they know their hardware inside and out and would be able to help you with your system design.

Wow, you wouldn't want to be casting a fishing line out. Or playing frisbee with your dog.

Nice find, thought there would other ways to do this. LVShellOpen.exe solution is very close to what I'd proposed.

Take a look at some of the TCP client/server examples, that should point you in the right direction. In your main which will also a TCP server have a loop that listens for a connection. When a connection is found and message received poke it into a user event which is registered to your event structure.

I had a poke around and found some info on implementing DDE into your LabVIEW application. I had a little play with it and you can create a simple DDE server and a client to pass data to each other. I dont know if this is the best way to tackle the problem but one solution might be to create one executable that is a DDE client that is registered to your file extension, as per your article. The client messages the file path to the DDE server which is your main application. If the client can't connect to the DDE server then it assumes that the server is not open so it opens it using the command line, once open it can message into it. You could also achieve the same using TCP. Again there may be a better way of doing this.

Yeah, I saw something similar when I was looking around at how to implement by ref objects using the DVR, I took a look at the xCE code from NI that Jon pointed to and saw that the way that by ref objects are achieved is by getting a ref to the object, but to achieve dynamic dispatch you have to wrap your methods in an in place structure and use DVR R/W on the object reference. It works, but it’s a lot of work to implement and what I don’t like is that you are requiring your layer above your object to manage that objects by reference capability, which as developers we intuitively don’t expect to have to do. I like my objects to manage their own by ref capability. So I thought that if the class just holds the DVR of the datamembers then I get dynamic dispatch without any fuss and I have a reference to my datamembers giving in effect a object that has by ref characteristics. Yes, I like this idea.

Yes, I like Jim's idea, especially the unbundle concept so that you only make a copy of the element. You are right, it would make a complete copy of the data, which isn't a great idea especially if you are just going to pick out one element from a cluster, but if Jim's idea were implemented it would make coding a bit simpler, and more efficient. Perhaps all bundle and unbundle on an uninterrupted DVR wire are equivalent to R/W In Place.

Sure, it's all listed here

Hi Jon Cool, I'm glad you like it. Its basically the same philosophy that I put into the Endevo design pattern, DVR really does simplify the object management that had to be done with SEQ, but in the end as I understand it DVR is a SEQ at its core. As I'm playing with it there is one thing I would really like, as with a queue you can preview the element, I'd like to see the same with DVR. At the moment all your methods have to employ a DVR Read/Write within an inplace structure. If I want a method that is just read only it will be locked until the current operating method completes, this is going to bog down a system that uses read only methods. LabVIEW performs cleanup on any references that were created within a VI that is no longer executing. So you need a way to keep your Launcher in memory until all your spawned vi's are closed. Possibly What I would do is feed each Spawned VI a queue ref that they can use to message back to the launcher when they are closed. When all spawned vi's have been closed then you can close the launcher. Perhaps a rendezvous may also work. The Endevo SEQ avoids cleanup when the caller is no longer executing is because I think you must be running in debug mode. In debug mode the object references are kept alive by a background process, as I understand it.

Hi Mate I've never played with this temp controller so I'm just working on assumptions and wrapped the driver in a script engine that will perform the series of operations that you need. Sounds like its not implementing ramp so each setpoint change drives it as fast as it can to that temp. I'll have a forage around and see what I find. Also check that when it hits temp_rampcheck that it polls an checks if the ramp is done before the script moves on.

Could you add the sample XML file to test.

Thanks everyone Will do, its been too long

Hi Take a look at the attached code it places a free label in the BD in the bottom left corner out of the way of all objects. You could easily modify it for the FP. Script.AddBDComments.vi

Whooo Hooo, it came through!! I'm really happy to be at this point, its a new direction for me but one that will be a lot of fun, and bloody hard work. Thanks to the guy's at NI Australia for your support

Just keeping this thread alive. I was wondering if anyone had any feedback on the LVOOP frameworks I was playing with, or had a different approach? I think there is a lot to explore here with DVR and LVOOP and I'd love to hear what everyone is doing. There is a lot of potential here that I think I have only just started to scratch the surface of. Also are there any pitfalls with regards to storing the DVR of the data members as object data? It seems to work well, inheritance is fine and I can access the parent members if I want. Getting and setting the datamembers inside a method using the inplace structure works well also, but I want to check I'm not walking into something silly before I start using these frameworks in a project.

One of my clients calls it "Pipework" I keep telling him, wrong trade, they are wires.

Hey Ataru I had a dig around and apparently DAQmx Create Timing Source doesn't work for USB devices due to the latency of the USB architecture. For more info check this knowlegebase article

The best place to start looking is the examples that ship with LabVIEW. Go to the help menu and select Example Finder. In the search tab search on spreadsheet. Take a look at the Read from Text File.vi and Write to Text File.vi they are good examples to show you how to read data from a tab delimited spreadsheet file and plot the results. Also take a look at some of the Graphs examples. If it's an Excel file that you need to read and not a tab delimited spreadsheet file then take a look at the NI Report Generation Toolkit. There are some free alternatives out there to read Excel files if you do a bit of searching.

Hi Pravin Could you provide more information about the problem? There could be many reasons why your software hangs or locks up. Perhaps you could post an image of your code where the problem is occurring or post some code that replicates the issue.