Test Equipment Anonymous

tggzzz wrote: ↑Sun Mar 12, 2023 7:52 pm And they say software engineers build things in an idiotic quixotic way.

Well, they do - but they aren't the only perpetrators.

bd139 wrote: ↑Sun Mar 12, 2023 9:26 pm

tggzzz wrote: ↑Sun Mar 12, 2023 7:52 pm And they say software engineers build things in an idiotic quixotic way.

Well, they do - but they aren't the only perpetrators.

We just try the hardest to do it badly!

tggzzz wrote: ↑Sun Mar 12, 2023 10:04 pm

bd139 wrote: ↑Sun Mar 12, 2023 9:26 pm

tggzzz wrote: ↑Sun Mar 12, 2023 7:52 pm And they say software engineers build things in an idiotic quixotic way.

Well, they do - but they aren't the only perpetrators.

We just try the hardest to do it badly!

The acronyms SNAFU and FUBAR are from WW2, and clearly predate software. Nonetheless, software and software weenies do tend to take everything to extremes.

Once software becomes mature, biohacking will take over that particular mantle.

bd139 wrote: ↑Mon Mar 13, 2023 8:34 am

tggzzz wrote: ↑Sun Mar 12, 2023 10:04 pm

bd139 wrote: ↑Sun Mar 12, 2023 9:26 pm

We just try the hardest to do it badly!

The acronyms SNAFU and FUBAR are from WW2, and clearly predate software. Nonetheless, software and software weenies do tend to take everything to extremes.

Once software becomes mature, biohacking will take over that particular mantle.

I can't wait to see people queuing up in Currys because they ended up with an extra nose instead of extra fingers.

tggzzz wrote: ↑Mon Mar 13, 2023 9:06 am

bd139 wrote: ↑Mon Mar 13, 2023 8:34 am

tggzzz wrote: ↑Sun Mar 12, 2023 10:04 pm

The acronyms SNAFU and FUBAR are from WW2, and clearly predate software. Nonetheless, software and software weenies do tend to take everything to extremes.

Once software becomes mature, biohacking will take over that particular mantle.

I can't wait to see people queuing up in Currys because they ended up with an extra nose instead of extra fingers.

Or, "If you want the antidote before it does you damage, send bitcoins to..."

I'll give it 50 years until that happens. The only question is when the 50 years started (past tense)

Robert wrote: ↑Mon Mar 13, 2023 5:47 pm Talking of software, what is the collective view of using Python for controlling hardware for commercial products?

Robert wrote: ↑Mon Mar 13, 2023 5:47 pm Talking of software, what is the collective view of using Python for controlling hardware for commercial products?

ch_scr wrote: ↑Mon Mar 13, 2023 7:59 pm

Robert wrote: ↑Mon Mar 13, 2023 5:47 pm Talking of software, what is the collective view of using Python for controlling hardware for commercial products?

Are you talking about controlling "commercial products" like a Keithley multimeter by Python, or "building a partially hardware product, which software side is python" ? For test automation, python can do good work in my experience. It's basically Python or Labview anyway, in that field. Also all the hobbyists use python for that stuff.

Robert wrote: ↑Mon Mar 13, 2023 9:04 pm Sorry wasn't clear. Building a partially hardware commercial item and using Python running on some kind of *inux OS on SBC to control HW. Also doing mission critical software tasks with Python.
Not low cost.

Robert wrote: ↑Mon Mar 13, 2023 9:04 pm Sorry wasn't clear. Building a partially hardware commercial item and using Python running on some kind of *inux OS on SBC to control HW. Also doing mission critical software tasks with Python.
Not low cost.

tggzzz wrote: ↑Mon Mar 13, 2023 9:41 pm

Robert wrote: ↑Mon Mar 13, 2023 9:04 pm Sorry wasn't clear. Building a partially hardware commercial item and using Python running on some kind of *inux OS on SBC to control HW. Also doing mission critical software tasks with Python.
Not low cost.

What is the expected benefit of using Python rather than another language?

Development speed? Scriptability? Field upgrades with extra functionality? What are the alternative ways of realising the benefits?

Don't fall into the trap of creating a domain specific language when a domain specific library is sufficient!

bd139 wrote: ↑Mon Mar 13, 2023 9:45 pm I would categorically never use: Ruby, C, Rust, C++, Java or C# for that sort of environment. Bad tradeoffs of time to market and footguns.

90% of the problem is what monkeys you have and what they can do though.

Robert wrote: ↑Mon Mar 13, 2023 9:04 pm Sorry wasn't clear. Building a partially hardware commercial item and using Python running on some kind of *inux OS on SBC to control HW. Also doing mission critical software tasks with Python.
Not low cost.

25 CPS wrote: ↑Tue Mar 14, 2023 1:10 am Whoever made this decided to break from the 3/4 inch spacing standard that has been used practically forever which means anything with a dual banana connector doesn't fit which rules out plugging in dual banana to alligator clip test leads or speaker wires terminated in a dual banana connector.

bd139 wrote: ↑Mon Mar 13, 2023 9:45 pm

Robert wrote: ↑Mon Mar 13, 2023 9:04 pm Sorry wasn't clear. Building a partially hardware commercial item and using Python running on some kind of *inux OS on SBC to control HW. Also doing mission critical software tasks with Python.
Not low cost.

I'm on the fence with that if I'm honest. Python can be used to make reliable software but it's not designed to. There are a number of language constraints which make it a difficult proposition in some cases. For example the dynamic/duck typed nature of the language has a bunch of foot guns. Also depending on what sort of deadline/latency guarantees you have, it might punch you in the face. If you require any concurrency or threading, it's probably worth looking elsewhere because there are still locking issues across the board. Also python packaging and dependency management is a shit show. It's one of those things that will require some maintenance down the line, not fire and forget. But it'll get you to the destination.

Depending on the architecture of the CPU, Go is worth a look at as well. That has proper concurrency primitives (based on Hoare's CSP paper with some extra bits), is properly statically typed and is memory safe, packaging is a joy, it cross compiles and it farts out one statically linked binary you can copy to the target machine and just run it.

I've got both in production under heavy load. Python has been stable but slow and difficult to maintain. Go has been stable, fast and not difficult to maintain. They can solve the same problem domain.

I would categorically never use: Ruby, C, Rust, C++, Java or C# for that sort of environment. Bad tradeoffs of time to market and footguns.

90% of the problem is what monkeys you have and what they can do though.

Robert wrote: ↑Tue Mar 14, 2023 7:56 am The 90% is the problem. Basically non software monkeys. Some of them think using ChatGPT to generate a starting point for code is a great idea
I'm no programmer, bar a bit of Pic Basic Pro 3, but have had to sort out the messes in the past. It's the combination of a open source interpreted language and lots of 3rd party libaries (and copied code) by non programming professionals that wories me.

Cerebus wrote: ↑Tue Mar 14, 2023 1:38 am

Robert wrote: ↑Mon Mar 13, 2023 9:04 pm Sorry wasn't clear. Building a partially hardware commercial item and using Python running on some kind of *inux OS on SBC to control HW. Also doing mission critical software tasks with Python.
Not low cost.

Python itself and the libraries that are an integral part run at a rate of acquiring CVE vulnerabilities of around one per month. Haul in any other python packages and you're looking at more. Which is another way of saying that managing the risks of a python deployment in the field are high.

Anyone who's used python commercially, and has an ounce of sense, will tell you the same story: managing updates and dependencies in the data centre is a pain in the arse. Doing it in the field is not something I would relish having to do; which is a very understated way of saying that I would be running the other way fast.

Cerebus wrote: ↑Tue Mar 14, 2023 1:38 am Python is fine for isolated fiddling. I use it to drive test gear, on the bench, where the stuff built is virtually throwaway. I also use it to drive my own systems configuration, during which time it is always supervised. I don't use it for anything mission critical, and when I have (there's a Telco out there that does mission critical core network automation on python code that I co-authored) it's surrounded with build pipelines that make sure they get exactly the right version of every identified dependency from a secure repository, and test cases that make up as much (possibly more) code than the job in hand.

When working seriously with python I always have the feeling that I'm working with a fragile, shifting, unstable pile of stuff that's just waiting to bite me in the arse at the first opportunity.

Cerebus wrote: ↑Tue Mar 14, 2023 1:38 am If you do end up having to use it, don't let anybody who identifies as a "python programmer" loose on it, use programmers who can also program in python. The python fanboys are some of the worst coders out there*.

Cerebus wrote: ↑Tue Mar 14, 2023 1:38 am *Example: one "python programmer" I was working with had a task that required counting the number of objects that had some particular characteristic. Instead of just running a simple loop iterating over the collection and adding one to a counter for each applicable object found and spitting that out as the count at the end of the loop, he ran the loop, inserted every applicable object into a "set" object, and then took the cardinality of the set as the result at the end of the loop. Changing it to a simple counter only made the loop run about 20 times faster. God save me from 'clever' programmers.

var count = lazyCollection.Select(s=>s.Attribute == "value").Count()

var output = new List<Item>();
foreach (var item in lazyCollection.ToList()) {
    if (item.Attribute == "value") {
        output.Add(item);
    }
}
var count = output.Count;

25 CPS wrote: ↑Tue Mar 14, 2023 1:10 am I just packed it in for the evening in sheer frustration.

The stereo receiver I'm using on the bench has switches for A and B pairs of speakers so I thought it would be convenient to have a set of pigtails brought out to an easy access location instead of having to go behind the receiver to connect speakers under test.

So, I bought a banana plug connector wall plate - which claimed to be a GE but probably made by a company that has nothing to do with General Electric except for a license to use their name and logo - and an electrical box, and assembled it tonight then connected it to B speaker outputs on the stereo receiver.





So far, so good, right? Right up until connecting something else.



You have to be kidding me.

Whoever made this decided to break from the 3/4 inch spacing standard that has been used practically forever which means anything with a dual banana connector doesn't fit which rules out plugging in dual banana to alligator clip test leads or speaker wires terminated in a dual banana connector.

That is supremely annoying. I'm going to have to find a wall plate with correct spacing or use panel mount connectors and a piece of sheet metal or plastic to make a replacement front for that box.