Multi-instrument behavior synchronization using jobs and milestones

Abstract

A method for synchronizing tasks in a test and measurement system, comprising: receiving a task input at a client in the system; receiving a call from the client at a job manager running on a first device processor in the system to create a job associated with the task; returning an action containing at least one job code block associated with the job to the client; receiving a call for the action; executing the at least one job code block by at least one processor in the system; determining that the job has completed; and completing the task. A device system comprises at least one test and measurement device and a device controller, the device controller having: at least one user input, a device controller processor configured to execute instructions, at least one memory storing data and storing instructions in the form of executable code, wherein the code causes the device controller processor to: receive input from a client, the input identifying a task; create a job associated with the task; return an action containing at least one job code block associated with the task to the client; receive a call for the action; determine that the job has completed; and notify the client that the job has completed.

Description

[0001] Related applications

[0002] This disclosure claims the benefit of U.S. Provisional Application No. 62 / 900,506, filed on September 14, 2019, entitled “MULTI-INSTRUMENT BEHAVIORSYNCHRONIZATION USING JOBS AND MILESTONES,” which is incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure relates to test and measurement instruments, such as oscilloscopes, and more particularly, to systems and methods for synchronizing the operation of multiple instruments. Background Art

[0004] The Standard Commands for Programmable Instruments (SCPI; often pronounced "skippy") protocol defines the syntax and command standards for controlling programmable test and measurement equipment. Two standard SCPI commands to be implemented on every device that supports SCPI are *OPC , which is an Operation Complete Query, and *WAI, which is a Wait to Continue command. These two standard commands, along with the *OPC command, are intended to be used by equipment controllers (such as computer-controlled automated test systems) to synchronize the execution of their programs with the actual operation of the device under test (DUT). This can be found in section 4.1.3.1 of the SCPI-99 specification.

[0005] However, it is well known in the test and measurement industry that due to the different and inconsistent implementations of SCPI in various test and measurement instruments, the instruments have different requirements for *OPC, *WAI and *OPC. Responses to commands do not behave in a predictable and reliable manner. For example, some instruments will return a response to an operation completion query indicating that the instrument has completed the operation when, in fact, the operation has not yet completed. Other instruments will actually complete an operation but will not return a timely response to the operation completion query. This inconsistent behavior causes many test engineers and other authors of device controller programs to insert various waits, delays, sleeps, and / or timeouts into their test programs to compensate for the different responses of the instruments. While these delays and timeouts are sometimes necessary for a test program to control some instruments, other times these delays and timeouts are irrelevant, inefficient, and result in an unnecessary reduction in the throughput of the automated test system, which can be a significant problem in a manufacturing plant.

[0006] Embodiments of the disclosed apparatus and methods address shortcomings in the prior art. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1An embodiment of a system having a device controller for synchronization is shown;

[0008] Figure 2 An embodiment of an operating environment is shown;

[0009] Figure 3 A flow chart illustrating an embodiment of a method of managing jobs in an operating environment;

[0010] Figure 4 A flow chart illustrating an embodiment of a method for managing job completion using milestones. DETAILED DESCRIPTION

[0011] In general, embodiments of the disclosed technology provide for synchronization of settings and data within an instrument, between multiple instruments, and between a device controller client program and one or more instruments. Embodiments also provide improved completion notification via the instrument's programming interface (PI) commands. This eliminates the need for delays, timeouts, or sleeps in automation code. This makes user testing more robust and significantly faster.

[0012] Figure 1 An embodiment of a system having a device controller that provides synchronization is shown. Figure 1 The embodiments shown herein illustrate multiple devices, but these embodiments can be implemented in a single device, where the single device can have one or more processors. The embodiments can be implemented in multiple devices, each of which can have one processor or multiple processors. The embodiments discussed herein are not intended to limit implementation in any way, and no limitation should be implied.

[0013] Figure 1 The system 10 shown in FIG has multiple devices 12, 14, 16, and 18, with potentially more devices. Each of these devices can be a test instrument, such as an oscilloscope, and one of the oscilloscopes can be designated as a device controller. Alternatively, and within the scope of the claims, one device can be a dedicated device controller that is not a test instrument, such as a general-purpose computing device, and in some cases, other devices can be connected to the dedicated device controller via a network.

[0014] For the purposes of this discussion, one of the devices 12 is a test instrument that also serves as a device controller. The device 12 may have at least one processor 20, a memory 22 for storing both code to be executed by the one or more processors and any data received by the device. The device 12 will have one or more ports, such as 24, that create a channel through which the device receives data, such as data from a test probe or signal generator. The device 12 may also have a network interface 26 that allows the device to connect to a network. Other devices 14, 16, 18 may connect to the device controller 12 via direct wired connections or wirelessly. The device 12 will typically have a user interface 28.

[0015] Many instrumentation systems use multithreading to execute more than one task at a time. The term "task" is used here to refer to an item of work to be completed. Tasks might include items such as the system adding a new measurement, displaying a waveform, and responding to mouse input simultaneously. These are tasks, and they can all occur simultaneously, but the threads handling each of these tasks may need to cooperate.

[0016] For example, when a user resets to factory defaults, the thread that sends settings to the hardware wants to send the new settings as a block. To do this, the thread must be warned when many new settings are to be calculated, and then be informed when the new settings are ready to be sent.

[0017] As used herein, the term "thread" refers to the smallest sequence of programmed instructions that can be independently managed by a scheduler. A thread is a component of a process. Multiple threads can exist within a processor. For the purposes of this discussion, each processor can execute on multiple threads, and threads can be transferred between processors within a device, or even between processors residing on two different devices. The embodiments herein improve the operation of computing devices, whether they are test and measurement equipment or general-purpose computing devices.

[0018] Figure 2 This provides a general overview of the environment in which the embodiments operate. Generally, the initial starting point for improved operation begins with a client 30, which has one or more threads 36 that generate calls to create jobs to complete tasks using the system. As will be discussed in more detail later, the client can be associated with an initiator 32, which is a parameter that identifies the client. This can be composed of a globally unique identifier (GUID) or a universally unique identifier (UUID). The following discussion will use a GUID 34.

[0019] The client thread can use a completion point (such as 58, which will be discussed in more detail later) to wait for the job to complete. Thread 36 generates a call to create the job at the job manager 38. The job manager can receive status requests from the client and use the GUID to track them.

[0020] The job manager facilitates collaboration by having jobs that threads can wait for. Jobs are used for specific tasks, such as calculating the new settings needed to reset to factory defaults. As a job progresses, many different threads may work on it. Other threads can wait for the job to complete. For example, a thread sending settings to hardware can wait for the new settings to be calculated first.

[0021] The programming interface also has a concept of operations that rely on waiting for a job to complete. For example, a programming interface user might add a new measurement, wait for the operation to complete, and then query that measurement. Such a user wants to ensure that the new measurement has actually been calculated based on valid data. This ability to wait for operation completion saves users time and money that would otherwise require delays in their PI test procedures.

[0022] A job 40 is an object associated with the task to be completed as discussed above. A client calls the job manager to create a new job. The client can then use the job object and share it with the rest of the system. As explained further below, a job has a number of associated job code blocks 42. If not all of these associated blocks have completed execution, the job is considered busy, as indicated by the busy attribute 44. Jobs are always busy when they are first created, and then become unbusy when all associated job code blocks have been executed and completed. Once a job becomes unbusy, it cannot be made busy again.

[0023] Jobs can also be completed or uncompleted, as shown by the completion attribute 46. To be completed, a job must not be busy. However, there are some additional requirements, as explained further below. Once a job becomes completed, it can never stop being completed. The intention is that all jobs will eventually become completed. Completion can be defined by a completion policy 48, which can involve one or more milestones 50.

[0024] The job completes with either success 54 or failure 56. The choice depends on how certain entry points associated with the job are called. Failure may have associated failure data, but success is simply the fact that there is no associated data. As discussed below, this may involve a completion point 58.

[0025] Clients can use the job object to find out whether the job is busy, completed, successful, or failed. Clients can also adjust the definition of completion for a job, as explained further below. Clients can register to be notified when a job completes, and can also wait until a job completes.

[0026] In an exemplary embodiment, the job code block can be a .NET System.Action. In other words, the job code block must be a C# delegate that has no parameters and returns void. Figure 1 environment, Figure 3 A flow chart illustrating an embodiment of the overall process is shown.

[0027] The client receives some kind of task input at 60. At 62, the client calls the job manager to create a job, and the client specifies a job code block for the job. The resulting job starts from this job code block in its job code block set.

[0028] As a job block executes, it may call the job manager to create another job block. In this case, the new job block is added to the job of the currently executing job block. The effect of this call is to extend the job to include the additional job block. These methods are the only ways to create job blocks. In particular, clients cannot add job blocks to a job from the outside.

[0029] When a client calls the job manager to create a job, the job manager also returns an action at 64. An example of this action can consist of a wrapped action, such as a .NET System.Action object with a job code block inside. The job manager does not automatically call the job code block on its own. Instead, at 66, the client, another thread, etc. must call the action, which invokes the job code block inside.

[0030] The client may choose to call the action directly. In one embodiment, another option may be to pass the wrapped action to a . NET System.Threading.Tasks.Task In any case, the job will remain busy at least until the action is called, and then execute the job code block at 68 and return.

[0031] When a job block extends a job, another job block is added by calling the job manager. The job manager returns an action, and the caller is responsible for arranging for that action to be called in one way or another.

[0032] This process can have several guidelines that allow for improvements in how it performs. For example, an action must be called exactly once; calling the action a second time will result in an error.

[0033] The job starts out busy and eventually becomes unbusy, with no possibility of becoming busy a second time.

[0034] Client code can control when and how job blocks are created, and can choose how to assign them to threads of execution.

[0035] The job manager considers that a thread may have an associated job. The job manager provides an entry point that returns the job associated with the calling thread. If there is no associated job, the entry point returns null. If a thread is currently executing a job's job block, then that job is the job associated with the thread at that moment. If the same thread later executes a different job's job block, the job associated with the thread changes to that second job. Therefore, a thread may have different jobs at different times, or even no job at all.

[0036] After determining that the job completion leading to task completion at 70 may take different paths. Figure 2 Jobs can include milestones. Milestones are provided by the job manager. A milestone represents a result of the job that results from collaboration with another non-job activity. For example, in a job that adds a new measurement, the user might want to indicate completion that the new measurement has been calculated. In this example, the job must collaborate with the subsystem that calculates the measurement. To separate the concerns between the job and the subsystem, it seems natural for the job to pass milestones, and the subsystem to use milestones to indicate when the new measurement has been calculated.

[0037] A milestone is always part of exactly one job. In one embodiment, a milestone can be categorized as a setup milestone or a data milestone. Other types of milestones may exist in the system, or new types may be created. A milestone begins as an unfinished milestone and becomes completed through success or failure.

[0038] The job manager provides an entry point for creating milestones. Milestones are always associated with the job of the calling thread. In other words, a job code block is executing and a milestone is created for its job. Here, this operation is described as the job publishing a milestone. In one instance, it may also happen that the calling thread has no associated job. In this case, the job manager generates a dummy milestone that has no effect. This arrangement eliminates the need for code to test whether it is executing from a job code block.

[0039] Since jobs can only publish milestones from within their job code block, only busy jobs can publish milestones. Once a job stops being busy, its milestone set cannot be changed. This property makes it easier to reason about job completion.

[0040] On the other hand, any code can complete a milestone by making it succeed or by making it fail. Once completed, a milestone ignores any further attempts to complete it and can never become uncompleted again.

[0041] Job failures occur in one of two ways. First, a client calls an entry point in the job manager to declare that the job associated with the caller's thread has failed. Such a client can optionally pass failure status data to be associated with the failure. It may happen that the caller's thread has no associated job. In this case, the call has no effect. This arrangement eliminates the need for code to test whether it is executing from a job code block. Second, a client calls a milestone method to declare that a milestone has failed, which causes the associated job to fail.

[0042] As mentioned above, a job can include a completion policy. The completion policy is the rule a job uses to determine when it completes. This policy is a property of the job. Different jobs can have different policies. When the job manager is called to create a job, the client must specify a completion policy. After the job is created, any client accessing the job object can change the job's completion policy.

[0043] All completion policies share the following rules. First, a failed job becomes completed immediately, regardless of whether it is busy or not. Second, no job can succeed until the job stops being busy.

[0044] In one embodiment, the client can specify one of three completion policies. First, set up The policy means that a job succeeds when it is no longer busy and all its set milestones have succeeded. Data how to run and set The policy means that a job succeeds when it is no longer busy, when all its setup milestones have succeeded, and when a collection is not running or otherwise all data milestones have succeeded. Third, Data and Settings Meaning that a job succeeds when it is no longer busy and when all of its setup and data milestones have succeeded. These are just examples of completion policies and are not intended to restrict to any particular completion policy, nor should any restrictions be implied.

[0045] The client can change the completion policy of a job, so the job may become completed even if other conditions have not changed. For example, when adding the measurement mentioned above, the job adding the measurement can select Data how to run and setHowever, if the code finds that only reference waveforms are implicated, it may decide to change the policy to Data and Settings , so that measurements are persisted even when acquisition is not running. Figure 4 A flow diagram illustrating an embodiment of a process for managing job completion using milestones is shown.

[0046] At 80, the job manager receives a call from the client that specifies the completion policy and provides a GUID as part of the initiator parameters. As discussed above, at 82, the job manager provides entry points for any milestones. The job manager then monitors the milestones at 84. The job manager receives notification that a milestone has completed. As previously discussed, the client can change the completion policy at 86, so the job manager tracks milestones to ensure that either the data milestone or the setup milestone is completed. For example, if the client has changed the completion policy at 86 and the setup milestone is completed, the job manager can mark the job as successful at 88 and then complete at 90. Even if the job fails, it will be marked as completed.

[0047] Even if the client does not change the completion policy, and all milestones complete, the job manager will determine success at 86 and then complete the job at 88 .

[0048] Once a job becomes complete for any reason, it cannot become incomplete again. Furthermore, a failed job cannot succeed again, and a successful job cannot fail again. Jobs can also be partially completed. For example, suppose a job publishes both a setup milestone and a data milestone. One might want to wait only for the setup milestone in one place, whereas final completion implies the completion of both milestones. Partial completion addresses the first scenario, where only the setup milestone is awaited.

[0049] In a partial completion, the client specifies which milestones to include. When the job is no longer busy and all milestones of the specified type have been completed, the job is considered partially completed. A job that has failed is also considered partially completed.

[0050] Another means of managing completion involves the use of "completion points," an abstract data type provided by the job manager. Completion points represent the ability to wait for a job, or sometimes several jobs, to complete or partially complete. Completion points also allow for testing for completion without waiting.

[0051] Completion points can be job- or client-dependent. For example, a client can retrieve a completion point from a job object. In this case, the completion point only waits for that job. In another embodiment, a client can query the job manager to wait for the completion points of all jobs created by the client up to the time of the query. In this case, the completion point waits for the completion or partial completion of all of the client's jobs in a single operation.

[0052] Because completion points may depend on the client, the job manager must keep track of its clients. To this end, when a client creates a job, it must identify itself using the initiator parameter mentioned above. In these embodiments, this initiator parameter consists of a globally unique identifier (GUID) chosen by the client. Later, when the client calls the job manager to obtain the completion points of all jobs to date, the client again identifies itself by passing the initiator parameter. The job manager can meet the client's requirements because it keeps track of the initiator of each job.

[0053] When a client waits for the completion of all jobs so far, the concept of completion for each of those jobs depends on the completion policy for that particular job. Therefore, in this case, completion can mean different things for different jobs in the collection. On the other hand, if a client waits for partial completion of all jobs so far, then partial completion means the same thing for each job in the collection.

[0054] In this way, system performance can be improved by adding a job manager to manage client requests and coordinate operations in the system. This eliminates or reduces the need to build in delays or pauses in processing, and the guesswork that can involve. In the example given above, where a user wants to add a new measurement, instead of having to build in a delay for the new measurement and not being able to confirm that the measurement has completed, the job manager in this system will complete the job for the new measurement and then notify the system that the job has completed, thus ensuring that the measurement is calculated based on valid data.

[0055] Examples of the present disclosure can operate on specially created hardware, firmware, a digital signal processor, or a specially programmed general-purpose computer including a processor operating according to programmed instructions. As used herein, the terms "controller" or "processor" are intended to include microprocessors, microcomputers, ASICs, and dedicated hardware controllers. One or more aspects of the present disclosure can be embodied in computer-usable data and computer-executable instructions, such as in one or more program modules executed by one or more computers (including monitoring modules) or other devices. Generally, program modules include routines, programs, objects, components, data structures, and the like that, when executed by a processor in a computer or other device, perform specific tasks or implement specific abstract data types. Computer-executable instructions can be stored on non-transitory computer-readable media, such as a hard disk, an optical disk, removable storage media, solid-state memory, electrically erasable programmable read-only memory (EEPROM), random access memory (RAM), and the like. As will be appreciated by those skilled in the art, the functionality of the program modules can be combined or distributed as desired in various examples. Furthermore, the functionality can be embodied in whole or in part in firmware or hardware equivalents, such as integrated circuits and field-programmable gate arrays (FPGAs). Certain data structures may be used to more efficiently implement one or more aspects of the present disclosure, and such data structures are contemplated as being within the scope of the computer-executable instructions and computer-usable data described herein.

[0056] Aspects of the present disclosure operate in various modifications and alternative forms. Specific aspects have been illustrated by way of example in the accompanying drawings and described in detail below. However, it should be noted that the examples disclosed herein are presented for the purpose of clarity of discussion and, unless expressly limited, are not intended to limit the scope of the general concepts disclosed to the specific examples described herein. As such, the present disclosure is intended to cover all modifications, equivalents, and alternatives of the described aspects, in accordance with the accompanying drawings and claims.

[0057] References in the specification to embodiments, aspects, examples, etc. indicate that the items described may include a particular feature, structure, or characteristic. However, each disclosed aspect may or may not include a particular feature, structure, or characteristic. Furthermore, unless otherwise indicated, such statements do not necessarily refer to the same aspect. Furthermore, when a particular feature, structure, or characteristic is described in conjunction with a particular aspect, such feature, structure, or characteristic may be used in conjunction with another disclosed aspect, regardless of whether such feature is explicitly described in conjunction with such other disclosed aspects.

[0058] In some cases, the disclosed aspects may be implemented in hardware, firmware, software, or any combination thereof. The disclosed aspects may also be implemented as instructions carried by or stored on one or more non-transitory computer-readable media, which may be read and executed by one or more processors. Such instructions may be referred to as a computer program product. As discussed herein, computer-readable media refers to any medium that can be accessed by a computing device. By way of example and not limitation, computer-readable media may include computer storage media and communication media.

[0059] Computer storage media refers to any medium that can be used to store computer-readable information. By way of example, and not limitation, computer storage media may include random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital video disc (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, and any other volatile or nonvolatile, removable or non-removable media implemented in any technology. Computer storage media does not include signals themselves or transitory forms of signal transmission.

[0060] Communication media refers to any medium that can be used to communicate computer-readable information. By way of example, and not limitation, communication media can include coaxial cables, fiber optic cables, air, or any other medium suitable for communication of electrical, optical, radio frequency (RF), infrared, acoustic, or other types of signals.

[0061] Example

[0062] Illustrative examples of the disclosed technology are provided below. Implementations of the technology may include one or more of the examples described below, and any combination of the examples.

[0063] Example 1 is a method for synchronizing tasks in a test and measurement system, comprising: receiving task input at a client in the system; receiving a call from the client at a job manager running on a first device processor in the system to create a job associated with the task; returning an action to the client containing at least one job code block associated with the job; receiving a call for the action; executing at least one job code block by at least one processor in the system; determining that the job has been completed; and completing the task.

[0064] Example 2 is the method of Example 1, wherein the first device processor resides in a controller device and the at least one processor in the system resides on a test and measurement device in the system.

[0065] Example 3 is the method of any of Examples 1 or 2, wherein the call from the client includes a completion policy, and determining that the job has completed includes determining whether the completion policy has been satisfied.

[0066] Example 4 is the method of example 3, wherein the completion policy is satisfied by one of a job failure or a job success.

[0067] Example 5 is the method of Example 4, wherein job success occurs when the job is no longer busy and one of the following is met: all setup milestones have succeeded; all setup milestones have succeeded and one of data collection has not occurred or all data milestones have succeeded; and all setup milestones and data milestones have succeeded.

[0068] Example 6 is the method of any of Examples 1-4, wherein executing at least one job code block includes creating at least one additional job code block.

[0069] Example 7 is the method of any of Examples 1-5, further comprising passing the action from the client to a different thread within the same processor or one of threads within different processors in the system.

[0070] Example 8 is the method of any of Examples 1-6, wherein executing at least one job code block comprises issuing a milestone having a unique identifier, the milestone to be completed outside of a job associated with the at least one job code block.

[0071] Example 9 is the method of example 8, further comprising receiving a notification that the milestone has been completed.

[0072] Example 10 is the method of Example 8, wherein the unique identifier is provided to the job manager, and the job manager tracks the milestone by the unique identifier of the milestone across multiple devices.

[0073] Example 11 is a device system comprising at least one test and measurement device and a device controller, the device controller comprising: at least one user input; a device controller processor configured to execute instructions; at least one memory for storing data and storing instructions in the form of executable code, wherein the code causes the device controller processor to: receive input from a client, the input identifying a task; create a job associated with the task; return an action to the client containing at least one job code block associated with the task; receive a call to the action; determine that the job has been completed; and notify the client that the job has been completed.

[0074] Example 12 is the system of Example 11, wherein the device controller processor comprises one of: one or more processors in the device controller separate from the test and measurement device, or one or more processors in the test and measurement device.

[0075] Example 13 is the system of example 11 or 12, further comprising at least one processor in the system other than the device controller processor that executes the at least one job code block.

[0076] Example 14 is the system of Example 13, wherein the at least one processor comprises a plurality of processors, and the at least one job code block is partially executed by more than one processor of the plurality of processors.

[0077] Example 15 is the system of Example 13, wherein the at least one processor includes multiple threads, or the at least one processor includes multiple processors with at least one thread, and the at least one processor that executes the at least one job code block includes multiple threads that execute the at least one job code block.

[0078] Example 16 is a non-transitory storage medium comprising a computer program product comprising instructions that, when executed by at least one processor in a test system, cause the at least one processor to: receive a task based on user input from a client; perform one or more operations to convert the task into a job; return an action to the client containing at least one job code block associated with the job; receive a call to the action; cause at least one processor in the test system to execute the at least one job code block; determine that the job has been completed; and complete the task.

[0079] Example 17 is the storage medium of example 16, wherein the task has an associated completion policy, and determining that the job has been completed comprises determining whether the completion policy has been satisfied.

[0080] Example 18 is the storage medium of any of Examples 17, wherein the completion policy is satisfied by one of a job failure or a job success.

[0081] Example 19 is the storage medium of Example 18, wherein job success occurs when the job is no longer busy and one of the following is satisfied: all setup milestones have succeeded; all setup milestones have succeeded and one of data collection has not occurred or all data milestones have succeeded; and all setup milestones and data milestones have succeeded.

[0082] Example 20 is the storage medium of any of Examples 16-19, wherein execution of the at least one job code block includes issuing a milestone having a unique identifier, the milestone to be completed outside of a job associated with the job code block.

[0083] Although particular embodiments have been illustrated and described for purposes of illustration, it will be appreciated that various modifications can be made without departing from the spirit and scope of the present disclosure. Therefore, the present invention is not to be limited, except as in the appended claims.

Claims

1. A method for synchronizing tasks in a test and measurement system, comprising: receiving a task input at a client in the system; receiving, at a job manager running on a first device processor in the system, a call from a client to create a job associated with a task; returning an action containing at least one job code block associated with the job to the client; receiving a call for the action; executing the at least one job code block by at least one processor in the system; confirming that the operation has been completed; and Complete the task, Wherein the call from the client includes a completion policy, and determining that the job has been completed includes determining whether the completion policy has been satisfied. 2 . The method of claim 1 , wherein the first device processor resides in a controller device and the at least one processor in the system resides on a test and measurement device in the system. The method of claim 1 , wherein the completion policy has been satisfied by one of a job failure or a job success.

4. The method of claim 3, wherein job success occurs when the job is no longer busy and one of the following is satisfied: all setup milestones have succeeded; all setup milestones have succeeded and one of data collection has not occurred or all data milestones have succeeded; and all setup milestones and data milestones have succeeded. The method of claim 1 , wherein executing the at least one job code block comprises creating at least one additional job code block.

6. The method of claim 1, further comprising passing the action from the client to one of a different thread within the same processor or a thread within a different processor in the system.

7. The method of claim 1, wherein executing the at least one job code block comprises issuing a milestone having a unique identifier, the milestone to be completed outside of the job associated with the at least one job code block. The method of claim 7 , further comprising receiving notification that a milestone has been completed.

9. The method of claim 7, wherein the unique identifier is provided to the job manager, and the job manager tracks the milestone via its unique identifier across multiple devices.

10. An equipment system comprising at least one test and measurement device and an equipment controller, the equipment controller comprising: at least one user input; a device controller processor configured to execute instructions; and at least one memory for storing data and storing instructions in the form of executable code, wherein the code causes the device controller processor to: receiving an input from a client, the input identifying a task; creating a job associated with the task; Returning to the client an action containing at least one job code block associated with the task; receiving a call for the action; confirming that the operation has been completed; and The client is notified that the job has been completed, wherein the device controller processor comprises one of the following: one or more processors in a device controller separate from the test and measurement device or one or more processors in the test and measurement device.

11. The system of claim 10, further comprising at least one processor in the system other than the device controller processor that executes the at least one job code block.

12. The system of claim 11, wherein the at least one processor comprises a plurality of processors, and the at least one job code block is executed in part by more than one processor of the plurality of processors.

13. The system of claim 11, wherein the at least one processor includes a plurality of threads, or the at least one processor includes a plurality of processors having at least one thread, and the at least one processor that executes the at least one job code block includes a plurality of threads that execute the at least one job code block.

14. A non-transitory storage medium comprising a computer program product, the computer program product comprising instructions that, when executed by at least one processor in a test system, cause the at least one processor to: Receive tasks based on user input from the client; performing one or more operations to convert the task into a job; returning an action containing at least one job code block associated with the job to the client; receiving a call for the action; causing at least one processor in the test system to execute the at least one job code block; confirming that the operation has been completed; and The task is completed, wherein the task has an associated completion policy, and determining that the job has been completed includes determining whether the completion policy has been satisfied.

15. The non-transitory storage medium of claim 14, wherein the completion policy has been satisfied by one of a job failure or a job success.

16. The non-transitory storage medium of claim 15, wherein a job success occurs when the job is no longer busy and one of the following is satisfied: all setup milestones have succeeded; all setup milestones have succeeded and one of no data collection has occurred or all data milestones have succeeded; and all setup milestones and data milestones have succeeded.

17. The non-transitory storage medium of claim 14, wherein execution of the at least one job code block includes issuing a milestone having a unique identifier, the milestone to be completed outside of the job associated with the job code block.

Images