LabVIEWIOControl

Similar Questions

• How to dynamically create variables of StationGlobals who are LabVIEWIOControl

  I'm looking for a way to dynamically create variables StationGlobals LabVIEWIOControl.  I know not how to create variables through "PropertyObject/SetValXXX", however I have some difficualty create variables that are custom data types.

  Thank you

  Bryon

  Bryon,

  You can use an expression as follows:

  StationGlobals.NewSubProperty("MyVariable",PropValType_NamedType,False,"LabVIEWIOControl",0)

  I hope this helps!

• LabVIEWIOControl not always spent in VI.

  Hi all

  I use a FileGlobal in TestStand to keep a table of LabVIEWIOControls of all agrees them I accede to my request of series. I pass the variable to a particular VI (Communication.vi) several times throughout my test sequence, but some of the time VISA resource name is not passed in and a _unnamedTask «»< (0)"="" appears="" in="" the="" vi for="" the="" visa="" resource="" name="" control="" on="" the="" front="" panel="" instead="" of="" the="" comport="" name (i.e.="">

  Of course VI errors if it doesn't have a VISA reference and reports

  "VISA: (Hex 0xBFFF000E) the given reference of session or the object is not valid.

  -1073807346; User-defined error code. »

  However, in debug mode, when the face before poster and is the resource reference VISA without name I can if necessary select comport on the menu drop down and the VI works.

  I am tracking the FileGlobal in the window settings step TestStand and it has the correct value, and the variable is related to the VI and passed through the connector pane. How did lose the Compote value from time to time? Looks like it works for the first few VI, (it usually fires on the second or third instance of VI, but not always), but once the value continues to have spent, he's stuck like this until I complete the sequence.

  The test sequence is not new, but this error is new and in the wake of the upgrade me to TestStand 3.5 to 4.1.

  Thanks for the tips. I put .seq and vi if necessary.

  Andrew

  However, he did not participate in this thread, Congrats to Bryan Heslop, ESF for the New Mexico to help us identify the problem.

  The fundamental problem was mismanagement of resources VISA session. Using sensors in the window spy in TestStand and LabVIEW, Bryan helped us refine the question at a particular stage in TestStand, which called a VI that would close the VISA session. We had not noticed this because TestStand held the value in a fileglobal and it was not clear that the session had ended.

  Oddly enough, this same bad management of the VISA resource was / is not a problem of TestStand 3.5 apparently more lenient. There must be a difference in sessions VISA 4.1 handles how that makes it a hard failure. I was always interested to understand the difference, if someone has a preview on this.

  Thank you

  Andrew

• integration of vi and teststand DAQmx

  So far I did well on teststand using instruments ordinary like scope, power, electric, generator functions, dmm and switches.

  So I had to use a map of daqmx for a particular test. And I found that I can't pass the reference to the task through teststand because he would be with a regular dmm, function generator tool. the trial regular that I'm used to is to:

  * init instrument (reference get)

  * use Vi to:

  Configure

  Read

  Beginning

  Stop

  * Close reference

  So what I had to end up doing for example in a test were I put the analog output value to my DUT then via a serial port, get the value that my DUT is reading.

  the ususal way will be as follows:

  -define daqmx

  -Start daqmx

  -DUT Serial read and limit test

  -Stop daq

  -Close task

  but it does not work like that.

  what I end up doing is run a vi on the bottom with the Daqmx task and have a notifier of testand my vi as the closing image

  

  TestStand notifier

  

  My daqmx statement is correct?

  It's one of the ways to do it with daqmx?

  your feedback to improve the use of daqmx on testand will help me much.

  Thank you

  Buton,

  You can pass the task handle DAQmx between different measures of LabVIEW. TestStand has what is called a LabVIEWIOControl, which is a particular type of object used to transfer these settings LabVIEW IO between steps. More information on this process can be found here: http://digital.ni.com/public.nsf/allkb/131A6A87C331B3CA862571EA0004D8C1

  Side of LabVIEW, all you need to do is create necessary/indicators controls wired to your façade with the task handle entries and exits; the KB above describes how to implement the object that manages these references on the side of TestStand.

• DAQmx tasks name variable

  Can someone explain why use a variable LabVIEWIOControl to keep the name of the task of DAQmx, Labview causes the sequence editor to become extremely slow. The vi attached does nothing more to open a chan (output on a pxi-6723) and its closure via the parameter of OPERATION enum (see teststand sequence).

  To simulate the problem, right click on the Action step and select "define the module." Once the tab "module" is open, click back and forth between Action 1 and 2 of the Action (1,2,1,2, 1.etc). You should see some delay, pulling up info from module of step up 2-1.

  My 'real' application works well, but a step of editing may take 10 seconds to get the info from the module. Note: This is the type of variable only what causes this problem that I have used cluster, string, enums, tables ect in the past without problems.

  I have attached a seq teststand advocating the vi.

  Görz

  There is a slowdown in TestStand, known while choosing a 8.6 VI, which has control of e/s on the side of the connector.

  See the following link for more details and a fix - http://digital.ni.com/public.nsf/allkb/1E3C0A420D28B60E862574C8004D9062

  Concerning

  Anand jegou

  National Instruments

• Parallel/lot Sockets using different I / O &amp; Com

  Guys,

  I'm working on a test that will use the parallel model or batch editing.

  For each DUT (testpoints), there is a table attached relays, connected to a single Bay of Amnesty International.

  I want to be able to switch to a different picture of relay for each socket.

  Example:

  0 - VCC_3.vi, SW0_0on, switch socket

  Bushing 1 - VCC_3.vi, SW1_0on / stop--> waiting for socket 0 end with VCC_3.vi, pass a different IO

  Etc. for all and the steps

  I also need of each use a different "com_port.vi".

  Looks like I need a model of Seq / by hyb?

  I couldn't find much in the way of relevant discussions on this subject, so I hope that you have some knowledge to share!

  Any suggestions would be greatly appreciated.

  -Derrick

  A couple of things about your question:

  You should be fine with just the parallel model or batch.  Personally, if you do not need to switch dynamically on DUT then I would go with the model of batch processing.  Why?  Because you can use synchronized sections.  Synchronized sections give you the ability to run a particular section of your movie file (i.e. several or a single step) in parallel, in the order or an outlet only.  With the parallel model you can kind of get there using locks and queues.  Search the Handbook of TestStand under annexes A and B for more information on the model of batch and synchronized sections.  To access the TestStand Reference Manual go to start > all programs > National Instruments >> Documentation > manuals.

  Regarding your screws and how they would handle each socket.  I don't think it's a good idea to do a different VI for each socket.  Just have some sort of case within the VI if 3 provided throughout the wires just to fill your switching or COM functions  For example: lets say 1 Socket runs and get to the step to call the com_port.vi.  One of the parameters for VI could be the number of the socket.  Inside of the VI you set the com port to read or write based on this setting.  You can set the parameter in TestStand using RunState.TestSockets.MyIndex (which will return taking you on that).

  In fact, you must even logic in your com_port.vi.  I guess one of the parameters in this VI would be a VISA session for your COM ports.  In TestStand, you use the LabVIEWIOControl data type which has the DeviceName property.  If you set this parameter to be '' COM' + Str (RunState.TestSockets.MyIndex)' then you will get the same thing from COM3 if you were in TestSocket 3.

  In any case, it's just a few ideas for you.  Of course, it must implement what makes sense.

  Hope this helps,

• What is the best way to open close, then send instrument labview teststand model handles parallel?

  I have a number of test systems that use a parallel model with labview. We have a number of instruments (PXI).

  What is the preferred method to open, close and passing instrument handles with labview teststand?

  Hello

  A few ways

  1 package return the session as a U32 handle, there are a few VI TestStand i of the palette of TestStand that you can use to make conversation.

  2 through a LabVIEWIOControl. TestStand handles these.

  3 do something fance as the use of LVGOOP and leave the handle as an object property and leave in memory. for example, do not pass it back at all.

  One thing, you'll have to monitor multiple executions trying to talk to the same instrument, use some lock/unlock or synchronization to avoid thi.

  Concerning

  Ray Farmer