Program that can log/control many multimeters and other devices.

[HKJ]

Can the control be modified that when it occurs a + sign is added to the upper side, or a :-command to add a + in the definition itself. The example is Temperature, many be not the most common use, but it is also for Voltage and Current.

I like you suggestion and have put it on my list. This means I will not do it now, but probably will do it later. It is a lot of controls to update!

[Cyclotron]

I do not know what HP driver I want. I want the one that support most functions on the power supply, but your explanations do not say if your driver support more, the same or less. Obvious it supports GPIB, but that update may be as simple as add the word gpib to the already existing driver.
A screenshot of both configuration menus may also help.

Fair, i didn't give you much to go on.  The driver I wrote implements the whole of the feature set. Here's a comparison.
I've also attached screen shots of the new driver.  if you want shots of the old one, I'll have to work on that.

	Stock: AgilentHP E363xA.TXT	New: HP_Agilent_E363xA.txt
Driver
File size	220 lines	642 lines
Controls	19	36
Tabs	Main, Limits, Store, Display	Main, Fine Adjust, Protection, Trigger, Utility
Driver type	SCPI	SCPIx
Models covered	E3632A, E3633A, E3634A	E3632A, E3633A, E3634A
Values and limits
Logged channels	Voltage, Current	Voltage, Current, VoltageSet, CurrentSet, Regulation
Setpoint limits	Fixed - one ceiling per model, used in both ranges	Dynamic - ceiling follows the selected range
Limit values from	Data sheet ratings	Read back from the instrument
Range names	Hardcoded P15V / P30V	Per model: 8V/20A, 20V/10A, ...
Features
Triggered setpoints	no	yes - pending V/I, arm, trigger
Stepped adjustment	no	yes - step size, down/up
CV/CC readout	no	yes - live regulation state
Overtemperature	no	yes
OVP / OCP	yes	yes
Stored states	yes - 6 buttons	yes - 2 rows of 3
Display on/off	yes	yes
Display message	no	yes - 12 characters
Beeper	no	yes
Diagnostics	no	ID, SCPI version, error queue, status byte, questionable mask

The stock driver has two faults on an E3633A or E3634A. Its range buttons send P15V/P30V, which are the E3632A's range names, hardcoded in the section shared by all three models — the instrument answers -224,"Illegal parameter value" and the range silently never changes. Its setpoint fields then offer one fixed ceiling per model regardless of range, so on an E3633A it accepts 20 A while in the 20 V range where the real ceiling is 10.3 A, and the supply takes it without complaint because it validates against the model maximum rather than the selected range. The limit figures are also the data sheet's rated values rather than the instrument's own (20 V where the supply reports 20.6, and an OCP ceiling of 20.5 A where it reports 22), so the top of each field's span is unreachable.

[HKJ]

Fair, i didn't give you much to go on.  The driver I wrote implements the whole of the feature set. Here's a comparison.
I've also attached screen shots of the new driver.  if you want shots of the old one, I'll have to work on that.
ceiling of 20.5 A where it reports 22), so the top of each field's span is unreachable.

You do not leave me much choice, I have update to yours 

Just a note: Be careful with logging too many values, it slows the driver down and reduces the maximum logging rate for all devices when it is used.

[Cyclotron]

Fair, i didn't give you much to go on.  The driver I wrote implements the whole of the feature set. Here's a comparison.
I've also attached screen shots of the new driver.  if you want shots of the old one, I'll have to work on that.
ceiling of 20.5 A where it reports 22), so the top of each field's span is unreachable.

You do not leave me much choice, I have update to yours 

Just a note: Be careful with logging to many values, it slows the driver down and reduces the maximum logging rate for all devices when it is used.

I debated about logging. I have to ask your advice because I believe you have a lot more experience doing characterizations batteries and so on. I set it to log the voltage and current but also the settings and regulation state. I thought that someone running a scripted or advanced test might want to see the real values vs the set points and know if the supply was in CV, CC, or unreg.  I left all 5 values in.

This also leads to me thinking if there's a way to allow the user to pick/enable/disable logging channels.

Regardless, If you have a view of the channels, I do not mind adjusting the driver and uploading another copy.  When I get around to using it, I can certainly enable the channels I want.

[HKJ]

I debated about logging. I have to ask your advice because I believe you have a lot more experience doing characterizations batteries and so on. I set it to log the voltage and current but also the settings and regulation state. I thought that someone running a scripted or advanced test might want to see the real values vs the set points and know if the supply was in CV, CC, or unreg.  I left all 5 values in.

I like seeing the setpoints logged in at least in some cases, but that is usually when doing a sweep with TC and technically you can let the sweep control do the logging.

This also leads to me thinking if there's a way to allow the user to pick/enable/disable logging channels.

Technically there is, but it is fairly complicated.
You have to declare different modes and keep track of them in the driver.
The you can use mode on the #value and #askValue lines to control how much is requested.
One example is the gossen metrawatt energy meter (I do not remember if modes are kept locally or is from the meter).

Regardless, If you have a view of the channels, I do not mind adjusting the driver and uploading another copy.  When I get around to using it, I can certainly enable the channels I want.

One important milestone is logging at 1/second, if it is cannot keep up with that it is too slow. In some special circumstances devices can log slower (Like DMM's or frequency counter where the sample rate is selected slow, but default is usually fast enough).

[Cyclotron]

@HKJ

I accepted the challenge but I'll let you be the judge.  I've done a lot of testing and work on this HP E3533a driver. I've now validated it against GPIB and serial and found some significant issues to resolve. I've exhaustively tested and find that with 5 log streams can be done on both in under a second but, lets talk about the real challenge.

I have worked out a way to be able to enable or disable logging channels individually in the setup page.

The loading of the setup page is a bit slow, more so over serial at 9600 due in part to this logging select "feature". You can check and uncheck the channels to log while watching the current values tab and they change. I doubt anyone would have need to do that but you can certainly go into the setup, check the box for the channels you want to log and that's all that TC will see to log for the device. I had to make it so the last channel unchecked will silently fail no matter what channel that is because at least one channel must be enabled.

I may have not used things as they are intended to be used but I'll leave that judgement to you.  I can create an emulator for the HP E3633A if you want to run your own test of this driver.

Word of warning to anyone that does develop drivers, I was very surprised at how much slower the HP E3633A is over Serial vs. GPIB. I had to go in and make some changes in timing to keep TC from causing a lot of issues on the instrument.  Probably lots of folks know that and I'm just learning it but I thought I'd say I've seen it.

[HKJ]

The loading of the setup page is a bit slow, more so over serial at 9600 due in part to this logging select "feature". You can check and uncheck the channels to log while watching the current values tab and they change. I doubt anyone would have need to do that but you can certainly go into the setup, check the box for the channels you want to log and that's all that TC will see to log for the device. I had to make it so the last channel unchecked will silently fail no matter what channel that is because at least one channel must be enabled.

I may have not used things as they are intended to be used but I'll leave that judgement to you.  I can create an emulator for the HP E3633A if you want to run your own test of this driver.

Word of warning to anyone that does develop drivers, I was very surprised at how much slower the HP E3633A is over Serial vs. GPIB. I had to go in and make some changes in timing to keep TC from causing a lot of issues on the instrument.  Probably lots of folks know that and I'm just learning it but I thought I'd say I've seen it.

That was to select channels are not really nice. In TC everything that changes number of channels are supposed to be in the mode menu, not the setup menu. This prevents it from being changed during logging.
You are also making the selection way to detailed, selecting of setuppoint and CC/CV logging would be more than enough. That is two options, instead of five.

[Cyclotron]

The loading of the setup page is a bit slow, more so over serial at 9600 due in part to this logging select "feature". You can check and uncheck the channels to log while watching the current values tab and they change. I doubt anyone would have need to do that but you can certainly go into the setup, check the box for the channels you want to log and that's all that TC will see to log for the device. I had to make it so the last channel unchecked will silently fail no matter what channel that is because at least one channel must be enabled.

I may have not used things as they are intended to be used but I'll leave that judgement to you.  I can create an emulator for the HP E3633A if you want to run your own test of this driver.

Word of warning to anyone that does develop drivers, I was very surprised at how much slower the HP E3633A is over Serial vs. GPIB. I had to go in and make some changes in timing to keep TC from causing a lot of issues on the instrument.  Probably lots of folks know that and I'm just learning it but I thought I'd say I've seen it.

That was to select channels are not really nice. In TC everything that changes number of channels are supposed to be in the mode menu, not the setup menu. This prevents it from being changed during logging.
You are also making the selection way to detailed, selecting of setuppoint and CC/CV logging would be more than enough. That is two options, instead of five.

Understood, I'll revert the logging changes. I'll look at making two modes.

[flash2b]

On: https://lygte-info.dk/project/TestControllerConfigDevice%20UK.html

:labelformat: This tag is used to format the text on the form (i.e. not buttons, edit fields, combobox or radio). It supports multiple types of format: Style: plain/bold/italic Size: one or more +, color: name or (r,g,b)

What do you mean with: Size: one or more +

Tried: Size: 20, Size: more, Size: +2, Size: ++ none work on radiobutton.

Could you explain the syntax ?

[HKJ]

On: https://lygte-info.dk/project/TestControllerConfigDevice%20UK.html

:labelformat: This tag is used to format the text on the form (i.e. not buttons, edit fields, combobox or radio). It supports multiple types of format: Style: plain/bold/italic Size: one or more +, color: name or (r,g,b)

What do you mean with: Size: one or more +

Tried: Size: 20, Size: more, Size: +2, Size: ++ none work on radiobutton.

Could you explain the syntax ?

Very simple: + ++ +++
No size specification, each + add a bit to the size.
But it cannot control all text, only some items of text.

[flash2b]

Also tried forgot to mention, no effect.

So only color: is needed the rest is descriptive text.

On separator this works:

:labelformat: bold +++ color: blue

On radio this has no effect:

:labelformat: + color: blue

I read color: is only for set button and separator

[HKJ]

Also tried forgot to mention, no effect.

So only color: is needed the rest is descriptive text.

On separator this works:

:labelformat: bold +++ color: blue

On radio this has no effect:

:labelformat: + color: blue

You do not need a color: label, it will look for known words/symbols and react to them any unknown item will be ignored.
I do list radio as one of the items not supported.

[flash2b]

Fair:( i.e. not buttons, edit fields, combobox or radio)

Clearer: (not supported on: buttons, edit fields, combobox or radio)

No color coded radio buttons for me then, clear.

[Cyclotron]

Here's the updated E363xA driver with two modes. Log all and log V and I only.

Let me know if you think other changes are needed.

[HKJ]

Fair:( i.e. not buttons, edit fields, combobox or radio)

Clearer: (not supported on: buttons, edit fields, combobox or radio)

No color coded radio buttons for me then, clear.

I would have like the options to color buttons, but Java render the button flat when I do, it do not look good.

[HKJ]

Here's the updated E363xA driver with two modes. Log all and log V and I only.

Let me know if you think other changes are needed.

Updated.

For "fun" you could add the #interface setReadoutString
It can be used from the Steps popup.

[flash2b]

when I use :color: blue, is there a way to make the font color white ? (on a set button)

[HKJ]

when I use :color: blue, is there a way to make the font color white ? (on a set button)

No, you have to use a color so the black color looks good.
I once do some code to switch to white when the color got dark, but I do not remember if I did it in TC (I do not believe I did).

[flash2b]

I changed blue to (0,160,255) and now it looks ok.

[Cyclotron]

Hmm, I'm down in a rabbit hole learning about #interfaceType PS and #interface.
I need to confirm some things.

#interfaceType PS seems like a great way to provide generic functions that are easy to swap into scripts and such.  But if namespaces are used like I have in the e363xa driver, and the standard VOLT / CURR are in a namespace like "main" (as in my example), the #interfaceType PS function seems to fail to match those standard interfaces.

Next. I've been trying to better define my driver(s) so they are better citizens of cool functions like "Steps". When I go to "Add" interfaces in Steps, they are pretty "ugly" names. I don't see a documented, easy way to define the names in a more user-friendly way or to manage what is exposed in that list. I have gotten the function to display text on the PSU display during each step which is way cool but its not intuitive what option to select.  I've included a screenshot to show what I mean.

[HKJ]

#interfaceType PS seems like a great way to provide generic functions that are easy to swap into scripts and such.  But if namespaces are used like I have in the e363xa driver, and the standard VOLT / CURR are in a namespace like "main" (as in my example), the #interfaceType PS function seems to fail to match those standard interfaces.

The read... function are depend on the columns, i.e. readVoltage and readCurrent will work (I suppose these columns are always in the same place). You do not need read... functions for setpoints, there the get... functions work.

Next. I've been trying to better define my driver(s) so they are better citizens of cool functions like "Steps". When I go to "Add" interfaces in Steps, they are pretty "ugly" names. I don't see a documented, easy way to define the names in a more user-friendly way or to manage what is exposed in that list. I have gotten the function to display text on the PSU display during each step which is way cool but its not intuitive what option to select.  I've included a screenshot to show what I mean.

The standard list is based on numbers control and name is handle.page.label, also note that advNumber is special, it only works when the setup popup is open (That is the reason for the message on some items). TC has no idea what the different number controls do, that is the reason it exposes all of them, you can then use the one you want (They can be used in a bunch of popups).
The set... functions are in a different name space and use different name conventions. There TC also expect specific functionality from specific names, this makes it possible to automatic use them in some popups.

The text function is mostly for remote readouts, but TC do not check device type when scanning function names for Steps. That was also the reason I said for "fun", the PS is not really a text display, but it can do the function and there is no harm in supporting it.

[Cyclotron]

#interfaceType PS seems like a great way to provide generic functions that are easy to swap into scripts and such.  But if namespaces are used like I have in the e363xa driver, and the standard VOLT / CURR are in a namespace like "main" (as in my example), the #interfaceType PS function seems to fail to match those standard interfaces.

The read... function are depend on the columns, i.e. readVoltage and readCurrent will work (I suppose these columns are always in the same place). You do not need read... functions for setpoints, there the get... functions work.

Next. I've been trying to better define my driver(s) so they are better citizens of cool functions like "Steps". When I go to "Add" interfaces in Steps, they are pretty "ugly" names. I don't see a documented, easy way to define the names in a more user-friendly way or to manage what is exposed in that list. I have gotten the function to display text on the PSU display during each step which is way cool but its not intuitive what option to select.  I've included a screenshot to show what I mean.

The standard list is based on numbers control and name is handle.page.label, also note that advNumber is special, it only works when the setup popup is open (That is the reason for the message on some items). TC has no idea what the different number controls do, that is the reason it exposes all of them, you can then use the one you want (They can be used in a bunch of popups).
The set... functions are in a different name space and use different name conventions. There TC also expect specific functionality from specific names, this makes it possible to automatic use them in some popups.

The text function is mostly for remote readouts, but TC do not check device type when scanning function names for Steps. That was also the reason I said for "fun", the PS is not really a text display, but it can do the function and there is no harm in supporting it.

Thank you! I am having some fun too. Each of these lets me learn a pathway and those are helping me drive more value to the users that may eventually use TC and the driver I work on.

[HKJ]

Thank you! I am having some fun too. Each of these lets me learn a pathway and those are helping me drive more value to the users that may eventually use TC and the driver I work on.

You could also look at declaring the CC/CV value a digital value.
If a chart has multiple digital values they are combined on one scale, this sort of sidesteps the limit on number of curves.
Digital values are not displayed as numbers, but as names and some functions will handle them different.

https://lygte-info.dk/project/TestControllerConfigDevice%20UK.html#Data_type_definitions

DIGITAL(B0,B1,B2,...) This switches the value to digital mode, this means all values are converted to integer and handled as digital bits. The parameters are names for each bit, use - to skip a bit. It is recommended to use short names (2 or 3 characters) for the bits.

[flash2b]

With DIGITAL please note it is left to right so LSB --> MSB in TestController.

This is (for me) very unusual but I managed to code it into my Relay, DI and DO definitions, after reading HKJ definitions. Nobody else is using it at the moment.

[HKJ]

With DIGITAL please note it is left to right so LSB --> MSB in TestController.

This is (for me) very unusual but I managed to code it into my Relay and DO definitions, after reading HKJ definitions. Nobody else is using it at the moment.

It is practical, because it is usually the first few bits that is used, like DIGITAL(ON) or DIGITAL(CV).