Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bionet!csd4.milw.wisc.edu!cs.utexas.edu!swrinde!kent From: kent@swrinde.nde.swri.edu (Kent D. Polk) Newsgroups: comp.sys.amiga.tech Subject: Real World Amigas? Keywords: Data Acquisition, Industrial, ASDG, GPIB Message-ID: <17668@swrinde.nde.swri.edu> Date: 23 Jun 89 16:34:05 GMT Organization: Southwest Research Institute, San Antonio, Texas Lines: 88 Please excuse if this article is not appropriate, but does anyone have experience with using Amigas for fast real-time data acquisition/ control? (As opposed to slow data logging or typically slow process control). We (I) build computerized inspection systems for non-destructive testing, and usually put together our own STD or VME bus systems (black boxes with custom electronics) which then talk to something with an operating system (Sun or HP). High-end systems for the power generation industry usually consist of many '020/'030 slave processors firing data at a Sun 4 as fast as it can take it. (Can you say "Drinking from a fire hydrant?) Fortunately, we also build small systems too. There has been much pressure to get us to use PC's for the whole system, & so have given in a couple of times, however the results were dismal - usually ended up disabling most interrupts (clock, keyboard in particular) that were not needed, & usually have to write our own custom drivers for things like GPIB, serial, keyboard; such as the custom driver I wrote for the National Instruments card when run on a PC - NI's software is way too slow, and the card has a tendency to drop bytes. The major obstacles in implementing real-time data acquisition on a PC are the lack of multitasking (especially involving disk operations which take forever & lock the machine until done) and the inadequate bus design. I have encountered problems using faster PCs (12 MHz ATs) reading I/O ports at a pretty good clip - it seems I have to wait for the bus to settle down a bit after a read or I'll get garbage (Tech manual for IBM ATs even mentions this when using assembler). Also, the design of the board has a lot to do with this problem. A couple of us have often entertained the though of implementing such low-cost systems on an Amiga and now have several opportunities to do so. The main reasons are for it's fast multitasking abilities which would solve many of the problems we have with PCs and it's graphics capabilities. Although I have an A2500 on order, I am looking fo info to determine its reliability, usefulness, etc. for light industrial operation and am concerned about it's appropriateness. Q: Is the A2000 is robust enough (maybe a rackmount version) for such use? Q: Has anyone experienced bus read problems (similar to the bus read garbage on PC's) on the Amiga? Can one recover from a bus error? We use GPIB devices quite often, usually configured with only 1 or 2 listeners, so setup is quite easy. However we need FAST transfer speeds and FAST bus setup times. When DMA is not used, most transfers are small, but bus setup time & small block transfer rate needs to be optimized and these type of operations bring the National Instruments PC GPIB board to its knees. This is where I have to write my own custom drivers. Q: Does anyone have such info relating to the ASDG GPIB board & it's operation on the Amiga with respect to the type of operations I just described? Q: ASDG TwinX boards: Since I haven't tried to access custom hardware the system, does ASDG provide software to access TwinX modules? Can one purchase driver source code? Q: Does ASDG buffer any of their modules/provide memory mapping for fast access? (This is one place that a multitasking driver could be a godsend). I usually have to wait for an event & then grab stuff from lots of different inputs (position/velocity/instrumentation values) over GPIB, digital I/O & A/D inputs. On our black boxes we always try to use memory mapped architecture so this can be done quickly. (Try to do this fast on an Intel chip - Ha!) Q: What modes of access to the PC bus are available from the Amiga side? Do I have to involve the 80xx.x in the process, or can I read the AT bus directly? Please forgive if these requests are not appropriate, or if there are too many questions. Thank you very much, "Too many notes" Polk :^) ======================================================= Kent Polk - Southwest Research Institute {cs.utexas.edu, gatech!petro sun!texsun}!swrinde!kent kent@swrinde.nde.swri.edu ------------------------------------------------------- "Anything worth doing is worth overdoing" =======================================================