-
Math page: the unit of a formula row is ignored
A row on the Math page keeps showing the unit it had earlier, whatever the Unit field says now.
What I did:
A formula row named Difference, originallyCode: [Select]YK_AO23020VC.OutputVoltageSetCH1-YOKO7552.Volt_DC
with Unit V. I changed the formula and the unit toCode: [Select](YK_AO23020VC.OutputCurrentSetCH2-YOKO7552_RS.Amp_DC)*1000000
with Unit uA.
On the Current values page the row still shows V:Code: [Select]YOKO7552 RS.Amp DC A 17.4u
Math.Difference V -17.4000
The value itself is right, it is only the unit that is wrong.
What I tried:
Stopping the log, clearing the table and starting again - still V. Renaming the row so a new column is created - the name changes, the unit stays V.
What does work is deleting the row and creating a new one with the unit set from the start. So the unit appears to be fixed when the row is created and changing the Unit field afterwards has no effect, on the row itself or on a renamed copy of it.
-
Math page: the unit of a formula row is ignored
A row on the Math page keeps showing the unit it had earlier, whatever the Unit field says now.
It is sort of related to the numeric format from earlier, when TC create a table header, it creates a format that includes the unit. There is no check if the unit changes. Other readouts will copy/link the information from the table header.
Basically TC has two places where it keeps format and unit information: device definition and table header. Math is missing, it gets a default format and the unit from the math definition. I may fix that sometime in the future. -
I have four analog output modules on the bench and no real idea how they compare, so I am measuring them one at a time against the same meter.
Setup: Yokogawa 7552 on RS232 as the meter for every run, 20 mA range with autorange off, 45 minutes of warm up first. Only the module under test and the meter are loaded in TC, everything else stays wired but unloaded so the bus is quiet. The Param Sweeper drives the module's setpoint from 0 to 20 mA in 101 steps at 3 seconds a step. The chart is X-Y with the setpoint on X rather than time, so runs taken hours apart can be laid over each other.
Two Math rows do the work: the difference in µA and the error in percent of reading. The sweeper saves the log and the chart itself at the end of the run, so nothing depends on me remembering to press anything.
The whole setup is scripted — chart, scales, colors, and the sweeper parameters through #SetParamSweeper — so every module starts from the same state. The generate script menu wrote most of those lines for me, which is how I found out the quoted arguments need double quotes.
Two runs so far.
Elecdemo YK-AO23020VC: mean error 5.7 µA, worst −29 µA at the top, and it does not quite reach zero, sitting at +17 µA. Best straight line through it is +0.1% gain, but the residual after removing that is still +22/−8 µA, so there is real curvature.
Ebyte ME31-XAXA0404: +1.66% gain, −345 µA at the top, so much less accurate as it ships. But the residual after removing gain and offset is +2.6/−2.1 µA, about five times better than the YK.
Which is the interesting part: the cheaper-looking module is the better converter, it just is not trimmed. Its whole error is one number and one number is correctable. The YK is trimmed but curved, and curvature is not something a gain register or a two point calibration can fix.
Still to do: the two Eletechsup modules, then the YK again at the end as the session's own drift check.
To be clear about what this is: a comparison between modules, not a calibration. My Yokogawas are officially out of calibration, but the same meter measures every run, so its error is common to all of them and cancels out of the differences.
Elecdemo YK-AO23020VC, CH2, 13-09-2026
zero floor +17.3 uA - it does not reach 0
mean error -5.71 uA
mean |error| 6.65 uA
worst error -29.3 uA at 19.8 mA
best fit gain +0.105 %, offset -4.6 uA
residual +22.00 / -8.11 uA, rms 6.01
residual % FS 0.110 %
Ebyte ME31-XAXA0404, CH1, 13-09-2026
zero floor +18.1 uA - it does not reach 0 either
mean error -181.60 uA
mean |error| 181.60 uA
worst error -345.3 uA at 19.6 mA
best fit gain +1.663 %, offset +20.0 uA
residual +2.65 / -2.09 uA, rms 1.13
residual % FS 0.013 %
Read it this way: the first four lines say the XAXA is far less accurate as shipped, the last three say it is a far better converter. Residual is what is left after the best straight line is removed, so it is the part no gain or offset correction can reach - 6.01 rms against 1.13, roughly five to one.
So the XAXA is about five times more linear than the YK. Its whole error is one number and one number is correctable - its own Output Scaling would do it. The YK is trimmed but curved, and curvature cannot be corrected by a gain register]
-
Eletechsup N4DBA06, CH3, 13-09-2026
floor 500 uA setpoint, meter reads 518.6 - it clamps below 0.5 mA and reports the clamped value back, so those rows share an X
mean error -41.77 uA
mean |error| 41.94 uA
worst error -90.4 uA at 16.6 mA
best fit gain +0.364 %, offset +5.2 uA
residual +34.57 / -26.49 uA, rms 12.37
residual % FS 0.173 %
step to step residual moves 15.3 uA between neighbouring points
Which splits the three cleanly:Code: [Select]XAXA rms 1.13 a slope - correctable with one number
YK rms 6.01 curvature - deterministic, not correctable by gain or offset
N4DBA06 rms 12.37 noise - not correctable by anything, and it will not repeat
Three modules, three signatures: tilt, curvature, noise. None of it visible from a datasheet.
-
#SetParamSweeper: the documented example uses single quotes, which do not work
The script commands page gives the M line asCode: [Select]M 'type' prepareTime pauseTime {sync}
Following that literally:Code: [Select]#SetParamSweeper M 'Primary only' 5 5 sync
leaves a stray character in the Prepare field and does not set the sweep type. Passing 0 as the type does not work either.
What does work is double quotes:Code: [Select]#SetParamSweeper M "Primary only" 5 5 sync
I found it by setting the sweeper up in the UI and using the generate script menu, which writes the lines with double quotes. That menu entry is very useful, by the way — it also showed me #ShowPopupSystem, which I would not have known to add.
Might be worth changing the quotes in the documentation example. -
#SetParamSweeper: the documented example uses single quotes, which do not work
Might be worth changing the quotes in the documentation example.
I could find where it uses sigle quotes, but I found two places with double quotes.
And the help window do also show double quotes. -
Will it work on Advanced Readout for a Math channel?
Not directly, but there is a way around that; Any value in the table has a format that works everywhere!
I.e, after you have logged it will work.
I added this in my script:Code: [Select]#ValueFormat Math.K34465A_STD_Run30 SI
#ValueFormat Math.K2010_STD_Run30 SI
#ValueFormat Math.SDM4065A_STD_Run30 SI
It worked immediately without needing to log first. I'm happy with that.
Thanks,
Josh
-
Final module also done:
Eletechsup N4IOA01, 13-09-2026
floor 500 uA setpoint, meter reads 555.1
mean error -1.59 uA
mean |error| 22.69 uA
worst error -61.0 uA at 1.0 mA
best fit gain -0.419 %, offset +44.3 uA
residual +25.77 / -21.44 uA, rms 10.75
residual % FS 0.129 %
step to step 8.1 uA
The only one of the four that reads LOW. Because its offset pushes the other way the error crosses zero around 8 mA, which is why a spot check at 10 mA looked excellent - mean error -1.6 uA but mean absolute 22.7. A single point near the crossing flatters this module badly.
Automation versus hand work
The measuring took twenty-five minutes. The setup took the rest of the day.
Four sweeps, five to nine minutes each, unattended, no timeouts, one dropped sample in four hundred. That half does exactly what it claims, and watching a curve draw itself against a meter is genuinely good fun.
Here is the other half.
It took twelve attempts to get one column to say µA instead of V. The unit is read once, when the row is created, and quietly ignored every time after — so editing it does nothing, renaming the row does nothing, and the only thing that works is deleting the row and building a new one. The chart then keeps its own stale copy, so you do it again there.
Every change to a definition means closing TestController, editing, saving and starting it again. I lost count of how many times today. The NullPointerException on import came up about twenty times.
A variable that has held a struct cannot be printed, cannot be compared, and cannot be assigned again. All three throw the same exception, and the error points at the statement after the one that actually failed, so you spend half an hour looking at the wrong line. The fix turned out to be assigning a dummy value first.
A command sat in the file, correct, and simply never registered — nothing in the log, no error, just absent. Moving it fixed it and I still do not know why.
The documented example for the sweeper uses quotes that do not work. The saved files went to a folder I had not chosen. An axis came up reading −1 to 0 with all the data piled at zero.
None of it is difficult once you know — but that is the point. It is all things you have to know and remember, and almost none of it is written down. What you can build with this is fascinating. It is not entry level testing, and nobody should walk in expecting it to be.
-
In the TC Load devices tab, I can't identify what GPIB address to use for a device 'Agilent 34401A', of type GPIB, that is connected to a Keysight 82357B interface. My Win10 device manager identifies the 82357B as located on Port_#0004.Hub_#0001.
Using Niravk Patel's software specific to 34401A, I connect using GPIB Port Address GPIB0::23::INSTR.
The TC Reconnect tab gives an error message suggesting I use "GPIB_id:local_address:Agilent 34401A", but TC gives me an error when I use any of the following variants as the address:
GPIB0:23:Agilent 34401A
GPIB_0:23:Agilent 34401A
GPIB_4:23:Agilent 34401A
GPIB_0:Port_#0004.Hub_#0001:Agilent 34401A
The GPIB+Modbus tab in the bottom row of tabs doesn't seem to include a list item for the 82357B GPIB interface.
Any thoughts on what I am doing wrong? -
Dear HKJ, while looking for a way to automate the testing of my fixed resistor banks, I came to the idea of implementing a virtual scanner in TestController using a relay board. Below is my idea for a Popup.
Idea: a Scanner Popup
A relay board used the way a scanner card is used in a DMM, driven from TestController.
Wiring
The COM pins of all channels are tied together and taken to the measuring device. The NO pins are the inputs. Ground is shared between the inputs and the meter.
Typical practical purposes
A set of resistors measured against one reference meter, or several voltage references compared against each other. One meter measures every channel, so the meter's own error is common to all of them and cancels out of the differences between them. That makes the popup useful with a meter that is out of calibration, which is the situation most of us are actually in.
Selection- Relay board - any device declaring #interfaceType Relay. An exact filter, so a device that is not a relay board cannot be picked by mistake.
- Measuring device - any device that can measure. No type filter.
The asymmetry is deliberate. The popup drives the relay board, so it has to know what it is. It only reads the meter, so it does not.
Channel count
The popup works it out itself through #interface. Nothing is typed in and no new directive is needed. Boards from two relays upward, and two is not a special case - two voltage references against one meter is probably the most common thing anyone will do with this.
No definition changes
Neither the measuring definition nor the relay definition is modified. How the measured value is read - through #interface or by another route - is for HKJ to decide. The requirement is only that no definition has to change to take part.
Timing
Three values, user set, each with a default:- On wait - after closing a channel, before reading. The settle time.
- Off wait - after opening, before the next close. Break before make. With every COM tied together, two channels closed at once shorts two inputs to each other, so this one is protection rather than timing.
- Interval - between scan cycles.
Single pass or continuous. Single is also the natural way to check the wiring before letting it run.
Logging
The popup does the logging itself, because it is the only thing that holds the channel and the value at the same instant. A row per scan cycle and a column per channel, so each channel is a curve that can be charted on its own rather than a slice of a sawtooth. The meter's normal curve is unaffected. A timeout is logged the way TestController logs one now.
The column count comes from the board, so the layout cannot be fixed in advance - two columns and thirty two columns are the same code but not the same screen.
Note
The relay definitions are all written already, and between them they cover Ethernet, RS485, RS232 and USB. Because the Popup goes through #interfaceType Relay it never has to know which one it is talking to - the transport stays the definition's problem. So every board I have works on day one, and a board on some future interface works without touching the Popup.
-
In the TC Load devices tab, I can't identify what GPIB address to use for a device 'Agilent 34401A', of type GPIB, that is connected to a Keysight 82357B interface. My Win10 device manager identifies the 82357B as located on Port_#0004.Hub_#0001.
Using Niravk Patel's software specific to 34401A, I connect using GPIB Port Address GPIB0::23::INSTR.
The TC Reconnect tab gives an error message suggesting I use "GPIB_id:local_address:Agilent 34401A", but TC gives me an error when I use any of the following variants as the address:
GPIB0:23:Agilent 34401A
GPIB_0:23:Agilent 34401A
GPIB_4:23:Agilent 34401A
GPIB_0:Port_#0004.Hub_#0001:Agilent 34401A
The GPIB+Modbus tab in the bottom row of tabs doesn't seem to include a list item for the 82357B GPIB interface.
Any thoughts on what I am doing wrong?
TC does not direclty support VISA connections. If you wan to use VISA connected devices with TC, you can use the VMSG tool I created for that purpose.
https://github.com/Cyclotronic/VMSG
It allows you to map your local VISA devices and it emulates a Prlogix Ethernet adapter which TC supports for GPIB devices. -
Dear HKJ, while looking for a way to automate the testing of my fixed resistor banks, I came to the idea of implementing a virtual scanner in TestController using a relay board. Below is my idea for a Popup.
Not a bad idea, some brainstorming from me:
1) It must identify the mode (volt, current, etc.) and create its own channels, like Scanner.Voltage1, Scanner.Voltage2, Scanner.Voltage3
1) Working mode:
a) Each measurement add a separate line to the log, with the other lines either a duplicate of last valid value or NotANumber mark.
b) It do a full scan and first log when it have all values.
2) This function will not work with any standard test in TC, only on its own. I.e. some options to chart and save may be useful.
Note: I am not sure how to control TC to do it.
-
Both things you are unsure about exist in TC already if I am not mistaken. A Scanner that registers as a virtual device gets its own channels, and with that the chart, the Math rows and saving come along for free - so the third point mostly solves itself, no separate chart or save path needed.
For the mode, #interface can be asked, or the mode search you built for the Battery Test popup can work it out.
On the working mode, a) and b) give the same table in the end - the difference is only when a row is written. What matters more is the filler: a repeated last value cannot be told apart from a fresh reading afterwards, so the log no longer shows which channel was actually measured on that line. With NaN it does, and the active channel is the one column that has a number.
One more thing worth allowing for: driving the relays in pairs, or in groups of four, so one scanner channel uses more than one relay. That is what 4 wire measurements need, and it means an 8 relay board becomes a 4 or a 2 channel scanner depending on how it is wired. -
HKJ,
I am working on a script that initiates a function on the connected device that takes 0.4 sec or more. Once I trigger that long function while that device is busy the console output shows errors. For example,.Code: [Select];; Value 1 from DMM1 2.978326E-02
;; Value 2 from DMM1 2.981300E-02
;; KLD: Rx as numbers <No data (timeout?)>
;; Value 3 from DMM1 2.983176E-02
;; Value 4 from DMM1 2.977365E-02
Device KLD is the one running the long trigger function and device KLD is the one showing a communication timeouts. These error happen even though no script command is trying to talk to that device and device data logging is off. By using debug mode I see that this error happens when the TC background process polls each of the connected devices to get a current value.
I tried
#DEVICELOGGINGDISABLE *
to turn off logging for all devices getting data from all devices but that did not help. To be clear, this script does not turn logging on at all but I thought it worth a try.
Is there a way to connect to a device so that a script can control it, but force TC not to poll it at all? Perhaps expand the action of #DEVICELOGGINGDIOSABLE to also block disabled devices from being polled in the background for current values also?? -
HKJ,
I am working on a script that initiates a function on the connected device that takes 0.4 sec or more. Once I trigger that long function while that device is busy the console output shows errors. For example,.Code: [Select];; Value 1 from DMM1 2.978326E-02
;; Value 2 from DMM1 2.981300E-02
;; KLD: Rx as numbers <No data (timeout?)>
;; Value 3 from DMM1 2.983176E-02
;; Value 4 from DMM1 2.977365E-02
Device KLD is the one running the long trigger function and device KLD is the one showing a communication timeouts. These error happen even though no script command is trying to talk to that device and device data logging is off. By using debug mode I see that this error happens when the TC background process polls each of the connected devices to get a current value.
I tried
#DEVICELOGGINGDISABLE *
to turn off logging for all devices getting data from all devices but that did not help. To be clear, this script does not turn logging on at all but I thought it worth a try.
Is there a way to connect to a device so that a script can control it, but force TC not to poll it at all? Perhaps expand the action of #DEVICELOGGINGDIOSABLE to also block disabled devices from being polled in the background for current values also??
Do the device not accept command during the 0.4sec interval, it is to short to give a timeout?
If you want to block the device from other stuff, it must be a command that returns a answer, then the device will be blocked while TC waits for the answer.
I do not believe #DEVICELOGGINGDISABLE support a * as parameter and I do not remember remember if it only excludes device from logging or from all parallel requests.
-
A Math row turns red when its source value is not available, which is fine.
The problem is that it stays red once the source is back. It never returns to normal on its own.
Unticking the row and ticking it again clears it, so the row itself is working - only the red state is latched rather than live.
I use TC v3.52 but probably true for previous versions too -
A Math row turns red when its source value is not available, which is fine.
The problem is that it stays red once the source is back. It never returns to normal on its own.
Unticking the row and ticking it again clears it, so the row itself is working - only the red state is latched rather than live.
I use TC v3.52 but probably true for previous versions too
It has worked, I will have to check it out. -
I am working on a script that initiates a function on the connected device that takes 0.4 sec or more. Once I trigger that long function while that device is busy the console output shows errors. For example,.
What is your #readingDelay set to? It might help to set that to 5 or something to give it more time for a response. -
HKJ,
#DeviceLoggingDisable does not list * in the web documentation but #DeviceLoggingEnalbe does mention * for all devices. Testing #DeviceLoggingDisable * does seem to turn logging off for all devices.
The long command is actually taking data to local device memory at significantly higher data rate than TC can directly log. While it is filling that local memory it can't reply to the #askValues request that TC sends in the background to maintain current values. Changing the driver file wait time limit for a reply won't work since it would have to go up to many seconds.
I have noticed that if I start logging with this specific device set to off with the #DeviceLoggingDisable command the errors disappear. The issue is only when not logging and waiting for the long high sample rate local/inside the device memory to fill up. While logging I am guessing that TC no longer polls for current value and just grabs them from the latest logged point.
Effectively, I need a way to make the TC background function keeping current values fresh not poll this device while the local trigger event is going.
-
Effectively, I need a way to make the TC background function keeping current values fresh not poll this device while the local trigger event is going.
Try putting [*OPC] as the first command in your #askValue, it is supposed to wait while the device is busy.
Note: Generally readouts piggyback on logging when it is fairly fast, but do their own when logging is slow.
-
Hi HKJ,
I know I've had success executing batch scripts (Windows) and passing arguments to the script for execution - is there a way to get a return value back in to Test Controller?
Based on what I currently know, the only way I can think of would be to have the return values directed to a text file, and for Test Controller to then read the text file, but seems less than ideal.
I have a device that enumerates with a proprietary USB driver but the API has been provided in a few languages. I'm contemplating the feasibility of writing a C program that Test Controller can run with arguments and receive return values from, but admittedly making software talk to software is not my area of expertise. -
HKJ, I am just curious, my scanner Idea is not feasible in TC ?
-
Hi HKJ,
I know I've had success executing batch scripts (Windows) and passing arguments to the script for execution - is there a way to get a return value back in to Test Controller?
Based on what I currently know, the only way I can think of would be to have the return values directed to a text file, and for Test Controller to then read the text file, but seems less than ideal.
I have a device that enumerates with a proprietary USB driver but the API has been provided in a few languages. I'm contemplating the feasibility of writing a C program that Test Controller can run with arguments and receive return values from, but admittedly making software talk to software is not my area of expertise.
The best way is to use a socket, i.e. a network connection.
But if you look in the programming language, it can execute external programs and console output is returned to the calling program (i.e. TC).
executeDos(program,path,timeout)
executeDos("c:\...\pgm.exe,"c:\...,2000)
The timeout specify how long to wait for output.
-
HKJ, I am just curious, my scanner Idea is not feasible in TC ?
I do not really know how to program it, but that do not mean I will not look at it, maybe I can find a way.
But it is not something I will do in a week or two. -
Hi HKJ,
I have a script that I am devloping that seems to crash Test Controller/Java runtime every single time I run it. More specfically there is a #while iteration loop and when that loop goes 59 times it crashes. I can run the script once with iterations at less than 59 times. If I then run it again in the same Test Controller session once the second run plus first run reaches 59 times Test Controller/Java run time crashes.
When it crashes the Java run time goes to high CPU and clicking to change something in Test Controller does nothing. Even clicking the upper right close appliation X does nothing. I have to force close Java run time.
If I start Test Controller and run the script just 58 or less times, close Test Controller, re-open Test Controller, and then run the script again I can do that cycle over and over again with no crash.
I was able to run in debug mode with timestamps and get the full DOS window contents. See the attached text file. The end of this debug file lists some out of memory errors. Since this PC has 32G of RAM I am assuming this is a Java limit being exceeded.
Below is the #while loop in question. Log time stepTime value is 0.1 sec and the loop counter n goes from 0 to steps which I change to change the number of iterations around the loop.Code: [Select]#while (n<(steps))
#log (stepTime)
(drive):REC.TRIG
#delay 1
; Get drive recorder average stats before stopping the log to block any background current value REC.TRIG from TC
= Ytemp = deviceRead(drive,"REC.CH3.AVG?")
= Y2temp = deviceRead(drive,"REC.CH4.AVG?")
#log 0
= Xtemp = tableCalcAvg(DmmCol,skip)/RShunt
; Print with fixed width numbers to be table like.
= "Point "+formatInt(n+1,2,2)+" Cmd: "+formatDouble(Itest,2,2,5,5)+" DMM: "+formatDouble(Xtemp,2,2,5,5)+" DUT Iu: "+formatDouble(Ytemp,2,2,5,5)+" DUT Iv: "+formatDouble(Y2temp,2,2,5,5)
= n = n + 1
#endWhile
Any thoughts on what more I can do to help figure out what is going wrong here?
For info on my HW setup below is the reply inside TC for #CONNECTED?
;; Computer: gby-avadirect 192.168.1.219, fe80:0:0:0:762d:5a7f:785:7b26%8
;; OS: Windows 11 x86 10.0
;; Java: Oracle Corporation 1.8.0_501
;; User: gby
;; Handle Device Serial number Version Address
;; CPX400DP Aim TTi CPX400DP 533881 2.02-4.11 192.168.1.70
;; KLD Kollmorgen LVDC Servo Drive 526260009 M_02-16-01-000_1256_80a47a2_alpha COM5
;; XDM1041 Digcreat XDM1041 25471190 V4.4.0 COM9
In case it helps:
Computer CPU: AMD AMD Ryzen 9 5900X 12-Core Processor (3.70 GHz)
Memory: 32 GB