DWUTKA at marlow.com
DWUTKA at marlow.com
Fri Feb 25 19:26:39 CST 2005
I took a look at the 'data acquisition' device, and that is not what I
built. That is something designed to 'trap' data. I developed something
that is designed to 'store' data. The database is close to a true
relational database as I could make it (which immediately puts it out of the
hands of engineers to just query it on their own! <grin>, one of the reasons
I have to build a custom reporting system). It also doesn't plug into
anything. It's a .dll, that a test equipment engineer can use, instead of
fuddling through ADO, and designing a good database, there is a web
interface to create a 'program' (which would equate more to a table, to us,
I guess, but it isn't really creating tables.....), which can then be used
by their software, to store data for that program.
For example, the CMM machine I mentioned may record height (yep, it does
height), width, length, etc. So that would be a 'program' in my system.
Here's some sample VB (which is actually something the admin web interface
will create for you)
Dim DataAcq
Set DataAcq=CreateObject("FECMM.Program")
DataAcq.ID=1
'Start of Loop
DataAcq.SetFieldValue("Dim 1")=0.147
DataAcq.SetFieldValue("Dim 2")=0.147
DataAcq.SetFieldValue("Dim 3")=0.035
DataAcq.SetFieldValue("Dim 4")=0.103
DataAcq.SetFieldValue("Dim 5")=0.057
DataAcq.SetFieldValue("Dim 6")=0.057
DataAcq.SetFieldValue("Dim 7")=0.006
DataAcq.SetFieldValue("Dim 8")=0.006
DataAcq.SetFieldValue("Dim 9")=0.006
DataAcq.SetFieldValue("Location")=
DataAcq.RecordFields
'End of loop
DataAcq.DisplayReport
Set DataAcq=Nothing
It has 10 fields. Dim 1 through Dim 10, and location. When the
FECMM.Program object is initialized, and data is put into it, it
automatically creates a batchID, which is attached to each Item (items are
recorded with the RecordFields function, and the batch ID's are used to
group a 'run' with the test equipment). The DisplayReport function displays
a web page on the test machine with the data from that run. Setting the ID
value of the object determines it's parameters (such as how many fields, and
what the fields are.....which is customizable from the admin web gui.)
Does this clear things up a bit. Not a test equipment system, but a data
storage system, for the relational db challenged developers out there.
<grin>
Drew
-----Original Message-----
From: MartyConnelly [mailto:martyconnelly at shaw.ca]
Sent: Friday, February 25, 2005 7:05 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Web based Data Acquisition Application.
You have been beaten to it by about 50 years. I have used some of their
products (National Instruments) 20 years ago.
But they may not cover visual inspection images for data acquisition, I
have seen some specialized systems to inspect welds with Xrays.
These are probably the biggest guys in US.
http://www.ni.com/
I haven't looked through their site recently, guess the switched to dotNet
DWUTKA at marlow.com wrote:
>Okay, this isn't a technical question, it's more like a marketing one. My
>company is a manufacturing company, which has several 'test machines' which
>are basically computers hooked up (through engineering cards) to test
>equipment. Most of these systems have custom built 'test software'. I've
>been here for five years, and I have yet to find the software engineer who
>actually knows his left from his right in a database. The databases they
>are dumping data into are horribly designed. For example, we have a few
'EZ
>Testers', which dump their data into one database, in fact, ONE TABLE in
>that database. This table has over a hundred fields. Each product that is
>tested, and each test, use only certain fields, so there is a lot of wasted
>space, and even worse, the searching of this database is a virtual
>nightmare. A few years ago, we bought a CMM machine, it's a visual
>inspection machine (pretty slick, measures things with a digital camera).
>It came with it's own program, which has a GUI that 'writes' QVScript
(which
>is essentially VB Script, just with it's own object model, and a few other
>quirks. It has no default data capture system (other then to the screen),
>so I was asked to capture the data. I wrote a very specialized .dll, that
>QVBasic could use to dump it's data into an Access database. Worked fine.
>They only needed two types of 'data dumps', so I wrote two versions of the
>.dll. Quick, fast, took me no more then an hour or two to whip up the
>.dll's.
>
>Now a few months ago, we bought a second CMM. This one was going to test a
>lot more then 2 different things, so it needed to be flexible. I also
>figured that since this was going to be my second 'test machine' database,
I
>figured I might as well prepare for the future, and create a completely
>generic data acquisition system. Which I did, sort of. I have the data
>acquisition part done, but haven't completed the reporting capability. In
a
>month or so, I will finally be able to start actually developing again
>(right now, I'm too busy being a Network Admin, and PC tech! LOL). My
first
>project is going to be to finish the data acquisition program. So here's
my
>question. Does anyone know if this kind of thing would have a market for
>it, and if so, are their competing products, and what do they cost?
>
>Drew
>
>
--
Marty Connelly
Victoria, B.C.
Canada
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com