OpenLab Standard

[MARSHALBSB]

First of all, hello to everyone,

I noticed a lot of OSH project at the forum.


So, what you think about we initiate a Open Source Lab project, initially with desired specification and functions of the all basics equipments for a regular lab (that would be like a pool of ideas), with specifications, functions, interface, usability, etc...

 My first idea is that each device can be accessed by pc (using usb for instance) with built in hub, that allow to connect another device in cascade...

[bwat]

First one: Maybe, we may not get a product immediately. And that's OK. What's more important is the continuous idea improve till the day that the end product will be as well designed, precise and cheap as a commercial version....

Some points that immediately spring to mind:
1) Is it a good idea to get talented people to work on already solved problems. Why have them emulate existing products? Would mankind not be better served if the talent worked on new products?

2) Spending money on products that cost more than the commercial version is a waste of resources. The difference could have been spent on something useful. The more people that do this, the greater the waste.

[MARSHALBSB]

First of all, sorry that I changed the original text, so your quote get lost...

Yes, the point that you bring are very true...
Which make me improve the idea to, not to make people work in already solved problems, but, to get the existing solutions and improve it in order to create a better solution...

[Bored@Work]

Since years, every half a year or so someone like you comes up here with such or a similar suggestion.

"Hey, lets build a XYZ. I have this great idea. Wouldn't it be great if ... bla, bla bla".

All such initiatives quickly die. Because, what these people really mean is

"I have this great idea, I have no clue how to do it, but all I need is a bunch of idiots doing the hard work for me.".

Well, you are about to learn is that your ideas aren't really new, ideas are cheap, and the real trick is in the ability to execute. Do you have the ability?

My first idea is that each device can be accessed by pc (using usb for instance) with built in hub, that allow to connect another device in cascade...

Ok, and what are YOU going to do to make that real?

And by the way, if you manage to pull that off, don't expect a revolution happening. Seven years ago a German computer magazine published a modular DIY lab system, of course computer controlled. It is hardly known.

[Fsck]

My first idea is that each device can be accessed by pc (using usb for instance) with built in hub, that allow to connect another device in cascade...

this already exists in two forms:
1) GPIB chains
2) Ethernet -> switch -> test equipment

[mrflibble]

My first idea is that each device can be accessed by pc (using usb for instance) with built in hub, that allow to connect another device in cascade...

this already exists in two forms:
1) GPIB chains
2) Ethernet -> switch -> test equipment

Indeed. And if you want to actually make something ... you could for example contribute to this one:

https://www.eevblog.com/forum/testgear/python-based-instrument-control/

That's already a pretty good starting point, based on existing standards.

google terms du jour: GPIB, LXI, SCPI.

[MARSHALBSB]

ok Guys...thanks a lot for the replies ... I'll check that and see how that apply to my idea...

[nikodemus]

Seven years ago a German computer magazine published a modular DIY lab system, of course computer controlled.

Do you remember the name of the magazine, and issue number? (Or even better, have a link handy?)

[BjoernS]

The magazine was "c't", the project is named "c't lab".
Link:
http://www.heise.de/ct/projekte/machmit/ctlab/wiki

[charlespax]

I've seen several threads discussing instrument control. What are some use cases? I'm starting an open source instrument company and I'd love to learn more.

[Michael Rempel]

There already is an instrument standard. IVI.

http://ivifoundation.org/resources/default.aspx

Most of the instrument companies try to make stuff compliant to some extent, but the differentiation of hardware creates deviations from the standard. And the standards body has created protocol docs in 3 flavors so far. They obviously dont have a strong software architect on the team because there is a lot of flavor of the month style to the code, with a lot of different interfaces to muck through. If I was picking one to focus on it would be IVI-COM but that limits you to Winderz. It is also pretty simple to talk to. But once you are past the most basic stuff, you will need to talk to the device driver for each instrument anyway. IVI provides some guidance to keep stupid down to a minimum but I dont call it an inter-operable standard. That said you can read a billion lines of standards docs to figure out an open standard that is similar.
If I was writing yet another device driver (oh it can be painful) and it was for open sourceable stuff, I would join IVI and make it translate to that standard for sure. $700 US per year. http://ivifoundation.org/resources/default.aspx
If someone is interested my fees are quite reasonable and I AM a software architect so you wont get crapped on with the usual opensource mega hack. Drop me a line. The next IVI device driver training course is in San Diego. Would I go at your expense? You bet! I love SD. Lived there for a few years and would love to spend a few extra days visiting old friends.

[suckiden]

any news on the OpenLab?

[the_memristor]

The magazine was "c't", the project is named "c't lab".
Link:
http://www.heise.de/ct/projekte/machmit/ctlab/wiki

Thanks BjoernS for the link, it helped me a lot setting up my lab[emoji2]

[awallin]

There already is an instrument standard. IVI.

http://ivifoundation.org/resources/default.aspx

...

If I was writing yet another device driver (oh it can be painful) and it was for open sourceable stuff, I would join IVI and make it translate to that standard for sure. $700 US per year. http://ivifoundation.org/resources/default.aspx

what about LXI over ethernet. Are there licensing fees for that too?
Someone needs to write a simple C/C++ library that is portable to all the MCUs people are using and uses standard Ethernet with IVI/LXI/some-standard for communication - that would be a step forward IMO. It needs to be a standard where the library-writer, developer, and user are not required to pay licensing fees or where the standards-document costs money to read.

[suckiden]

for me it doesn't sound like you have to pay any fees. The specification is online on their homepage and what I also found:

The LXI Consortium is a not-for-profit corporation initially established by Keysight Technologies (formerly Agilent Technologies Electronic Measurement Group) and VTI Instruments (formerly called VXI Technology). Its primary purpose is to promote the development and adoption of the LXI Standard, an open, accessible standard identifying specifications and solutions relating to the functional test, measurement and data acquisition industry.

What I really like is the aim of connecting hardware (test equipment) with software (web interface). In this way you can keep the hardware costs at a minimum because displays, buttons or knobs are not absolutely necessary.

[alex.forencich]

For devices: https://github.com/j123b567/scpi-parser

For control: https://github.com/python-ivi/

In terms of VXI-11 (LXI) support, it's just an RPC server.  The RPC protocol is rather old, but I am not aware of any licensing restrictions.  The VXI-11 standards can be downloaded online and it's not terribly difficult to implement. Putting that on a microcontroller may be a bit of a stretch, though. 

[mrflibble]

For devices: https://github.com/j123b567/scpi-parser

Yup, I can confirm that one.  I use it with some minor patches + chibios on stm32 to give diy projects scpi capabilities. It does gobble up a reasonable amount of stack though, so the thread handling the incoming scpi commands does tend to have the largest stack. It's not super light weight, but quite acceptable (thread stack size 1 - 2 kB I recall). That could probably be reduced, but would take some more rewriting effort which of course never happens because 1) lazy and 2) next project. All that to say that it's the best free scpi parser I know that runs on a reasonable size mcu.

For control: https://github.com/python-ivi/

And another thumb up, also use that one. 

[sarp]

Dear Sir,

I am planning to implement a VXI-11 server on my STM32H7 dev-kit to make the kit usable as a testing instrument.
I've found a project that already and thankfully someone had done it https://github.com/bankrasrg/colortestkitmeter

But, it is implemented for arduino using C++.

My aim is to implement/convert it to C99 using LwIP and FreeRTOS.

May I ask if you've achieved your goal on implementing/arising a VXI-11 server on STM32?

Kind Regards
Sarp

[DrG]

There is the OpenBehavior effort http://openbehavior.com/ which is concentrated on Behavioral Neuroscience laboratory apparatuses.

There was also a hackchat on the OpenBehavior effort recently. Transcript links are:

https://hackaday.io/event/169511-open-source-neuroscience-hardware-hack-chat/log/174068-hack-chat-transcript-part-1
https://hackaday.io/event/169511-open-source-neuroscience-hardware-hack-chat/log/174069-hack-chat-transcript-part-2

[wizard69]

This thread makes me wonder if Marshalbsb's original effort died?    I like the idea of open hardware and frankly USB control of that hardware.   The problem is puling it off without the capital to back development.

[mrflibble]

This thread makes me wonder if Marshalbsb's original effort died?

Well, 16 posts total. You decide.

I like the idea of open hardware and frankly USB control of that hardware.   The problem is puling it off without the capital to back development.

The problem is OpinionSourcedHardware. Projects that start with an open invitation for spects, where everyone gets a say in said specs ... well, they tend to die quietly long before anything gets made.

That sort of project stands a far better chance if it is just one guy who just starts out with a personal project, and does the initial work. Then at some point, when there is something sorta-usable, he shows off the advantages of project XYZ and opens it up for people to join. And doesn't have to be just one person. I'd say 3 max at the initial stage. Anything more will get to be too much noise real fast.

Incidentally, a project dying somewhere along the spec stage doesn't have to be a total loss. Post mortem extraction of the good ideas and then using that as inspiration for your project XYZ can be useful.

And to keep it on topic, why invent a new "standard" when there's already things like USBTMC and LXI? Why not use existing specs, write an open sourced implementation, and plonk it on github?

[wizard69]

This thread makes me wonder if Marshalbsb's original effort died?

Well, 16 posts total. You decide.

I like the idea of open hardware and frankly USB control of that hardware.   The problem is puling it off without the capital to back development.

The problem is OpinionSourcedHardware. Projects that start with an open invitation for spects, where everyone gets a say in said specs ... well, they tend to die quietly long before anything gets made.

After reading through a second tie I did get the feeling that it was a "can you guys do this for me type of request".   Like open source software there has to be somebody driving the software with a vision.

That sort of project stands a far better chance if it is just one guy who just starts out with a personal project, and does the initial work. Then at some point, when there is something sorta-usable, he shows off the advantages of project XYZ and opens it up for people to join. And doesn't have to be just one person. I'd say 3 max at the initial stage. Anything more will get to be too much noise real fast.

Incidentally, a project dying somewhere along the spec stage doesn't have to be a total loss. Post mortem extraction of the good ideas and then using that as inspiration for your project XYZ can be useful.

And to keep it on topic, why invent a new "standard" when there's already things like USBTMC and LXI? Why not use existing specs, write an open sourced implementation, and plonk it on github?

[prasimix]

The problem is OpinionSourcedHardware. Projects that start with an open invitation for spects, where everyone gets a say in said specs ... well, they tend to die quietly long before anything gets made.

That sort of project stands a far better chance if it is just one guy who just starts out with a personal project, and does the initial work. Then at some point, when there is something sorta-usable, he shows off the advantages of project XYZ and opens it up for people to join. And doesn't have to be just one person. I'd say 3 max at the initial stage. Anything more will get to be too much noise real fast.

Incidentally, a project dying somewhere along the spec stage doesn't have to be a total loss. Post mortem extraction of the good ideas and then using that as inspiration for your project XYZ can be useful.

And to keep it on topic, why invent a new "standard" when there's already things like USBTMC and LXI? Why not use existing specs, write an open sourced implementation, and plonk it on github?

@mrflibble, you're are right at the point. I've started some time ago DIB "initiative" that is in line with OpenLab discussed here. It went nowhere because of too many opinions, musical wishes, wishful thinking with the occasional trolling .

But, I've continue working on that idea and first realization is DIB specification described here, and first project based on it is EEZ BB3 (Bench Box 3) discussed here (GitHub).
There were a lot of dead ends (XMOS as MCU, my own AC/DC power pre-regulator aka CF-DIC), but something was learned along the way and what came up was rewarded through a crowdfunding campaign. The first module created is a DC power module (DCP405), a continuation of the EEZ H24005 project, the second is a two-channel auxiliary DC power module (DCM220) and three new modules are currently being worked on: MIO168 (mixed signal I/O, data-logger), SMX46 4 x 6 switch matrix) and PREL6 (6 x power relay).

Everything is open source, comes with heavy support for SCPI (over 400 commands so far), supports MQTT, MicroPython and we have our multi-platform EEZ Studio for communication with SCPI instruments and for visual programming GUI for local touch screen!

Communication with PC is over USB or Ethernet. Ethernet will be used to communicate with other EEZ chassis (i.e. BB3 and new one without TFT display but with more slots).

Currently the "master" MCU is STM32F769 (I've H743 version ready for prototyping) running FreeRTOS, but we also working with ULX3S team that have a successful implementation of Lattice ECP5 FPGA for future more capable modules that will communicated with extended DIB, e.g. v2.0.

I will try to continue working on new modules, and I will be especially pleased to work with others who want to add new modules, already have an instrument but want to "weaponize" it with everything we have added so far through this project, etc.

[AlanS]

I agree that someone has to own the project - because they want to. Someone needs to get it to the viable stage. Denis, Martin and co have got us a test frame (BB3) through a great deal of 'character developing' heartache. I can't see me helping much with development - my expertise is elsewhere. BUT I can afford to help fund the effort - and I can certainly use the tools that are being developed for my own products. That way we all benefit - the community gets the test equipment it needs, Denis and Martin get their good work funded and others use this as a platform for launching more ideas.