Using An AVR FOR Automated Parametric Testing...

Log in or register to post comments
Go To Last Post
6 posts / 0 new
Author
Message
microcarl
microcarl's picture
Level: Raving Lunatic
Joined: Sun. May 30, 2004
Posts: 8363 View posts
Location: Cincinnati, Ohio
#1
Posted by microcarl: Fri. Dec 5, 2008 - 02:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This thread may be off-topic, but it does directly relate to AVR controllers. If its felt to be off-topic, feel free to move it to the appropriate forum.

Looking at my workbench, I am aware that the B&K 5491A bench meter, the Tektronix TDS2012 oscilloscope, the B&K 1786A programmable power supply, the BitScope and the new Fluke 8845A bench meter all have RS232 communications.

Thinking about this, I have the making for the basics for an automated test bench. What is lacking is the central controller.

I've played with the manufacturer supplied software for each instrument at one time or another and frankly, what is provided by the instrument manufacturer is usually nothing more then a chunk of code that turns a PC into a glorified data recorder.

I've thought about making an attempt at writing something using Visual BASIC or Visual C# aimed at automated testing, but I have no real experience with either of those languages that would be useful for me on this type of project. Besides, I don't want dependence on a particular PC platform - beyond the use of a garden variety VT100 terminal emulator, or the like. No, I don't need a spiffy GUI, just a solid command structure and workable file storage capability.

I'm thinking that I might use one of those spiffy Xmega samples that I got from Atmel as a traffic cop containing a protocol emulator for each instrument. The key here is that I'll need quite a few serial communications channels, and if I remember correctly, the Xmega has something like 4.

Then too, maybe I could come up with a controller for each instrument that supports a particular instruments command protocol, and use an Xmega as the traffic cop with a common command protocol that communicates with each sub-controller dedicated to each specific instrument.

I have no low level (or high level, for that matter) experience with automated testing. But I think that this could be a fun project to tinker with.

Any thoughts, especially those from the side of experience, would be welcome.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Top
Kartman
Kartman's picture
Level: 10k+ Postman
Joined: Thu. Dec 30, 2004
Posts: 21763 View posts
Location: Melbourne,Australia
Posted by Kartman: Fri. Dec 5, 2008 - 02:50 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

LabView! But this ties you to a PC and a nice spiffy GUI. But, you can knock up a test bench very quickly as LabView will most likely have drivers for most of your equipment.

If I had to do what you were proposing, I don't think I'd use a small microcontroller - I'd most likely go for a small embedded Linux board like the ones at www.embeddedarm.com (I'll have to ask for a kickback for this shameless plug!) as you have tons of ram and no shortage of cpu performance. You could also script up the stuff in php and webify it without too much trouble.

Generally, when I have to do some sort of automated test jig, I always look for the fastest, simplest way I can get the job done- testing is never fun or glorious! (except if it involves explosives or motorised vehicles)

Top
microcarl
microcarl's picture
Level: Raving Lunatic
Joined: Sun. May 30, 2004
Posts: 8363 View posts
Location: Cincinnati, Ohio
Posted by microcarl: Fri. Dec 5, 2008 - 03:18 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
...testing is never fun or glorious! (except if it involves explosives or motorised vehicles)

Well, I certainly don't need automated testing on my workbench. But as more and more of the test instruments that I'm purchasing have the ability to be remotely controlled, I was thinking it might be a fun thing to experiment with - but probably not as fun as blowing up something.

But then too, there might be applications that would be better tested (or understood) using automated testing - realizing that those tests would be only as good as the test methods involved, or the skill of the individual who wrote them.

I just thought I'd learn something about automated testing that I could put into practice or application down the road.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

Top
ArnoldB
ArnoldB's picture
Level: Raving Lunatic
Joined: Thu. Nov 29, 2007
Posts: 3188 View posts
Posted by ArnoldB: Fri. Dec 5, 2008 - 07:06 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The industry standard on Windows PCs for this one is indeed LabView. You'll find that a single copy is rather expensive, but you often get older versions at a discounted price, and sometimes a current version from NI at a discounted price in a promotion.

In recent years I have almost entirely moved away from LabView. It is very shiny, but not what I need. I moved to scripting languages. There is a plethora of these on Unix, in particular on Linux, but many of them are also available for Windows.

No compilation involved, scripting languages are made for wiping up something quickly, speed is more than adequate for serial interfaces, and if you chose the right one they are easily portable. Once you have done the ground work, e.g. wrapping instrument commands in a collection of functions for that instrument, it is easy to script measurement tasks.

To name a few classic scripting languages: Perl, Python, Tcl. BTW knowing any of these is a marketable skill, looking good on a resume.

Stealing Proteus doesn't make you an engineer.

Top
microcarl
microcarl's picture
Level: Raving Lunatic
Joined: Sun. May 30, 2004
Posts: 8363 View posts
Location: Cincinnati, Ohio
Posted by microcarl: Fri. Dec 5, 2008 - 09:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ArnoldB wrote:
In recent years I have almost entirely moved away from LabView. It is very shiny, but not what I need. I moved to scripting languages. There is a plethora of these on Unix, in particular on Linux, but many of them are also available for Windows.

No compilation involved, scripting languages are made for wiping up something quickly, speed is more than adequate for serial interfaces, and if you chose the right one they are easily portable. Once you have done the ground work, e.g. wrapping instrument commands in a collection of functions for that instrument, it is easy to script measurement tasks.

To name a few classic scripting languages: Perl, Python, Tcl. BTW knowing any of these is a marketable skill, looking good on a resume.


Thanks, Arnold, I'll look into scripting. It I'd be great to add something like that to my resume.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

Top
Bingo600
Bingo600's picture
Level: Raving Lunatic
Joined: Sun. Apr 25, 2004
Posts: 4023 View posts
Location: Denmark
Posted by Bingo600: Sat. Dec 6, 2008 - 11:01 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Carl

If i was going to control those things i's either go the Xmega way (4 Uarts) , but i'd certainly also look into a couple of
M48/M88's talking RS232 , to the instruments , and have a master talking TWI or SPI to the units. I'd use TWI for sure if the TWI HW was working properly , and it might in a single master system. That way you could have a TWI BUS to hang the slaves on.

That would make the system scalable , and cheap and doable in a DIP version.

Like the others say i'd look into a scripting language , and just implement "basic transparency" in the avr's towards the instruments

/Bingo

Top