The present teachings are best understood from the following detailed description when read with the accompanying drawing figures. The features are not necessarily drawn to scale. Wherever practical, like reference numerals refer to like features.
In the following detailed description, for purposes of explanation and not limitation, illustrative embodiments disclosing specific details are set forth in order to provide a thorough understanding of the present teachings. Moreover, descriptions of well-known devices, hardware, software, firmware, methods and systems may be omitted so as to avoid obscuring the description of the illustrative embodiments. Nonetheless, such hardware, software, firmware, devices, methods and systems that are within the purview of one of ordinary skill in the art may be used in accordance with the illustrative embodiments. Finally, wherever practical, like reference numerals refer to like features.
The detailed description which follows presents methods that may be embodied by routines and symbolic representations of operations of data bits within a computer readable medium, associated processors, microprocessors, digital storage oscilloscopes, general purpose personal computers, manufacturing equipment, configured with data acquisition cards and the like. In general, a method herein is conceived to be a sequence of steps or actions leading to a desired result, and as such, encompasses such terms of art as “routine,” “program,” “objects,” “functions,” “subroutines,” and “procedures.”
The apparatuses and methods of the illustrative embodiments are described in implementations in a measurement system including one or more testing devices (e.g., oscilloscopes, waveform generators and logic analyzers). Machines that may perform the test functions according to the present teachings include those manufactured by such companies as AGILENT TECHNOLOGIES, INC., HEWLETT PACKARD, and TEKTRONIX, INC. as well as other manufacturers of test and measurement equipment.
However, the apparatuses and methods of the present teachings are more broadly applicable. For illustrative purposes, it is contemplated that the present teachings are applicable to computers, sensors, actuators, robotics, mobile phones and other technologies that require synchronization and relative timing of actions, or the absolute timing of actions, or both. Notably, the methods and apparatuses of the present teachings are contemplated for use in automated manufacture and assembly.
With respect to the software useful in the embodiments described herein, those of ordinary skill in the art will recognize that there exist a variety of platforms and languages for creating software for performing the procedures outlined herein. Certain illustrative embodiments can be implemented using any of a number of varieties of operating systems (OS) and programming languages. For example, the OS may be a commercially available OS from Microsoft Corporation, Seattle, Wash., USA, or a Linux OS. The programming language may be a C-programming language, such as C++, or Java.
In accordance with certain embodiments described herein, a graphical programming editor is implemented in Java. Moreover, the compiler is implemented in Java as well. However, those of ordinary skill in the art also recognize that the choice of the exact platform and language is often dictated by the specifics of the actual system constructed, such that what may work for one type of system may not be efficient on another system. In other applications, the choice of platform and language(s) are merely the choice of the implementer, with many fungible alternatives.
The selection of a computer with a display to illustrate certain features of the present teachings is merely illustrative. In particular, the ICS 101 is portrayed as a personal computer or other similar terminal. The present teachings contemplate the ICS 101 implemented in other known devices. For example, the ICS 101 may be a portable computer, a portable digital assistant (PDA) or even a mobile telephone. Naturally, these alternative ICSs will include the requisite hardware, software and, if needed, firmware, to function in accordance with the present teachings. In many instances, present portable computers, PDA and mobile phones include such hardware and software, or will likely in the future, given the predictions of Moore's Law.
The devices 102 may be test equipment, such as oscilloscopes, optical interferometer measurement devices and logic analyzers. As noted this is merely illustrative of the application of the GUI of the illustrative embodiments. As required, some or all of the devices 102 may be connected together and some or all of the devices 102 may be connected only to the ICS 101. Such configurations are dictated by the application and are not discussed more fully to avoid obscuring the description of the embodiments.
As noted, the devices 102 may accept commands, or may be adapted to have code downloaded thereto, or may be adapted for both. Commands and/or programs may be communicated to the devices 102 via a communication channel. The devices 102 may send data to other devices 102 or ICS 101 via communication channels.
An example of a device 102 that accepts commands is an Agilent 33220A function generator. Like many test instruments, the Agilent 33220A function generator can be configured and operated using Standard Commands for Programmable Instrumentation (SCPI) commands sent over a communication channel from another device 102 or ICS 101. The Agilent 33220A function generator can also be configured and operated via IVI (Interchangeable Virtual Instrument) driver software running on a computer such as ICS 101.
Examples of devices 102 that allow for having code downloaded include, but are not limited to some computers and some mobile phones. For example, some mobile phones allow Java code to be downloaded to them to extend their capabilities.
Notably, the devices 102 that are programmable are not necessarily the same and thus the compiler is adapted to translate the graphical program into the respective target code for each respective target device 102. Moreover, instead of, or in addition to providing executable code to external devices (e.g., devices 102), the ICS 101 may provide executable code for coordination of activities and correlation of data of its functions. Moreover the executable code running on ICS 101 or a device 102 may configure or operate other devices 102 via commands or drivers (as in the case of controlling an Agilent 33220A function generator).
The ICS 101 is connected to the device(s) 102 via a wired, wireless or fiber-optic link. The link between the ICS 101 and the device 102 may be through one of a variety of standards/protocols known to those skilled in the art. For example, the link may be a local area network (LAN), a wide area network (WAN), or a wireless local area network (WLAN) to name only a few possible configurations. One skilled in the art will appreciate that one or more of a variety of standards/communications protocols may be used to implement the LAN, WAN or WLAN. It is also contemplated that the link between the ICS 101 and device(s) 102 may be carried out via a General Purpose Interface Bus (GPIB) as defined by IEEE 488, or via Universal Serial Bus (USB), or via IEEE 1394.
The inputs to the timing and control elements may be selected from a drop-down menu(s), input via a “wizard” dialog sequence, or provided as a dedicated input in the field or region 201. In an illustrative embodiment the specification of a start time literal (absolute) value would be human readable and could be based on International Standard ISO 8601. Provision is made so that the start and duration times can be expressions that reference program variables. The duration time is a logical constraint on its associated frame that can either specify that the frame has an exact duration or a duration less than some value. For example, if the duration is given as “5 ms” or “=5 ms”, then the duration of the frame is exactly 5 ms, whereas, if the duration is given as “<5 ms” then the duration of the frame can be any period of time less than 5 ms.
A synchronization edge 202 is also shown in the frame 200. As described more fully herein, the synchronization edge 202 allows the user to select and attach certain functions to occur beginning at the same time. The frame 200 includes a frame interior 203 in which one or more graphical programming element (GPE) 204 may be provided.
In the presently described embodiment, GPEs 204 are associated with a computation, procedure, function, programming control construct, graphical programming construct, event or action. An example of GPEs that could be included are the blocks and constructs of the Agilent VEE graphical programming language. In general, the GPEs of the illustrative embodiments include a variety of graphical constructs, other than a synchronization edge, that can be attached to a synchronization edge or placed in the interior of the frame. For example, a frame sequence, which is one or more frames in a horizontal row, is also a GPE of illustrative embodiments. GPEs of the illustrative embodiments may be provided in frames via drop down menus, moveable icons, pallets of moveable icons, and other similar methods implemented via the graphical program of the illustrative embodiments.
The frames 301 includes an initialization test element (Init Test) 302, which is followed by a first synchronization edge 303 to which a trigger switch GPE 304 is attached. The frames 301 may also include timing elements that often specify, inter alia, start times (start field), duration of a frame (duration field), as described above. For example, the frame containing trigger switch GPE 304 includes a timing element 305 having a specified duration. Moreover, the frames 301 optionally include one or more control elements that allow control constructs to be associated with a frame.
In the illustrative embodiment, the timing element 305 has a duration of 5.0 ms. It is contemplated that the time duration of a timing element may be specified to occur in less than a finite duration of time (e.g., <5.0 ms). In addition, if there is no duration specified, the associated frame may take as much time as is necessary to complete.
A second synchronization edge 306 follows on the termination of the timing element 305. The edge 306 has a trigger ARB GPE 307. (As is known, a trigger arbitrary waveform generator is often referred to as a trigger ‘ARB.’) and a trigger digitizer GPE 308 attached thereto. As such, 5.0 ms after the initiation of the first synchronization edge 303, the ARB and digitizer are simultaneously initiated.
A Next Switch Configuration GPE 309 is provided after the commencement of the GPEs 307,308 and a Read Digitizer GPE 310 follows the completion of GPE 308. As shown, a timing element 311 having a duration of 2.0 s is provided and specifies the time allotted for the completion of GPEs 307-310. A control element 312 is provided that requires the test sequence beginning with the trigger switch GPE 304 and terminating with the expiration of the duration of timing element 311 to be repeated five (5) times.
In the presently described embodiment, timing elements 313 have an unspecified duration field. As such, the corresponding frame terminates when all of the GPEs in the frame terminate. A check pass/fail GPE 314 is provided in one of the frames 301 as shown. Thus, after the quintuple repetition of the steps described above, the check pass/fail sequence is initiated.
However,
At step 401 in
Using similar operations, at step 403, the user optionally specifies start times and duration times in the start fields and duration fields, respectively, of the timing elements of the frame or frames of the frame sequence constructed in steps 401,402. The culmination of the constructs to this point is shown as frame 405 and includes a synchronization edge and a duration GPE of 2.0 ms.
At step 404, the user optionally specifies one or more control elements with one or more frames of the frame sequence. As noted previously, a frame can have zero or more control elements associated with it. A control element enables control constructs to be associated with a frame.
Frames 406-410 illustrate how some common programming language control constructs would be associated with a frame. It is emphasized that the frames described are merely illustrative and that frames to carry out other functions known to those skilled in the art are contemplated.
Frame 406 shows a REPEAT control field. The REPEAT control field specifies that the frame should be repeated 5 times before starting the next frame. There is also a duration of 2 ms associated with the frame. Each repetition of the frame is specified to take 2 ms.
Frame 407 illustrates a WHILE control field attached to a frame. The WHILE control field specifies that the frame should be repeated as long as the value of the program variable X is less than 10.
Frame 408 illustrates a CASE control field attached to a frame. The CASE control field determines whether the frame is executed. If the Boolean expression following the keyword CASE is true then the frame is executed, otherwise the frame is skipped and the next frame is considered for execution. Frame 408 is executed if the program variable X is greater than zero.
Frame 409 illustrates both CASE and REPEAT control fields attached to a frame. Each repetition of the frame evaluates the CASE control to determine whether it should execute.
Frame 410 illustrates a FOR control field attached to a frame. The FOR control field corresponds to the conventional FOR loop programming construct found in Pascal or Visual Basic. The frame is repeated until the program variable I is greater than program variable N. Each time the frame is repeated, the value of I is updated and made available to the contents of the frame.
The present teachings contemplate that more than one GPE may be attached to an edge via applications of steps 411 through 413. A frame 415 shows the culmination of the graphical construct to this point in the method with the GPE added to a frame that already had a GPE (crosshatched in the figure) attached to its synchronization edge.
The query construct is useful for obtaining information associated with the synchronization edge of the frame. For example, the information could be the absolute time associated with the edge or success/failure/status information about the timing of the previous frame or synchronization at the edge. The query construct obtains the information and assigns the information to a program variable or places the value on its output port. More than one such query construct may be attached to a single edge.
The execution constraints of frame 432 are specified in a known dataflow notation where lines interconnecting GPEs are used to specify data dependency relationships. Some illustrative execution sequences for the plurality of GPEs in the dataflow diagram in
In accordance with the certain illustrative embodiments, the temporal sequence of the GPEs corresponds to the ‘left to right’ order on the display and at their respective horizontal level. However, except for GPEs attached to a synchronization edge, there is no temporal correlation of GPEs at different vertical levels of a frame. In addition, in the embodiments in which a timing element specifying a duration time is provided, the GPEs of the frame are constrained to all complete within a specified time of the start of the frame, and after the synchronization edge. In addition, the elements must obey the execution constraints implied by dataflow dependencies or other explicit or implicit control mechanisms.
The method includes compiling the graphical program with a compiler of the graphical programming editor into an intermediate code such as C or C++ and then subsequently compiling the intermediate code into executable target code (e.g., machine language) for each of the respective devices 102, using different compilers for different executable targets. The method can be adapted to work with devices that are configured to execute with either software or firmware (for example, field programmable gate arrays (FPGAs)), or a combination of the two. In the case of firmware, VHDL or Verilog may be generated as intermediate code, and executable code would be generated using the conventional synthesis, place and route tool chain.
At step 501, the graphical programming editor receives user input that assembles a graphical program based on the GPEs, synchronization edges, timing elements, control elements and other components of the frames constructed via the methods of
At step 504, the ICS 101 or graphical programming editor receives a user input specifying that the digital format of the graphical program stored in step 503 is to be compiled into target code(s) for the ICS 101 and the devices 102 of the system 100. The ICS 101 then compiles the graphical program. In a programming environment, typically a framed sequence would be input to the compiler, which would generate code (software or firmware) for a target networked distributed system consisting of several hardware devices and software components (e.g. different instruments, microprocessors, communications hardware, and operating systems). With respect to frame sequences, the compiler has two primary objectives:
1. For elements attached to synchronization edges, the messages that schedule the events corresponding to the synchronization edge must be sent and received before the scheduled time of the events. The compiler generates code to send the messages and check their timely receipt;
2. Generate code to notify the program if the execution of a frame exceeds its duration time.
Notably, known graphical programming and simulation systems usually have a construct for defining a new composite block in terms of other blocks and graphical constructs. In Simulink this definitional construct is called a subsystem, in Ptolemy, the definitional construct is called a composite actor; and in LabVIEW the definitional construct is called a subVI. The corresponding construct in textual programming languages such a C is called a procedure. In LabVIEW, for example, once a subVI is defined, the construct can be used many times in other parts of the program and can be used by other subVIs to an arbitrary nesting depth.
Notably, frames can “share” a synchronization edge and that these shared edges are treated as a single edge. An example of this occurs in
A compiler for the framed sequence construct may ensure that the specified behavior is met by the generated code or the compiler may simply make a “reasonable effort.” For illustrative purposes, a “reasonable effort” compiler is briefly described. To aid debugging and tuning, a reasonable effort compiler generates code that notifies the program if there is a synchronization or timing failure. (Note that even in the case where a compiler can ensure that the specified behavior is met, a hardware failure could result in a synchronization or timing failure).
It is comparatively straightforward to generate target code for item number 2 above. It is also straightforward to generate target code that detects a timing or synchronization failure for item number 1 above.
Suppose that Fn and Fn+1 are consecutive frames in a frame sequence. In an embodiment, code is generated that sends a message to schedule an event associated with the synchronization edge of frame Fn+1. The code is generated so that the message is sent when all of the blocks contained in frame Fn have executed. This ensures that the sent message will not overwrite any pending messages. The code that checks for timely receipt and possibly retries the message send is also generated. This code generation method may fail to send the scheduled event message in time. A more sophisticated analysis by the compiler would analyze resources in order to determine if the message could be sent earlier.
At step 505, the target code is optionally saved in the persistent storage device of the ICS 101 and at step 506 the target code is deployed via the network to respective devices 102. It is contemplated that rather than continue with step 506 on the ICS 101 in which the graphical program was created, the program stored in the persistent storage device (e.g., disc) may be removed from the ICS and executed in another ICS 101. Finally, commands are provided at step 507 to execute the code to perform the designated actions or processes.
Note that a corresponding textual version of the graphical framed sequence construct could also be defined. An example Lisp-like syntax for a frame-sequence is:
(timed-sequence (timed-frame start duration <synchronized-statements><unsynchronized-statements>) . . . )
where <synchronized-statements> and <unsynchronized-statements> are lists of statements, and frame-sequence is a member of statements.
In view of this disclosure it is noted that the various methods and devices described herein can be implemented in hardware and software. Further, the various methods and parameters are included by way of illustrative only and not in any limiting sense. While certain useful aspects of the GUI of the illustrative embodiments have been described, there are clearly modifications that will be apparent to one of ordinary skill in the art having had the benefit of the present disclosure. For example, the width and height of a frame may be expanded or contracted to accommodate more or fewer GPEs, timing elements and control elements. In view of this disclosure, those skilled in the art can implement the present teachings in determining their own techniques and needed equipment to implement these techniques, while remaining within the scope of the appended claims.