There were 2 new # commands introduced that listed the Global and Local vars. What are the commands and documentation location ?
print(getVarList(0))
Another PSU family to the list:
This driver covers the E3640A, E3641A, E3642A, E3643A, E3644A, and the E3645A.
This was created and validated against an E3641A
https://github.com/Cyclotronic/TC-Drivers/tree/main/drivers/HP_Agilent_E364xA
So, I made the mistake of keeping the "HP" part in the name of this driver. I had realized it was never produced under that brand and removed the metadefs but didn't fix the name.
And, I just acquired one of the dual output units in this line so its a good time to fix the name as well as update the driver to handle all 10 of the PSUs in this series. I've tested against at least one from the single and one for the dual output units and both GPIB and serial on each.
That's a solid number if you count the total coverage toward your goal of 2k instrument coverage.
The dual output and single output are detected and the setup menu changes to reflect that.
Please replace "HP_Agilent_E364xA.txt" with the one attached.
While building a device definition I ran into a few things worth reporting. TC version 3.51, Windows.
1. popupFile from a #scpiCmd #pgm#
Calling popupFile() inside a #scpiCmd #pgm# throws java.lang.NullPointerException at dk.hkj.script.FunctionsPopup$14.execute(FunctionsPopup.java:427). Same exception with two, four and five arguments. The same call works from #otherFunc.
2. Underscore in a text control value
A value typed into a #cmdSetup text control arrives with underscores replaced by spaces. Typing YOKO7562_GP and reading the variable back gives "YOKO7562 GP". A value built in a #pgm# keeps the underscore.
3. Unknown command in :write:
If :write: names a #scpiCmd that does not exist, nothing happens and nothing is logged. Other errors produce a stack trace with the ____<----____ marker.
4. getGlobalVar() is not in the documentation
getGlobalVar(name) works and takes a variable name as a string, for example s = "" + handle + ".commandTimeAverage" followed by print(getGlobalVar(s)). I could not find it on the Calculator, Functions or Intro pages.
5. path variables are not in the documentation
print(getVarList(0)) lists five read-only globals: path.config, path.data, path.devices, path.program and path.script. These give the correct directories for a definition that reads or writes files. I did not find them documented.
While building a device definition I ran into a few things worth reporting. TC version 3.51, Windows.
1. popupFile from a #scpiCmd #pgm#
Calling popupFile() inside a #scpiCmd #pgm# throws java.lang.NullPointerException at dk.hkj.script.FunctionsPopup$14.execute(FunctionsPopup.java:427). Same exception with two, four and five arguments. The same call works from #otherFunc.
I am fine with that, you do not do menus from a scpiCmd.
2. Underscore in a text control value
A value typed into a #cmdSetup text control arrives with underscores replaced by spaces. Typing YOKO7562_GP and reading the variable back gives "YOKO7562 GP". A value built in a #pgm# keeps the underscore.
I may have to look into that, but I do not know if it is something I can fix.
3. Unknown command in :write:
If :write: names a #scpiCmd that does not exist, nothing happens and nothing is logged. Other errors produce a stack trace with the ____<----____ marker.
Any command will be send to the device, except if it matches a defined #scpiCmd. That means no errors are output (Except maybe a timeout).
4. getGlobalVar() is not in the documentation
getGlobalVar(name) works and takes a variable name as a string, for example s = "" + handle + ".commandTimeAverage" followed by print(getGlobalVar(s)). I could not find it on the Calculator, Functions or Intro pages.
I will update the documentation.
5. path variables are not in the documentation
print(getVarList(0)) lists five read-only globals: path.config, path.data, path.devices, path.program and path.script. These give the correct directories for a definition that reads or writes files. I did not find them documented.
The documentation do not really list any predefined variables (There are more than them), I may have to update it a bit.
Transforming the parameter in a #scpiCmd
In a tx line, NS(int(value)) fails with "Expected a identifier" and the marker shows round100.0, so (value) is substituted before parsing. Is there a way to get an integer out of a plain #scpiCmd, or does it need a #pgm#? The control is an advNumber, which returns 100.0 where the meter needs 100. :format: D0 changes the display only, and numberInt returns an integer but takes only literal bounds where this needs a computed range.
Transforming the parameter in a #scpiCmd
In a tx line, NS(int(value)) fails with "Expected a identifier" and the marker shows round100.0, so (value) is substituted before parsing. Is there a way to get an integer out of a plain #scpiCmd, or does it need a #pgm#? The control is an advNumber, which returns 100.0 where the meter needs 100. :format: D0 changes the display only, and numberInt returns an integer but takes only literal bounds where this needs a computed range.
You hit a optimization, any instance of (value) is replace with the actual value, instead of calling the parser.
To get around that use: ( value ) i.e. add spaces around value.
Follow-up: getting an integer out of a plain #scpiCmd
The spaces tip solved the substitution, thanks. For anyone hitting the same thing, two more steps were needed. What did not work: NS(int(value)) fails with "Expected a identifier" because of the literal replacement; NS( int( value ) ) parses but then fails with "Invalid digit in <100.0>" because the parameter arrives as text with a decimal point, and round() fails the same way underneath; :format: D0 changes the display only, verified with and without on two controls; and getElement with "." as the separator returns an empty value, because the separator is a regular expression and the dot matches every character - that one shows up as a read timeout rather than an error. Escaped as "[.]" it works. The full form for an advNumber control writing to an instrument that needs an integer:
#scpiCmd numSamples tx NS( getElement( value ,0,"[.]") )
:setvar: numSamplesVal = getElement(inputValue,0,"[.]")
Documentation suggestions from the above
Four behaviours here are not on any page and each cost time on its own: that (value) written exactly like that is a literal replacement rather than an expression, and that spaces around it force the parser; that the separator argument of getElement is a regular expression, so "." has to be written "[.]"; that advNumber returns a floating point value where numberInt returns an integer; and that :format: affects the display only. Adding those four would have made this a five minute job.
Still short...
Mine is in MD format and is slightly longer....
I've published a new notebook on things I've learned creating drivers for TC.
https://github.com/Cyclotronic/TC-Drivers/blob/main/notebooks/silent-failures-in-cmdsetup-and-ascii.md
These are things that haunted me because I didn't see an error. It just silently ignored me much like my wife does. 
I hesitate to call anything a bug unless the developer says it is. These are just observations and may well be intentional design choices.
Do you check console output for errors?
Also note that debug mode do not activate all debug options, there you need to use the #debug command.
Documentation suggestions from the above
Four behaviours here are not on any page and each cost time on its own: that (value) written exactly like that is a literal replacement rather than an expression, and that spaces around it force the parser; that the separator argument of getElement is a regular expression, so "." has to be written "[.]"; that advNumber returns a floating point value where numberInt returns an integer; and that :format: affects the display only. Adding those four would have made this a five minute job.
I may update a bit in the documentation.
The issue with int("100.0") is that it directly tries to convert the string to a int and that fails. I cannot change that, but I could change the int function to not use the vars own type conversion.
I've published a new notebook on things I've learned creating drivers for TC.
https://github.com/Cyclotronic/TC-Drivers/blob/main/notebooks/silent-failures-in-cmdsetup-and-ascii.md
These are things that haunted me because I didn't see an error. It just silently ignored me much like my wife does.
I hesitate to call anything a bug unless the developer says it is. These are just observations and may well be intentional design choices.
#2 I cannot reproduce, my Yokogawa uses E command txrx E works like a charm but is longer than tx E
#4 infoAsk does not support :update: by design since a user has to press get
#5 I can confirm the same behavior experience, know your default when timeout
Does sync popups update infoAsk? Or what about that update all command that I can't remember right now?
No, I think it's a #commandThing.
I used it a few hundred posts ago, and it replaces all need for the :update: command across the setup menu.
#SYNCPOPUPS ??
what you describe is #updateModeChange no not for :updatemodechange: with that one
#updateModeChange 1
...but I dunno if it affects infoAsk or not.
#updateModeChange 1
...but I dunno if it affects infoAsk or not.
#infoAsk only updates when the button is pressed
Can I from the definition:
- Start the log
- do a loop of 500 samples to output to the #askValue command
- Stop the log
or
- do a loop of 500 samples
- return those as a sting of values space separated
- read them in or start log to read them in
- stop the log
All from the def so not in the #otherMenu
Can I from the definition:
- Start the log
- do a loop of 500 samples to output to the #askValue command
- Stop the log
or
- do a loop of 500 samples
- return those as a sting of values space separated
- read them in or start log to read them in
- stop the log
All from the def so not in the #otherMenu
You might be able to do something like that from a #scpiCmd #pgm#, but TC is not designed to work that way.
You have much more freedom in the other menu.