Control the burst period on a 33511B using IVI driver Fgen

[Thor_Oden]

Hello,

I have a trouble piloting the function generator 33511B using the IvI driver. The goal it's to make it send burst of a define sinus function.

The entry parameters in the software are:

• Frequency of the sinus
• Amplitude
• Burst duration in ms
• Burst period in ms

In manual mode on the generator we would have to configure:

• Frequency of the sinus
• Amplitude
• The number of cycles
• Burst period in ms

In order to know the number of cycles a simple conversion is done.

There is no problem to setup the frequency of the sinus and its amplitude except a small error on the generator that doesn't disturb his behaviour (-221 setting conflict not able to setting the phase in this mode). Because the function used to setup the waveform is the IviFgen Configure Standard WaveForm, that’s configure by default a phase of 0.

For the burst the number of cycle is well configured, but not the Burst period. It takes the minimum period necessary to perform the full number of cycles and not the command that it's obviously higher.

The function used to setup the number of cycle is the IviFgen Configure Burst Count, the function used to configure the Burst period is IviFgen Configure Internal trigger Rate (With the conversion of the period in frequency in order to match the entry). As it is explained in the documentation In the section 17 page 179 the Burst should occurs at each trigger.

The driving of the generator is done by using NiMax and the IVI section. The generator is connected in Ethernet 

For this application I’m using:

• Labview 2015
• The driver ag3352x that is coming with version 5.0 of the IViFgen
• IviEngine 18

What i have experienced so far :

• I've run the same code for piloting a 33220A without any trouble. But in the configuration of the 33220A I have to change the driver and use the hp33120a that is coming with the version IviFgen 3.0
• I've change the code and use the function IviFgen configure Arb Frequency and this alternative works also with the 33220A but not with the 33511B.
• I've tried to drive directly with the driver ag3352X, thats worked, so i have a workaround BUT the goal is to use the IVI drivers in order to change the generator type without changing the code and only the configuration in NIMax

So maybe i'm not properly configure the burst generation in the code, i don't know...

Thanks for you reading, i hope that we can find a solution. If it's laking any element do no esitate to tell.

[Thor_Oden]

Some elements that could help me to resolve this topic are :

• Are you experiencing the similar problems with your equipements ?
• If no, how do you program/setup your soft maybe i've forget to do something.

[santo_13]

Most users of third-party instruments use SCPI programming (the majority of experienced users understand that the manufacturer-supplied LabVIEW drivers are riddled with bugs and go with custom implementation from scratch)

[Thor_Oden]

Hello Santo_13, thanks for your reply,

My goal was to use the "universality" of the IVI drivers in order to be able to switch quickly between instruments using uniquely NiMax panel and without changing the code of the software.

I'm not familiar to the SCPI programming, but it’s like coding the driver between LabVIEW and the instrument?

Actually, i have something like this:

User > LabVIEW > IVI > Manufacturer Driver > Instrument 

I have tried the User > LabVIEW > Manufacturer Driver > Instrument that works perfectly so for me the manufacturer driver is not responsible. However, i cannot let the code like this, as it will no longer be universal.

Does with some SCPI programming (that i'm not familiar with) i could do something like this: 

User > LabVIEW > SPCI > Manufacturer Driver > Instrument? 

[santo_13 · Accepted solution]

SCPI is a Text based command structure from IEEE followed by all leading instrument manufacturers. You use the VISA drivers to send Text commands to the instrument and receive text responses.

https://en.wikipedia.org/wiki/Standard_Commands_for_Programmable_Instruments

https://labviewwiki.org/wiki/VIWeek_2020/Proper_way_to_communicate_over_serial

Anyway, you're trying to leverage the HAL feature of IVI drivers. That is a good approach, if you observe errors in IVI drivers supplied by manufacturers, you need to reach out to the respective manufacturer support as it is the responsibility of the manufacturer to develop/maintain IVI drivers.

[Albert.Geven · Accepted solution]

Hi

I understand your frustration about IVI.

The idea is good but it should have been implemented in LabVIEW with source added.

At the time however those features were not available in LabVIEW but now it should be possible with objects.

On the other hand I don't believe the gain is high enough to build a new framework.

Keep in your application a good API between the instruments and the application and it will be easy to add new instruments. And because the communication language SCPI or IVI does not matter anymore you can use the available driver when it is good enough or ad one yourself.

Good wiring