09-16-2023 06:54 AM - edited 09-16-2023 06:58 AM
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:
Things Not Working:
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:
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.
09-16-2023 07:48 AM
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.
09-16-2023 03:46 PM
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
09-17-2023 02:22 AM - edited 09-17-2023 02:30 AM
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.
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:
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:
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!!
09-17-2023 04:52 PM
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
09-18-2023 02:19 AM
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:
(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?
09-18-2023 02:53 PM
@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