Program that can log from many multimeters.

[HKJ]

Got a chance to start working with V144 with #driver Block and ran into Java errors and would not connect.  Below is the stub driver file I started with.

Code: [Select]

#verifyDevice txrx1? \0x26 \0x00


Stay away from the #verifyDevice for now, only the listed tx/txrx commands have been tested, nothing else. The rest is just copied from the ascii driver, but not modified for a binear comm driver yet.

[gby]

Taking the #verifyDevice out allowed progress using the #driver Block.  I can now read raw values from the device.  But, I can't seem to do any :readmath" on the returned value.

Below is the stub device file with two #scpiCmd's defined and :readmath:'s commented out.  These #scpiCmd's with :readmath: commented out return decimal numbers interpreting the returned serial byte as a signed 8 bit integer that are correct.

Code: [Select]

#idString "S200"
#name Kollmorgen S200 Servo
#handle S200
#port com
#comfixedbaud
; 19200 baud, Odd parity, 8 data bits, 1 stop bit
#baudrate 19200O81
#driver Block
#author gby

#scpiCmd HsTemp? txrx1? 0x4c 0x00
;:readmath: poly(value,-50.0,1.4775)

#scpiCmd Model? txrx1? 0x04 0x00
;:readmath: (0xF8&value)
If I un-comment either :readmath: line I get Java errors and Rx timeout.  The HsTemp with :readmath: command gives:

Code: [Select]

;; S200: Tx <HsTemp?>
;; S200: Tx <txrx1? 0x4c 0x00
:readmath: poly>
java.lang.NumberFormatException: For input string: "00
:readmath:"
        at java.lang.NumberFormatException.forInputString(Unknown Source)
        at java.lang.Integer.parseInt(Unknown Source)
        at dk.hkj.util.StringUtil.parseInt(StringUtil.java:531)plus a bunch more java error lines.  The Model? command gives a slightly different java error:

Code: [Select]

;; S200: Tx <Model?>
dk.hkj.script.ProgramExceptions$OperationNotSupportedForDataTypeException: BitAnd
0xF8&value____<----____
        at dk.hkj.script.Script.parseBitOp(Script.java:351)
Further confusing me, if I leave the readmath commented out and run the following script lines it works fine.

Code: [Select]

=var temp=0
=temp = deviceRead("S200", "HsTemp?")
=temp = poly(temp,-50, 1.4775)
=temp
So, how to successfully do :readmath: with #driver Block in the #scpiCmd's?

[HKJ]

But, I can't seem to do any :readmath" on the returned value.

It sounds strange, I will take a look at this tomorrow.

[jmurray]

Is there any way to view the release notes other than rolling back to a previous version of the software? Could not see a readme file or anything on the website.

I have not posted the release notes on my website, but you can find them in this thread and here they usually contains more explanation.

I hope you post the definition when you get it working (Remember the #author tag).

I haven't covered much of the ET5410's functionality, but I spent a lot of time correcting the formatting of its SCPI responses so that TestController can work with it.
There's probably still plenty of things that don't work quite right, but at least it's a starting point should anyone need it.
File attached.

I'm currently exploring the popup functions. Very handy as they're exactly what I'm looking for.
I am facing two challenges however:

1. I have tried both using #popupFileName, and declaring a var with the use of #popupText - I can not seem to get the #log function to use this filename as the argument it asks for is the literal filename - I do not appear to be able to pass it a variable to use as a filename for the log.

2. I suspect it is more an issue with the Java environment than with your program, but when I enter a string of text into the above prompt, I can not hit Enter on the keyboard to "OK" it - the OK button has to be clicked. This is not a massive issue, but I am planning to use this in conjunction with a QR code reading program that outputs keyboard emulation with a text string and then the carriage return key. The more I can automate, the more confident I can be about leaving the task in the hands of someone else! 

[HKJ]

I haven't covered much of the ET5410's functionality, but I spent a lot of time correcting the formatting of its SCPI responses so that TestController can work with it.
There's probably still plenty of things that don't work quite right, but at least it's a starting point should anyone need it.
File attached.

Thanks, it will be included in the next release.

1. I have tried both using #popupFileName, and declaring a var with the use of #popupText - I can not seem to get the #log function to use this filename as the argument it asks for is the literal filename - I do not appear to be able to pass it a variable to use as a filename for the log.

To use variables or expression put parenthesis around the parameter. I.e. filename is the text filename, (filename) is replaced by the contents of the variable filename. This basically works for all parameters on the command line.

2. I suspect it is more an issue with the Java environment than with your program, but when I enter a string of text into the above prompt, I can not hit Enter on the keyboard to "OK" it - the OK button has to be clicked. This is not a massive issue, but I am planning to use this in conjunction with a QR code reading program that outputs keyboard emulation with a text string and then the carriage return key. The more I can automate, the more confident I can be about leaving the task in the hands of someone else! 

That is my programming, I do not really know if I want it to terminate input on a ENTER in a input field.

[HKJ]

But, I can't seem to do any :readmath" on the returned value.

My bug with readmath is fixed in this .jar file: http://lygte-info.dk/pic/Projects/TestController/TestController.jar It is not a general release, the jar file do not contain device definitions and only changes compared to v1.44 is in the Block driver.

Added a "txrxn/txrxn?" where first parameter is number of bytes to receive.

The default format is unsigned, I have fixed that, but you can easily get a signed value, use: txrx1? 0x12 0x00 / 0i1
Everything after / is output format specifiers, it is possible to use many when receiving multiple bytes.
The first number is offset into the received data.
The letter is format: i=signed (1 to 8 bytes), u=unsigned (1 to 8 bytes), f=float (4 or 8 bytes), s=string, add a r to swap byte sequence (Default is lsb first).
The next number if how many bytes to use for the number
It is also possible to add a multiplier with *factor or divisor with /factor (Ignored for string)
And a offset with +offset or -offset (Multiply/divide must be first) (Ignored for string)


The #VerifyDevice works, but do not support readmath, it can be used this way:

#verifyDevice S200 deviceModel?

#scpiCmd deviceModel? txrx1? 0x26 0x00
:readmath: value==0x32?"S200":"unknown";

[gby]

HKJ,

Thanks for the interim update.  :readmath: works with #driver Block now.  I am making progress.  Couple of comments and questions:

1.  #verifyDevice in the device file leads to lots of java errors:
     java.lang.StringIndexOutOfBoundsException: String index out of range: -1
        at java.lang.String.substring(Unknown Source)
        at dk.hkj.devices.DeviceBlock$TranslatingCommInterface.cmdIdn(DeviceBlock.java:57)
        at dk.hkj.devices.DeviceBlock$TranslatingCommInterface.write(DeviceBlock.java:328) ....and bunches more
     Changing to #VerifyDevice with capital "V" and it works.  Should TC really care about the capitalization??
2.  When doing the model determination I need to match 8 possible 5 bit codes to the corresponding ascii text names.  I could do getElement with 32 entries but for only 8 possible valid values is there a simpler way to do the enumeration from the code number to the ascii text?
3.  I am trying to read a 16 bit value by querying the device for the two bytes and combining them.  If I individually read each byte and combine them in a script it works.  I then tried to do it with one device serial command:
     txrx2? 0x5e 0x00 0x5c 0x00 / 0u2
    and got lots of Java errors:
    java.lang.NullPointerException
        at java.util.Arrays.copyOfRange(Unknown Source)
        at dk.hkj.devices.DeviceBlock$TranslatingCommInterface.parseFormat(DeviceBlock.java:216)
        at dk.hkj.devices.DeviceBlock$TranslatingCommInterface.writeRead(DeviceBlock.java:270)
        at dk.hkj.devices.DeviceBlock$TranslatingCommInterface.write(DeviceBlock.java:349)
      .... more Java errors ending in Rx Timeout.
    I then tried variations on this command with/without format specifier and other variations all with Java errors and ending in Rx Timeout.
    How would you suggest I read two consecutive locations (sending two bytes for each request) to make one 16 bit word?  Or, 24 bit word, etc.
4.  This device uses 1 start bit, 8 data bits, odd parity, and 1 stop bit.  I have not seen a way to specify a start bit on the driver.  How to do that?  I have the line #baudrate 19200O81 in the device file which I assume tells TC to do Odd parity, 8 data bits, and 1 stop bit.
    By the way, when using parity what does TC do when there is a receive parity error?
5.  On the Load Devices tab when I enter the Baudrate manually for this device as 19200O81 it takes it.  But the next time I restart TC it comes back as just 19200.  So, in the Load Devices tab how do you set parity, data bits, stop bits and get it to stick?  If the device file has #comfixedbaud does TC use the #baudrate command in the device file and ignore the value listed in the Load Devices tab?

[HKJ]

1.  #verifyDevice in the device file leads to lots of java errors:
     java.lang.StringIndexOutOfBoundsException: String index out of range: -1
        at java.lang.String.substring(Unknown Source)
        at dk.hkj.devices.DeviceBlock$TranslatingCommInterface.cmdIdn(DeviceBlock.java:57)
        at dk.hkj.devices.DeviceBlock$TranslatingCommInterface.write(DeviceBlock.java:328) ....and bunches more
     Changing to #VerifyDevice with capital "V" and it works.  Should TC really care about the capitalization??

When you get into programming it is case sensitive, regular command line is not.
It is the lower case v that works, using the upper case is the same as not using any.
I did check the code I posted, if you modify the constants it will work.

2.  When doing the model determination I need to match 8 possible 5 bit codes to the corresponding ascii text names.  I could do getElement with 32 entries but for only 8 possible valid values is there a simpler way to do the enumeration from the code number to the ascii text?

Check the function "matchBitsList" https://lygte-info.dk/project/TestControllerFunctions%20UK.html#matchBitsList
It is exactly for that type of jobs.

3.  I am trying to read a 16 bit value by querying the device for the two bytes and combining them.  If I individually read each byte and combine them in a script it works.  I then tried to do it with one device serial command:
     txrx2? 0x5e 0x00 0x5c 0x00 / 0u2
    and got lots of Java errors:
    java.lang.NullPointerException
        at java.util.Arrays.copyOfRange(Unknown Source)
        at dk.hkj.devices.DeviceBlock$TranslatingCommInterface.parseFormat(DeviceBlock.java:216)
        at dk.hkj.devices.DeviceBlock$TranslatingCommInterface.writeRead(DeviceBlock.java:270)
        at dk.hkj.devices.DeviceBlock$TranslatingCommInterface.write(DeviceBlock.java:349)
      .... more Java errors ending in Rx Timeout.
    I then tried variations on this command with/without format specifier and other variations all with Java errors and ending in Rx Timeout.
    How would you suggest I read two consecutive locations (sending two bytes for each request) to make one 16 bit word?  Or, 24 bit word, etc.

I suspect you do not get both answer. You can do it as two txrx1? with ; between on one line and the use :readmath: to combine the result

4.  This device uses 1 start bit, 8 data bits, odd parity, and 1 stop bit.  I have not seen a way to specify a start bit on the driver.  How to do that?  I have the line #baudrate 19200O81 in the device file which I assume tells TC to do Odd parity, 8 data bits, and 1 stop bit.
    By the way, when using parity what does TC do when there is a receive parity error?

Start bit is ALWAYS 1, I have never seen anything else. To use the #baudrate specification you must use "#port comfixedbaud", this will disable manual entry of baudrate. Note: You have to delete and reload the device when changing the #port specification.
I do not remember, but it will probably ignore it.

5.  On the Load Devices tab when I enter the Baudrate manually for this device as 19200O81 it takes it.  But the next time I restart TC it comes back as just 19200.  So, in the Load Devices tab how do you set parity, data bits, stop bits and get it to stick?  If the device file has #comfixedbaud does TC use the #baudrate command in the device file and ignore the value listed in the Load Devices tab?

It is supposed to stick, settings is saved when you leave the "Load devices" page. Also note that you have to delete and reload the device when changing the #port specification. The selected port specification is saved separately from the device definitions and this gives issues when changing the #port specification.

[gby]

HKJ,

1.  Thanks for setting me straight.  The device file is case sensitive and using #VerifyDevice with capital "V" is like commenting the line out.  The real problem was I did not include the string to compare to in the line.  Silly syntax error on my part and sorry to bother you.

2.  I looked at the suggested matchBitsList.  It seems to use a mask to see if a bit sequence is set.  The required function is match a number.  I originally asked because the web page for getElement says "This is used to convert a index (From 0 and up to about 10 or 20) to a text." and I was worried 32 entries might not work.  32 entries works fine so this step is done with getElement.

3.  Still experimenting with ways to read two bytes to form 16 bit word.  I can get it to work in a script if I put a #delay between the two individual byte read requests.  However, in #scpiCmd's I can't seem to replicate the result.  If I put two read requests in a row in a script the second read errors and Rx Timeouts.  So, if there are two lines in a row like
    =templ = deviceRead("S200", "txrx1? 0x5E 0x00")
    =tempm = deviceRead("S200", "txrx1? 0x5C 0x00")
the first read works and the second one doesn't.  For #driver Block with two commands in a row does TC wait for the first response before sending the second request?  The device expects to receive byte, byte then sends reply and after reply is done is ready for next receive byte.  This simple device has no receive buffer to que commands.  Suggestions for #scpiCmd to retrieve multiple bytes and have delays between byte requests?

4.  Thanks for the clarification on how the serial port works.

5.  I deleted the entry in Load Devices tab and set it up again.  It makes sense now.  You must be correct that I changed #port definition in the device file and had not re-loaded in Load Devices tab.

New question:
6.  How to set/clear individual status bits within a byte?  For example, there is a byte with individual bits and want to set one bit and not change the others.  The standard way to do that is to read the location, set the one bit, and then write the modified value back.  In a device file how to read, modify value, and write it back?

Again, thanks for all your help and patience with my questions.

[HKJ]

2.  I looked at the suggested matchBitsList.  It seems to use a mask to see if a bit sequence is set.  The required function is match a number.  I originally asked because the web page for getElement says "This is used to convert a index (From 0 and up to about 10 or 20) to a text." and I was worried 32 entries might not work.  32 entries works fine so this step is done with getElement.

With 8 valid values out of 32 codes I would prefer the matchBitsList. That you have to write the bit mask, instead of using a integer is not really a bit issue.
I like to provide multiple ways to solve a problem.

3.  Still experimenting with ways to read two bytes to form 16 bit word.  I can get it to work in a script if I put a #delay between the two individual byte read requests.  However, in #scpiCmd's I can't seem to replicate the result.  If I put two read requests in a row in a script the second read errors and Rx Timeouts.  So, if there are two lines in a row like
    =templ = deviceRead("S200", "txrx1? 0x5E 0x00")
    =tempm = deviceRead("S200", "txrx1? 0x5C 0x00")
the first read works and the second one doesn't.  For #driver Block with two commands in a row does TC wait for the first response before sending the second request?  The device expects to receive byte, byte then sends reply and after reply is done is ready for next receive byte.  This simple device has no receive buffer to que commands.  Suggestions for #scpiCmd to retrieve multiple bytes and have delays between byte requests?

I have no idea what you problem is, maybe a "#cmdDelayTime" in the definition can add the needed delay.
Each txrx command will send its data and wait for the answer, before the next one is processed. When you have multiple on the same line you will get a string with multiple values in. I did add a fairly useful debugger tool in a previous version: displayVar(), it may help you figuring out what you receive.

6.  How to set/clear individual status bits within a byte?  For example, there is a byte with individual bits and want to set one bit and not change the others.  The standard way to do that is to read the location, set the one bit, and then write the modified value back.  In a device file how to read, modify value, and write it back?

There is no build-in support for that kind of operation, you could do something with :readmath: and deviceWrite(), but it will not be safe (Handle is not know). If doing a setup popup you may be able to do something, some controls create variables with their value (That is read from the device).
In script you can, of course, easily do it and with the new GridPanel that may be the best solution (A panel with scripts will be added, try typing "#GridPanel Script "Script" " on the command line).

[Messtechniker]

Been using the Calculator popup quite extensively. 
Occasionally it would have been nice to copy and
paste some of the results.

[HKJ]

Been using the Calculator popup quite extensively. 
Occasionally it would have been nice to copy and
paste some of the results.

Right click is you friend. You can copy to clipboard or log window or you can open a popup to show more complex results.

There are right click menus nearly everywhere in TestController.

What are you using the calculator for? Regular math, binary stuff, electronic calculations (I have some special functions for that) or something else?

[Messtechniker]

Nothing too advanced. Simply

1.) parallel resistor calculations
2.) frequency from R and C
3.) R from f and C.

Not 

Mainly because my old Texas Instruments SR-56
is gradually giving up the ghost being erratic. Probably time for the
good old thing to retire.

[HKJ]

1.) parallel resistor calculations
2.) frequency from R and C
3.) R from f and C.

I hope you found the par(r1,r2,...) function, it saves a bit of typing.
There is also the findR(series, value) that will use the specified series and find the best combination of two resistors to match the specified value.
You can do (Using E12):
findR(12,45) and the answer is: {R1=27, R2=18, tolerance=0, type=Series}
findR(12,31k) answer: {R1=39k, R2=150k, tolerance=-1.5361m, type=Parallel}

There is one caveat: The lowest series you can directly specify is 12 or E12, below that the numbers works different (See documentation).

There are a couple of variation on the findR(), they are all listed in the documentation: https://lygte-info.dk/project/TestControllerFunctions%20UK.html#Combine_two_standard_values_to_get_an_a_good_match

[Hydron]

Please see attached my driver for a HSPY 400V/1A power supply, controlled via RS232/Modbus.

This driver should hopefully work for other supplies in the series (with minor changes for data ranges, types etc). I can't work out any way to query the model sorry - there are a limited number of holding registers (many undocumented - I have included my notes on what I found) and none seemed to hold a version number or anything (doesn't help not having any other devices to compare against either).

A question about driver implementation - for a PSU, should #askValues be set to fetch only current values (output V, I and power in this case), or should it also fetch the setpoints as well? (V and I in this case - there is a power setting mode but it's not very usable so I've skipped it).
I have provided two versions of the values command in the driver, with the one with setpoints included commented out - if I've made the wrong choice in your opinion then please fix it!

I will also contribute a driver for the DCL6104A Dingchen electronic load once I have finished it (hopefully this weekend).

[HKJ]

Please see attached my driver for a HSPY 400V/1A power supply, controlled via RS232/Modbus.

Thanks, it will be included with the next release.

A question about driver implementation - for a PSU, should #askValues be set to fetch only current values (output V, I and power in this case), or should it also fetch the setpoints as well? (V and I in this case - there is a power setting mode but it's not very usable so I've skipped it).
I have provided two versions of the values command in the driver, with the one with setpoints included commented out - if I've made the wrong choice in your opinion then please fix it!

It is optional, I have some that includes set point and some that don't. On multi channel supplies it may be a bad idea, due to the amount of data, on single channel I cannot really decide. My old logging software did not have it and I did miss it a few times when using the voltage as x-axis on a chart.

Another details: You do not have to define a values? command, you could just have used a couple of defined SCPI commands on the #askValues line

I am happy you have added interfaces, they are useful for scripting, especially when I publish some, because they are not locked to a specific device. There will also be some panels in GridPanel that will use the interfaces (I am working on a panel readout that will include power, capacity and energy on any supply that has volt and current interfaces).

I will also contribute a driver for the DCL6104A Dingchen electronic load once I have finished it (hopefully this weekend).

I look forward to it.

[Hydron]

OK thanks for the tips - I've added back in setpoints and cleaned it up (removed the special values? command - I'd copied this method from another modbus definition). I have also fixed up the interfaces thing - I hadn't read the docs fully and misinterpreted the get/set/read definitions. Should be OK now.

See attachment below.

[HKJ]

I have also fixed up the interfaces thing - I hadn't read the docs fully and misinterpreted the get/set/read definitions. Should be OK now.

Sorry interface is wrong this time around, using

#interface readVoltage 2
#interface readCurrent 3
#interface readPower 4

works better (The number is the column for that #value).
And you had one to many SetOn

There is a popup to test the interface with.

[Hydron]

OK, that will teach me to do things in a rush!

Should I have a third go? Or have you already fixed my errors? (If the latter, I'll just wait for the next release, as I won't be using the interface bit myself).

[HKJ]

OK, that will teach me to do things in a rush!

Should I have a third go? Or have you already fixed my errors? (If the latter, I'll just wait for the next release, as I won't be using the interface bit myself).

I fixed the things I wrote about, but (of course) I did not test anything.

You might get around to use some of the new functions and scripts, that uses the interface, when I publish them.

The difference between interface and setup popup is that TestController do not know and cannot reliable guess what the function in a setup popup do, but with the interface it can usually easily decide it.
I.e. with a interface I/TestController know a device is a 3 channel power supply and how to control each channel, with a setup popup there is no way to know it. For the more advanced stuff knowing about devices is important.

[HKJ]

V1.47 is up.
It add more GridPanels, a easier way to modify scripts and a few new devices.
   Added: More GridPanel panels: Chart, Histogram, Script, System
   Added: Appa meters & HSPY-400-1 power supply (Thanks Hydron)
   Added: #waitUI, this will secure all pages are update, can be necessary before some UI manipulation from script.
   Added: Script list popup, found in "Generate script" menu. Used to administer the scripts.
   Added: #scriptNoLog a script filter that prevent a script from being listed while logging
   Added: #scriptTable a script filter that requires a table loaded, before it will list the script.
   Added: Device to handle Appa multimeter protocol.
   Added: Block device, this is for binary devices that answers with a fixed length block.

Meter readout with charts (This can be used for any supported DMM):


System panel (Contents can be adjusted):


Script panel (Contents can be adjusted):


In the "Generate script" menu there is a entry for opening this page:

[Hydron]

Found a bug in my HSPY script - missed a zero on the IOut? query so it's 10x larger than it should be. Correct line below:

Code: [Select]

#scpiCmd IOut? holding? 0x1003 /1000Other than that it seems OK, thanks for the correction (I did a quick check with the interface function too).

Another quick question - is there a recommended way to deal with a SCPI command that changes what units are returned depending on another setting?
In the other device I'm trying to write a driver for (a DCL6104A electronic load), the same SCPI command returns battery capacity as as either Wh or Ah depending on another setting (CC/CP/CR discharge mode), and I'm not sure what the best way to handle this is. You _can_ query the CC/CP/CR discharge mode setting to determine what the units are (CP is Wh, others Ah).

[HKJ]

Found a bug in my HSPY script - missed a zero on the IOut? query so it's 10x larger than it should be. Correct line below:

Code: [Select]

#scpiCmd IOut? holding? 0x1003 /1000Other than that it seems OK, thanks for the correction (I did a quick check with the interface function too).

Fixed.

Another quick question - is there a recommended way to deal with a SCPI command that changes what units are returned depending on another setting?
In the other device I'm trying to write a driver for (a DCL6104A electronic load), the same SCPI command returns battery capacity as as either Wh or Ah depending on another setting (CC/CP/CR discharge mode), and I'm not sure what the best way to handle this is. You _can_ query the CC/CP/CR discharge mode setting to determine what the units are (CP is Wh, others Ah).

You have to use #cmdMode to select mode and then enable/disable columns. All multimeters uses this..
For this you must:

Add one or mode mode parameters to each #value definition.
Define #cmdMode that can change the modes.
Define #askMode to return current mode.

You can see a definition in "Keythley2000".

[microplayer]

FY7900-60M - FeelElec Arbitrary Waveform Generator - Firmware v1.3
Issue: Waveform numbering in TestController differs from built-in waveforms sequence

Hi all,

I´m completely new to TestController software and still trying to make all my devices accessible by this wonderful piece of software. Thank you very much, HKJ!

However, one oddity already showed up in my own testing.
The numbering scheme 0..99 of waveforms in the v1.47 package differs from the sequence programmed in my generator running on firmware 1.3.
If you select a certain waveform in the TestController setup window, you might end up with a different signal going out. 
A cross check with the FeelElec programming manual "FY6900 Serial communication protocol.pdf" from 02.11.2019 also showed some differences in the sequence of signals when using the dial on the device.
So I dialed through the first 35 entries to correct the numbering in the original v1.47 "FeelElecFY6x00-xxM.txt" file...
Starting with entry #36 users can enter their individual waveforms into the generator´s memory. So no need to check anything from 36 upwards.   
Now settings in TestController are in sync with the entries selectable using the dial.

I´m happy to share the corrected file "FeelElecFY6x00-xxM-Waveform-Numbering-Scheme-from-FY7900-60M-Firmware-V1.3.txt" as an attachment.

One thing...
Maybe it is of interest to someone who bought a KORAD KA3005P clone from the german distributor Reichelt:
The attached "Korad KAxxxxP-Contains-entry-for-RND-320-KA3005P-by-Reichelt.txt" has an additional entry for this specific device name.
Nothing special, though. Just a little copy & paste & edit. However it might save you some time.

Kind regards,
microplayer
 
   

[HKJ]

I supposes you mean FY6900.

I have added the modified table to the device definition, it will be used for all FY6900 generators, but it is not tested!!
I have also added the #metadef for the RND supply to the Korad definition (Note: Version & serial number  must not be included in idstring)

Generally a extra #metadef entry can be posted directly and I will add it

And thanks for the updates.

The new FY definition file is attached, please check it (Use it to overwrite the original definition file).