[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:	DECmcc user notes file. Does not replace IPMT.
Notice:	Use IPMT for problems. Newsletter location in note 6187
Moderator:	TAEC::BEROUD

Created:	Mon Aug 21 1989
Last Modified:	Wed Jun 04 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	6497
Total number of notes:	27359

4184.0. "A/D Requirements" by KYOA::BOYLE (Dirty Jobs Done Dirt Cheap) Wed Dec 02 1992 08:05

    My customer is interested in replacing a wall of analog recorders with
    DECmcc and some display devices.
    
    1.  Inputs to these recorders are +- 1V at milliamp currents.
    
    2.  There are 60 of these analog inputs.
    
    3.  We need on-the-order-of 10-50 millisecond sampling rate per channel.
    
    What are the issues?  What are the A/D options we can use?  What I/O
    buses are required?  For 60 inputs, what type of host is required?
    
    Thanks in advance,
    
    Jack Boyle  DTN 323-4448

T.R	Title	User	Personal Name	Date	Lines
4184.1	largely unhelpful answer...	MCDOUG::MCPHERSON	pre-retinal integration	`Wed Dec 02 1992 08:25`	16
	Sounds interesting, but exactly what does the customer expect that DECmcc will do? MCC is not a data acquisition system, per se (except to the extent that it will gather management information from managed objects...) Your specific questions about the data collection subsystem probably won't get answered here... I doubt that there are many lab Data acquistion system system designers monitoriing this conference. FWIW: Most of the data acquisition systems that I know of are PC-based (DOS), with special add-in A/D boards, sensors and acquistion software... Do we (DEC) still have an organization that sells to the scientific community? Maybe they have some platform suggestions for data acquisition; once you get that, then maybe you could work on how DECmcc might manage the acquisition by 'speaking' to those objects. /doug
4184.2	Sorry...	KYOA::BOYLE	Dirty Jobs Done Dirt Cheap	`Wed Dec 02 1992 08:37`	5
	Boy, did I screw up 8^)... I was looking for a different door. You know, the one marked RTI... Sorry...
4184.3	?What is "RTI" ?	MCDOUG::MCPHERSON	pre-retinal integration	`Wed Dec 02 1992 08:57`	17
	Don't run away too quickly! I think Gen. George Patton said, "Never apologize. It's a sign of weakness." ;^) Actually, depending on what the customer expectations of DECmcc are, there might be an interesting little AM/FM development project lurking in there... I mean, we're already using DECmcc to manage/supervise air conditioners, so monitoring data acquisition equipment or other process control doohickies is not out of the question... Try to suss out the customer requirementys some more and we may be able to help you a bit more... /doug
4184.4	Use for the common agent?	SKIBUM::GASSMAN		`Fri Dec 04 1992 09:18`	9
	If the customer is interested in getting the real-time information into DECmcc, the common agent approach should be looked at. A real-time application on a computer would take the readings, and update a MIB in real time. The common agent could be pre-loaded with thresholds that would send an event to DECmcc if something went screwy, and DECmcc could poll the common agent for updated status, history, and such. If you package both in the same machine, you could call it a system. bill