07-07-2015 06:57 AM
07-07-2015 08:05 AM - edited 07-07-2015 08:19 AM
Hello,
Looking into a bit deeper the Agilent driver, I really do not like what I see. Quite ugly work, whoever did it...
anyway, just an idea, but I have found that someone had similar problem in the past, the link is here:
So could you try the following modification of my VI?:
Yes, I have a strong feeling about this causes the error...who gives out such a driver??? Shame...
Configure.VI :
07-07-2015 09:24 AM
Up to this point, I had assumed the instrument drivers were something NI approved for placement on their site because the instrument was one commonly used with LabVIEW. Is this not the case? Does the supplier just throw the VI set over to NI, say "here you go", and NI hosts it? No verification?
Cheers
--------, Unofficial Forum Rules and Guidelines ,--------
'--- >The shortest distance between two nodes is a straight wire> ---'
07-07-2015 09:45 AM
Yep. If I have time, I will report this bug toward NI, so they can fix it.
Actually this is not the first time I encounter such problem. Never trust any "official" driver, even if you download from NI. As I remember back,
I had a strange bug with a Keithley 2400 sourcemeter. I used the sourcemeter in the 1 mA range, in this case the programmable step resolution is 50 nA. Ok, I made my test VI, and started a test. I just did not understand, even if I change the current control (double precision) with 50 nA, I do not get the same change at the KE2400 display 😄 OK... I have looked into the used VI, called "Configure Output.VI". You know what I have found? 😄
This!:
Coercing the given double value into single precision! 😄 Haha, so with this "official driver", you cannot use the possible best step resolution which is 50 nA in 1 mA range...
This was a few years ago, as I remember I reported the problem, but have a look, the driver still contains the same bug:
Of course after realising this mistake, it is very easy to fix it:
So be guys always careful with any given driver, there can be many hidden bugs! 🙂
07-10-2015 05:00 AM
Respected Sir Dennis_Knutson,
I understand what you've suggested and I've converted dynamic data it to an array. Now I am facing problem to write the array to the instrument. Any help will be appreciated?
The program with random number run succesfully and I'm trying to change the random number with array of numbers.
like I've said before, I plan to see the arbitrary signal which I am giving, to the output when I connect oscilloscope.
File is attached.
Thanks. 🙂
07-10-2015 05:04 AM
Hello Blokk,
I have done the modifications you've suggested and the error seems to have solved.
Thus I can see the random number generation. Thanks!
Now if you remember my actual aim, I need to send signal via Labview to output. Any suugestions ? Have a look at my program and suggest!
Thanks,.
07-10-2015 05:22 AM
07-10-2015 06:40 AM
@jeet.saha3.js wrote:
Hello Blokk,
I have done the modifications you've suggested and the error seems to have solved.
Thus I can see the random number generation. Thanks!
Now if you remember my actual aim, I need to send signal via Labview to output. Any suugestions ? Have a look at my program and suggest!
Thanks,.
First of all, you need to learn more about LabVIEW, start some tutorials, and online course if you have access.
Here I give you just an idea, it is up to you to do some more work. You want to send an arbitrary signal, ok. It is not totally arbitrary, since you have limitations in timing, lets say 100 msec is the smallest rate how you can change the voltage level output for this PSU.
In this snippet I can show you how to feed a 2D array into a for loop which will set your DC PSU. the first column contains the timing info (required delays in msec), the second column contains the required voltages. This can be done also with an ASCII file: you read the content of the text file into a 2D array, and connect it to the FOR loop.
If you want to change the voltages with a constant rate, you only need a 1D array containing the voltages, and you set a constant, for example 100 msec to the "Wait (msec)" function inside the FOR loop.
I think I helped enough, now it is up to you what you develope...
07-14-2015 06:24 AM
Can anyone tell me what is wrong with the program as I am not being able to see the voltages correctly. The power supply should make it 4times(as it is having a gain of 4) or at least show the voltages similar to input. But the output goes to 1v and then comes down and settles around 0.378V everytime I run it.
There must be some problem with the communication with GPIB i guess. But I checked, and can't find any problem.
Sir, I agree and heartily thank you for helping me throughout. I request to help me one last time.
Hope I'm not disturbing.
Thanks.
07-14-2015 07:13 AM
As I see you just do not understand how this VI works, even if I gave a description to it:
"In this snippet I can show you how to feed a 2D array into a for loop which will set your DC PSU. the first column contains the timing info (required delays in msec), the second column contains the required voltages. "
What you show in the "Screenshot (7).png" screenshot, you try to feed relative time values in seconds (0.000, 1.066, 2.257, 3.400, ...). As I wrote above, my example VI works as it takes the first column of the 2D array, and creates the delays in the FOR loop in milliseconds!
So using my VI you cannot feed relative time values as they are. You should create the differences between the values, and convert them to milliseconds (multiply by 1000). You can do this even in Excel, and type in the values in msec, if you do not want to programm more...
Beside, the array values (also in your txt file) what you show in yoour screenshot has a problem! The 6th value is 4.488, but the previous one is 4.560 !!! The arrays values must be in ascending order to make sense if they are supposed to be relative time values, not???
Other thing to consider: do not create much lower time delay as 100 msec as I wrote earlier! Between the 5th and the 6th relative time values, the difference is smaller than 100 msec! It still should be ok, until it is larger than 50 msec (the limit by the manual), but I would not go below 100 msec still...
Also you must read the manual and consider the step resolution in voltages: it is one thing you send a voltage value to the device from LabVIEW, like 1.192 Volts. But since the voltage programming accuracy is 10 mVolts, the actual used part of the required voltage value will be only 1.19 Volts, and NOT 1.192 Volts!