The trigger in on the dmm6500 is 5v logic.
Your GPIO might be 3.3v, so you’d need an interface for that.
something like : https://www.sparkfun.com/products/12009
The default mode of the trigger is falling edge from 5v to zero.
Depending on what you want to do, the TSP script environment in the DMM might allow you to implement some of the automation with the dmm.
The HV triax at rear of 2470 is deliberately different so that “conventional” triax cables from max 200V products cannot connect.
The TRX-1100V-x cable is required for the HV triax on rear panel of 2470.
Maybe what is unexpected: The male triax connector on this cable is also compatible with “conventional” sized female triax barrels, feed through, etc. However, do keep in mind the 1100V rating.
There are various TRX-1100V-xxx accessories. Also our legacy 237-xxx accessories are also rated for 1100v and are compatible with the HV triax cable.
I advise you to consider the voltage rating of the probing setup and use 1100V components throughout.
Last page of Datasheet says 1200 readings per second into buffer at 0.01 nplc and with other things turned off.
This gives some idea of the overhead.
using trigger model to acquire N measurements into buffer will be most time determinant was to operate the 6514.
Can the timestamps give you some info?
Alternately, there is an analog signal on the preamp output. You can sample that for exactly 1 second with scope if looking for area under current vs time curve for amp-hr info.
The smu.source.sweeplinear() function is doing two things:
- it builds a source configuration list containing voltage levels to source; it also has source settings such as range and current limit, etc.
- it builds a trigger model to loop through the source config list and get a measurement.
To have control over the volt / sec ramp rate, need to modify the trigger model to make use of a timer to control the rate that it moves through the list.
I'll upload some demo code, but keep in mind there are many opportunities for logical error pitfalls in it.
For example, at faster desired ramp rates, need to make sure the measurements can keep up.
But at 100msec at each source level, there is plenty of time.
I cannot think of any intended firmware differences in 4.x that would account for it.
Can you capture a NI IO Trace during the attempt to use Labtracer with firmware 4.x and upload.
On the old forum, user blegeyt gave helpful answer.
The old post was for model 2400 but you have different model of product.
Suggest: use ni trace to capture the gpib bus traffic and see which exact command and error occurs.
I suggest to verify root cause more fully.
User blegeyt suggest to stop use of status byte reading and *opc, and instead *opc? and visa read with appropriate duration timeout. He attributes the issue to usb to gpib interface or driver used by PC.
Typical way is to use raw sockets from the AB to talk to the instrument over LAN.
Alternately, add a KTTI-rs232 communication module to the DAQ if the AB has COM port ability.
This seems somewhat related:
Using external equipment with AB PLC
You might also want to contact David at the email in earlier post.
Are you using any output off mode commands?
Are you using the high capacitance mode?
What is the Isc at 0V of your cell?
What is the Voc at 0A?
In KCON settings, your EOI is off. Try turning that on in KCON for the gpib communication.
Thanks for clarifying.
see if this post helps. Same DST process for SMU or DAQ: