Arcus Technology, in conjunction with Kod Integrations, LLC recently added to its suite of stepper motor software tools a fully functional LabVIEW driver. This application note is designed to facilitate even the novice LabVIEW developer in swiftly creating their own functional LabVIEW applications utilizing this driver and a set of (3) DMX-J-SA-17 stepper motors.
Please note that this document is not intended to act as a lesson in proper LabVIEW development techniques, nor does it focus on one design pattern over another. Its intent is to demonstrate the usage of the Arcus supplied LabVIEW driver for controlling DMX-J-SA-17 stepper motor(s) via simple, clean and functional examples.
Before one can begin developing their own custom application, an understanding of the fundamental LabVIEW driver components is necessary. Assuming the driver has been downloaded and properly installed to the LabVIEW development environment, the top-level of the Arcus custom palette of VI’s looks as seen in the figure below:
The three primary LabVIEW VI’s to be discussed here are “Create Connection”, “Send/Receive Command” and “Close Connection”.
Before any standard communications can be established with an USB-connected DMX device, a connection reference must first be established. This is where the create_connection.vi comes in:
Perhaps the heart of the driver is the Send/Receive Command VI designed to communicate the commands defined in Arcus Technology ASCII Language Specification for the DMX Series devices:
Once communication with the attached motor is complete, the reference must be properly closed:
With a firm understanding of the primary driver components required to establish communication with the DMX series stepper, the following steps to building a simple LabVIEW application will be much more intuitive.
Have a look at the following front panel and block diagram for the VI “01_issue_raw_command_string.vi”:
Front Panel:
Block Diagram:
As demonstrated here, all three main components individually described in Section 2 above are wired to form a single, simple application for communicating with a single DMX series stepper motor.
Note that because this is a single-motor application, the “device_index” input will always be ‘0’. The value of this input becomes more important when dealing with multiple connected devices (described in subsequent sections).
To see how this VI works, simply go to the “dmx_applications.lvproj” project and launch the VI “01_issue_raw_command_string.vi” beneath the “single_unit” folder:
Enter a command in the “command (raw)” field and RUN the VI. For example, enter the command “DN” (without the quotes) and RUN the VI. The motor ID is returned.
Although this VI demonstrates the full functionality of initializing the motor, issuing a command and closing that reference, doing this each time to send multiple commands is inefficient and unrealistic. Have a look at the following front panel and diagram:
Front Panel:
Block Diagram:
In this particular example, when the VI is executed, the attached motor at index 0 (remember, by default) is initialized and the VI sits and waits for the User to (1) enter a command to be issued and (2) click the “ISSUE COMMAND” button to send that command. This allows the User to send multiple commands in a single session without the need to initialize the motor (create a reference) and terminate that motor session (closing the reference) each time a command is issued. Ultimately, when the User is finished with communications, he/she clicks the “EXIT PROGRAM” button to exit the “commands on demand” while loop above and closing the motor reference.
To see how this VI works:
Note the VI continues to run, waiting for the User to issue another command (or until the User clicks the “EXIT PROGRAM” button). So to best demonstrate the advantage to this design approach, one might want to issue a number of commands in a single session: get the device ID, enable the motor output, jog the motor in the positive direction, stop motor movement and disable motor output:
Note this VI presents an alternative approach to issuing these same commands. On the front panel, click the “OPTION 2” tab to reveal two fields “Pre-defined Command” and “Parameters”. Rather than recalling, for example, what the ASCII command may be for retrieving the motor ID one has the option to choose the command from a human-readable drop down list. Revisiting the same sequence of commands:
The “Parameters (where applicable)” field isn’t required for these commands. An example of where one might make use of the parameters array control is if a command requires some additional parameters for proper execution. Setting the device ID is an example.
The ASCII command for setting device ID is DN=
Many applications may require more than one DMX series motor to be controlled at one time. This section, as with the previous section, covers two example applications demonstrating the use of the Arcus LabVIEW driver but to control (3) DMX series stepper motors as opposed to (1).
Having a look at the front panel and block diagram of another VI (in the same project) named “01_issue_raw_command_string (multi).vi”:
Front Panel:
Block Diagram:
Analogous in behavior to the first example discussed in Section 3, this VI demonstrates usage of the three primary driver components applied to (3) stepper motors.
The attached device indexes are 0-indexed – meaning the first connected device is index 0, the second is index 1, the third is index 2 and so forth. Here the initialize step is encased in a For Loop, indexed by an array of device indexes 0 through 2. Therefore the first step creates (3) separate references, 1 for each initialized motor.
The second step permits the User to send (3) independent commands to each of the referenced motors, with a 500ms delay imposed. All three responses are retrieved and sent to (3) independent indicators on the front panel.
Lastly, all three references are closed.
To see how this VI works:
Note in this particular example, the second step (issue raw commands) is wrapped in a case structure, displaying the TRUE case. As mentioned above, the three motors receive their commands sequentially. Have a look the FALSE case, illustrated below:
This case demonstrates an approach to simultaneously send independent commands to all three motors.
Now for a more realistic design approach. Take a look at the VI “02_issue_commands_on_demand (multi).vi”:
Front Panel:
Block Diagram:
Analogous in behavior to the second example in section 3 above, the User first RUNs this VI and proceeds to send commands on demand. However, in this case, just a single command is delivered to motors of the Users choosing. For example (as illustrated in the front panel screenshot above), the use can issue a Jog command (J+) to all three motors by checking the checkboxes for each motor and clicking the ISSUE COMMAND button.
To see how this VI works:
When dealing with multiple motors, it is not intuitive as to which of these motors will be assigned to which index – making it difficult when programmatically identifying and targeting specific motors. That said, for more sophisticated applications, a mechanism must be in place to identify a motor by both its index and its name (referred to as device ID in this document). Once set, a motors name/ID will never change. However, its index can and likely will depending on the configuration of the application.
All motors received from Arcus technologies will likely be shipped with the same name (JSA00 or JSA01). It is highly suggested to connect each motor independently and change their names to be JSA00, JSA01, JSA02, etc. Now you can imagine an initialization routine that is capable of (1) identifying how many devices are attached to the controlling PC, (2) initializing all motors and (3) retrieving their ID’s (names) and associating them to their references. Now, knowing the names of each motor (and the function of each), they can be properly identified in the program, regardless of their assigned index. Consider this alternative method for initialization and identification, having a look at VI “03_initialization_and_identification.vi”:
Front Panel:
Block Diagram:
As an alternative, more thorough approach to initializing the attached motors, one may want to consider using this utility VI supplied in the “dmx_applications.lvproj” project library. Not only does this utility VI initialize all attached motors, but it outputs a complete list of associations where each motor is identified by not just its reference (as in all past examples) but by its reference, its index and its name. Now, this permits the developer that ability to make logical business decisions in downstream code based on an unchanging, assigned device name and not just an index or reference.