DMM Software design - Help appreciated

[Claude Desjardins]

Heya!

I'm new to this group and I hope I'm directing this to the right
peoples. I'm a great programmer but I'm unfortunately only scratching
the surface of the electronics; I recently had to program a software for
a very specific purpose and now that it's not needed for this purpose
anymore, I would find it absolutely stupid to loose the efforts put in
it so I want to expand it to reach a global pool of electronics
beginners and experts who would (I hope so) find a good use for such a
thing.

The software is basically a DMM (Digital MultiMeter) acquisition system
coupled with a plot & grid engine; or the most basic explanation; "Plug
your multimeter in, and you get a list of your values and a graphic to
go with it".

I would like the community to help me identify the needs for beginners
to experienced electronics workers so I can, with your help, add
features to the software. I have no clue of the distribution model at
this point but be assured that whatever the community gives me, I will
return it.

If you have any suggestions on what you would like to find in the
software, it would be greatly appreciated. For now, here is the list of
the integrated and to-integrate features (in other words; what it does
and what it'll do)

- Multiple inputs (plug as many multimeters as you want)
- Internet i/o (receive or send data from a multimeter to a remote client)
- Events logging / saving / printing
- Fully configurable input
- Output binders (you can bind an input (dmm) to an output plugin such
as "CSV Output" or "Internet Output"
- Variable / configurable sampling rate to the millisecond, per-input
- Live visual slider graphic
- Live visual micro plotter graphic
- Optional smoothing on the micro plotter graphic
- Noise follow-up (pc speaker beeps at a frequency equiv. to the actual
value percentage in the min/max scale, so you can follow the ups and
downs without constantly looking at the monitor)
- Low / High thresholds recording (keeps a record of the lowest/highest
values per-input)
- Auto-scaling of the input graphics
- Sampling recorder (Records input data to a sampling grid, keeps a
record of the event time, value, unit, mode and optional note)
- CSV output of the sampling recording
- Open, Save, Print sampling records
- Multiple variable selectable input to the sampling recorder
- Plotter; I'm not all set there
- Scriplets (Write small scripts to control the DMM I/O and software
interactions)
- Dynamic Link Library (DLL) based input translation & control
(Multimeter support is added by one single DLL file per protocol)



I have posted a screen shot of the actual software at the following URL.
http://www.rapidbin.com/1189391634885
The screenshot shows a sample scriplet.


If you have any idea, suggestion, recommendation - it would be GREATLY
appreciated. I can not guarantee I can / will add the function to the
software but it is guaranteed that I will consider all input received.

You're welcome to leave your email address; I will send you a free copy
of the software by email (or at least a link to get it) as soon as it's
ready (~1 to 2 months from now)

Kind regards

CD / RM.

 

[David L. Jones]

Heya!

I'm new to this group and I hope I'm directing this to the right
peoples. I'm a great programmer but I'm unfortunately only scratching
the surface of the electronics; I recently had to program a software for
a very specific purpose and now that it's not needed for this purpose
anymore, I would find it absolutely stupid to loose the efforts put in
it so I want to expand it to reach a global pool of electronics
beginners and experts who would (I hope so) find a good use for such a
thing.

The software is basically a DMM (Digital MultiMeter) acquisition system
coupled with a plot & grid engine; or the most basic explanation; "Plug
your multimeter in, and you get a list of your values and a graphic to
go with it".

I would like the community to help me identify the needs for beginners
to experienced electronics workers so I can, with your help, add
features to the software. I have no clue of the distribution model at
this point but be assured that whatever the community gives me, I will
return it.

If you have any suggestions on what you would like to find in the
software, it would be greatly appreciated. For now, here is the list of
the integrated and to-integrate features (in other words; what it does
and what it'll do)

- Multiple inputs (plug as many multimeters as you want)
- Internet i/o (receive or send data from a multimeter to a remote client)
- Events logging / saving / printing
- Fully configurable input
- Output binders (you can bind an input (dmm) to an output plugin such
as "CSV Output" or "Internet Output"
- Variable / configurable sampling rate to the millisecond, per-input
- Live visual slider graphic
- Live visual micro plotter graphic
- Optional smoothing on the micro plotter graphic
- Noise follow-up (pc speaker beeps at a frequency equiv. to the actual
value percentage in the min/max scale, so you can follow the ups and
downs without constantly looking at the monitor)
- Low / High thresholds recording (keeps a record of the lowest/highest
values per-input)
- Auto-scaling of the input graphics
- Sampling recorder (Records input data to a sampling grid, keeps a
record of the event time, value, unit, mode and optional note)
- CSV output of the sampling recording
- Open, Save, Print sampling records
- Multiple variable selectable input to the sampling recorder
- Plotter; I'm not all set there
- Scriplets (Write small scripts to control the DMM I/O and software
interactions)
- Dynamic Link Library (DLL) based input translation & control
(Multimeter support is added by one single DLL file per protocol)

I have posted a screen shot of the actual software at the following URL.http://www.rapidbin.com/1189391634885
The screenshot shows a sample scriplet.

If you have any idea, suggestion, recommendation - it would be GREATLY
appreciated. I can not guarantee I can / will add the function to the
software but it is guaranteed that I will consider all input received.

You're welcome to leave your email address; I will send you a free copy
of the software by email (or at least a link to get it) as soon as it's
ready (~1 to 2 months from now)

Kind regards

CD / RM.

Sounds good, looks good, nice work. I guess the only problem is a lack
of standard for Multimeter I/O, so people would have to write their
own driver for every OneHungLow brand multimeter on the market. But
seems you have thought of that by adding a scripting interface to
handle that sort of stuff.

All multimeters with I/O come with their own software, and most people
just want to Plug'n'Go, so if there is a driver available then your
software is very attractive, if not then they'll most likely put up
with what software they are given. But I guess drivers will build up
over time.

For high end instrument multimeters it would be handy to have an IVI
interface driver (http://www.ivifoundation.org/)

Dave.

 

[Claude Desjardins]

Sounds good, looks good, nice work. I guess the only problem is a lack
of standard for Multimeter I/O, so people would have to write their
own driver for every OneHungLow brand multimeter on the market. But
seems you have thought of that by adding a scripting interface to
handle that sort of stuff.

All multimeters with I/O come with their own software, and most people
just want to Plug'n'Go, so if there is a driver available then your
software is very attractive, if not then they'll most likely put up
with what software they are given. But I guess drivers will build up
over time.

For high end instrument multimeters it would be handy to have an IVI
interface driver (http://www.ivifoundation.org/)

Dave.

Hi dave, thanks for your comment.

It's entirely true; the different protocols used by different
multimeters makes it a pain to build generic support. The driver is not
the main problem here as most (not to say almost 95%) of all the
multimeters will communicate through a serial port or a serial emulator
(eg. the optical translator found in va & mastech mms) - Actually I'm
supporting the protocols through libraries so adding support to a new
multimeter will only require a DLL to be added into the input libraries
directory. I might release a howto document so the community knows how
to build the DLLs, and I have started buying some extra multimeters to
write what's needed to support them.

I had to get myself a pc dmm for the original project and figured this
would come with some sort of software ... I don't know if you tried the
V&A series, but I wanted to at least take a look at the software they
had before I make mine and *YUCK!* - their software is primitive to the
bone and as unstable as they managed to make it. I have made a reasearch
to find out what kind of softwares where available for the other makes
and still *yuck* for most of them.

The only make I found that will ship you a decent software is National
Instruments but we know how affordable their hardware is.

I personally don't think that peoples want a PC DMM so they can see a
graphic of what's being tested or to see the values on the screen
instead of on the multimeter itself. I'm sure there is alot more to do
with this technology than to just clone what's on one screen to the other

Claude

 

[David L. Jones]

Hi dave, thanks for your comment.

It's entirely true; the different protocols used by different
multimeters makes it a pain to build generic support. The driver is not
the main problem here as most (not to say almost 95%) of all the
multimeters will communicate through a serial port or a serial emulator
(eg. the optical translator found in va & mastech mms) -

Correct. RS232 seems to remain the standard here. Can't say I've seen
too many USB multimeters.
A lot of meters are also rebadged under half a dozen different brands
names, so that helps a lot.
If you supported say half a dozen popular low end brands, that would
be a great. The Protec 506 comes to mind.

Actually I'm
supporting the protocols through libraries so adding support to a new
multimeter will only require a DLL to be added into the input libraries
directory. I might release a howto document so the community knows how
to build the DLLs, and I have started buying some extra multimeters to
write what's needed to support them.

That would be nice, as a lot of people would baulk at having to write
a DLL.

I had to get myself a pc dmm for the original project and figured this
would come with some sort of software ... I don't know if you tried the
V&A series, but I wanted to at least take a look at the software they
had before I make mine and *YUCK!* - their software is primitive to the
bone and as unstable as they managed to make it. I have made a reasearch
to find out what kind of softwares where available for the other makes
and still *yuck* for most of them.
The only make I found that will ship you a decent software is National
Instruments but we know how affordable their hardware is.

I personally don't think that peoples want a PC DMM so they can see a
graphic of what's being tested or to see the values on the screen
instead of on the multimeter itself. I'm sure there is alot more to do
with this technology than to just clone what's on one screen to the other

Correct, there is no point connecting it to just emulate the DMM
screen, most people connect for data logging purposes. And usually
this involves SLOOOOOOW sampling, for say getting a battery discharge
curve or temperature plot over 24 hours. And usually all you want this
sort of software to do is logging and exporting to Excel, as most
people prefer to use a familiar tool like Excel to analyse their data.
So as long as your software is easy to use, supports a wide range of
logging options, and saves to and automatically imports into Excel
without any fuss or setup, then you will have a winner.

I don't if it has this feature or not, but one handy thing is for the
software to only take a sample when the data changes (and to time
stamp each sample). That way you can sample at a fast rate for days or
weeks on many channels and not end up with millions of data points.

Dave.