Python application for running test equipment

You might want to consider using YAML, and the Python support for it in e.g. PyYAML.

On Friday, 8 October 2021 at 16:40:23 UTC-7, Klaus Kragelund wrote: ...

...

There's PyVISA

kw

Is that *all* the interactions you expect to have with some "other" entity?

I suspect you might, also, want to "catalog" those results (instead of just "making a report") so that you can watch trends (without having to hunt down some Word document and write a script to extract the data from it).

The point I'm alluding to is that you may want to put a database in place -- from which to extract configuration data and into which to deposit results (?)

Wanting both actions makes the justification for going that route with *either* (config or results) easier; learn/develop one mechanism and apply it in both cases.

Regardless, you'll likely need to design a front-end that simplifies defining the experiments (in a human-friendly manner). And, something to parse those parameters to ensure they are consistent and complete.

[With a database approach, that front end can dump directly into the database -- your python script fetching directly from it. You can also use the front-end to facilitate viewing preexisting experimental criteria (a "pretty printer" of sorts).]

Nice, thanks. Looks like a good parser.

In my older windows tool, I have created Ini files for the setup constraints and did my own parser. Your suggestion is a lot better, building on stuff available

Yes, that is what I am using now. Used in PyCharm

I have saved the data in CSV files for now. Later I will let Python call Excel to skip the importing step

A database is a good idea. In my case, the tests will go to different customers, so I think it better to keep it in separate files

Yes, that's what I did in the Labwindows days. Did a parser, a compiler and a sequencer. But it took a long time to do all that, so looking for something simpler, but still versatile

(ick, Excel)

OK, as long as you are careful to include "column names" in the file (in case the format changes *or* different experiments involve different numbers of parameters, etc.)

You can always create a report from the database. There are many "report generator" products out there for this sort of purpose.

OTOH, if each report potentially has access to the entire DB, you might "accidentally" include data from another test that doesn't really belong in THIS report (e.g., different customer)

I'm wondering if you can use any "GUI controls" library to piece together a graphical form (think knobs, dials, sliders, etc. that can be used to SET parameters as well as coerced into *indicating* past settings/results)?

Ii have something similar, here, as my UIs are independant of output modality -- so I have to be able to present data (and take input) in a variety of different, but semantically equivalent, ways. E.g., "display" a value in Braille, speech, graphics, text, etc.

You can also put logic in the DBMS to enforce constraints on data input. So, attempting to submit a configuration that defies those rules causes the submission to be ignored.

E.g., if "voltage * current < 200" then submitting {10, 30} would never "stick". That doesn't make your job any easier, though. But, it does guarantee that you're results always "make sense" within these rules. (assuming you can develop such rules that apply to ALL experiments)

Yes, not preferred, but easy and it works

Yes, adding headers is mandatory :-)

Actually, I just implemented it, 30minutes, and now it's working.. (module openpyxl)

Yes, need to keep tight doors between customers

Yes, that is my idea. Also, being able to load all past tests for easy repeat and modification

For critical devices, I would need to add a protection layer. So if this voltage is out of bounds, shut down right away etc

Understood. My first read of your post had me thinking you were storing test equipment settings -- the likes of which never changed between experiments -- for N instances of the same DUTs. Like summarizing test results of devices coming off an assembly line.

I now suspect you are coming up with different experiments for different DUTs for different customers (?)

A database is less useful if the entries aren't "very similar", conceptually. E.g., its easy to make a schema to address your music collection: song, title, artist, duration, etc. Considerably harder to unify that with your

*paperbacks* collection: title, author, publisher, format, etc.

For that matter, neither is a spreadsheet, from row to row. But, you can easily create a spreadsheet with an entirely different set of columns for a particular experiment -- there's no inherent requirement that every spreadsheet have the same columns!

Yes, I should maybe have mentioned that. One test may be a power supply, with 230Vac, 12V out, 100W. Another with different parameters. That's easy solved with loading a settings file

Another scenario is testing maybe a diode for leakage current. Then it's DC voltage, and a current measurement, plus maybe a voltage measurement for voltage after a burden resistor

And so on...