crossrulz

...and it is still only the first 200 in the thread. So when someone does update the "Alpha Thread", "5th Dimension", etc., the I am still only seeing posts from 2007.

If you are using DAQmx 9.0, there is a Configure Logging function so the data will go straight into a TDMS file. If you want to look at the data in Excel, NI has an add-on so that Excel will read the TDMS. I did this for a system I'm using now and it works great. Here's a screen shot of my prototype.

LabVIEW gives us lots of tools that we can use where appropriate.

That is the name of the game: which tool is appropriate where? For the application you described, I would probably do something similar as you. By no means is there a single "good" way nor is there a silver bullet for every application (no matter how much we want there to be).

So to answer mstoeger's original question, yes you can save a queue reference in a FGV and it does work well. Is it really want you want to do? Well, that's for you to decide based on your application needs. My experience has been that queues work best with only one reader/consumer. Following that methodology, I would not put your Dequeue Element inside of you FGV if that is the route you want to take.

Maybe the example mstoeger gave is a bad one for this function. In the way I use these functions, my diagrams are a lot cleaner because I don't have to pass the queue reference everywhere (to several loops, into subVIs, through structures, etc.). I only have one reader of the queue. Notice that I do not use my FGV to read the queue, only get the reference. The benefit here over the FGV holding an array is that the reader will just sit there and use no CPU time. With a single reader I could have commands that come from many different sources (user interface, reactions to outside sources, etc.), often not even on the same diagram (different TestStand calls) or many subVIs down. Yes, I could obtain the queue reference by name, but that is a pain to keep track of my queue's name, obtain the queue, send a quick command, and "close" the reference (not destroy since another thread still has it open). My company had a VI that did that and I eventually said "Why not just keep the reference here?" Hence the FGV given above. I noticed a good performance boost, no hard data on it, but I could definitely tell.

I do this all the time. You can check out here and here for examples. I was unable to open your VIs (I'm using 8.6), but attached should be an idea of what you want. I use this VI to communicate between threads. One thread reacts to what the other thread sends. But I have several commands that could be sent. So this VI is used to open the queue, send commands, simply get the reference, and close the queue.

Monitor Queue.vi

Australian spirit: Sit in the back and wait for everyone to wipe out?

I know Cincinnati wasn't hit quite as hard as the east coast, but Round III is here and hitting hard. I even heard reports of yet another big snow possible this weekend.

We did something similar here using MS Access. Personally, I hate it. Only one person can be in the database at a time, it is a pain to maintain, and our SCM is constantly having to update the VBA due to new program requirements or general complaints. However, there are no licensing fees (other than your normal MS Office license) and you can tailor it to exactly what you need. As you stated, it is ok for a small organization or group. But we have had many problems with people leaving the data base open and then nobody else can access it.

I think our cat is trying to become an engineer. My wife woke up this morning to him playing with my Newton's Cradle.

I like to have VIs that wrap a queue to communicate between the threads. You can visit here for a good example. I mostly do this to avoid polling and I know I get every data point.

I did something similar to what rolfk is suggesting for a presentation I gave back in April. I would like to attach the results, but apparently I'm not allowed to upload .xls files. I used a for loop to write to and indicator using the terminal, local variable, an explicit property node, and a property node w/ a reference 1 million times.

Keep in mind that I ran this on a Windows machine that IS had a hand in, so the timing can be off a little bit.

Hello,

Does anyone know the different between "property->Value" and "Local Variable", I feel they have same funtion in Labview.

Functionally, they are the same. But the implementation is totally different. A property node will force the front panel to draw and will really slow down your program. Local Variable is faster, but not nearly as fast as a wire, shift register, or terminal.

So could you please tell me how did you create the reference "Sequence Context in" in the LabVIEW? How to link it to TestStand?

I use the "TestStand - Get Property Value.vi", right click on the sequence context and choose create control. In newer versions of TestStand it is an ActiveX control. If you are using an older version (like 3.5), it is a separate control you can find under TestStand -> Legacy.

Thanks you for your example Crossrulz.

I am a LabVIEW developer and a newbie with TestStand, so I would like to ask some question about the way we use the VI in the TestStand.

In the first sequences Monitor, the Monitor.vi is called. There is one input which is "Sequence Context in". I cannot find the value for this number and as I understand it's a reference number. I don't know how this value is initialized?

In the action "Send TERM Monitor CMD", you call the Monitor Queue.vi to send command to the Monitor.vi. One thing I don't understand is there is no queue reference or name queue is used here. How this queue can link to the queue runs inside the Monitor.vi.

Because I only know LabVIEW so I think the way LabVIEW does. Please help me understand this.

Thank you,

Thang Nguyen

I too am a LabVIEW developer. I fully understand having trouble thinking in TestStand. I am still fighting it.

The Monitor Queue.vi is a functional global variable which will hold the queue reference for outsiders to use. During the Initialize case of that vi, the queue reference is created and stored in the uninitialized shift register. The queue is then destroyed during the Close case. The Initialize and Close should only be done in the monitor vi itself.

"Sequence Context in" is a reference from TestStand. This reference is needed if we need to look at TestStand variables, abort the application, etc. See the following screen shot for finding it in TestStand.

Here you go.

test_vis.zip

When I upgrade the VI, it didn't break. Not sure why Francois would be different.

scxi-1122_voltage.zip

I must admit, old examples is the only reason I kept 7.1 on my machine.

The key word there is "annoyed": your bosses are paid to put up with you annoying them - the admins and moderators here at LAVA are not. The old adage of "the squeaky wheel gets the most grease" does not apply here - in fact, it may be the opposite.

That is a very good point. I will endure until the kind, wonderful admins of this great forum find the problem.

I, well, used to get threads from: http://lavag.org/ind...ype=forums&id=1

All ****ing Alfa String now.

Yep, my RSS was cleaned out and then *bang* 200 postings, all Alpha String. My RSS will only grab the first 200 from that post so I don't know who to shoot for actually posting to the Alfa String.

I think I'm with Ton, complain until it is fixed. That's how it goes around my work too. I don't know how many months I annoyed my boss before finally getting a response about NI Week.

Or if you are looking for a piece of software for screen shots, I highly recommend Snagit

I too have had problems with USB-to-serial adapters. If I remember correctly (I'm going back a few years), the main problem was that each time the adapter was plugged in it had a different COM port or the settings were totally different. I also had to "synchronize" the VISA drivers in MAX to what Windows had occasionally.

Yes this issue is still present because those threads are probably being moved from the 1.0 forum to the 2.0 forum and somebody replied to it. It's not getting worse, it just depends on the number of old topics that have new replies. Once the full thread is received in your reader once, you should only see the new replies from then on, not the old ones anymore. I use Google reader and this is the behavior I see.

For me, it seems to rear it's ugly head daily. If a new post comes in on day 1, I get the entire thread. If someone else posts on the same thread on the same day (after I went through and deleted), only that one post shows up. Next day, new post will cause the entire thread again. Doesn't matter if it is Lava 1.0 or Lava 2.0 threads.

:worshippy:Thanx

Have you ever used it ?

If so can you give me an example. (if not I must test this ASAP)

Thanx

I made this one to find the serial ports available in a system.

Get List of Serial Ports.vi

Is there a way of finding all GPIB/VISA/Serial instruments connected to the system programmatic ? (get the same list as VISA showing) When I have found all instruments I need I can start the test.

Offen (or always) when I move a system from development to the real test, instruments have not the same setting as I have in the R&D. So If I find a way to find the instruments programmatic this will solve many problems.

Thanx

Like the VISA Find Resource

Hi crossrulz

In your example you have a section that is named "Remote Instruction Handler"

I see that you start a new Queue, but What is this be used to ?? Is this something that you reading each step ?

Please advice

Thanx (again)

The Remote Instruction Handler is what reads and processes the data being sent to the monitor (from Test Stand or internally) via the Monitor Queue. What we do is for each test step we send the Test Paragraph, Description, Upper Limit, Lower Limit, Measurement, and Pass/Fail via the Monitor Queue to the monitor. The Remote Instruction Handler will then read from that queue and process the data however it needs to (send data to be written to file, update step information, update measurement displays, etc.). The queue is being created in the Monitor Queue.vi when the task is set to Initialize. We have a wait in Test Stand that will sit there and wait for the queue to be created before performing tests (poll the Monitor Queue to see if the ref is still a NULL). This way we know the monitor is up and running and we won't miss commands (which was a lesson learned over the years). But the Remote Instruction Handler is the main part of the Monitor VI.

Thanx for this example.

But I have a hard time understanding what is happening.

I understand that my code is put in the "run stuff" but how to get the result from Runstuff into the monitor interface I don't understand.

So if you have the change, give me a lite intro

Thanx for your time

You send data to the monitor using the Monitor Queue.vi. That VI is an action engine. Set the task to Send Message and pass in the string data. The data will then be placed in the queue that the monitor VI will read from. The monitor VI will then decipher the message however you need to. When your test is over, send the "TERM" command to shut down the monitor.