Not a member? Register Now
Sales & Support: 1.800.377.6329
Register for full access to Galil's on-line tutorials, product manuals, downloads, and more.
The Accelera motion control family is Galil's latest generation of ultra-highspeed controllers. Now the Accelera series is even more powerful with the release of new firmware (DMC-40x0 firmware 1.0b and DMC-18x6 firmware 1.0c). This release introduces two powerful new controller features:
A host PC in charge of managing an application has a lot of tasks to balance. Motion supervision is just one in a large list of possible chores. From data analysis, PLC management, computer vision, safety monitoring, user interface, and data logging tasks, the more autonomous the motion control aspects can be, the better. All Galil controllers support a fullfeatured firmware and an embedded program space that allows the digital motion controller (DMC) to run independently on Galil's embedded real-time operating system.
This autonomous operation is at the foundation of stand alone Galil applications which do not employ a PC. But what about the applications where a PC is central to the management of the application? When a PC is responsible for machine management, the communication between a PC and the DMC is critical.
As an example, consider an application where a frame grabber provides image data to a computer vision application. The PC uses image analysis algorithms to derive position data which is then dispatched to the motion controller. Galil controllers contain motion buffers which allow position data to be pushed to the controller by the host and then used when needed by the DMC. As with any buffer application, the buffer needs to be filled by the PC when needed to avoid a buffer underrun condition. Sending data too soon, however, can result in a buffer overrun condition. How then should the PC decide when to send more data? There are two general methods:
Galil provides buffer operands which indicate how much space remains in the various motion buffers. The PC can poll for this data in a loop, waiting for the available number to be sufficiently large to indicate a new burst of data. Polling is an inefficient method for determining a change in state, however, as each polled value which does not yield a decision to proceed is unnecessary overhead on the PC's microprocessor, the communication bus, and the DMC's microprocessor (Figure 1).
Figure 1: Polling is very inefficient. In this example, only 1 in 5 polls provides new information.

An efficient, high-performance method of communication uses the concept of an interrupt signal to tell the PC when to send more data. Using this method is 100% efficient, in that no overhead communication is required to maintain the buffering (Figure 2).
Figure 2: Interrupts release the host and the DMC from servicing polling.

Interrupts are a fundamental hardware feature on the PCI bus. Galil's PCI controllers, such as the DMC-18x6, have always had interrupt support. By specifying which interrupts should be generated with the EI command, the controller will automatically interrupt the host PC when the specific event occurs. User interrupts (UI) are also provided to allow DMC code to trigger interrupts directly from embedded code.
Revision 1.0b of the DMC-4000 firmware has ported this interrupt functionality to Ethernet. The interrupt signal is a UDP packet dispatched on the event instead of a discrete digital output on the PCI bus. This difference is abstracted away from both the DMC programmer and the Host programmer with identical syntax from DMC code and identical function calls in the GalilTools programming API, interrupt(). http://www.galilmc.com/support/manuals/galiltools/library.html#interrupt
In addition to 16 unique user interrupts callable directly from embedded DMC code, the firmware can be configured to automatically generate interrupts on the following events as shown in Code 1.
A very common procedure is for the host PC to command a move, sleep until the move is completed, during which other threads can fully utilize the processor(s), and then command another move once the DMC is complete.The example shown in Code 2 is a C++ example demonstrating this using either Ethernet or PCI interrupts to optimize the communication overhead while still delivering optimal performance.
Code 1: Interrupt Events, excluding user definable Interrupts (UI)

Code 2: C++ example snippet of interrupt driven synchronization between DMC and host.

The Galil programming language, while simple and easy to learn, provides a very powerful interface to the underlying hardware. Features and abstraction techniques such as variable axes, multithreaded program design, automatic subroutines (similar to Events in Microsoft languages), and a program stack have made DMC code a formidable tool in motion application development, often holding its own to general purpose, higher-level languages. Now a new feature added to the DMC program stack has further increased the power of Galil's programming language.
To understand the concept of a program stack, consider the following analogy. Imagine you're making a salad. You chop lettuce, carrots, onions, olives, and so on and mix them into a large bowl. Now you need to make the dressing; taking a separate bowl and mixing olive oil, balsamic vinegar, and salt and pepper together to form vinaigrette. Only after the dressing is mixed, is it ready to be served with the salad. A separate bowl was used to create the dressing, and then the results of that bowl were returned to the salad. If your friend didn't like vinaigrette, you might use another bowl to mix up a ranch dressing.
A program stack works in a similar fashion. The main code (the salad) can call other code (the dressing bowl) to be run. When that code is finished (dressing complete), the stacked code returns program execution back to the main code (salad preparation continues). Often times information can be sent from the main code to the stack code to allow it to know how to proceed (e.g. make vinaigrette or ranch dressing), and the results of the stack code can be returned to the main code when ready (finished dressing). Like with various mixing bowls, the same general algorithm (mixing dressings), can be customized with passed values (ranch or vinaigrette), and can even be run simultaneously in multiple threads (extra chefs).
Galil has traditionally had a program stack which provided for calling code from the main code, and returning to the main code after completion. This was accomplished using the jump to subroutine command (JS). The newest Accelera firmware takes JS one step further by allowing the main code to pass parameters to the program stack, and allowing the stack to pass a return value back. This allows for powerful code reuse and code abstraction techniques in DMC code.
To start with a simple example, consider the case where multiple arrays are constantly being dimensioned and deallocated in a dynamic data processing application. When a Galil array is dimensioned, the array values are not zeroed. This means that stale data remains in the array memory even after old arrays are deallocated, similar to C data. A common procedure when allocating arrays would be to zero the array elements before use. _ is would ensure that no stale data is present while working with arrays.
In Code 3, the stack is used to make this a very easy and efficient operation. The array is passed to the function, along with the index of where to start zeroing. The function then zeros the array from the starting index to the end, and then returns the last array zeroed, effectively the length of the array. This function is general purpose as any size array can be passed, with any array name.
Code 3: Simple array zeroing example using the stack.

To highlight some of the powerful subtleties of the new stack, consider Figure 3, in which the program stack is used to count up the numbers between a starting number, a, and an ending number b, and then count back down from b to a. The counting algorithm used by each stack is always the same, shown in Code 4. Each stack examines the values of a and b passed to it. If the values are equal, the counting up is complete, and it simply returns b-1 to the stack below it to begin the counting down procedure. If a>b, then the stack prints the current count and calls a higher stack, passing it a+1 and b. The rest of the counting up job is left to the stacks above. Once the stack above returns, the calling stack prints the returned value as part of the count down, and then returns the same value, decremented by one to the stack below to continue the count down. This form of stack programming is known as recursion, and may take careful scrutiny to fully understand. In practice, subroutines should remain very short and simple to facilitate debugging. Consider the stack a way to delegate common tasks to a small subroutine, as shown in the array zeroing Code 3.
Figure 3: An example of the program stack running the count up/down program.

Code 4: Recursive Algorithm for counting.

To download the latest firmware, visit http://www.galilmc.com/support/firmware-downloads.php. For more information and code examples, see JS and EI in the command reference and chapter 7 in the user manual, both attainable from http://www.galilmc.com/support/manuals.php or call Galil today to speak with an Application Engineer.

