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 “Initialize”, “Send/Receive Command” and “Close”.
Before any standard communications can be established with an USB-connected DMX device, a connection reference must first be established. This is where the initialize.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:
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, the generated "reference" upon initialization is an instantiated base "_Controller" class that contains parameters that identify the initialized motor
Within the Controller class object are data members such as "Device ID", "Device Name", "Device Model (or type)" and "Device Index". This information is inherently transmitted via the reference throughout the control application and is accessible at anytime prior to closing said reference. The example (03_initialization_and_identification.vi) demonstrates the initialization process and how one might want to access these parameters via a series of "member accessor" VIs (all of which are available in the Arcus USB Comm driver).
NOTE: 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.
Front Panel:
Block Diagram: