Skip to content

ActiveX Tech Notes

Circuit fails when loaded using 64-bit Matlab

TN0973

Product: ActiveX
Version: All
Date Added: 2016-08-02

Issue

Using 64-bit Matlab to load a circuit that uses the HP_LP_Filter macros or the PZ5_Control macro will fail. The 64-bit RPcoX control is unable to load any circuit that uses a ScriptTag component. The error message in 64-bit Matlab looks like this:

"Error using COM.RPco_x/LoadCOF Error: Object returned error code: 0x2686BFC0"

In v78 and above LoadCOF will fail with no error.

Workaround

This failure occurs because these macros use a VBScript component that isn't 64-bit compatible.

The HP_LP_Filter can be replaced using cascading HP/LP Biquad filters in the circuit, which is functionally equivalent.

There is currently no workaround for the PZ5_Control macro. Contact TDT support for assistance.

Solution

Use 32-bit Matlab or replace the functionality of the ScriptTag component in your own custom code.

ConnectPA5 method always fails (returns 0)

TN0850

Product: ActiveX
Version: 68
Date Added: 2009-04-28

Issue

The ActX for PA5 installation is not compatible with version 68 of TDT Drivers. Attempting to call the ConnectPA5 method will always return a 0 (fail) even if the PA5 is correctly connected and detectable in zBUSmon.

Solution

Upgrade to v70 or above.

Writing console applications with ActiveX or OpenDeveloper controls

TN0830

Product: ActiveX, OpenDeveloper
Version: > 66
Date Added: 2008-05-13

Issue

Console-based ("formless") applications written in C++ or Python (console driven and no user interface) are not compatible with previous versions of ActiveX and OpenDeveloper controls. Methods called on an instantiated ActiveX or OpenDeveloper control fail to work.

Solution

The latest versions of ActiveX and OpenDeveloper controls provide support for formless applications. Update to the latest version of ActiveX or OpenDeveloper.

Using the GetStatus method with RX devices returns erroneous information

TN0826

Product: ActiveX
Version: All
Date Added: 2008-05-09

Issue

When using the GetStatus method with RX devices, the method returns erroneous values. RX devices return higher bit information, and this causes issues with the status values described in the ActiveX help documentation.

For example, a GetStatus value 7 corresponds to a device that is connected and has a circuit loaded and running. Using the GetStatus method on a connected RX device that has a circuit loaded, and running will not return the value 7, but will return the value 7 plus high bit information resulting in the erroneous value.

Workaround

To access relevant status information in Matlab, use bitget (or the equivalent in other programming languages) to read each bit directly. For example, the following code is compatible with RX devices:

if all(bitget(RP.GetStatus,1:3))
    disp('Circuit loaded and running');
end
If RP.GetStatus And 7 <> 7 Then
    Msgbox("Error loading circuit")
End If
Converting WAV File Sampling Rates

TN0279

Product: ActiveX
Version: All
Date Added: 2008-03-05

Issue

Before .wav files can be played using TDT System 3 devices, they must often be resampled. The sample rate of the file must match the sample rate of the device. CoolEdit or other audio editing programs can be used to resample and save .wav files. After the file is resampled, it can be played from RPvdsEx using a SourceFile component. MATLAB can also be used to resample .wav files in real- time just before they are played. The file data can then be written to an RPvdsEx buffer for playing. This is especially helpful if many files are being used.

Workaround

The example code below reads in a .wav file and returns resampled data that is ready to play out on the DAC. WriteTagV is used to load the data into the SerialBuf component of an RPvdsEx circuit. In the example circuit, the data is fed to the SerialBuf using the "data_in" parameter tag.

wav_filename = 'c:\tmp\myfile.wav'; % put path of .wav file here
new_sample_rate = 24414.0625; % put sample rate of RP here
[data, sample_rate, bps] = wavread(wav_filename);
[p, q] = rat(sample_rate / new_sample_rate, 0.0001);
new_data = resample (data, q, p);
RP.WriteTagV('data_in', 0, new_data');
RP.SoftTrg(1);

Note

This example can also be applied to other types of data (e.g. 16-bit integers).

Using LoadCOFsf to set arbitrary sampling rates yields erroneous results

TN0278

Product: ActiveX
Version: All
Date Added: 2008-02-27

Issue

The ActiveX method LoadCOFsf is used to load a Control Object File (*.rco or *.rcx) and set the sampling frequency of a device. LoadCOFsf also allows arbitrary sampling rates to be set for rates of 50 and above, however not all devices support arbitrary rates. Setting unsupported arbitrary rates for the device yields erroneous results. Specifically, the RX6 and RX8 devices equipped with sigma-delta A/D or D/A converters do not support arbitrary sampling rates, so care should be taken to specify only realizable rates.

The RV8 and RX8 devices equipped with PCM A/D or D/A converters support arbitrary sampling rates.

Workaround

When using the RX6 or RX8 devices equipped with sigma-delta A/D or D/A converters refer to the RX6 realizable rates table on the RX6 Fast Facts on the TDT website.

Repeated use of the ActiveX Connect command causes the system to crash

TN0252

Product: ActiveX
Version: All
Date Added: 2007-04-13

Issue

System crashes after repeatedly using the ActiveX Connect command (e.g., RP.ConnectRX6(IntName,DevName)).

Solution

Invoke the Connect command only once to connect to a device, and then use ClearCOF and LoadCOF commands to upload or reload the control object to implement changes to the signal.

GetStatus returns incorrect information for bit-0 on an RZ2

TN0234

Product: RZ2, ActiveX
Version: Microcode version 62 and below
Date Added: 2007-01-07

Issue

GetStatus always returns a zero for bit-0 on an RZ2 with microcode v62 and below.

Solution

Update to latest version of TDT Drivers. After installing the drivers, reprogram the RZ2 with the new microcode. Keep in mind that reprogramming the microcode on an RZ processor will take about five minutes per DSP.

Note

Unlike the Medusa base station, bit-0 of the GetStatus return value is not used to report PZ amplifier status. RZ users should refer to the LCD screen for amplifier status information.

Buffering a long signal at a high sample rate causes a memory allocation error

TN0230

Product: RX, ActiveX
Version: All
Date Added: 2006-12-04

Issue

The memory allocation for the buffer on an RX device is 14450300 samples. When the buffer required exceeds this limit a memory allocation error is reported.

Solution

Either use two buffers each holding half of the data then use ScaleAdd to sum them together, or compress the data into 16-bit integers and expand back into 32-bit floats on the hardware.

If the signal can be expressed in 16-bit format, use the ActiveX command WriteTagVEX and ExpandFrom16 as shown in the figure below. Scale the input data so the maximum values scale to ± 32767. Write the 16-bit data to the Data port of the source component. Expand from 16 to 32 bits using the ExpFrom16 component with the inverse of the scale factor used in the first step. Note: not recommended for 32-bit signals such as wav files or signals acquired on a TDT device.

This Matlab example assumes an input to the SerSource component bounded by unity:

s = 1:2000;
s = sin(s); % input bounded by unity
s = s*32760; % scale the data to best fit the range +/- 32767

2000 16-bit input data points fit into the SerSource buffer of size 1000.

RCO files created with RPvdsEx v50 or earlier might fail to load when using ActiveX v60 and greater

TN0227

Product: ActiveX
Version: > 59
Date Added: 2006-10-27

Issue

After upgrading to v60 ActiveX or greater, some older RCO files may fail to load using ActiveX commands.

Workaround

If an existing RCO fails to load to a device using ActiveX 2.0 commands, rebuild the RCO with RPvdsEx v60 or greater. Also, beginning with RPvdsEx v60, users can utilize the new combined (RCX) file format. See Tech Note #0226 for more information.

zBusSync always returns zero when using USB2, Gigabit, or Optibit interfaces

TN0206

Product: ActiveX
Version: All
Date Added: 2006-05-21

Issue

The zBusSync command has no effect and returns a zero when used with a USB 2.0 (UZ2/UB2), Gigabit (FI5/PI5) or Optibit (PO5/FO5) interface.

The zBusSync ActiveX Command is used for synchronizing caddies with USB1.1 (UZ1/UZ4) interfaces and should not be used with other types of interfaces. The Optibit and Gigabit interfaces are automatically phase locked to a single clock and the USB 2.0 interface is automatically synchronized when the Sync line is used. For more information on these interfaces see the System 3 Manual.

GetStatus returns zero or zBus error 'Failed locking device.'

TN0193

Product: FI5, ActiveX
Version: All
Date Added: 2005-08-19

Issue

Attempting to connect to a TDT device more than once using the ActiveX methods ConnectRxx (e.g. ConnectRX6, ConnectRP2 etc.) can cause a communication failure when using the gigabit interface.

Workaround

Connect to a device only once and then use ClearCOF and LoadCOF to ensure that a new .rco file is loaded.

Memory leaks occur in Matlab when calling ActiveX functions with improper capitalization

TN0191

Product: ActiveX
Version: All
Date Added: 2005-07-28

Issue

When using ActiveX controls such as ReadTagV with Matlab 6.5, calling the function with the characters readtagv (all lowercase) will cause a memory leak of 8 bytes per point returned. When using ActiveX controls such as GetTagVal with Matlab 7.0, calling the function with the characters gettagval (all lowercase) will cause a memory leak of 40 bytes per function invocation.

Workaround

To avoid these leaks, make sure to call the functions exactly as designed (with the proper capitalization, e.g. ReadTagV and GetTagVal).

HardwareReset always returns 0

TN0181

Product: ActiveX
Version: > 3.6
Date Added: 2005-03-10

Issue

HardwareReset returns 0 both when the reset is successful and when it is not.

Workaround

You can determine the status of the hardware reset by viewing the module's front panel LCD display or front panel LEDs while the method is being called. The LCD display and status LEDs on an RXn device will display the boot loader sequence and the indicator LEDs on an RPx device will light accordingly.

GetStatus always returns a 0 for the RA16BA connection status (least significant bit)

TN0162

Product: ActiveX
Version: All
Date Added: 2004-12-30

Issue

Although ActiveX seems to connect and properly load a circuit to the RA16BA (Medusa Base Station), the GetStatus method will consistently return a 0 for connection status.

Workaround

Use the second (circuit loaded) and third (circuit running) bits.

Synchronizing devices using zBusSync

TN0139

Product: ActiveX
Version: All
Date Added: 2004-09-01

Issue

There are several things to notice when synchronizing devices through the ZbusSync in ActiveX.

First, there is a crystal that drives the processor for each device. The crystals have small differences in their actual frequency, which is less than .001%. However, over several seconds this slight difference can have a large effect between racks that is in the milliseconds range. In order to remove this problem, all devices are driven by the same clock. For the gigabit interface the PI5 controls the clock. However, for the USB interface the clock is in the USB connection, which will often create more of a delay between racks.

The second issue is the start and stop time for devices. When two or more devices are running there will always be a slight delay between the start of one and the start of the other (several milliseconds).

Workaround

A ZBUSsyncA or B can be used to ensure that they are synced. This trigger can be used to reset the buffers sync clocks and then synchronize the devices. Once they are synched, the only differences between devices will be a slight jitter of no more than ½ a sample period.

Invoking the ActiveX zTrigA or zTrigB calls always returns a zero

TN0133

Product: ActiveX
Version: > 56
Date Added: 2004-08-12

Issue

Invoking the ActiveX zTrigA or zTrigB calls always returns a zero, irrespective of the actual result.

Workaround

You can monitor the actual result in one of two ways. In your RPvdsEx circuit:

  1. Link the output of the TrgIn component to a digital output on your device. This will allow you to view the trigger result on the front panel of the device.

  2. Link a parameter tag to the output of the TrgIn component. You can then read this tag using RPcoX's GetTagVal method.

After upgrading the ActiveX controls, VC++, VB, and Delphi programs that used to work no longer work correctly

TN0072

Product: ActiveX
Version: All
Date Added: 2002-11-13

Issue

After upgrading the ActiveX controls, VC++, VB, and Delphi programs that used to work no longer work correctly. Typically, the problem is seen with the connect functions, such as ConnectRP2 and ConnectZBUS. These functions will always return 0 (failure). However, other functions such as ReadTag and SetTagVal may also fail.

Workaround

This problem occurs because VC++, VB, and Delphi remember the older ActiveX version. Remove the ActiveX control instances from the project and re-create them.

ZTrig does not work while using ActiveX with USB

TN0001

Product: ActiveX
Version: All
Date Added: 2002-01-10

Issue

Logical devices may have changed when racks were turned on and off. For example, a single device might have shifted from device 1 to device 2. This will cause sending out a global zTrig to fail because zTrig uses the first rack as the Master from which all the others are set. This should only be a problem with USB and not Gigabit interfaces. Rebooting solves this problem.