AMTI Accu sway Force Plate Data Acquisition with NI myRIO-1900

[yogesh10994]

Hi all,

My aim is to read the AMTI Force Plate (Model AccuSway) via the NI myRIO-1900 microcontroller. The Force Plate has a USB port and I am plugging it into the USB Host port of myRIO.

Things that are already working:

1. Reading AMTI Force Plate with their software AMTINetForce running on PC with an AMTI USB SDK package (containing AMTIUSBDevice.dll).
2. The LabVIEW Code for reading Force Plate is also working. Here, I opened a LabVIEW project and the VI runs under the Computer Hierarchy, that is, using the host PC resources.

Things Not Working:

1. When the Force Plate is connected to myRIO via myRIO's USB Host Port the VI runs on the target and not on the Host PC.

In this case, while deploying code on myRIO error pops up as: "AMTIUSBDevice.lvlib:fm Broadcast Zero.vi loaded with errors on the target and was closed.". I tried running the code on the myRIO target using two different libraries ("AMTIUSBDevice.lvlib" and "G 5.lvlib") but the same error popped up.

My Hypothesis:

1. When I run the code on the Host PC, no error comes. Go inside the block diagram (of the Zero.vi on the Host Side) and open the Call Library Function to Configure it. Under the path dialog box, the correct path is provided which is in the D drive of my Host PC ("D:\National Instruments\LabVIEW 2017\user.lib\AMTIUSBDevice\AMTIUSBDevice.dll"). However, if you open the same code under the myRIO target, the path folder changes to "/D/National Instruments/LabVIEW 2017/user.lib/AMTIUSBDevice/AMTIUSBDevice.dll" ----> This shouldn't make sense because my Host PC has a D drive and not the myRIO. In the deployment window the "AMTIUSBDevice" or the "G 5" Library successfully gets deployed...its when the Zero.VI is deployed the error pops up (see attached image for error message). This makes me think about what should be the correct path for the .dll file when running this code from the target? 
2. From my other projects with myRIO, I know that the single USB Host port on it appears as ASLR:3:COM Port in the VISA Resource. The AMTIUSBDevice.dll file that I got was originally made in Visual Studio by the AMTI guys for Windows OS purposes 32-and64-bit. I am using the  32-bit (64-bit was giving an error). The VI code on the Host PC "somehow" understands that the Force Plate is connected to the CPU via USB (Had to run an SDK to detect the Force Plate on Windows USB). Coming to the myRIO Target, I know I connected it to the ASLR:3:COM Port, so somehow this information needs to go into the AMTIUSBDevice.dll file?

Does this make sense? Please let me know what are all your suggestions for the solution.

I am attaching the LabVIEW project with a simple version* of a VI running on Host PC and myRIO Target with two different libraries made (just for my debugging: one has .dll in the lib and another does not). The manuals, SDKs for AMTI, and other full acquisition VI are also attached in the same .zip. The error images are attached separately.

*This simple version just sets the zero line of the Force Plate. I did not include other complicated codes like querying for the data acquisition.

[ZYOng]

myRIO is running NI Linux RT and cannot run Windows-based DLL. It can only run the shared libraries with an extension of SO. You need to reach out to AMTI to see if they provide SDK and libraries for Linux.

[Bob_Schor]

I completely agree with @ZYOng that you have no use for the myRIO to acquire Force Plate Data -- AMTI's software is designed to work with PCs running Windows, and supports both C/C++ with one set of DLLs and LabVIEW with another set of DLLs.  In either case, the AMTI hardware must be connected to the PC running the AMTI acquisition software, which runs under the Windows OS.

The myRIO, running the LabVIEW/Linux Real-Time OS, could be used to directly acquire data from the A/D, D/A, and signal conditioners that are "inside" the AMTI box, but AMTI has already provided the firmware to do this, and provides you an API to allow you to use Windows (on your PC) to communicate with this API, either through C++ or through LabVIEW calls.  That is all that the USB connection is doing -- exchanging "messages" with the AMTI box to get it to carry out functions that they provide, including those that return data to you in a format determined by their API for you to use as you see fit.

Save your myRIO for another Project where you need to acquire Analog and Digital signals directly (using the myRIO's I/O ports).  The USB port on the myRIO, in this scenario, is connected to the PC, making the myRIO + its attached hardware + its LabVIEW-RT code the equivalent of the AMTI box, accepting "commands" from the PC and returning "data" as appropriate based on the code running on the myRIO.  [I hope you understand what I'm trying to say ...].

Bob Schor

[yogesh10994]

Dear @ZYOng and @Bob,

Thank you for your replies.

@Bob:

Connecting the AMTI Force plate to NI myRIO-1900 is part of our bigger project. We are already acquiring data from IMUs (SparkFun BNO085), and Encoders (BroadComm AEAT-6012) and controlling in real-time brushless motors from Faulhaber. For these three we made our own labview codes reading their respective manuals (It was time-consuming but a fun process)! These three work fine on LabVIEW with myRIO-1900.

Now, we want to integrate AMTI Force Plate readings in real-time with NI myRIO.

We tried one thing.

• Run AMTI Windows DLL code on the Host Side. Our other code is on the NI Target side. Then we used network-shared variables between the target and the host PC to bring the force plate data onto the target side.

This worked with no errors. But when we validated the syncing with IMUs and other systems. We found that there is a syncing issue due to not doing all the stuff on the same microcontroller. The force plate data "somehow" dilates over time. The offset in time is also not constant...varies with time. 

We debugged this by using two different systems:

1. using another microcontroller (Arduino's Flagship Portenta h7 running the IMUs) which sends a trigger signal to the AMTI Force plate via RCA pin input. So what happens is Arduino portenta is the master...when data saving has to begin it sends a 3.3V to the force plate which gets triggered and starts recording data on its Windows API. Data saving of IMU happened on Arduino and for force plate, it occurred on Windows. Still, the same issue of syncing came. "The offset in time is also not constant...varies with time. "
2. We brought both the IMU and Force plate on a single data logger. Here, we used Vicon's Lock Plus to read IMU data and bring it into the Vicon Nexus software. We read Force Plate via our computer's USB Host port and then using the USB DLL file it was brought into the Nexus software. When you record data on the nexus by clicking capture....all data from IMU, Motion Capture System, and Force Plate are synced. No issues.

AMTI Force Plate's USB DLL file somehow takes into consideration the syncing issue (see their manual). 

With the debugging we did, we figured out that everything (data acquisition from IMUs, Encoders, Force Plate, and Motors) has to happen on a single microcontroller/data logger.

So coming back to our case, I see two further steps:

1. Get in touch with AMTI to compile Windows DLL to a Linux-based compatible file. (How can I do this myself? What do I need?) ..........I only have the AMTIUSBDevice.dll, AMTIUSBDevice.lib, and AMTIUSBDeviceDefinitions.h files. These are attached below. (It did not allow me to attach .lib file in this forum) How can I use these three only to create something that is compatible with myRIO Linux RT?
2. Understand why using network shared variables between the host PC (running Windows dll force plate data acquisition) and target (myRIO: running and controlling IMU, Encoder, and Motors) creates a sync issue between the two systems. (Note it does not create an issue when not using AMTI Force Plate....somehow the internal clocks of the signal conditioner inside the AMTI box create an issue...not sure though)

I hope I explained my systems and what I need clearly. Let me know if any information or testing/debugging is required)

Looking forward to collaborative solutions on this topic!!

[Bob_Schor]

Thank you for the more detailed explanation, especially the role of the myRIO in the mix.  As I now understand it, you have a number of sensors and actuators that you are running on the myRIO, taking advantage of its Real-Time OS.  As it happens, we are also constructing an instrument that has a complex stimulus/recording/analog + digital scheme that we realized could best be solved by "embedding" a myRIO "inside the box" (we're currently using USB as the TCP/IP connection between Host and Target, but I'm also testing using the myRIO's WiFi instead).

The "tricky part" is the Force Plate, which seems to have (only) a Windows driver, which means you need to run it on the Host.  You still might be able to pull this off -- you'll need to "invert the control scheme" slightly.

Normally, in the LabVIEW RT code I've developed, I use the PC as the "User Interfacer", in control at the beginning (to gather "control" information, i.e. "Read the Front Panel settings", but relegate all of the time-critical (a.k.a. "Real-Time") stuff to the Target.  I establish multiple Network Streams to tie the two systems together -- a bilateral pair for Host->Target and Target->Host "Messages" (both Host and Target run QMH-like Message Handlers, and these streams let the Host send a "Do This" message to the Target, and vice versa), and the other Streams are data from Target to Host.  One of those Data Streams are generated by the Target's "Read Message" function to tell the Host "I'm doing Such-and-Such at 13427 ms since I started" -- the Host has a dedicated loop processing these "Events" which it can use to keep "in synch" with the Target.

So suppose you write an Acquisition routine on the Host (where you have access to the Force Plate DLL) to gather Force Plate data and "do something interesting" with it (which I assume consists of "saving the data", "showing the data", and possibly some "analysis of the data") which is probably better suited to the Host, with its multiple cores, large amount of memory, and fast/large storage devices.  The only "trick" is getting the Host and Target "in synch", since the Target has to run the timing of all the rest of the hardware.

I just erased a paragraph where I described a Network Stream channel dedicated to starting the Host Force Plate acquisition and trying to synch it with the Target.  But you could also use a "wire" (coax) from a Digital Output on the myRIO to a Digital Input on the Host.  The Host "Acquire" loop could do single DI Reads and start the Force Plate "Read" when the DI goes High.  There may still be a (small) latency, but you could "tweak" that by having the Target send the High, then delay its code by the same (small) latency.  A little clumsy, but better than trying to rewrite the DLL to work "native" in the myRIO (which has somewhat limited memory).

Bob Schor

[yogesh10994]

Dear Bob_Schor,

Thank you for your reply. It does give me some new perspective. I will try out the things you suggested and report back.

Meanwhile, I am contacting AMTI guys to get a Linux-compatible DLL file to later try with myRIO. (Can I do this myself? Please suggest)

I am getting curious about the paragraph you deleted explaining about "Network Stream channel dedicated to starting the Host Force Plate acquisition and trying to synch it with the Target". I got excited about it because if this works...I don't have to connect a hard wire from myRIO to the Host PC. (Please provide information about this. Getting such information from NI guys directly is a privilege indeed in this community forum!!)

Meanwhile, I will try the hardwiring thing connecting the wire from myRIO's digital output to the Host's digital input. About this, I have a query:

1. Is Windows 11 cable enough to understand a digital input? How do I do this?

(Should I connect the USB host port of myRIO with the USB host port on Windows CPU...and use the VISA resource to send commands from myRIO?)    Or what do you suggest?

[Bob_Schor]

---

@yogesh10994 wrote:

I am getting curious about the paragraph you deleted explaining about "Network Stream channel dedicated to starting the Host Force Plate acquisition and trying to synch it with the Target". I got excited about it because if this works...I don't have to connect a hard wire from myRIO to the Host PC. (Please provide information about this. Getting such information from NI guys directly is a privilege indeed in this community forum!!)

Meanwhile, I will try the hardwiring thing connecting the wire from myRIO's digital output to the Host's digital input.

---

I'm not an "NI Guy", though I have been using LabVIEW in my work (and helping colleagues who use LabVIEW) for a few years.  I wrote something about Network Streams on the Forums about a decade ago, but it was really about keeping the Host and Target "more-or-less synchronized" -- the Target told the Host every time it started a new State, and the Host gave the Target occasional commands to make it "start" a State -- one could adapt this to more-or-less "synch" Host and Target, but I'm not sure how accurate or precise this would be.  Would need to experiment.

I was a little tired when I wrote that reply yesterday -- it was a little unclear, and incomplete.  I was thinking you would use a Digital Output on the myRIO to make a TTL Pulse that would go out a thin (RG-174?) coaxial cable, but didn't think to say you'd need something like a USB-600x multi-function unit on the PC to look for this pulse as a "Go" pulse.  Of course, that's backwards -- if you are starting the Force Plate from the PC side, you should also generate the TTL Pulse on the PC side (again, with a USB-6xxx) and wait for it on the RT side (multiple parallel loops on a myRIO are amazing!).  You should be able to get sub-millisecond synchronization this way, with hardware.

If you don't want to use a physical Wire and actual "hardware", you can still use Network Streams, but this time, now that I'm more awake, do what I suggest in the previous paragraph -- send a "Go" Network Stream message from PC to myRIO, which can have its Network Stream "receiver" running in a tight loop, just waiting ...  Because it is software driving TCP/IP, it will be slower than "pure hardware", but you could try making some measurements to determine the delay, then send the Network Stream message "just before" the PC starts the Data Acquisition.

Bob Schor