Kurt Friday

Could you upload that in LV 8.5? Can't wait to try this.

No problem, try downloading it again its now in 8.5

I've been playing around with this and have something that works. Check out this post.

SciWare, that looks indredibly promising. I just have a few questions regarding that method though. With the method "InsertFile", would you send the report you want appended into the Attachment of the InsertFile node? When I used the "Attachment" parameter, the output data was jumbled. I'm not sure if I mentioned this before, but the saved documents I'm trying to append to also has images and tables (not just text).

I found some time to play with this again and came up with something that works.

Office.Word.InsertDoc.vi

This should get you going.

Hi

I am using LabVIEW 8.6 and using cRIO 9215 and 2 NI 9215 modules to read 8 analog channels. I am streaming the data from RT to windows.

In windows, I read the data from the TCP and have to plot the data into 8 separate waveform graphs. One second data on ecah graph contains 50,000 points. ( that is , we are measuring 50 Hz voltage signal per second) . I am using 8 build array function to append every seond data. The data on the 8 graphs is fine upto 5 seonds. After that , i get less data than expected. If it is 7 secs, i get 6.5 secs data on the plots. For 20 secs, i get 14 secs data. So please can i know how to efficeintly plot the data on the waveform graphs.

I have attached the trial VI.

thanks

Hi Joshua

From a quick look at your vi I would guess that the memory management required to build those 8 large arrays starts to interfere with performance causing it to lag behind the RIO application. I would also suggest that redraw of those 8 plots will take longer the more data you are throwing at it.

Try breaking it up using a queue driven state machine. One process just manages reading the TCP packets and poping them into a queue. Another process waits on that queue and builds your display buffer.

Also consider pre-allocating your display arrays this will reduce the memory management overhead.

You probably dont need to update your plots when each packet arrives, perhaps once every 250 msec or sec is sufficient.

Hope this helps

I had the same luck. I wasn't able to get multiple pages appended using Microsoft Insert Object vi. I did not quiet understand what the final post had mentioned stating "thinking of trying it with multiple 'Add Object' vi in concatenated way...".

I don't know either what Add Object in a concatenated way means or how it would be implemented.

I had a bit of a play and found a few things which should push you in the right direction. I don't think Add Object is going to be the way to go with this, I found that if you perform Insert -> Object from Word then you get the same result, just a single page. However if you do Insert -> File then you get what you want. So this then suggests the method that you need to implement. If you look inside Word Insert Object.vi then you see Method "AddOLEObject"

A path to investigate would be from the Document Ref get the Content Ref. On the Content Ref perform method "InsertFile"

I had a quick play with some partial success, but more tinker time was needed.

Just as an update: I can finally open a previously saved document into my program, but can't seem to get it to append to anything (not sure how this is done). I can't use the "append report" vi's because the prior documents are not just text (they have graphs and tables).

I don't have access to LabView currently or I would attach what I have. Any suggestions on how to append multi-page reports to eachother would be much appreciated.

I have tried using Word Insert Object VI, but it seems as though it is appended as an object and only the first page of a report is appended.

Take a look at this post.

Robert Clain and Miguel Salas Intro to Microcontroller Programming final project:

http://instruct1.cit...mos22/index.htm

The Effects of Hydrogen Sulfide table was an eye-opener and the second patent referenced reaffirms my confidence in my government...

Perhaps a new toolkit

LabPHEW

Hi all scripting fans

I don't like the build in Sorting feature of Event cases in the Event Structure, and though about creating an RCF-module for this.

But I can't read the Names/Cases from an event structure.

It's easy to do this if it's a Case Structure since you have the Property Node: CaseSel.FrameNames

But there is nothing like this what I can find (I might just be blind) for the Event structure.

Since there are methods (Invoke Nodes), to rearrange cases in the Event structure, there must be ways of reading the names/objects of every case.

Ideas?

Cheers,

Mikael

Hi Mate

I don't think its exposed. Check this post

Mmmmmm Toast!!!

Open Query XML Document for Multiple Nodes.vi (from the example finder), and delete the error line immediately after the for loop. Save what you're working on... and run the XML VI. LV apparently fishes around for a moment, then goes away.

Joe Z.

x-post to http://forums.ni.com...ssage.id=437600

I think what is happening is that by deleting the error wire you break the dataflow. So the order of operations may be Load XML String, Get All Matched Nodes, Close then run invoke node Get XML on the Node Result Array which will now be invalid because you closed the main ref. Why it's crashing LabVIEW I don't know.

I am currently having problems opening a Microsoft Word document in LabView. I currently have "lab reports" on my computer that were created from a different LV program. I want to open these Word documents in Labview and "resume" these documents by appending a new report to them.

I haven't started programming the rest of the project, as I am currently stuck on how to open a microsoft word document in Labview to alter.

Any help would be appreciated!

Take a look at

LabVIEW\vi.lib\platform\browser.llb\Open a Document on Disk.vi

This should help you.

Probably you were not missing anything. The applications were I used that never required to be build into an executable so I never came across that limit and therefore never tried to tackle that problem.

Although I did intend to leave the VITs and their subVis external to the exe for the case we ever would attempt to do the build. But not sure if that would make a difference.

Rolf Kalbermatter

Ahhh, cool. I'm a little more wiser now.

I'm just revisiting the bad old days of vits and playing with Rolf's suggestion that you can place a vit on the BD in a similar way as the reentrantly called vi is done in my posted example SpawnFP_2. I can get it to work in dev environment but not as a built exe. Here is a shot of my code.

The trick to get it to work in the dev environment was casting the spawned vit name to a path, this must request LV to open the vit and rename it as a new instance. If you just wire the vit name into the Open VI as a string it complains that "Cannot instantiate template VI because it is already in memory" So OK that makes sense.

But When I build it and run it it just complains that "Cannot instantiate template VI because it is already in memory"

I'm just playing with it for intrest sake to see if there was something I missed when I was playing with vit's back in the late Jurassic with the Popup Menu.

Hi Rolf

Some nice tips.

You can do that with.vit too although I usually have those dynamic VIs rather in a "allVIs" top level VI that I have open when developing (and add to thebuild as explicitedly added VI). To put a VI Template on a diagraminstead of its instantiated VI you need to drag the icon from an openVI Template (file->open) or or dragging it from the explorer intothe diagram, rather than using the "Menu Palette->File Browser"method.

Rolf Kalbermatter

I was trying to do something like this when I was developing the popup menu toolkit. It was built in LV 7.0 and I had to use vit's because each recursively spawned submenu needed its own unique FP. I remember experimenting by placing the vit in the BD as you mention but there was an issue that I'll have to take another look at, I'd say it's been resolved in later versions of LV. So as part of the user documentation I tell the developer that they need to include PopupMenu.MenuSelector.vit into their build.

Seems in LabVIEW 2009 VIs will not be remove due to constant folding.

E.g. this VI will be included in a 2009 build, it was not in 8.6.1

I can't think of any reason why. Perhaps it breaks some new feature of LV2009.

Well done guy's

Hi SciWare,

Thanks, my problem has beed resolved.

My VI Server setting is wrong.

The Agent is great.

Brilliant!!

Yeah, it's a handy technique.

Are you getting the error when you run the executable or the source code?

Is anyone else who downloaded the demo experiencing the same issue?

What version of LabVIEW are you using?

Try the suggestions in this link.

Hi SciWare,

Thanks, this still can not work on my PC.

There is a question, why use agent? Could you like to tell me the reason?

Can you provide more detail, is there an error message?

I included source code and a build, did either of those work?

I just knocked up a demo that shows how to implement an agent to read the palette from an exe.

Agent.PaletteDemo.zip

Hope this helps

Hi SciWare,

I try to use Open Application Reference and use "localhost" as Machine Name input. And I also check the VI Server Configuration.

But I still got the same results.

Weird, I just tried it, it should work but doesnt.

Time to try an agent.

Hi,

I try to use "Write/Read Palette" functions in my VI. And it works well.

But after I built it to EXE file. An -4406 error happened.

Error -4406 occurred at an unidentified locationPossible reason(s):LabVIEW:  A VI item in the palette data array is not supported in this version of LabVIEW.

Has anyone met this problem before? Or can anyone help me?

Thanks a lot.

I think what you need to do is open an application reference and pass it to your Read/Write Palette functions. Use machine name "localhost" also check that your VI Server Configuration is correct by going to Tools -> Options. Enable TCP/IP and machine access to 127.0.0.1

Beer induced deadlock?

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

Talk to Mikael... putting the DVR inside the class sounds an awful lot like the GOOP Toolkit implementation where they wrap a raw reference to data in a class to give it dispatching behaviors. Mikael may have some info about the deadlock potential of this situation.

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.