Keysight EDU36311A (rant)

[capt bullshot]

Some parts of the EDU36311A must have been written by a clueless intern ...

Use case:
I want to test some DUT (nominal voltage 12V) over some voltage range. Starting at nominal 12V, then decreasing the voltage down to maybe 8V, then increasing up to 14V.

So first step - enter 12V using the keypad and turn the output on.



Next - turn the voltage adjustment knob ccw, voltage decreases by 0.1V.



Adjust the step to 1V (using the cursor button)



Turn further ccw until you reach 8V.



Now start turning the voltage knob clockwise to increase the voltage by 1V per step.



Works fine up to 10V - no you didn't notice the cursor changing the digit ...



Boom - DUT is toast by applying 20V out of the sudden (because now one step is 10V, not 1V).   



Yes, I know there's an OVP setting which one could have set e.g. to 14V - but this doesn't do what would be useful here. It just shuts down the output, not limit the setting to a max. of 14V.
But that's not the point at all, this is the stupidest implementation of a voltage adjust button I've seen until today. It acts as expected and suggests you're safe with what you're doing until it doesn't. 


Disclaimer: No human beings, animals or electronics were harmed by this experiment. Luckily, the DUT could stand 20V 

[mnementh]

...But that's not the point at all, this is the stupidest implementation of a voltage adjust button I've seen until today. It acts as expected and suggests you're safe with what you're doing until it doesn't. 

Disclaimer: No human beings, animals or electronics were harmed by this experiment. Luckily, the DUT could stand 20V 

« Last Edit: Today at 11:17:08 pm by capt bullshot »

Safety devices hinder evolution

Perhaps they read your signature and decided to implement it in the firmware...? 

mnem
 

[Zucca]

In 2022 all FW should be open source.
The EE community is far more competent than some bored at work eng (maybe not well paid)

This comes to my mind.

[tooki]

Some parts of the EDU36311A must have been written by a clueless intern ...
…
Works fine up to 10V - no you didn't notice the cursor changing the digit ...



Boom - DUT is toast by applying 20V out of the sudden (because now one step is 10V, not 1V).   

As a former UX designer, I appreciate how awful that is! Yikes.

[THDplusN_bad]

I think this is what the palm face smiley was invented for ... 

[capt bullshot]

As a former UX designer, I appreciate how awful that is! Yikes.

I don't need to be an UX designer, I've programmed such stuff (adjusting values by cursor keys) myself some 15 years ago. As I was the designer, coder, and (one, there's been customers, too) end user in one person, I knew how to do this right. Sometime it's hard, because it's not just a string but rather a physical value with influence to the real world. Though there's not that one "right" way, but what keysight did is clearly a sign of ignorance - fresh from uni bachelor boys PC or Smartphone App programmers / designers that never used any kind of TE (or other real world appliance) before.

[floobydust]

This is terrible. Probably an issue when setting current as well? Not a 1A can do the same one-button click to boom 10A feature, but still a decade jump.
I dare you to try submit the firmware issue to Keysight, let me know how that process goes. I find it takes way too much effort to write it up and submit it only to be treated as a "support request" and assume it's "user error".
After a product is released, Keysight seems to have paltry resources allocated to fixing bugs or dangerous UI issues.

[Someone]

Its not like they have the "excuse" of the number of digits after the decimal point changing. Counting the cursor position in digits on a number with variable digits, pretty funny. Almost the daily WTF funny.

[J-R]

In 2022 all FW should be open source.
The EE community is far more competent than some bored at work eng (maybe not well paid)

This comes to my mind.

So then the BB3 should be excellent?  But I think it's far from it.  I picked one up last year but quickly became annoyed with having to use the relatively small touch screen for everything.  It really needs a few more buttons.  There are also some other odd behaviors and of course it is a switching power supply not linear. 

Firmware development seems glacial at this point.  With the supposed flexibility, you would think they would have half a dozen UI configurations and such, but if you want that it seems you have to do it all yourself?

But I didn't mind throwing some money their way and who doesn't like putting kits together?  At the end of the day it does work.


Current favorite supply is the E36313A.  It actually doesn't even have a way to use the rotary encoder to adjust specific digits.  But otherwise we seem to be on the same page most of the time via the keypad.

Back to the EDU36311A, is the OP running the latest firmware?  I don't see any specific notes about them fixing that issue, but there have been a few updates since the product came out:
https://www.keysight.com/us/en/lib/software-detail/instrument-firmware-software/edu36311a-firmware.html

[Brumby]

I can see one way how such a result might have occurred - but it is programming laziness.

The fact it made its way out into the market, is an extreme condemnation of their testing process.

Just ... wow.

[Brumby]

Actually, thinking more about the programming - I'm suspicious about the whole approach being used.

Things I'm curious about:
 1. What happens if: with the voltage is set to 9.9 and the increment 0.1, you step up 3 times?
 2. Is the output voltage tracking the expected (indicated) value - or does it take some transient value along the way?
 3. Do you see any strange behaviour when stepping down?

[Brumby]

Then again.... maybe Keysight is teaching by introducing the concept of "know your equipment" since this is the EDU series.   

[capt bullshot]

I'm using the latest firmware, I've checked this first.

The "quirk" happens each time the setting crosses 9.xxx to 10.xxx, no matter which digit you're on. When crossing 9.xxx to 10.xxx, the cursor jumps one position to the left, so if you're starting with 0.001 steps at 9.999V, and cross that magical border a few times the cursor ends up at 10V steps.

Doesn't happen if you're decreasing the value and using less than 10V steps. At 10V step you end up at 0V and cursor at 1V step.

The obvious hint what's happening: The power supply displays 9.999V, then 10.000V (there's no leading '0' or ' ' when it's displaying values below 10.000). So the cursor just stays at the same position from the start of the displayed string, but the length of the string changes.

As the current setpoint doesn't change the length of the string, there's no such effect setting the current.
Interestingly, dialing towards 0A ends up in 0.001A setpoint, and dialing up keeps that 0.001A -> 1A, 0.9A, ... 0.1A, 0.001A, 0.101A, ... 1.001A

Output voltage follows the setpoint quickly (about 10ms settling) with no over- or undershoot. Didn't test the current limiting behaviour, this is often desastrous, especially with the HPAK units I know.

[Berni]

 
This is the most appropriate use of the facepalm smiley i ever did on this forum.

I would understand some cheep Chinese PSU doing this, but this is Keysight! One of the worlds top test equipment manufacturers!

I suppose since it is a EDU unit the person using it is certainly going to get some extra educational value out of it about knowing your equipment as well as having to learn some troubleshooting steps to fix the circuit they have fried just now.

[tv84]

Then again.... maybe Keysight is teaching by introducing the concept of "know your equipment" since this is the EDU series.   

Lesson 2: "know how to repair your equipment" 

The obvious hint what's happening: The power supply displays 9.999V, then 10.000V (there's no leading '0' or ' ' when it's displaying values below 10.000). So the cursor just stays at the same position from the start of the displayed string, but the length of the string changes.

  Most probable cause. I guess the whole handling system is so "prehistoric" that even the acceptance procedure was not able to include such use cases... 

[Brumby]

As someone who first started writing test scripts in 1978, the whole exercise is checking for normal actions as well as abnormal - looking for ways things could go wrong.  It baffles me how you could miss things like transitions across decades.

[nctnico]

As someone who first started writing test scripts in 1978, the whole exercise is checking for normal actions as well as abnormal - looking for ways things could go wrong.  It baffles me how you could miss things like transitions across decades.

I guess this is likely due to a new batch of software engineers taking over from the greybeards that all went into retirement at once.

[Berni]

I guess this is likely due to a new batch of software engineers taking over from the greybeards that all went into retirement at once.

Yeah these days programmers think about things very differently.

They appear to want to be as far removed from the hardware as possible. Everything is handled by libraries that use libraries that do the actual thing using a library. Nobody knows or cares how the thing actually gets done under the hood, they just care that it works. Memory is treated as being infinite and so are CPU cycles. Computers are fast anyway.

Like for example my Agilent 34461A bench DMM takes ~30 seconds to boot. For a damn multimeter...
On the other hand my Agilent MSO6034A scope boots up and is ready to go in ~10 seconds even tho this is an old scope from the 2000s that has a slower less performant CPU running vxworks.
But but... these new DMMs have USB and Ethernet and all that, you need a proper WindowsCE OS behind it to make that work! Well.. that scope also has USB and Ethernet and it works fine... The power on self tests for a 4 channel 2GS/s scope are also probably more complicated than a run of the mill 6.5 digit DMM.It is not even all that impressive of a DMM as i keep using the Keithley 2015 DMM instead (That was designed back in 1998)

[Bassman59]

Perhaps there's a way to report this bug to Keysight so they can fix it?

They're not reading this forum.

[tv84]

They don't support hobbyists... 

Only professional bugs are accepted.

[tooki]

I guess this is likely due to a new batch of software engineers taking over from the greybeards that all went into retirement at once.

Yeah these days programmers think about things very differently.

They appear to want to be as far removed from the hardware as possible. Everything is handled by libraries that use libraries that do the actual thing using a library. Nobody knows or cares how the thing actually gets done under the hood, they just care that it works. Memory is treated as being infinite and so are CPU cycles. Computers are fast anyway.

Like for example my Agilent 34461A bench DMM takes ~30 seconds to boot. For a damn multimeter...
On the other hand my Agilent MSO6034A scope boots up and is ready to go in ~10 seconds even tho this is an old scope from the 2000s that has a slower less performant CPU running vxworks.
But but... these new DMMs have USB and Ethernet and all that, you need a proper WindowsCE OS behind it to make that work! Well.. that scope also has USB and Ethernet and it works fine... The power on self tests for a 4 channel 2GS/s scope are also probably more complicated than a run of the mill 6.5 digit DMM.It is not even all that impressive of a DMM as i keep using the Keithley 2015 DMM instead (That was designed back in 1998)

I don’t think it’s an issue of “wanting” to be far removed from the hardware, it’s a matter of needing to get things done quickly and cheaply because your boss is a bean counter and not an engineer.

And libraries are a good thing: they tend to make things more stable and reliable, not less! You think this bug here would have happened in a battle-tested commercial UI widget library? Unlikely. More likely, it’s the result of DIYing it for whatever reason.

Abstraction is what makes modern software possible. It would be categorically impossible to write even distantly stable software with today’s feature sets without them. Reinventing the wheel is a bad thing. Letting one person write that wheel well and letting us focus on our specialty is a much better approach. Not knowing or caring how it happens under the hood is a huge, HUGE advantage, since it is what makes portability possible.

[Berni]

Well yes libraries are required due to complexity.

I am talking more about slapping together more and more libraries on top of each other with each one being slightly abused to do the thing they actually need it to do, or not quite understanding how to properly use the library efficiently. The result being a product that performs oddly slowly given how powerful hardware it is running on while perhaps even being unstable at times.

Why does my Agilent bench DMM take 30 seconds to boot? (It used to take even longer before the firmware update) What is that much more complex in a DMM as compared to a lot of my other test gear (like the old Agilent 6000 scopes, Rigol DP832..etc) that have similar modern interfaces like Ethernet and USB? What benefit does WindowsCE bring to the usability of a DMM?

Another example are some of the slightly order Philips TVs. They also can take >30 seconds to boot. Once it boots you get a picture, after 2 seconds the sound comes in and after about 5 seconds it starts accepting button presses from the remote. But if you do open the menu in the first 10 seconds after it starts accepting input the menus animate in at about 5 fps. Once it settles in the menus start rendering a bit faster at 15fps while there is a clearly noticeable delay of about 1/3 of a second upon pressing a button and seeing the menu move. I have updated the firmware multiple times on multiple models, it never got fixed. None of the DVD players from 20 years ago ware this slow and clunky while they could still play video from USB. The modern Samsung TVs cold boot in <5 seconds and have smooth and responsive menus while having smart functionality.

Similar story with 3/4 of car infotainment/digital dashes. They take a long time to boot only to offer choppy slowly responding UI once it does start running. Despite most of of them having hardware accelerated graphics hardware on board.

Yes you do need a mountain of fancy libraries to get it to do all the modern features, but given that the thing is running on hardware possessing easily 10x the computational power. it should not run many times slower than its predecessors.

[floobydust]

Perhaps there's a way to report this bug to Keysight so they can fix it?

They're not reading this forum.

Like I've said

[...] I dare you to try submit the firmware issue to Keysight, let me know how that process goes. I find it takes way too much effort to write it up and submit it only to be treated as a "support request" and assume it's "user error". [...]

I found it's a demoralizing experience. They should offer $CASH$ rewards for finding dangerous bugs in their products, if they had an interest in being the best.
They don't even have a way to submit a bug - it's all done as a support request, that you need help with their flawless products.

[nctnico]

I guess this is likely due to a new batch of software engineers taking over from the greybeards that all went into retirement at once.

Yeah these days programmers think about things very differently.

They appear to want to be as far removed from the hardware as possible. Everything is handled by libraries that use libraries that do the actual thing using a library. Nobody knows or cares how the thing actually gets done under the hood, they just care that it works. Memory is treated as being infinite and so are CPU cycles. Computers are fast anyway.

That is not the problem. Some companies grew an engineering team quickly which then got old together without a lot of influx of new engineers along the way. Then the old engineers retire and are expected to transfer 30+ years of experience onto new engineers within a couple of months. In such situations details will be lost (*). A better approach for a company is to make sure the age across all departments averages around 35 to 40 years with an even distribution.

Dave interviewed one of the R&D managers from Keysight a while ago and that person hinted towards having this exact problem.

* And there is more to it. One of the problems I encounter personally when dealing with new engineers is that I often forget about the details I take for granted but which are not obvious at all for new engineers. After a few decades working as an engineer there is a crapload of stuff you do on auto-pilot.

[kcbrown]

A better approach for a company is to make sure the age across all departments averages around 35 to 40 years with an even distribution.

Good Luck With That.  The only way to do that is to force early retirement onto the older engineers, who tend to be the most capable ones you have, or to get rid of your middle-age engineers who are just starting to become as capable as the older engineers.

End result: you compromise the capability of your organization, make it worse than it would be otherwise.

Unless your organization is large enough that you have a steady stream of people who are retiring, and can bring in young people as replacements, and have an even enough distribution of age and capability both within groups and across groups that your remaining older people can step into the roles that were left by the retirees, you're going to have a really tough time pulling anything like this off.

Engineering is one of those disciplines where youthful exuberance does not make up for hard-won experience.  Yes, someone who is relatively new and fresh can occasionally get a flash of brilliance and approach things in a new and insightful way that nobody else thought of before, but that's rare and completely unpredictable, and often comes with its own set of tradeoffs (for instance, making rookie mistakes in the implementation of the new idea).  Ideally you should have a mentorship arrangement where younger engineers are paired with older engineers so that the younger engineers can continually learn from the experience of the older ones.   I don't know how often that happens in practice in hardware-oriented organizations.  I've never seen it in the software world, because the software world is focused on doing things fast and cheap at the expense of pretty much everything else (such as maintainability, reliability, execution efficiency, etc.), and adopts idiotic development methods (e.g., "agile" programming) that pretend to be about quality but really are about speed of development and nothing else.