LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

advanced scan vi agilent used for continous measurement

hii..

 

till now i have been using example to acquire data from single channel without includings units, or channel number in the scan list... now i  want to take readings from two channels....how will the readings be arranged in the string in 'read' vi???

i am attachin my vi which i used to read for single channel, 321. I converted string into number and built an array from it. Because it is single channel i din face any problem while reading. Now i have to read 2 channels...i dont understand how the readings wil be arranged.... i need to use 2d array now to read from two channels??

 

can anyone help me?

0 Kudos
Message 81 of 89
(1,078 Views)

yes you may have to use a 2D array ..choose two channels and run the vi ans see how it comes out ..in rows/cloumns...

accordingly you can index later to acess different elements...

 

By the way ...you have removed the original string separation code which was there in the original example..it will not make any problems unless you extract only the data/reading from read vi. 

0 Kudos
Message 82 of 89
(1,066 Views)

hi all.... i am facing problem .... the read vi is not waiting for the scan to finish.... i used trigger vi outside a for loop and i want the readings to be taken for a number of times which is equal to the trigger count.... i even placed a time delay between the standard event vi and the read vi....the standard event register vi has been set for operation complete bit. Yet the read vi is not waiting.

 

so can anyone let me knw if the delay helps in waiting the read vi to finish the scan??

will the read vi give out the readings for each scan or will it just display random values??

 

im posting the vi here... i kept the scan count to be 15 and scan-scan interval as 1sec. ( so it implies that im using a timer source for triggering) I used a time delay of 0.9secs in between standard event register vi and the read vi. 

 

i used a for loop insted of a while loop coz i need the number of readings = scan count. i placed the trigger vi outside the for loop.

 

can anyone have a look over this vi and help me out?

 

0 Kudos
Message 83 of 89
(1,046 Views)

 I dont understand your problem completely...you say read does not wait for the trigger vi to complete..so you have put a delay..but so long before this how was the whole thing working?

 

secondly i had some similar problems before but after running the pgm without reset it started working fine...

 

thirdly your read vi neads to wait for the trigger vi only at the first instance after that inside the for loop its only read read read....so where is the question of read vi requiring to wait for trigger vi.

 

and at last may be the scan scan interval timing and your delay timer dont match well...

 

and when your pgm runs fine pls do report on what was the maximum speed at which you were able to measure the readings.

0 Kudos
Message 84 of 89
(1,031 Views)

 

I recall having a simmilar problem when takign large amounts of readings through the serial interface.

 

Specially if using 6 digit resoultion or integration.

 

Insted of a delay try increasing the VISA timeout.

 

Message Edited by RTSLVU on 09-03-2009 07:13 AM
Message Edited by RTSLVU on 09-03-2009 07:15 AM
========================
=== Engineer Ambiguously ===
========================
Message 85 of 89
(1,020 Views)

RTSLVU wrote:

 

I recall having a simmilar problem when takign large amounts of readings through the serial interface.

 

Specially if using 6 digit resoultion or integration.

 

Insted of a delay try increasing the VISA timeout.

 

Message Edited by RTSLVU on 09-03-2009 07:13 AM
Message Edited by RTSLVU on 09-03-2009 07:15 AM

The part of this VI snippet that makes it work is the OPC bit set sub-VI.  This causes the VI to wait until the OPC bit is set before moving on.  In other words, it waits until the equipment is signals that it is done doing whatever you told it to do (initiate a sweep or whatever) before sending another command (read the result or whatever).  Using this method, we've initated sweeps on some instruments that took 1 MINUTE to complete.  The combination of reading the OPC bit plus increasing the VISA timeout to > 1 minute worked beautifully.

 

A more generic version of the OPC command is this VI.  The command for the function you wish to initiate (i.e. a sweep, an aquisition, etc.) is input to the "command" input.  A "*OPC?" query is appended to it.  (This works a bit differently than the example above.  Here, instead of waiting for the OPC bit to be set in the register, it simply waits for the equipment to output anything (usually a "1") in the output buffer before continuing.  I believe that anything that will respond to the OPC bit set will also correctly respond to the *OPC? query.

 

Bill

screen1.jpg

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 86 of 89
(1,006 Views)

billko wrote:

The part of this VI snippet that makes it work is the OPC bit set sub-VI.  This causes the VI to wait until the OPC bit is set before moving on.  In other words, it waits until the equipment is signals that it is done doing whatever you told it to do (initiate a sweep or whatever) before sending another command (read the result or whatever).  Using this method, we've initated sweeps on some instruments that took 1 MINUTE to complete.  The combination of reading the OPC bit plus increasing the VISA timeout to > 1 minute worked beautifully.

 

A more generic version of the OPC command is this VI.  The command for the function you wish to initiate (i.e. a sweep, an aquisition, etc.) is input to the "command" input.  A "*OPC?" query is appended to it.  (This works a bit differently than the example above.  Here, instead of waiting for the OPC bit to be set in the register, it simply waits for the equipment to output anything (usually a "1") in the output buffer before continuing.  I believe that anything that will respond to the OPC bit set will also correctly respond to the *OPC? query.

 

Bill

 


Your OPC vi is doing exactly the same thing as using the Agilent Standard Event Status vi and checking the Operation Complete Bit (OPC?)

Message Edited by RTSLVU on 09-03-2009 08:58 AM
========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 87 of 89
(1,002 Views)

RTSLVU wrote:

billko wrote:

The part of this VI snippet that makes it work is the OPC bit set sub-VI.  This causes the VI to wait until the OPC bit is set before moving on.  In other words, it waits until the equipment is signals that it is done doing whatever you told it to do (initiate a sweep or whatever) before sending another command (read the result or whatever).  Using this method, we've initated sweeps on some instruments that took 1 MINUTE to complete.  The combination of reading the OPC bit plus increasing the VISA timeout to > 1 minute worked beautifully.

 

A more generic version of the OPC command is this VI.  The command for the function you wish to initiate (i.e. a sweep, an aquisition, etc.) is input to the "command" input.  A "*OPC?" query is appended to it.  (This works a bit differently than the example above.  Here, instead of waiting for the OPC bit to be set in the register, it simply waits for the equipment to output anything (usually a "1") in the output buffer before continuing.  I believe that anything that will respond to the OPC bit set will also correctly respond to the *OPC? query.

 

Bill

 


Your OPC vi is doing exactly the same thing as using the Agilent Standard Event Status vi and checking the Operation Complete Bit (OPC?)

Message Edited by RTSLVU on 09-03-2009 08:58 AM

You bet it is!  🙂  My implementation is more generic and can be applied to any instrument and doesn't need the Agilent driver suite.  Yours was the actual answer; mine was an embellishment.  (Which is why I gave you kudos!)  😉

 

Bill

Message Edited by billko on 09-03-2009 11:06 AM
Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 88 of 89
(997 Views)

@siva0182 wrote:

I have been using ez temp vi to measure continous temperature mesurments using agilent 34901A.However the speeds are are not fast.

I am trying to read atleast 60 channel readings/sec.BUt as of now I am able to do only 2-3 readings per sec.

 

 

LAter I learnt form some discussiond here that use of advanced scan vi might help.

 

 

So I tried using advanced scan vi .But it worked in debug mode but not in the actual run mode.

Then I learnt from this forum below. that there needs to be a delay timer before configure and trigger vis.

 

 http://forums.ni.com/ni/board/message?board.id=170&message.id=249889&query.id=726386#M249889

 

After doing so  it works.

 

But I want fast measurment rates and a continous measurment. can these delays not be avoided.?

So with out having a while loop if continous measurment is required how is it done?

 

 



Hi siva0182. I am trying to modify the advanced scan vi to measure temperature and current (pressure transducer) continiuosly. up to now, I have no success on it. I read the all pages but could not find a proper post and also example vi. could you find a proper answer or example vi about this subject. if you do, could you inform me about it?

Egemen
0 Kudos
Message 89 of 89
(643 Views)