Problems performing offset null and shunt calibration in NI PXI-4220

I am using a 350 ohm strain gage for the measurements, i have already create a task in MAX, when i want to perform offset null in the task, the program shows a waiting bar and the leds in the 4220 board start to tilting, but when the waiting bar stops, MAX gets blocked. it has been impossible to me to perform the offset null, what can i try?.
which will be the correct values for the parameters beside the gage parameters for the strain measures?

Hello,
Thank you for contacting National Instruments.
Usually when this problem occurs, it is do to incorrect task configuration or incorrectly matched quarter bridge completion resistor. Ensure that you have the correct Strain Configuration chosen. The default is Full Bridge I. If you only have a single strain gauge in your configuration, you will need to change your configuration. Also ensure that if your are using a quarter bridge completion resistor make sure that it is 350Ohm not 120Ohm. If the resistor if 120Ohm you will more thank likely not be able to null your bridge.
Please see the PXI-4220 User Manual for more information about your configuration and signal connections: http://digital.ni.com/manuals.nsf/websearch/F93CCA9A0B4BA19B86256D60
0066CD03?OpenDocument&node=132100_US
Also, you can download and install the latest NI-DAQ 7.2 driver: http://digital.ni.com/softlib.nsf/websearch/50F76C287F531AA786256E7500634BE3?opendocument&node=132070_US
This 7.2 driver has a signal connections tab displayed when configuring your DAQmx Task which show you how to correctly connect your signals.
Regards,
Bill B
Applications Engineer
National Instruments

Similar Messages

Does the cRIO Scan Engine Support Offset and Shunt Calibration on the 9237 module

Thanks.

Sachsm,
The documentation for the Set Shunt Calibration (Scan Interface).vi should have been in the VI help but it looks like it didn't make it so I'll make sure it gets updated. I'll double check my understanding tomorrow morning but the documentation should be the following for the inputs of this VI:
slot - Specifies the chassis slot of the strain module (9237, 9235, 9236 ). Valid values are 1 through N, where N is the number of slots in the chassis.
channel - Specifies the channel to be affected. Valid values are 0-N where N is the channel for shunt calibration.
value - Turns Shunt calibration on or off. Valid values are 0 or 1 where a value of 1 will turn shunt calibration on for the given slot and channel.
Now, for your orginal question about offsets on the AI inputs, here are my addtional thoughts:
Unlike our SCXI products, the NI 9237 does not have an internal hardware nulling circuitry because its input range is sufficiently wide so that the inputs will not saturate even with a very large initial bridge offset. Since the 9237 does not have any hardware nulling circuitry, you have to perform offset nulling with software compenstation, and save the value to use later in the application as you mentioned. For example, when an offset null is performed in DAQmx, the entire offset is stored in the Initial Bridge Voltage property and is stored in software. You should see the same offset if you used the module from DAQmx, FPGA Interface, or in the Scan Interface. With that being said, I believe what your seeing is really just the resting measurement of the module and transducer together and you should be able to zero out your measurement by performing Software Compensation.
Regarding, Offset Calibration, I think its important to make clear exactly what it is providing as the name is a little misleading. The Offset Cal feature of the 9237 is really more like an Auto Zero used for eliminating offsets generated by an amplifier stage and doesn't provide the same behavior as offset nulling. In Auto Zero Mode, the 9237 shorts the input channel to ground and subtracts the obtained measurement from all subsequent samples. Performing an auto zero is a quick calibration technique that takes place at the beginning of a scan. A typical use of the Offset calibration feature would be to set it true at the begining of acquiring data and then leaving it on indefinitely.
Personally, I do not bother enabling offset cal in my FPGA applications because the measurement of the sensor at rest takes into account all sensor and module offsets.
And finally, if your looking for some information on how to perform shunt calibration, I like to refer to the example VI located here:
C:\Program Files\National Instruments\LabVIEW 8.6\examples\CompactRIO\Module Specific\NI 9235\NI 9235 Getting Started
As it has walks through the programming steps of setting up Shunt cal and applying the Gain Factors. Its written for LabVIEW FPGA but it should be easy to use with Scan Interface.
Hope that helps a little bit,
Let me know if you have questions and I'll help where I can or bug the right engineer.
Basset Hound

Error 200380 occurred at DAQmx perform bridge offset nulling operation

I had a working VI that could balance a wheatstone half bridge and read and record measurements. My sensors are attached to a SCXI-1314 modle in a 1520 box in channel 0 (positioned as in the manual for half bridge) with the completion resistors in the appt places in ch7. It used 'custom voltage with excitation'.
Wanted to improve this VI so that it would also do a shunt calibration. I therefore connected the shunt resistor in the board over my active sensor as in the manual. I tried then to create a virtual channel for it - but it wouldn't work. So I gave up on that idea and tried to put things back how they were - deleted the virtual channel, and removed the connections to the shunt resistor. Except now none of my previously working VIs will work. I have built a new VI, and that can find a signal but not balance the bridge. I get:
error 200380 occurred at DAQmx perform bridge offset nulling operation.
I have checked the hardware again, and it's all wired correctly - it seems like the VI can see the channel but doesn't know what to do with it. Have running the VIs with and without a custom voltage with excitation channel created but nothing works.
Help!

Hi LucyWH
Have you tried re identifying the chassis in Measurement and
automation explorer?
Have you changed the jumpers at all as when rewiring this is easily
overlooked?
I have found some links that you may find useful:
Error -200380 When
Calibrating SCXI-1520 in NI-DAQmx
http://digital.ni.com/public.nsf/allkb/6E94108C9611910186256D43007C2584?OpenDocument
Common NI-DAQmx Error
Codes and Solutions: Codes -200300 to -200999
http://digital.ni.com/public.nsf/allkb/8A0E097385A4269586256DBA0054E668?OpenDocument
Regards
Robert
National Instruments UK & Ireland

Output gain adjustment factor from DAQmx Perform Shunt Calibration (strain).vi

Hi
We are using the DAQmx Perform Shunt Calibration (strain).vi to apply a gain adjustment to the output of our strain gauges. We would like to view the Gain Adjustment applied by the DAQmx Perform Shunt Calibration (strain).vi, and we have tried to do this using a property node.
I have attached screenshots of the property node we included before the DAQmx Perform Shunt Calibration (strain).vi (which seems to work fine), and the property node we have included after the DAQmx Perform Shunt Calibration (strain).vi (which doesn't output anything).
Could someone please advise of what I am doing wrong, or if ouputting the Gain Adjustment applied by the DAQmx Perform Shunt Calibration (strain).vi is even possible?
Cheers
Bart Scicchitano
(using his supervisors NI account with her permission)
Attachments:
ShuntCal_GainAdjustFactor_Before.PNG ‏29 KB
ShuntCal_GainAdjustFactor_After.PNG ‏45 KB

Hello, thank you for your response.
Sorry I wasn't clear. We get 0 from the property node when using multiple gauges in series. We have since found that the property node works when outputting the gain adjustment factor from only a single gauge, but we still cannot get it to work for multiple gauges in series.
I have posed the question in a more clear fashion (I hope) in the Labview forum (link below)
http://forums.ni.com/t5/LabVIEW/How-to-get-gain-adjust-from-multiple-strain-gauges/m-p/2304956/highl...
Thank you again for your response
Bart

Problem accessing /config_general/null/Default.action Reason:There is no Action mapped for namespace/ config_general and action name default

in use:
vRO 5.1
eclipse 3.7.2
vRo plug-sdk 5.1
steps:
1.create a plug-in project from samples(choose solar system)
2.find the dar package and upload it by vRo configuration
3.vRo configuration said upload successfully,but the solar system configuration is not properly configued..
problem:
Problem accessing /config_general/null/Default.action Reason:There is no Action mapped for namespace/ config_general and action name default
How to solve it??
Thanks so much!!

There was problem from crm side...its working now..

Problem with ORA-25240 and msgId:=NULL

Hi,
I have a problem with ORA-25240- the documentation says that you cannot specify a message ID and correlation ID int the dequeue- options. However I am getting it setting msgid explicitely to NULL!
The code snippet is:
vr_message jms_message_with_header_type;
vr_dequeue_options DBMS_AQ.dequeue_options_t;
v_message_handle RAW(16);
BEGIN
vr_dequeue_options.deq_condition := 'tab.user_data.header.properties IS NOT NULL AND '
|| 'tab.user_data.get_string_property('MYServicename'') = '''
|| i_MY_Servicename || '''';
vr_dequeue_options.correlation := i_correlation;
vr_dequeue_options.navigation := DBMS_AQ.FIRST_MESSAGE;
-- should be default anyway:
vr_dequeue_options.msgid:=NULL;
vr_dequeue_options.wait := DBMS_AQ.NO_WAIT;
DBMS_AQ.DEQUEUE
queue_name => 'MYQUEUE',
dequeue_options => vr_dequeue_options,
message_properties => vr_message.header,
payload => vr_message.message,
msgid => v_message_handle
Any ideas?
Thank you,
Steffen

Hi,
the version is:
SQL> select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
PL/SQL Release 10.2.0.3.0 - Production
CORE 10.2.0.3.0 Production
TNS for HPUX: Version 10.2.0.3.0 - Production
NLSRTL Version 10.2.0.3.0 - Production
SQL>
The example behind the link is not complex enough. They are not using deq_condition and correlationId of the deque- options. If I set one of these values to NULL the code works fine but it complains about msgId if I have both values set with msgId=NULL?!?
Thanks,
Steffen

Updated Illustrator CC to CC 2014, having problems with CC performance. Slow and does not quit

Updated Illustrator CC to CC 2014, having problems with CC performance. Slow and does not quit. What can be causing the issue?

Hello, please checkout my post concerning lagging issues.
I've also provided a link to a video I've recorded showing the Illustrator behavior on my iMac 27"
Adobe Illustrator Cs6 Lagging Extremely Slow on Yosemite 27" iMac i7 late 2013

Gain error with shunt calibration

Hello,
I have a problem with shunt calibration of bridge based displacement transducers. The shunt calibration routine sets gain factors that give errors around 2% in the measured displacement. I have also found that the shunt calibration gain factors run out of bounds without a preceding offset null.
The hardware is a cDAQ-9188 with 9237 modules. The gauges have four wires, two input wires that I have connected to EX+ with jumper to RS+ and EX- with jumper to RS-/SC-, and two output wires that I have connected to AI+ with jumper to SC+ and AI-. LabVIEW is used with a VI shown in the attached figure.
Does anyone know why the shunt calibration behaves like that or what I do wrong?
/Emil
Attachments:
labview.png ‏19 KB

Hi Anton,
Setting the gain manually from a known displacement is not an option as some of the transducers are mounted so that they cannot be tested with gauge blocks.
Setting the DAQ Assistant Express VI or Create Channel VI to strain mode gives the same shunt factors as the general bridge mode.
I have done additional measurements to outrule any chance of coincidence with the sensing wires. With jumpers from EX+ to RS+ and from EX- to RS- on the first four of ten transducers the shunt factors are:
1.0046; 1.0246; 1.0347; 1.0246; 0.9649; 0.9811; 0.9600; 0.9720; 0.9591; 0.9793
with jumpers only on the first two transducers the shunt factors are:
1.0044; 1.0247; 0.9867; 0.9729; 0.9648; 0.9811; 0.9599; 0.9721; 0.9589; 0.9791
and finally for all transducers without jumpers the factors are:
0.9624; 0.9715; 0.9868; 0.9728; 0.9647; 0.9809; 0.9600; 0.9721; 0.9592; 0.9792
The conclusion is that the shunt factors are wrong but stable if the wiring is unchanged. Jumpers between EX and RS terminals effects the shunt factors. The shunt factors are between 0.04 and 0.06 larger with jumpers.
Should the RS terminals be connected for gauges without an extra sensing wire? Should there be a difference with and without the jumpers? Do you suggest anything special to look into regarding the EX wiring?
/Emil

Bridge Offset Nulling Doesn't Seem to Work With SCC-SG24

Does anyone know if the DAQmx "Perform Bridge Offset Nulling Calibration" vi works with the SCC-SG24 modules? We have used our NI-9237 module in the past to acquire dual-channel load cell (thrust & torque) measurements, and calling that vi does a fine job of zeroing out the values before applying the load. However, it doesn't seem to work when we try to take the same measurements using an SCC-SG24 module.
We are able to zero the values manually, by using the nulling resistors and potentiometers in the SCC-SG24. But, whether the nulling resistors are installed or not, we are not able to zero the values using the "Perform Bridge Offset Nulling Calibration" vi. Running that vi does induce a significant offset in the values, but it is not the correct offset needed to bring the values to zero. For example, with no load applied, a torque reading before running the vi may be +1090 in-lbs, and be "zeroed" to -465 in-lbs after running the vi. Running the vi multiple times (to check repeatability) always brings us back to approximately -465 in-lbs.
An additional issue (not sure if it's related or not) is that if we try to run this vi to offset just one of the channels in the task (such as just thrust, but not torque) it will still induce a small offset in the other channel, which doesn't seem right.
I guess I'm not clear on whether the subject vi is performing an operation on the hardware, the software, or both, so I'm not sure whether the SCC-SG24 modules may not be compatible with this vi?
Thanks for any help you can provide.

Hello Dhruser1,
I think that the DAQmx Perform Bridge Offset Nulling Calibration should work for the SCC-SG24 module. Take a look at this article: Removing Large Initial Offset for Load Cell or Strain Measurements with SCXI-1520 or PXI-4220 in particular it mentions that using this VI in addition to the auto zero can introduce an offset. If you're doing both these is likely the cause.
Also, when you specify specific channels using the channels input are you also setting the "skip unsupported channels to false? If not this may be why it affects other channels.
I hope this helps, and if not please feel free to post back with an update after trying these things.
Cheers,
Brooks

Problems with ListViews Drag and Drop

I'm surprised that there isn't an Active X control that can do this more
easily? Would
be curious to find out if there is - although we aren't really embracing the
use of
them within Forte because it locks you into the Microsoft arena.
---------------------- Forwarded by Peggy Lynn Adrian/AM/LLY on 02/03/98 01:33
PM ---------------------------
"Stokesbary, Michael" <[email protected]> on 02/03/98 12:19:52 PM
Please respond to "Stokesbary, Michael" <[email protected]>
To: "'[email protected]'" <[email protected]>
cc:
Subject: Problems with ListViews Drag and Drop
I am just curious as to other people's experiences with the ListView
widget when elements in it are set to be draggable. In particular, I am
currently trying to design an interface that looks a lot like Windows
Explorer where a TreeView resides on the left side of the window and a
ListView resides on the right side. Upon double clicking on the
ListView, if the current node that was clicked on was a folder, then the
TreeView expands this folder and the contents are then displayed in the
ListView, otherwise, it was a file and it is brought up in Microsoft
Word. All this works great if I don't have the elements in the ListView
widget set to be draggable. If they are set to be draggable, then I am
finding that the DoubleClick event seems to get registered twice along
with the ObjectDrop event. This is not good because if I double click
and the current node is a folder, then it will expand this folder in the
TreeView, display the contents in the ListView, grab the node that is
now displayed where that node used to be displayed and run the events
for that as well. What this means, is that if this is a file, then Word
is just launched and no big deal. Unfortunately, if this happens to be
another directory, then the previous directory is dropped into this
current directory and a recursive copy gets performed, giving me one
heck of a deep directory tree for that folder.
Has anybody else seen this, or am I the only lucky one to experience.
If need be, I do have this exported in a .pex file if anybody needs to
look at it more closely.
Thanks in advance.
Michael Stokesbary
Software Engineer
GTE Government Systems Corporation
tel: (650) 966-2975
e-mail: [email protected]

here is the required code....
private static class TreeDragGestureListener implements DragGestureListener {
     public void dragGestureRecognized(DragGestureEvent dragGestureEvent) {
     // Can only drag leafs
     JTree tree = (JTree) dragGestureEvent.getComponent();
     TreePath path = tree.getSelectionPath();
     if (path == null) {
          // Nothing selected, nothing to drag
          System.out.println("Nothing selected - beep");
          tree.getToolkit().beep();
     } else {
          DefaultMutableTreeNode selection = (DefaultMutableTreeNode) path
               .getLastPathComponent();
          if (selection.isLeaf()) {
          TransferableTreeNode node = new TransferableTreeNode(
               selection);
          dragGestureEvent.startDrag(DragSource.DefaultCopyDrop,
               node, new MyDragSourceListener());
          } else {
          System.out.println("Not a leaf - beep");
          tree.getToolkit().beep();
}

ValueHolder/Proxy indirection regarding UPDATE set null and DELETE

In our first implementation we were using ValueHolder indirection for 1-1 indirect relationships. For our entities to be portable, we changed our 1-1 relationships to use proxy indirection. Lazy loading works fine, but now when we delete an entity targeted by a NON NULLABE FK we get this error:
javax.faces.el.EvaluationException: java.lang.RuntimeException: com.taleo.akira.transaction.RollBackException: Exception [TOPLINK-4002] (OracleAS TopLink - 10g (9.0.4.1) (Build 040128)): oracle.toplink.exceptions.DatabaseException
Exception Description: java.sql.SQLException: ORA-01407: cannot update ("GISD_TSG100"."POLICYSTATEMENT"."POLICYCONTEXTNO") to NULL
I tried to always create the ProxyIndirectionHandler when we set a new value, to update the inner value of the ProxyIndirectionHandler created by TopLink, to just set the value as is without proxying, to call hashCode() on the old value to ensure that it is loaded, but nothing works. Do I miss something? Is it fixed in a later release? (Unfortunately we can't update TopLink for now) Thanks for your help, Yannick

Sorry, I made a mistake in my explanation. In our framework, we manage bidirectionnality. To be able to delete an entity, we must remove all references to it. The problem occurs when the entity to delete has a bidirectionnal relation. With ValueHolder indirection, TopLink detects that the entity will be deleted and doesn't update the to NULL. It just executes the DELETE statement. Using proxy indirection, it executes the UPDATE statement to update the FK to NULL and then DELETE the entity. When FK are not nullable, an exception is thrown. Even if we change our FK to be all nullables, it will execute the UPDATE statement which is not good performance wise. Do you think of a solution? Thanks, Yannick

[HOWTO] fix throttling/temperature problems of GTX 870m (and probably others)

Hey,
The problem:
Other than repasting and undervolting using a VBIOS mod, you can't do much to prevent the guaranteed 93°C hit on the GS70 with the GTX 870m,
which results in serious throttling after a short while of full load on the GPU to prevent hardware-damage and thus, while playing, massive FPS drops. Also the mentioned "fixes" only delay the inevitable.
That's what I thought to be correct - turns out, it isn't.
This may work for any laptop/card combination with temperature/throttling issues, not only the GS70-2PE + GTX 870m!
I've found a way to circumvent the 93°C problem on the GS70 with a GTX 870m (may apply to other laptops/cards aswell):
The NVIDIA driver (and only the driver, not any hardmodded VBIOS) is able to set some stuff about the temperature target, you can't change with a hard mod - I've talked to svet about that.
Let's have a look some screenshots I took:
Screenshot #1 - default behaviour:
On the first screenshot you see the default behaviour of a brand new GS70-2PE with a GTX 870m - not repasted. It was taken right after I took the second screenshot, so there's still some amount of data left on the charts from before.
Have a look at the "GPU Core Clock" in GPU-Z. You'll notice big spikes (which go down to about 480 MHz) on the right hand side of the graph. That's the throttling the card automatically does when it's hit its 93°C temperature for about a minute. That are lag-spikes when playing something demanding.
You also notice on the "PerfCap Reason" row - when it was throttling in the "GPU Core Clock" row no soft performance cap was induced so this was done by the card (or the EC?) internally (that's the empty space on the right hand side of the chart).
Now let's look at the second screenshot.
Screenshot #2 - fixing things:
Notice the difference on the right hand side of both screenshots' "GPU Core Clock" charts. See the spike-downs gone in the second screenshot?
You can also see, that compared to the first chart, the driver has reduced the voltage to reach the Temperature Target while the clock rate was reduced.
Here I've slightly lowered the base clock of the GPU by -40 MHz, aswell as reduced the Voltage Offset by -18.8 mV. (Both settings may not even be necessary, please report your results)
This is the important part:
Additionally I've set the Temperature Target as priorized over the Power Target, and set the Temperature Target to 90°C.
As you can see when the GPU hits 91°C, after a couple of seconds it will clock down, but controlled by the driver (you can see that in the "PerfCap Reason" chart). It's not as bad as the drop to 450 MHz, it's just a 100 MHz drop, to about 810 MHz in my case. It stays there until it reaches a temperature of about 86°C, stays there a bit, clocks up again, and so on. (The clock values you see don't reflect the 810 MHz, the screenshot was taken while the PerfCap was not in effect)
Results
What have we gained?
No massive last-resort throttling by the card itself, but a small clock drop induced by the NVIDIA driver to meet our desired temperature target. A huge all-around performance improvement when the card gets hot and less FPS drops when playing for a long time or a GPU hungry game.
What have we lost?
Some few seconds of boost clock as the card clocks down a bit earlier. Also in my case I've lost 40 MHz of base clock (that may not even be necessary).
Combine that with a decent repasting and I'd call my GS70-2PE with a GTX 870m "stable" and reasonably fast on full GPU load.
By pressing the "Create Clocks Shortcut" button in NVIDIA Inspector those settings will be set on boot.
Please tell me what you think. Any improvements and experiences welcome.
panni

Quote from: bahadir.onc on 24-September-14, 18:37:57
Hey everyone!
I downloaded nvidia inspector to apply this fix,but shocked to see in default behaviour my Voltage Offset was -68.8. Should I change that? There is a big difference with the value the fix provides and my default value..
Also,I consider repasting with IC Diamond. Should I?
Hey,
the offset shouldn't matter - inspector showed some weird behaviour when modifying and/or initially setting it. Try to apply my fix and don't do anything to the offset as a first try to be safe. It shouldn't matter nevertheless, as we're talking about a very small millivolts value, nothing big.
Regarding repasting with IC Diamond: I've had great success in "repasting" using Liquid MetalPad - you might want to consider this.

Shunt Calibration Failed

Hello! I'm pretty new to LabVIEW so I apoligize if I am confusing.
I'm trying to put together a VI that will take the strain measurements from four gauges, initially based off of the example provided through the "Strain - Continuous Input.vi". I'm using a cDAQ-9147 equiped with a NI 9237 and a NI 9944. Since our system won't be changing I wanted to set the Shunt resistor value and location as constants (100,000 ohm and R3, respectively). Unfortunately when I then try to run the VI with "Enable Shunt Cal" on I get an error::
"Error -201493 occurred at DAQmx Perform Shunt Calibration (Strain).vi:5630001
Possible reason(s):
Shunt calibration failed. The calculated gain adjust is out of range. Ensure that the shunt calibration terminals are connected properly and that the shunt resistance and shunt element location settings match how the hardware is wired.
Property: AI.Bridge.ShuntCal.ShuntCalAResistance
Corresponding Value: 100.0e3
Simulated Value with Shunt: 1.750000e-3
Measured Value with Shunt: 603.757856e-6
Property: AI.Bridge.ShuntCal.GainAdjust
Requested Value: 2.898513
Possible Values: 500.0e-3 to 1.500000
Channel Name: Axial 2
Task Name: _unnamedTask<A>"
I should note that the original example works on all gauges, so I know it's a mistake I've made somewhere. I've included the VI if that will help.
Thank you!
Attachments:
Strain_HELP.vi ‏98 KB

Hi Sunkistist,
This error can be caused by one of 3 things:
Your 9237 is so far out of calibration that the gain adjustment it would take to correct it is higher than the maximum supported by shunt calibration. Since the shipping example works, and your confident with the readings, we can assume this is not the case.
Improper physical connections. Again, we can rule this out for the same reasons as #1.
Improper configuration. Check to ensure the all the bridge resistance and strain gauge information is correct.
Here are some links you might find helpful:
Shunt Calibration with NI-DAQmx
Connecting Strain Gauges and Shunt Resistors to the NI 9237
NI 9945 or NI 9944 with an NI 9237 Connection Guide
Jeff Munn
Applications Engineer
National Instruments

Shunt calibration CDAQ

Hi:
I’m using C-DAQ NI 9237 module with Signal Express and I have the following doubts: 1) How can I perform a shunt calibration using a ¼ Wheatstone bridge? I’m using module NI 9945 and I don’t have any way to perform the shunt.2) Concerning the half and full Wheatstone bridge the shunt calibration is possible using module NI 9949. Is the precision resistor of 100kOhm internal to the module? Can I connect an external precision resistor to pins 1 and 10 of the module? 3) If the precision resistor is internal how can I activate the resistor? I suppose that is just short-cut pin 1 to pin 10. Is that right? Regards, Diogo Ribeiro.

Hi Diogo,
Thanks for posting! To answer your questions:
The
100 kOhm shunt resistor is internal on the 9237 (connected to a switch across pins 1 and
10). The 9945 accessory performs the 1/4 bridge completion and the
circuit containing the shunt resistor is wired across R3 internally.
Running the calibration in Signal Express will automatically
connect/disconnect the shunt as necessary.
To perform the shunt
calibration on the 9949, you would use jumper cables to connect the Shunt Calibration
pins (1 and 10) across the desired resistor (you can specify the resistor used in software).
Again, the driver will automatically connect and disconnect the shunt resistor during the calibration process. You can provide
your own external shunt resistor on the 9949, but you would have to
make the measurements and scale the data yourself in software. I would recommend that you let the driver handle this.
I hope this answers your questions, if you have any others please let me know.
-John
John Passiak

Error offset null

Hi. I try to take a data of torque on shaft with strain measurment (half bridge system with 2 gages on 45 degrees). Everytime when turn on offset null data starts from 0 and then jump to 80 Nm. The problem is that jump. I dont have any load to have that jump and i dont have prestressed state. I use filtering ( low pass 1hz) to get over the noises in static system. Can anyone help me with that jump problem. Thanks.
Solved!
Go to Solution.
Attachments:
Untitled.jpg ‏471 KB
Untitled2.jpg ‏262 KB

Thanks for reply. I set AC & DC Estimator VI to show me starting and established values. Then with constan I move all values to zero (any time I wаnt). After that I can start loading to the shaft normaly. What you think for that solution?
Attachments:
Untitled3.jpg ‏229 KB

Problems performing offset null and shunt calibration in NI PXI-4220

Similar Messages

Maybe you are looking for