LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

hp8648c instrument driver

Hi,
 
I am trying to create instrument driver for hp8648c using hp8648a (found in NI website). Could you please help how I can do this?
The only difference is the operating frequency range between two signal gens.
Does this take alot of effort?
 
Thanks in advance!
0 Kudos
Message 1 of 18
(3,275 Views)
I don't think it will require too much to change. You'll have to modify the initialize function because it's looking for 8648A as part of the *IDN? query. The function that sets the RF frequency (HP8648A Configure Frequency) does not do any range checking so it should work as is. If you wanted, you could change the "A" in all of the icons to a "C" but that's just a cosmetic change. There's a VI for querying the instrument for any errors so you might want to run that periodically as you try the different functions.
0 Kudos
Message 2 of 18
(3,263 Views)
Remember to change the operating frequency limits else you could have a hanging situation.
On the appropiate front panel modify min frequency and max freq to new values ensue you coerce if necessary then save vi else you will lose the new values.
If you have a problem just post the salient vi !
chow
xseadog
0 Kudos
Message 3 of 18
(3,255 Views)
Please DON'T do this.
0 Kudos
Message 4 of 18
(3,252 Views)
Clarification Dennis ??

xseadog
Message 5 of 18
(3,249 Views)
I just don't think it's necessary and it's somewhat limiting. If the original author of the driver had made the *IDN? more generic by verifying the instrument returned HP8648 instead of HP8648A, then the driver could have been used by all models with no changes. If the author had done the same thing by setting a limited range for numeric controls, it would have further limited the driver to a single model. It would also be harder to find for an inexperienced user trying to modify the driver. It could also be confusing. Say someone uses a driver and sends a frequency out of range. With coercion, the driver will send a valid number. The user will get no feedback that an invalid frequency has been sent. All the user will know is that the instrument is set to a frequency that he or she did not request. If, on the other hand, there is no coercion, the instrument will receive an invalid number set an internal error (often an error indicator on the instrument as well) and then the instrument can be queried for the error status.
Message 6 of 18
(3,242 Views)
Hi Dennis
while I can appreciate your point of view. Smiley IndifferentI am not in full agreement with you,
let me explain.
The Original driver attempts to capture the return code which ends with 8648A
thus using a different model will in present state generate an error.
Which is what should occur. Lets remember that signal generators supply HF
energy which in HF applications can be extremely hazardous ( power amplifier driven
into saturation on open circuit !!!) Resulting in component damage and possible
 exposure to HF radiation  (higher levels than mobile phones!!)Smiley Mad
A dam good reason why the author used 8648A and not 8648.
Back to the point if the library is being modified then surely a compenent engineer would
ensure that all safeguards were implimented, if necessary improved !! YOU cannot not say
well it was some one else software code.
By modifying the library you are taking resonibility for it.
So renaming it 8648C would be most appropiate.
Dedicating the library to a specific model ensures that it could not be accidentally used
in other model applications without re engineering. Thus the onus is now on someone else.
By coercion the VI will only operate in the predefined frequency range.
Let not forget a whether it is a virtual instrument of a physical instrument one should
read the instrument guidlines before attempting to utilise it. Usually though i find that
 people refer to the manual when they have a problem.

With regard to your point about the driver sending a valid number, you are assuming that
the labview programmer is using error messaging throughout his code.

chow
xseadog
0 Kudos
Message 7 of 18
(3,226 Views)
I don't see your point. If someone attempts to program a 100MHz RF signal generator for 150 MHz, the instrument itself will prevent that. Range limiting and coericion on a numeric control doesn't add anything. If someone attempts to program a 150 MHz RF signal generator for anything up to 150 MHz, then nothing can prevent someone applying too high a frequency to some component. Granted that there may be dangerous situations or incorrect settings that the driver author should prevent but I think the proper way to do that is by generating an error.
0 Kudos
Message 8 of 18
(3,218 Views)
Dennis
my impression (correct me if i'm wrong) is that you probably don't work in a production
 environment and certainly not with microwave products.

well what can I say?
Time is money - while one wishes to create a perfect solution with error coding, etc -project constraints
mean that if the application is functional' then production utilise it!!!

  Error coding- yes would ensure that the operator would be aware of the problem.

How-ever in my experience while debugging development code, certain signal generators
when incorrect commands have been sent- the bus hangs.
The only way to re-establish contact is by turning the power supply off  and on again.
So error coding would not solve the problem, I would also question the code overhead to
 impliment this.

In a production environment
It would also cause a rerun of the test sequence!!!
So if you test application takes 15 minutes to conduct all appropiate tests and the system
  crashes due to incorrect numerical data command(overrange) then you test time could
 in worst case double.  By forcing the frequency to remain in a defined range enables the function
to operate.

Generic drivers are extremely useful but in my opinion it is still necesary to have
specific drivers unique to independent functions of the instrument.

Ok i finished my rant

chow
xseadog

0 Kudos
Message 9 of 18
(3,202 Views)

I've worked in production environments for over 25 years and have often worked with microwave.

Listen, all I'm saying is that using a numerical control ability to coerce and limit a range is not the most elegant. Incorporating some simple range checking is not all that difficult and provides all the benefits of restricting what values are passed to an instrument and providing feedback to the user at the same time. Error checking means that no incorrect commands are sent. It does not mean write the command and return an error. When you set the error Boolean true in the error cluster, no write or read is possible.

If a production program is passing incorrect values to an instrument, then there's a major problem with the production program and the test is invalid. If my program has such a bug, I want it to stop. How else are you going to fix it?

I thought we were talking about generic drivers. Imho, anything else belongs in the higher level application program.

0 Kudos
Message 10 of 18
(3,190 Views)