I have three PXI5673 generators in my system. Each of them actually comprises of a three instruments - PXI-5652 generator, PXIe-5450 I/Q generator, and PXIe-5611 I/Q modulator.
According to the programming model all the PXI-5673 generators have to be operated using the NI RF Signal Generators niRFSG_xxx set of functions.
However, I'm running into this strange side effect:
In order to get the error state do I have to open a session with NI Signal Generators function set (niFgen_init) and then get an error state using niFgen_GetError function?
Is this the only way to acquire error information from PXIe5450? Or there is some way to get the error using the existing RFSG session?
Solved! Go to Solution.
If you run a Measurement and Automation Explorer (MAX) test panel on your 5611, during a time where your 5450 has the Active LED red light error, you will see an error for the device and receive an error code. Since the 5611 uses the RFSG driver, this indicates that you are able to obtain error information from that session without opening an FGEN session.
What error code are you receiving from the device? The red LED indicates either overheating of the board or a board that is not phase locked. Be sure to properly ventilate the card as well as tie the clock out on your 5450 to the Reference In/Out for the 5652.
The question is this: do I have open a separate session to niFgen to get the status of 5611 separate or I can use my niRFSG sessions?
You do not have to open a separate session to niFgen to get the status of the 5450. If an error is thrown by the 5673 system, you will see it in the RFSG session.
The reason for using Test Panels in MAX to see the error is to prove that you can see the error with RFSG. The 5611 does not use the FGEN driver by itself, it does use the RFSG driver, reference here and here for the respective latest drivers for each and notice that the 5611 support is not included in the FGEN driver but is included in the RFSG driver.
Knowing that the 5611 Test Panels can show you an error or not show you an error will help narrow down if this is a corrupted driver or if you truly cannot see the error using RFSG. What version of RFSG are you using?
Try running a simple example for RFSG, such as the RFSG Single Tone Generation.vi, and see if you can run it with the Active LED error gone (connecting reference from 5611 to 5450), and then run the code with the Active LED error present (disconnect reference) and see if an error code is generated.
I meant for you to open a test panel on the 5611 while the 5450 is not functioning, since the 5611 uses RFSG, and see if an error came up in the test panel. This would prove that you are seeing or not seeing an error code in RFSG with the 5450 is not functioning.
The Red LED, according to your other discussion forum here, was from the 5450 not being able to PLL to your system. So to cause the Red LED, you would simply need to disconnect the reference clock between the 5450 and the 5611.
Can you let me know what error code you are looking for on the RFSG session? Going off of what you say on your second point, the operation performed should involve all hardware in the 5673 system and the test panel uses the RFSG driver, so by inference the errors should come up in the RFSG driver session since it will cause the operation to fail. Is niRFSG_GetError not returning an error from the 5611 in any situation?
Well, I'm looking for an explanation of the red LED on the instrument. Normally red LED indicates an error condition. I would like to know what the error is.
The niRFSG_GetError is returning an error, but not in this case. I saw the red LED on only one of the instruments in 5673 system and the usual niRFSG_GetError didn't return any error code.
The red LED you were mentioning is on the 5450 correct? Does your application stop working when the red LED comes on? Does the red LED stay on for an extended period of time? There are some times where communication is interrupted that the red LED will show up, such as when the chassis is turned on but no PC is controlling the chassis, but it should go away after communication to the card is restored. Also, in an overheat situation, the red LED will come on and that may possibly not show an error because the device no longer responds. Another scenario is the PLL clock cannot be read, due to loose or missing connections between the system and the 5450. You can get a NI-Spy capture while you run your code so that when the red LED appears you will see exactly what happens with your code.