Error changing from OuputMode FUNC to ARB and reverse

[ihouses]

Hello,

I have an Fgen with two channels, I try to set a DC value and then a ARB, when I do that the driver returns an error:

Model: 'Model': '5433 (2CH)

 raise DriverError(code, description)
 nifgen.errors.DriverError: -1074126845: The operation cannot be completed in the current output mode.

I have pasted the code and more details in the follow topic in the GitHub place for NI Fgen python.

https://github.com/ni/nimi-python/issues/961#issuecomment-458876947

[balexand]

Hi,

I looked at the python script you posted on Github.  The first error I got when running the script was:

nifgen.errors.DriverError: -1074126845: The operation cannot be completed in the current output mode.

Output mode should be the same for all channels in the session.

I was able to fix the first error by setting the output_mode of both channels to standard function mode:

#set a DC value
session.channels[0].output_mode = nifgen.OutputMode.FUNC
session.channels[1].output_mode = nifgen.OutputMode.FUNC
session.channels[0].configure_standard_waveform(nifgen.Waveform.DC, 1.1, 0, 0, 0)

session.initiate()

but this led to a different error:

nifgen.errors.DriverError: -1074135039: IVI: (Hex 0xBFFA0001) Instrument error detected.  Call the PREFIX_error_query function and examine the error code and error message parameters for additional information regarding the error.

Invalid trigger mode. Only continuous triggering mode is available in standard function output mode.

So to fix this, I changed the triggering mode of channel back to continuous:

#set a DC value
session.channels[0].output_mode = nifgen.OutputMode.FUNC
session.channels[1].output_mode = nifgen.OutputMode.FUNC
session.channels[0].trigger_mode = enums.TriggerMode.CONTINUOUS
session.channels[0].configure_standard_waveform(nifgen.Waveform.DC, 1.1, 0, 0, 0)

session.initiate()

After making those two changes, the script worked on my test system.

[BerndF]

Hello,

In my case I didn't get the second error.

The problem is that this sentence:

session.channels[0].output_mode = nifgen.OutputMode.FUNC

is not really correct, the correct way would be:

session.output_mode = nifgen.OutputMode.FUNC

Doing so there is no problem.

The python library lets you choose the channel for a propertie that must be common in both channels... that's not nice.

Thanks for you help!

[kirsch]

---

The problem is that this sentence:

session.channels[0].output_mode = nifgen.OutputMode.FUNC

is not really correct, the correct way would be:

session.output_mode = nifgen.OutputMode.FUNC

Doing so there is no problem.

The python library lets you choose the channel for a propertie that must be common in both channels... that's not nice.

This is no different than the NI-FGEN LabVIEW, C, CVI, or .NET APIs. You can always specify channels when setting any attribute. NI-FGEN does not return an error until after the session configuration is finished and all attribute values can be analyzed together. Thanks!

[balexand]

that's not nice.

I agree.  On one hand, it is plausible that some device in the future would allow different modes on different channels, so having the mechanism to set these independently through the API is nice.  But I think this was actually just an oversight.  IviFgen spec documentation and NI-FGEN documentation both indicate that this attribute/property should not be channel-based.

On our C and LabVIEW APIs, we always provide a mechanism for specifying which channel to set the attribute on.

In C:

ViStatus niFgen_SetAttributeViInt32 (ViSession vi, ViConstString channelName, ViAttr attributeID, ViInt32 attributeValue);

In LabVIEW:

So it is not much different to provide the mechanism to set any attribute "per channel" through the Python API, even if the attribute is not actually channel based.

If running on a simulated 5450 device, and you try to set the output mode on a single channel, you will get this error:

Error -1074134971 (0xBFFA0045)
The channel or repeated capability name is not allowed.

You do not get that error on the 5433, but I think we should change our NI 5433 implementation so you do get that error (for consistency).