PXI 6713

Hi All
I have been tasked with writing a LabView application to test the functionality of all the input and outputs of a PXI 6713 module. All was going well until I tried to get an output from the 'FREQ OUT' and 'EXT STROBE' pins. User manual briefly mentions these pins as outputs but when I try to configure in DAQmx they are not selectable as physical channels. Can someone please tell me how to configure them to give an output that I can measure.
I'm using LabView 2011, MAX 5 .0 and DAQmx 9.3.5
Thanks in advance

Hi Ian,
If you consider the old usual manual, then there is a little more information on the two outputs you are referring to, that might prove useful:
FREQ_OUT Signal
This signal is available only as an output on the FREQ_OUT pin. The
frequency generator for the 6711/6713 device outputs the FREQ_OUT pin.
The frequency generator is a 4-bit counter that can divide its input clock by
the numbers 1 through 16. The input clock of the frequency generator is
software-selectable from the internal 10 MHz and 100 kHz timebases. The
output polarity is software selectable. This output is set to tri-state at
startup.
EXTSTROBE* Signal
EXTSTROBE* is an output-only signal that is used for controlling SCXI
devices.
There is also a table in this document specifying information about the inidividual inputs and outputs that could also prove useful.
Let me know how you get on, or if you require any further information.
Kind regards,
Matt H
Applications Engineer
National Instruments UK

Similar Messages

How Do I Configure the PFI Lines as input in PXI 6713 module

Hi,
I have PXI 6713 module in my PXI 1044 chassis. I have configured PXI 6713 module to geneate certain analogue signals to my board.
Board inturn process this analogue signal and responds back the status signals through a status register on the board. In my application,the status bits in status register of the board are mapped to the PFI 0:3 bits on PXI 6713 module ( pins 11,10 , 42 and 43).
My query is how do i configue the PFI lines as input in PXI 6713 module to read these status bits ??
May be below explanation could give you little bit more information w.r.to my query.
When i use NI USB - 6008 module to read the same bits , since this device has 12 digital I/O lines, i could able to read the status bits in to the last 4 digital lines by configuring the those digital lines as input.
In PXI 6713 module i have only 8 digital lines. These 8 digital lines i have used to send the digital signals to the board. I am left with no digital I/O lines. Hence i couldn't use these digital lines. I am left with only one option to use. Theya re PFI lines. Moreover the status bits in the pin out of board are mapped such that the bits can be read through the PFI lines.
I am wondering do we have any example code to use inorder to read these status bits on the board using the PFI lines.
Please let me know if you need additional information to help me out.
Thanks.
Solved!
Go to Solution.

Hello There,
When using the PFI pin as an input, you can individually configure each PFI for edge or level detection and for polarity selection. This PFI information can be referenced in the DAQ Analog Output Series Manual on page 6-1 (http://www.ni.com/pdf/manuals/370735e.pdf). Unfortunately, the PXI-6713 PFI lines are only capable of timing input and output signal for AI, AO, or counter/timer functions. The option of creating static DI from the PFI lines is not available for the PXI-6713. However, some cards have this capability. Newer National Instruments products with PFI lines have the option of setting PFI lines as:
Static Digital Input
Static Digital Output
Timing Input Signal for AI, AO, DI, DO, or counter/timer functions
Timing Output Signal from AI, AO, DI, DO, or counter/timer functions
(http://digital.ni.com/public.nsf/allkb/14F20D79C649F8CD86256FBE005C2BC4)
When set as static DIO, the PFI lines are assigned to a different port (eg. PFI0-7 is Port1). More details about this can be referenced at:
http://digital.ni.com/public.nsf/allkb/DA2D3CD0B8E8EE2A8625752F007596E1
http://digital.ni.com/public.nsf/allkb/862567530005F09E8625677800577C27
Regards,
Roman Sandoval | National Instruments | RF Systems Engineer

Generating a square waveform of 100 KHz from one of the Anolog output channels of PXI-6713 ?

Hi
I am trying to generate a square waveform from one of the anolog output channels of PXI 6713.
I am developing my application in VC++
My requirement is a continous 100 KHz square waveform with 90% duty cycle and 1.5 V amplitude.
The following is the code i have used (i have removed error handling code):
***** code *******
i16 deviceNumber = 6; // PXI 6713 Device Id as per NI-MAX
i16 deviceNumberCode; // to be returned by Init_DA_Brds function
i16 chan = 2; // DAC channel 2
i16 numChans = 1; // only one channel is used for
i16 chanVect[1] = {2}; // DAC Channel 2
f64 gain = 1.0;
i16 binArray[10] = {0};
i16 group = 1; // default for most of the devices
u32 count = 10; // 10 data points
// 9 data points ON and 1 data point OFF constituting 90% duty cycle
f64 voltArray[10] = {1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,1.5,0};
u32 iterations = 0; // Repeat waveform indefinitely
i16 mode = 0; // Disable FIFO mode / delay mode
f64 rate = 100000; // 100,000 points / sec
i16 units = 0; // points / sec
i16 timebase;
u32 updateInterval;
i16 whichclock = 0; // update clock
i16 operation = 1; // Start waveform initiation
Init_DA_Brds (deviceNumber, &deviceNumberCode);
WFM_Scale (deviceNumber, chan, count, gain, voltArray, binArray);
WFM_Group_Setup (deviceNumber, numChans, chanVect, group);
WFM_Load (deviceNumber, numChans, chanVect, binArray, count, iterations, mode);
WFM_Rate (rate, units, &timebase, &updateInterval);
WFM_ClockRate (deviceNumber, group, whichclock, timebase, updateInterval, mode);
WFM_Group_Control (deviceNumber, group, operation);
If I try to generate 10 KHz waveform with the same 90% duty cycle and 1.5 V amplitude, the waveform gets generated continously....
But for 100 KHz, itz generating continously....but only few waveforms....
Is there any hardware limitations ? I've tried changing the value of the timebase ( points / sec) and update interval etc...
plz help me
thanx in advance
sriram.

Sriram;
The best way to get started is to run one of the NI-DAQ shipping examples. You can find a good example at
C:\Program Files\National Instruments\NI-DAQ\Examples\VisualC\Ao. Take the one named WFMDoubleBuf.c.
On that example, you will just need to change the data written to the buffer to met your application's pulse train requirement.
Hope this helps.
Filipe A.
Applications Engineer
National Instruments

I can't reset my PXI-6713.

I can't reset my PXI-6713. My os is Windows 2000 , LV 6.1 , Nidaq 6.8.0 . I have another card in the pxi chassis , a 6704 wich I can reset. Im using the Reset vi located in Daq AO . I know I have the right dev number as I can set the analog outputs to any level I choose.

Reset on the PXI6713. I found out the 6713 analog outputs won't respond to the Device Reset.VI because of the way the hardware is designed. I don't get an error code except 0 (ok )on the status output. I know the reset failed because I set the outputs to a voltage and they did not go to Zero. I also have a simulator analog card PXI6704 which would respond to the Reset.
Now I just send zero volts to the outputs and that solves the problem. I think doing a low level the STC Joint_reset_register (72) I could reset the 6713
thanks for all.
P.S I tried this with the CVI Init_ , it did not work either.
John

Aquisition of a voltage Signal with PXI 6713

Hi.
I want to make voltage aquisition with a PXI 6713 card. I take the Channels ai16 to ai33. The voltage at the clamp is 3.886VDC ( measured with a DMM ). When i measure the voltage and calculate it into a current ( see my applikation atteched ) the result is something between -10 and -24mA?!?!?
Are the settinges in the DAQmx Express-VI "analog voltage aquire" wrong or could it be another Problem?
My settings are:
RSE
voltage measuring from 0 to +8VDC
N Samples
I hope of yous Answer.
Thanks
Attachments:
analog_voltage_aquisition.jpg ‏33 KB

Is it a trick question??
First of all, Looks like you mentioned the card wrong PXI 6713 is an AO card, without any AI channels
Which card are you using??
Are you connecting a 390 ohm Resistance on your connector block to convert current signal to Voltage equivalent?? ( Sounds like you are not )
Are you measuring the Voltage correctly in the first place??
if you are not, check if the signal is connected correctly for RSE mode
Hope this Helps
Regards
Dev
Message Edited by devchander on 07-28-2006 07:35 AM

Timebase synchronization issue with PXI 6713

As indicated in another post, I need to use a common timebase to all cards within my PXI chassis to synchronize my acquisition/generation DAQmx tasks.
I performed that successfully by setting timebases of all boards from the 20MHz timebase of a E-series DAQ board.
I have another system setup where I do not have E-series DAQ boards but only M-series. In this case, I tried to synchronize all the cards with the 10MhzRefClock of a PXI 6254 board. It seemed to work correctly, until I looked at the analog output signal of one PXI 6713 board.
This device has 8 analog outputs, I performed as for DAQ boards : I set its timebase to a 10Mhz clock. When I have at least two outputs with hardware timing I observe on scope really weird signal : nothing is visible when all outputs are left to zero volt, but when another voltage is set, the output toggles at very high frequency between 0V and the setting voltage. When two outputs are set to values different from zero, the output also toggles but between these two settings...
I thought it was a board failure, but I checked with another PXI 6713 and the behavior is the same.
When synchronizing with a 20MHz timebase, everything is fine, but 10MHz clearly shows this issue. I checked the 6713 documentation, and it seems possible to use a timebase different than 20MHz.
I attached a VI that illustrates the problem : I create a DAQmx task containing 2 AOs, where 10MHz timebase is taken from a M-series DAQ board. A hardware timed single point timing is configured and outputs are updated in a while loop. If you connect a scope to the first analog output, you will see the phenomenon.
Everyting is fine when you select a 20MHz clock as a timebase. 10MHz leads to this issue. I also tried to synchronize through PXI backplane clock (i.e. /6259_1/PXI_Clk10) but it leads to the same problem.
Please note that using the same 10MHz synchronization on DAQ cards (PXI 6040E, 6071E, 6254, 6259...) for AO works perfectly. I only encountered this problem with PXI 6713 board.
Message Edité par Inpriser le 08-18-2006 02:54 AM
Attachments:
Synchro 10 MHz PXI AO.vi ‏34 KB

Inpriser,
You wanted to use the PXI 10MHz clock to synchronize to 6713s using the PXI capabilities. I’m afraid that since the AO series doesn't have a PLL, you won't be able to use the PXI 10 clock.
I made a few search and found this:
“Neither the 6713 nor any of the AO series support PLL synchronization. However, the M-Series does, though in that case you are limited to a smaller number of analog outputs. Regardless, the best option is using an Arb or other card that can use the Star Trigger, or an m-series device with PLL synchronization capabilities.”
For more info’s about how to deal with PXI and PLL, please check this forum:
http://forums.ni.com/ni/board/message?board.id=170&message.id=11986&requireLogin=False
I’m sorry to disappoint you, hoping you’ll manage to deal with that,
Regards,
BRAUD Jean-Philippe
Field Sales Engineer - Nord et Centre France
LabVIEW Certified Developper

Is there an output switch at the analog front end of PXI-6723 and PXI-6713?

I was reading the analaog output user manual and i could not find this. Is there any output switch just before the analog output of each channel for PXI-6723 and PXI-6713? I am would like to have total isolation between when these output are not needed. If yes, is there any specification to refer to?
Thanks.

Hello Chris,
I would recommend having a look at the examples in the LabVIEW
example finder to start with. In particular i would look at 'Cont Gen
Wfm-Ext Clk.vi' This is a basic example that allows you to output a
waveform through the card and source an external clock source to do
this. I would recommend exporting the sample clock that you wish to use
from the 4462 on one of the RTSI lines and then setting this as the
sample clock source for the Analog output card.
Another good example to look at is the 'Cont Gen Voltage Wfm-Int Clk
non regeneration.vi' This does not regenerate the same waveform in the
buffer but instead creates a new waveform to output after the previous
one has been written to the buffer.
It should be noted that there may be some gliltching if you are
updating the waveform. This is because the buffer will already have a
waveform in there to output before you input the new one so a new
frequency may not have an exact number periods that fit into the
pre-defined buffer. If you are looking to generate dynamic waveforms
then the best option for the best results would be one of our arbitrary
waveform generators here.
Good Luck,
LeeM
NIUK

Problem initializing DIO for PXI-6713

Hello,
Several years ago I wrote a very large RT program in LV 6.1 which has run without problems for 3 years. While adding some new features, I decided to upgrade to LV 7.1 (it was too scary to take it all the way to LV 8.0).
I am using 18 bits of DIO (6 groups of 3 bits) to drive some external divider circuitry, 12 bits from a PXI-6602 and 6 bits from the PXI-6713. I am also using 6 counters from the 6602 and 6 Analog outs from the 6713. After the upgrade, it will no longer initialize the digital output of the PXI-6713, even though it worked fine in LV 6.1
Later in the program, I use each group of 3 bit DIO to determine the divisor of each circuit. After power-up, I have to go into MAX and use the 6713 DIO test panel to "jump start" the DIO outputs, and then it works from there. Luckily, we run continuously and power down only once every few months.
The problem is the same in 5 different PXI systems.
Attached is a condensed version of the DIO inits for both cards.
Thanks for any help I can get,
mcsynth
Attachments:
DIO Init example.vi ‏98 KB

Nicolas,
Thanks for your reply,
< When you say that it will not initialize the DO, do you mean that the power-up states are not what you expect? >
After the initialization, the DO is all zeros, and the periodic updates do not create anything other than zeros. I don't record any errors, but the DO updates do not respond to any commands. Basically, the 1st 6 bits should be able to output in groups of 3 bits (typically 00_110_101 or 00_101_101. The result is that the output of my divider circuit is always divide by 1, rather than 60, 40, 30, 24, 20, or 15.
Once I "jump start' in MAX, the outputs will update normally for months afterwards, until the system has to be powered up again.
< Try using the Device Reset.vi (which can be found on the Calibration and Configuration palatte) before the Port Configure.vi>
I won't be able to try anything until the next shutdown, which could be months from now, but I will be sure to try it then.
< Also, did you upgrade your NI-DAQ driver when you upgraded from
LabVIEW 6.1 to 7.1? >
Yes, it's been upgraded to NI-DAQ 7.2.0
I'm attaching an extract of the VI which updates the output, although it always works correctly once the initialization is good.
Thanks again,
McSynth
Attachments:
Divider Outputs.llb ‏116 KB

Does PXI-6713 have a 50 ohm impedance and capability to go from 0-1 volt

does PXI-6713 have a 50 ohm impedance and capability to go from 0-1 volt?
Thanks!

Hello,
According with the specification (the help file can be download on Analog Output Series Help (User Manual and Specifications))
The Voltage Output Impedance is 0.1 Ohms
The Output Range is +/- 10V or +/- AO ext ref.
Best regards,
Nick_CH
Attachments:
Voltage Output Specifications.JPG ‏13 KB

Configure DAQ cards in RT PXI system

Greetings all,
I'm just trying to learn how to use Real Time and I'm having trouble setting up the DAQ cards in the PXI chassis.
I am able to successfully connect to the PXI RT system and run simple VI's that have no DAQ or VISA access.
What I can't any info on is how to setup and access the DAQ and serial ports on the RT system. A quote from teh help file says,
"To configure remote DAQ devices, select your DAQ device from the Devices and Interfaces category under My System. Select Tools»NI-DAQ Configuration»Remote DAQ Configuration from the MAX menu to launch the Remote DAQ Configuration dialog."
I've tried this and it wants to see the RDA server running on the PXI, which of course isn't there sin
ce it's running RT.
What am I doing wrong here?
I'm running a PXI-8156B with a PXI-6071E and PXI-6713. This also has NT4 installed. Both PXI and host machine have LVRT 6.0.3, NI-DAQ 6.9.1
The host is running Win200.
Thanks
Ed
Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.

I'm using:
LabVIEW 6.1
NI-DAQ 6.9.2f4
MAX 2.2.0.3010
This may be obvious to others, but it certainly was not to me...
I wanted to configure devices on my remote PXI RT system, and I experienced the exact situation described above.
All the instructions and help I could find seemed to suggest that I should select the following menu item:
Tools >> NI-DAQ Configuration >> Remote DAQ Configuration...
But when I went there and entered the name or IP address of the Remote System, MAX couldn't find it. The PXI system was listed in the "Remote Systems" folder, and I could set up its networking parameters and software downloads from the "Remote Systems" folder.
It turns out the
key is to:
right-click on "Devices and Interfaces" in the "My System" folder
select "Create New..." to bring up a dialog<\li>
selec "RDA/Ethernet Device" then click "Finish" to bring up yet another dialog
specify the remote systems address, then click "Next"
The List of Remote Devices Appears!!! (Hallelujah!)
select a device, "Next", specify a local device number, "Finish"
Now the Remote Device is listed in the "Devices and Interfaces" folder of "My System" (strange that it's not listed under the Remote System - but who cares at this point).
repeat for each device
Now you can go back and select that original menu item (Tools >> NI-DAQ Configuration >> Remote DAQ Configuration...), specify the address, and (Behold!) there are those pesky remote devices.
(NOTE to NI... If this process is described anywhere in documents or help files relating to configuring devices on a remo
te RT PXI system I couldn't find it. Perhaps my trouble is that I've never used a PXI system or remote devices prior to trying to us LabVIEW Real-Time, but I'm probably not the only person in this situation.)

Analog out DMA performance problems

I'm working on an open-source driver for m-series and e-series boards (http://www.comedi.org). I've discoved some performance problems doing dma to analog outputs that I can't resolve. In summary, dma transfers to the analog output of a PXI-6281 in a pxi crate being controlled through a mxi-4 connection (pxi-pci8336) are VERY slow. I'm talking 250k samples/sec slow. That's the maximum speed the dma controller can fill the board's analog output fifo from host memory. I've also got an older PXI-6713 in the same crate, and dma transfers to it are about 15 times faster (about 3.5M samples/sec). I did notice that clearing the dma burst enable bit in the mite chips channel control register caused the 6713 to slow way down to something comparable to the 6281 (about 500k samples/sec). Setting or clearing the burst enable bit had no effect on the speed of the 6289. Is there some special mojo that needs to be done to enable burst transfers on the 6289? Also, even the relatively speedy 6713 does dma transfers much slower than it should, since the pxi-pci8336 advertises 80MB/sec sustained transfer rates over mxi4. Can you provide any insight into this matter? I've already looked through the ddk, and a register level document describing the mite chip, and example code which had chipobjects for the mite and an analog input example.
By the way, dma transfers for analog input on the 6281 weren't as bad, I didn't measure the transfer time, but I was at least able to do input at 500k samples/sec without fifo overruns.
I'll post more detailed performance measurements in a subsequent post, and include measurements for a couple other similar pci boards (a pci-6289 and pci-6711). In case you're wondering, neither of the pci boards get anywhere close to the bandwidth provided by the pci bus, but they're not as spectacularly bad as the pxi-6281.

Here are my measurements:
PCI-6711, tested on 1.4GHz Pentium 4:
5.2 to 5.3 milliseconds to load fifo to half-full using dma. 0.9 to 1.0 microseconds to write to a 16-bit register. 1.9 to 2.1 microseconds to read from a 16-bit register. The mite's burst enable bit has no effect.
PXI-6713, tested on 3.2GHz Pentium D:
2.2 to 2.4 milliseconds to load fifo to half-full using dma. 0.5 to 0.7 microseconds to write to a 16-bit register. 5 to 7 microseconds to read from a 16-bit register. Turning off the mite's burst enable bit causes the dma fifo load time to increase to 16 to 17 milliseconds.
PCI-6289, tested on 3GHz Pentium 4:
2.0 to 2.2 milliseconds to load fifo to half-full using dma. 0.4 to 0.6 microseconds to write to a 16-bit register. About 1.2 microseconds to read from a 16-bit register. The mite's burst enable bit has no effect. I could do streaming analog output on 1 channel with an update rate of about 2.1MHz before the board's fifo started to underrun.
PXI-6281, tested on 3.2GHz Pentium D:
18 to 19 milliseconds to load fifo to half-full using dma. 0.3 to 0.4 microseconds to write to a 16-bit register. 4 to 6 microseconds to read from a 16-bit register. The mite's burst enable bit has no effect. I could do streaming analog output on 1 channel with an update rate of about 250kHz before the board's fifo started to underrun.
Notes: the 671x boards have a 16k sample ao fifo, the 628x boards have 8k.
The 4 to 7 microseconds times to read a register on the PXI boards seems large too, is that normal overhead for going over the mxi-4 connection?
I wasn't doing anything else intensive on the pci bus during these tests. For what it's worth, according to pci specs the two pci boards should be able to dma their analog output fifos to half full in less than 150 microseconds.

NImax.exe entry point not found TDMS_GetDataValueEx in cviTDMS.dll

I have a remote PXI-8108 and I'm trying to create a task in MAX. I have no other tasks as this is my first attempt at creating one. The following sequence is performed on the remote system: left click on the PXI-6713 under "NI-DAQmx Devices" --> create task --> generate signal --> analog output --> voltage --> ao0 --> default name of "MyVoltageOutTask" --> click "Finish"
An error window titled "NIMax.exe - Entry Point Not Found" pops up with the following message: The procedure entry point TDMS_GetDataValuesEx could not be located in the dynamic link library cviTDMS.dll.
The only option is to click "OK", at which time the box continually reappears. the only way to get rid of it is to kill MAX in the windows task manager. When I restart MAX, the remote system data neighborhood has a broken task under it, and clicking on it locks the program up (needs another kill in windows task manager). The only way to get rid of it is to reset the remote system's DAQmx configuration and start over.
I have reinstalled NIDAQ 8.9.0, reset the remote system configuration in MAX, updated/reinstalled all the software on the remote system (so that it matches the host system). not sure what else to try. I figure this should be an elementary step: I've done it plenty of times with simulated devices on a host system. Not sure why the remote system is giving me problems.
Solved!
Go to Solution.

I was able to do this on an 8196 controller no problem with DAQmx 9.0 on the controller and my computer having 8.9.5. Updating to 9.0 or even 8.9.5 should update MAX and hopefully get rid of what you are seeing. You are correct that the host and controller should have the same driver version so make sure you update both of them together. It is quite strange that the error is linking to a LabWindows/CVI dll file. Are you using CVI RT on the controller?
Doug Farrell
Product Manager - Condition Monitoring
National Instruments
National Instruments Condition Monitoring

100% CPU using LabView 7.1 and DSC module

Seven years ago I used BridgeView and PXI to execute a project, and the results were so good that after that initial system, I installed one more using BridgeView, and three more using LabView 7.1.
BridgeView is working very well, but lately, LabView 7.1 is giving me more and more problems. It all started in a system running LabView 7.1 and DSC on Windows XP, using a PXI-8187 controller with a PXI-1042 chassis. I have two PXI-6533 digital I/O boards, one PXI-6030E multifunction, one PXI-6713 analog output board, one PXI-6602 counter board and one PXI-8422 serial com. board. In may/06, all of the sudden, the CPU went to a 100% use. Since I am running PID's to control a flash-butt welding machine in a steel factory, this was extremely dangerous. I changed the controller and everything went back to normal. It was running fine until december/06, when the same behavior appeared again. This time changing the controller did not help. We increased the system memory, from 256 MB to 512 MB and everything worked fine. But one month later (january/07) the fault reappeared. This time we changed the chassis and from that moment to this time, we are running smoothly.
Application problems were suspect from the very first time this problem appeared, but I was unable to identify the source, if any. I used PROFILE VI's and apparently the write/read tags were taking all the processor resources. However, changing the routines and disabling communications, and optimizing CPU intensive programs never solved the CPU overload.
Until now, I was aware of only one system showing this erratic behavior. But today I went to check another system, with a totally different application. This one is used to measure the thickness of the steel sheet on a rolling mill. Is not so resource-intensive, but the maintenance folks told me that every time they turned off this particular system, they always had problems trying to turn it on.
I was suspecting of a PLC-communication related issue, but what I found turned my alarms on. I turned off the system, which was fully functional, and turned it back on, and there it was, CPU load at 100%!. Is exactly the same problem that I have on the welder. This system has a PXI-8184, a PXI-1042 chassis, Windows XP, one PXI-6030E, one PXI-6713 and one PXI-6533. I battled for 20 minutes to put the system back in normal conditions.
I specified every single board, installed everything and programmed all the applications. The BridgeView applications have never showed anything like this. I am using the DSC (Datalogging and Supervisory Control Module) on both applications, and the Lookout Protocol Drivers are communicating to Modicon PLC's.
Please, I need help to solve this issue. I believe none of your actual Knowledge Base "100% CPU" articles apply to my case...
Thanks in advance...
Antonio Jimenez
[email protected]

Thanks for your reply...
Yes, sometimes I have the feeling that the systems works again because some file or database gets initialized after so many reboots.
Intentionally I turned off all the events and alarm logging to disk. Also the historical data logging is disabled. This is done by code, every time the main VI is started. This was included precisely to save CPU processing power. However, I am communicating to PLC's, and of course I have to declare variables inside the citadel database to make the communication possible.
Right now I can't have access to the application, because the mill is rolling, but during the next maintenance stop I will check the database location and size, and I could change the directory location the next time the fault comes up.

Glitch on dc signal

Hello,
I am using Analogue module PXI 6713 A[5] pin in PXI
chassis 1044, to generate a Glitch( amplitude 1.2V with a depth of 0.5V) on a DC signal. The glitch on the DC signal
through A[5] pin is achieved in the following way.
Method 1: (Please refer Glitch_2ms.JPG and VMON_Ramp.vi
files)
1) Start generating the DC signal from 1.2V.
2) Once it reaches the 1.2V start decreasing the voltages
in steps of 0.1V until it reaches 0.5V.
3) Once it reaches 0.5V start increasing the voltages in
steps of 0.1V until it reaches 1.2V.
Repeat steps 1 , 2 and 3 ...
This way I am able to achieve the glitch width of 2ms
with a decrease of 0.1V /interval. But I would like to achieve the glitch of
width 1us or 10us. I followed below steps to generate the minimum glitch width.
Method 2: (Please refer Glitch_180us.JPG and
VMON_Ramp_debug.vi files)
1) Start generating 1.2V DC signal.
2) Immediately generate 0.5V DC signal.
Repeat steps 1 and 2.
But the glitch width I could able to achieve is only
180us which doesn’t meet my requirement of 1us.
The Labview source code for both the
methods are attached.
Could you please give your inputs in order to achieve the
glitch width of 1us order.
Thanks.
Sincerely,
Srinath.
[email protected]
816 728 2134
281 274 2988.
Attachments:
2ms_180us.JPG ‏75 KB
VMON_Ramp.vi ‏30 KB
VMON_Ramp_debug.vi ‏26 KB

I believe I understand what you're trying to do. You cards maximum sample speed for single channel analog output is 1MS/s. This means that 1/1MS/s = 0.000001s/S is the minimum interval between samples that you can write. This is precisely 1 microsecond minimum dt. As a result, trying to write a glitch at 1microsecond means that it will be instantaneous and not ramped (there is no room to ramp because it would have to happen in the interval between 2 samples). Also, are you trying to make the clitch 2microseconds wide (1 down and 1 up)? That is reasonable as you can have 1 sample of down time at .5V and the rest up at 1.2V. Otherwise you're working on too small of a time scale (.5 microseconds down and .5 up is too small of an interval for the maximum sample speed of the card).
Also, if you're trying to do regenerative output (meaning you load a set number of samples to the card), you're going to have to make sure that the FIFO size (which is somewhere around 16k samples) is big enough to give you the appropriate interval upon which you want to re-trigger the glitch. In the case of that cards FIFO size this is a very small (16ms) interval. Is that a small enough interval for retriggering? You can also do it in non-regenerative mode which would allow you more control, however you'll need to be very careful about underflow issues. See the example in labview about continuous non-regenerative internal clock analog generation for an example of how to do this (should be in Hardware Input and Output->DAQmx->Analog Generation). If your "configurable time period" is smaller than around 16ms, you'll want to do things nonregeneratively. There may be a way to do it with some sort of complex triggering system, but I don't think the card is going to be capable of that, I think non-regenerative software methods are the only way to accomplish it on a larger time interval.
You may also (if this seems to daunting) wish to be put in touch with an alliance member who might be able to help you get the code written. It will cost a little, but if this will take a sizable chunk of your time it may be worth it.

Counter Error -10609 "transferInProgError"

I am trying to use a Quadrature Encoder VI (found on ni.com and included below) to simulate wheel speed sensors. However, when I integrate this VI into my program on a PXI-6713 card, I receive the -10609 transfer in progress error. The problem occurs when I move from Park (encoder paused) to any movement speed. I have also been able to generate the same error in the Encoder VI just by moving the knob fast. My guess is that it is trying to update the new frequencies too fast, but I don't know how to solve that. I have the settings for it at Rev/sec and set for 1 pulse/rev. In modifying the quadrature VI to my program, the loop wait time has been changed from 90 to 100 ms, but that shouldn't be a factor.
Attachments:
Quadrature_Encoder_Simulator.llb ‏483 KB

Hello,
This is strange. I tried to run the VI and could not face any problem. But of course I had an E series card available with me. If you have an E series card could you please try to see if you get the error? I will try to check out a 6713 and try to run there too.
But my guess is, there might have been some other counter operation with the same counter going on when you ran this qudrature encoder VI. Just a thought. Double checking might be helpful.
Sincerely,
Sastry V.
Applications Engineer
National Instruments

PXI 6713

Similar Messages

Maybe you are looking for