Daqarta for DOS Contents
ID and other
housekeeping information. So around 16000 keystrokes can be
stored as Key Macros. If you try to store more than that, the
macro will be ended at the limit, an alert will be given, and
the message line will show:
'Out of Key Macro memory.'
A previously-stored Key Macro may be replaced simply by storing a new macro with the same ID. A macro can be removed by storing an "empty" macro: Just hit SHIFT-K or ALT-INS to end the macro before storing any keys. In either case, all memory that is no longer used will be reclaimed.
Repeated cursor motions are stored and run as a single large step to minimize memory use. This applies to trace cursors and to scrolling values while adjusting menu items, but it does not apply to moving between items in a menu... those motions are not actually stored. Instead, the cursor position within the menu is stored directly when ENTER is hit to change any item.
The descriptive name line for each macro is stored in a separate portion of "hidden" video memory. Enough memory is reserved to hold up to a full line (57 bytes plus ID text) for each of the 142 possible macro IDs. This memory use is not included in the report of bytes free after a KeySt, since no management is required... you can't "use it up".
Quit a session after making any changes to the macro storage. All descriptive name text will be included in the file.
The default file DQA.MAC will be loaded, if present, each time you start Daqarta. If you want to have several sets of macros for different types of experiments or different users, give each a different file name when prompted at the Quit for that session. Then use a standard DOS batch file to run Daqarta for each condition. The typical file would look like
COPY USER.MAC DQA.MAC DQAwhere USER.MAC would be different for each case.
Note that DQA.MAC is normally expected to reside in the same directory that holds Daqarta itself. However, a better method might be to keep different macro files in different work directories, where they would remain together with the associated data files. In this case, invoke Daqarta from the desired work directory, but in the DQA.CFG file INIT line use an M:0 parameter, as in
INIT M:0This will cause the DQA.MAC file to be loaded from the current directory. NOTE: This will only work with DOS versions 3.00 or later.
ID, that macro will be run automatically from DQA.MAC after Daqarta starts up. During the session, that macro is still available for normal use.
It is usually a good idea to define the desired initial macro using some other ID, then use the !-macro to invoke that one as a subroutine with KeyRn. That way, you can easily disable the automatic operation just by redefining an empty !-macro, and re-enable it later as needed.
trace cursors are involved. This is because the starting position of the cursor is not stored as part of the macro, so when the macro is run everything will be relative to the current cursor position. This is sometimes desired, as in the case of moving a cursor across the trace in fixed step sizes to note the value of the wave or spectrum at certain intervals. But much of the time the absolute position must be controlled. In the above cursor motion case, you would probably want to have a "normalize" macro that places the cursor in a particular start position, and a separate "step" macro that moves by intervals.
To assure a specific location for a cursor, start the macro with the cursor at one extreme and move to the opposite extreme before moving to the final value. When run, this will assure that the first motion will move the cursor to the end of its travel, since the cursor can't go past that point despite repeated attempts. Even if the cursor starts from a point at or near that end when the macro is later run, the motion will be limited to that end... it doesn't "bounce back" or "wrap around". The second motion will thus carry the cursor to the desired spot.
When a macro is used to adjust some item in a menu, make sure that you use CTRL-whatever to invoke the menu as part of the macro. Do this even if the desired menu is aready active, since it might not be when the macro is invoked later. Otherwise, the macro will try to adjust whatever item is in the same relative position in the then-current menu... probably with undesireable results!
Another possible pitfall has to do with menu items or entire menus that are disabled in certain situations. If a macro tries to adjust an item that is missing or disabled, it will exit immediately with an error message so you know that the intended operation did not take place.
Configuration file parameters for your particular ADC board driver affect the presence of DDisk and Averager Remote control options, and of the External and Pulse trigger source options. If you reduce the maximum stimulus buffer size for the STIM3A Stimulus Generator module, macros which set stimulus duration may be affected.
macro (either manually invoked or auto-initialization) which sets parameters. Then a second macro might collect an average and save the results to a file. A third macro might adjust some parameter by a fixed step, ready for the average-and-save macro to be invoked again. Or a whole series of average, save, and adjust macros could be strung together and invoked by the auto-initialization macro, followed by a Quit sequence for a totally automatic collection package.
Most of these macro operations are pretty straightforward, but file handling deserves special attention. The main issues revolve around organization and naming of files to prevent attempted overwrites of existing data, which will cause the macro to terminate when it prompts for overwrite confirmation. The IncNm option allows for automatically incrementing file name extensions... but you still need to insure that it starts with the proper file.
If you "hard code" the initial file name and extension, or accept a default like DATA.000, then the macro will attempt to write the same series of files on the next session and will fail. Instead, consider appending to one large series of files. The IncNm option allows up to 2700 file extensions, from 000 to Z99. Activate IncNm at the start of the session, then use InDat or DskRd (as appropriate) to attempt to read from the series having your selected main file name but with a '*' extension, like
'TESTDATA.*'This will cause all files starting with TESTDATA to be shown. Use CTRL-END to go to the last file in this list, and hit ENTER to read it. Then discard this file by unPause (for InData files) or by toggling DskRd off (for DDisk files). Now when you invoke OutDt or DDisk, the next file in the series will be the default, courtesy of IncNm, and you can just accept it with ENTER.
A typical key sequence might look like this:
ALT-I Turn on IncNm I InDat prompts for file name ALT-DEL Delete the default name TESTDATA.* File names to search (in current path) ENTER Enter file system, show matching files CTRL-END Move cursor to last file found ENTER Read that file P unPause to discard it
Note that we use CTRL-END instead of plain END here, in case there are more files in the series than will fit on a single screen.
When you get near the limit of 2700 files, you can either change the macro, move to a new directory, or rename all the files from DOS, as in:
REN TESTDATA.* TEST1998.*However, note that if you choose to rename the files, the DQALOG.TXT file created by EdSav will no longer hold the correct names.
To move to a new directory, you simply start Daqarta from that directory. EdSav always saves the log file to the current directory.
To make it easier to change the macro, make sure when you create it that the 'TESTDATA.*' text is invoked as a separate "nested" macro. Then you can change the series name simply by creating a new text macro assigned to the same ID.
Questions? Comments? Contact us!We respond to ALL inquiries, typically within 24 hrs.
25 Years of Innovative Instrumentation
© Copyright 1999 - 2006 by Interstellar Research