Mitsubishi PA10 Manipulator and ARCNET Communication with LabVIEW and CompactRIO

Publish Date: Nov 04, 2011 | 0 Ratings | 0.00 out of 5 |  PDF

Table of Contents

  1.  Introduction to Mitsubishi PA10 and ARCNET Communication
  2. National Instruments Real-Time Hardware
  3. Methodology
  4. Communication Example
  5. Conclusion
  6. References

1.  Introduction to Mitsubishi PA10 and ARCNET Communication

The Mitsubishi PA10 is a six degree-of-freedom serial manipulator that is an excellent platform for biomechanical research, including mechanical testing of human joints or as a dynamic tracking X-ray system. It has six revolute joints with AC servo motors and harmonic drive transmissions. These manipulators were designed as an open research platform and can be used with a variety of software packages, either on Windows or Linux. Our research laboratory has chosen to use National Instruments LabVIEW and Real-time products for developing our robotics framework. One of the challenges with this decision is that the PA10 depends upon the ARCNET communication protocol over fiber-optic. This is a unique token based protocol that is deterministic and transmits data at 5 Mbps.  Commercial products exist for interfacing with ARCNET but are PCI based and not available for real-time targets. Therefore, we chose to implement our own ARCNET network interface using LabVIEW and CompactRIO.

 

Figure 1: Mitsubishi PA10 serial manipulator

                One difficulty in implementing a deterministic communication protocol is the strict timing deadlines. At a communication speed of 5 Mbps, each bit (either 1 or 0) is represented by a 200 nanosecond (ns) pulse.  For example, a 0 is represented by the signal being low for the entire 200 ns. Conversely, a 1 corresponds to a high signal for 100 ns, and then low for the remaining 100 ns. Furthermore, the fiber-optic signal must be transformed into a voltage and sampled at least every 100 ns, or 10 MHz. Once the bits are sampled, they are reconstructed into packets of information. ARCNET protocol implements only a few basic but powerful messages, including ITT (Invitation to Transmit), FBE (Free Buffer Enquiry), ACK (Acknowledge), and PAC (message). The timing constraints for decoding messages and initializing a response are typically tens of microseconds.

 

Back to Top

2. National Instruments Real-Time Hardware

Our hardware solution to implement this protocol uses the following:

  • CompactRIO 9022 Real-time (RT) Controller
  • 9402 High-speed Digital I/O Module
  • 9113 Virtex-5 FPGA chassis

While the CompactRIO 9022 isn’t specifically used to implement ARCNET, it is the brain that connects FPGA and RT code together. It runs at 533 MHz, and it’s mainly responsible for the controller math based on feedback from the PA10 sent over ARCNET to the FPGA. It also manages user input.

The high-speed digital I/O module comes with four BNC connectors and has a 55 ns sample rate, which allows for reliable sampling of a 10 MHz digital single. To convert the fiber-optic signal to a voltage, an Optical Conversion Board (provided by Mitsubishi) takes the light signal and converts it to a 3.3 volt digital signal. This signal can then be directly connected to the I/O module.

Finally, the Virtex-5 FPGA chassis has a four slot backplane with a FPGA (Field programmable gate array) core. With this, LabVIEW code can be directly implemented into hardware with logic gates (and, nand, or, etc…), allowing for truly deterministic, parallel code. The FPGA has a base clock that runs at 40 MHz which was multiplied to 120 MHz. An image of the hardware setup is shown below.

 

Figure 2: National Instruments real-time hardware with optical conversion board

 

Back to Top

3. Methodology

The ARCNET standard 878.1 specifies using a Finite State Machine (FSM) to handle the communication logic, and we have implemented this on the FPGA. There are two central parallel loops that are always running:

  • Data Acquisition Loop: A SCTL (Single Cycle Time Loop) that runs at 120 MHz and continually samples the Digital I/O module and stores each sample in a flip-flop based FIFO buffer.
  • Logic Loop: A FSM with 15 states that handles decoding, interpreting, and responding to messages.

Figure 3: Block diagram snapshot of FPGA code for ARCNET communication

 

Our data acquisition must be consistent and with minimal jitter to maintain proper communication. If the measurement becomes out of phase with the original signal, bits are received incorrectly and the message is no longer useful. To maintain our desired sampling frequency, we use SCTL, which are special structures inside of LabVIEW FPGA. Any code placed inside a SCTL, must execute within 1 clock cycle, which is 8.3 ns in our design. LabVIEW achieves this by only placing flip-flop gates at the beginning and end of your critical code path to optimize execution speed. This is allows for precise timing but can be more challenging to implement due to the strict timing restrictions for code inside a SCTL.

The FSM inside this first loop has 12 states, which correspond to 100 ns chunks of time. Since each state finishes within one clock tick, we deterministically know data is sampled every 100 ns if samples are taken in the 12th state. The challenge remains to sync the sampling phase with each new incoming message. This is accomplished by triggering on the high bit at the beginning of every message before sampling every 100 ns. The logic loop controls whether the data acquisition loop is in triggering or recording mode depending on the current state of network. Once in recording mode, samples are placed in a FIFO buffer to be processed by the logic loop. Figure 4 below details this process.

Figure 4: States in data acquisition FSM

While the data acquisition loop has a specific task, the logic loop is responsible for actually implementing the ARCNET protocol. It has its own FSM where each state is specified by the protocol (see Table 1). In most states, there are subvis that implement a specific task, such as composing and decoding messages and cyclic redundancy checks. Furthermore, it handles actually sending messages with the digital module with the appropriate timing. Since this logic is too complex to put inside a SCTL, the Tick Count and Wait Functions were used to maintain proper timing. For more details about this portion of the code, please refer to http://code.google.com/p/drics/.

Table 1: Required states for ARCNET Finite State Machine

0: Reset

Reset the ARCNET network with RSU message

1: WT_Idle

Wait for silence

2: WT_ACT

Wait for communication to start

3: DCD_TYPE

Decode the type of incoming message

4: DCD_DID

Decode the destination of the message

5: RECON

Network reconfiguration if needed

6: RX_FBE Respond to Free Buffer Enquiry
7: Pass_Token

Pass token to the next node

8: WT_Token

Wait to see if any node is transmitting

9: TX_FBE

Transmit a Free Buffer Enquiry

10: WT_FBE

Wait for a response to a FBE

11: TX_PAC

Send message

12: WT_PAC

Wait for message to be received

13: RX_PAC

Receive and handle incoming message

14: PAC_ACK

Send reply that message was received

 

Back to Top

4. Communication Example

The figure below demonstrates a successful communication between the CompactRIO and PA10. Messages in red correspond to messages from the PA10, while messages in green are from the CompactRIO. The signal and the receive lines on the Digital I/O module were duplicated to record network activity. The sequence shown is a typical example of control information sent to the PA10, which includes control input for joint velocity or joint torques. Each bit is represented by two thin vertical lines side by side. For a 0 bit, both lines are white. For a 1 bit, there is a black and then white line. Some of the bars appear to be large black columns, but that is simply because there a hundreds of bits very close together due to image scaling.

 

Figure 5: ARCNET communication sample between PA10 and CompactRIO

 

Back to Top

5. Conclusion

The LabVIEW and CompactRIO hardware allowed us to implement a complex communication protocol in real-time for robotic systems.  Many of the challenges we faced were more manageable in LabVIEW versus traditional programming techniques. For additional information on this project, please refer to LabVIEW and CompactRIO for Dynamic Radiographic Imaging Control.

 

Back to Top

6. References

1. “ATA 878.1 – 1999 Local Area Network: Token Bus”, ARCNET Trade Association, www.arcnet.com 

2. “FPGAs – Under the Hood”, National Instruments

3. Dynamic Radiographic Imaging Control Software, Orthopedic Biomechanics Laboratory, University of Florida

4. "LabVIEW and CompactRIO for Dynamic Radiographic Imaging Control", Dr. Scott Banks, University of Florida

 

Authors:

Ira Hill, University of Florida

Tim Elmore, University of Florida

Prof. Scott Banks, University of Florida

 

Back to Top

Bookmark & Share


Ratings

Rate this document

Answered Your Question?
Yes No

Submit