Products > Test Equipment
Keithley DMM7510, SMU 2450 & 2460 problems
MrFox:
On windows, the apps like TSB are using dotnet.
But the instruments seems to be running freebsd (I think?) and a Lua interpreter for scripting. Lua is a nice efficient solution.
MegaVolt:
--- Quote from: MrFox on November 19, 2018, 07:35:00 pm ---On windows, the apps like TSB are using dotnet.
--- End quote ---
It is very good. And then I was already scared :)
--- Quote ---But the instruments seems to be running freebsd (I think?) and a Lua interpreter for scripting. Lua is a nice efficient solution.
--- End quote ---
I learned so many new words with this device :)) And so far all I could get is a buffer through the web interface at a speed of 334 kB / s
Brad O:
--- Quote from: MegaVolt on November 19, 2018, 06:29:16 pm ---It's inside DotNet :palm:
That's what it gives out when trying to run a demoscript.
--- Quote ---com.keithley.internal.dotnet.ProxyIKeithleyTspInstrumentData.Java_com_keithley_internal_dotnet_ProxyIKeithleyTspInstrumentData_Write(IntPtr pEnv, IntPtr pObj1, IntPtr pStr2)
KeTSP Driver version: 4.0.6766.19771
--- End quote ---
--- End quote ---
--- Quote from: MegaVolt on November 19, 2018, 08:06:09 pm ---
--- Quote from: MrFox on November 19, 2018, 07:35:00 pm ---On windows, the apps like TSB are using dotnet.
--- End quote ---
It is very good. And then I was already scared :)
--- End quote ---
Were you using TSB? The boxes themselves have no .Net or Java. Can you share your script that causes the error?
For your buffer resizing issues, a couple comments come to mind. The DMMs don't have any defragmenting tools built into firmware, so if you continually make/resize/delete buffers, you will limit the maximum buffer size by limiting the size of contiguous blocks of memory. Also, all memory is treated the same. So buffers, TSP variables, scripts, and all other volatile memory objects use the same space. As a consequence of this, variables created in a TSP script and not cleaned up properly can also affect the buffer size.
MegaVolt:
--- Quote from: MegaVolt on November 14, 2018, 03:02:08 pm ---Discovered curious spikes for a range of 100 V and NPLC = 1 and NPLC = 0,1. Other NPLCs look pretty ordinary.
--- End quote ---
In Firmware v1.6.7c emissions on the 100V range are gone !!!
But they appeared on the ranges of 0.1V - 10V with the input connectors open and the input resistance 10MΩ.
Emissions go exactly 160 measurements. I would venture to suggest that the problem is in synchronization with the frequency 50Hz. When the measurement does not get to the right place.
See attachment:
MegaVolt:
--- Quote from: Brad O on November 20, 2018, 07:10:34 pm ---Were you using TSB? The boxes themselves have no .Net or Java. Can you share your script that causes the error?
--- End quote ---
Yes, I studied TSB. Unfortunately, I can not describe the procedure. In my opinion, I copied a piece of the script from the help file and inserted it into the Instrument Console and tried to execute it :)
I will try in the future to lay out repeated mistakes :)
--- Quote ---For your buffer resizing issues, a couple comments come to mind. The DMMs don't have any defragmenting tools built into firmware, so if you continually make/resize/delete buffers, you will limit the maximum buffer size by limiting the size of contiguous blocks of memory. Also, all memory is treated the same. So buffers, TSP variables, scripts, and all other volatile memory objects use the same space. As a consequence of this, variables created in a TSP script and not cleaned up properly can also affect the buffer size.
--- End quote ---
I manage to repeat the error with the buffer on the freshly turned on device and the touchscreen without any scripts.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version