1. Home
  2. Hobby Electronics Basics
  3. DMM Software design - Help appreciated

DMM Software design - Help appreciated

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.

formatting link
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.

Reply to
Claude Desjardins
Loading thread data ...

URL.http://www.rapidbin.com/1189391634885

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

formatting link

Dave.

Reply to
David L. Jones

URL.http://www.rapidbin.com/1189391634885

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

Reply to
Claude Desjardins

URL.http://www.rapidbin.com/1189391634885

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.

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

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.

Reply to
David L. Jones

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.