I am using Ethernet to feed data into my LabVIEW system from a custom FPGA hardware. I wanted to know if there is some vi functionality or front panel functionality to display the throughput of the data received from the Ethernet port into the LabVIEW system or the PC.
Scouting through the National Instruments forums, I did not find a solution for showing this statistic in LabVIEW.
This level of diagnostic is not something that is typically available from a LabVIEW function.
If you want to determine this data rate, you have a couple of options depending on your implementation:
Monitor the data rate yourself: Presumably you are catching and processing this data somewhere so write your own wrapper that counts the number of cycles and packets it is processing
Look for a .NET implementation: LabVIEW has fairly nice integration with Windows .NET libraries, and if you are able to find an appropriate library that implements this functionality you should be able to work with it.
Run a monitoring tool like iPerf via the command line periodically. This may not return as accurate data since it is external, but it should be reasonably straight-forward for testing.
Related
as I mentioned above,
does Arduino Uno capable of running application that is taking input from sensors around 6 sensors and sending that input to a remote database through out internet by using either (Wi-Fi shield, ethernet shield)?
I am asking such a question because I am going to use it in the next semester of academic year as a part of my final year project, but I am worried that it's RAM size is not enough since it is 2KB and I need to decide either using Arduino Uno or switch to Raspberry Pi.
It should be possible, altough you may have a hard time searching for a suitable driver for your database. If using MySQL, there is already a project to do exactly what you want.
Another (more flexible) approach is to write a small PC software to receive sensor data in a simple protocol you define, and write them to the database. Run it on the database machine (or any other machine, really), and then make the Arduino communicate with your proxy software instead.
It's about a mechatronical system that needs to be controlled via software. It is not yet clear in which language it will be written, but since it is not important, let's just say in Java.
The 1. thing is that we will need to send messages via CAN. So we have the control software, some event happens and we send a message via CAN. The mechatronical system will react.
Now the 2. thing is that obviously it would be good to be able to test the software without a real mechatronical system, since it reduces effort. So I thought about writing another program, a simulation program.
So I imagine that the simulation program notices when a CAN message is sent and reacts to it.
How is a good approach to accomplish that?
I mean for the real mechatronical system the control software needs to send a CAN message directly on the bus(, maybe via some native code). For the simulation program some kind of interprocess communication is needed. How must the control software be designed that it doesn't care if there is some simulation program that is listening or a real mechatronical system that gets the CAN messages?
My first thought was that the control software always sends "CAN messages" via an interprocess communication approach. Let's say for the sake of simplicity it is RMI. Then to send real CAN messages via the bus there is some module in the same control software that gets the "CAN messages" via RMI and forwarding them to the real CAN bus.
Now the simulation program is able to receive the "CAN messages" via RMI, too, and can react to it.
Is that a good approach? Because I see that there is some overhead in the control software by communicating to itself via interprocess communication, which is not neccessary in principle. But I see no other possibility to have an abstraction layer, such that I have no special code for the simulation program in the control software.
Thank you for feedback!
You're describing one aspect of Hardware-in-the-loop testing. It's a standard approach for developing mechatronic systems that combine software and hardware.
In a software setting one way to solve this problem is to provide an interface (as in a Java interface, rather than a physical one). You end up with two concrete implementations of that interface, one for your real hardware, and one for your test version. Because the real and test versions provide the same interface, they should be interchangeable.
Once you've got your interfaces described how you implement them should be irrelevant (ie/ you could use a scripting language to develop the test code more quickly or cheaply) - so RPC may be a possibility, but there are certainly other choices.
I need to create a hardware-in-the-loop test setup. I will be using Modelica (Dymola) to do a real time simulation of a system. Dymola should send/receive data to/from some hardware and where the received data will be input to the model.
I am trying to communicate with Modbus over a serial connection. The hardware is a PLC-like device so this seems like the preferred method.
I do not have the hardware yet, so I am testing with an Arduino Uno. I have installed a Modbus-slave library from here on the Arduino, and tested it with it with an Modbus tester.
I cannot figure out how to communicate with Dymola. I have tried the Modelica_DeviceDrivers library and was able to send or receive (not both together) data from the arduino but not by the Modbus protocol. My question is if there is any modelica library for modbus communication or any other way to accomplish this from Dymola/modelica?
The free ModelPlug library will connect SystemModeler (and potentially Dymola too) to an Arduino board for I/O. You can download it here: http://www.wolfram.com/system-modeler/libraries/model-plug/
If you want to write your own drivers, you could go to the Resources\Include folder under Modleica_Device_Drivers library, there is a bunch of c header files, and they are very good examples of how to write your own driver. If you can write it in the way that it could be compatible with Modleica_Device_Drivers "package", then it will be quite easy to assemble/disassemble your data messages.
If you just want something quick, you can write a C function and reference it in Dymola.
Both methods may require when(sample(...)) clauses in order to sync your sim time with real time. But this means event generation, tho it is a time event, but for big models with a lot of states, it may slow down your simulation.
I would prefer to create several inputs and outputs around the model, then export the Dymola model as a C or FMU model, I'll write another communication program to control the data flow.
So I took it upon myself to learn all about the FPGA this semester. To test my skills, I picked up a project to encrypt and decrypt files using a FPGA implementation of the age old AES. Now implementation of AES using Verilog has been done umpteen times and for my reference I used the code at http://opencores.org/project,systemcaes. What I wish to do is use the Verilog file handling functions to read a small file, use it as input to the encryption block on the FPGA, and save the encrypted file back on the computer. I am aware that this can be done on the testbench(though I have not attempted it, I am sure it can be done). But how do I do the same when I implement the code on the FPGA board? Is there a way to select the file to be encrypted/decrypted and pass it onto the board? Is it even possible?
Sorry if I come across as a noobie, its my first time in the world of FPGAs. Thanks in advance everyone!
You need to understand that the FPGA will only take a description of the hardware that you are going to build. It is not like a programming language.
So if you want to load data into a memory on the FPGA you need a way to move the data from you PC into the FPGA. The easiest way is to implement an UART on the FPGA so you can communicate with a serial port on your PC. Then you load data from some terminal program on your PC into the FPGA.
Then you can use the serial port to read the data back to your PC.
This of course require you to have implemented the hardware needed to read and write things to and from a memory in your FPGA.
It might also be that you can stream data through the FPGA. But then I think I would use two serial ports.
Verilog RTL does not have a concept of a file system, you would need the FPGA 'driver' to break the file down and send it over byte by byte or load it into a memory for the program on the FPGA to read.
I am not experienced with FPGAs, my under standing is that you synthesis the design and stream it into the FPGA. I thought that you might have still had some connectivity to the device where you were able to stream data to it. In the same way I think you can control the Arduino over USB.
How do you plan on getting the data back out of the FPGA? Do your tools allow you access to send and load data?
I am communicating across USB, using a proprietary protocol, with some custom hardware I've built. I have a GUI that handles all the communications/interaction with that hardware and a (C#) DLL which exposes all the relevant USB functionality. I need to write a LabVIEW driver (VI) for communicating with the hardware. My thought is that I just use LabVIEW to open up my GUI and have a socket with which I expose all the relevant control to LabVIEW with. Is it possible to open a socket in LabVIEW and communicate with my GUI? Is this a bad approach or should I just try and make LabVIEW invoke the DLL and handle the hardware control instead of my GUI (polled communications, solicited/unsolicited commands, etc)?
IS there a reason you want to use your GUI only? In terms of time, I would say build a good front panel in LabVIEW and just communicate to the hardware directly using the DLL. Adding the GUI is just an added layer of complexity which might be difficult to maintain later on? Why not do everything in LabVIEW if you can?
Yes, LabVIEW supports sockets using both TCP/IP and UDP.
You should be able to create a program/service that continually runs acting as TCP/IP server. You can send commands and receive responses as strings. If you need to pack data, you can use the flatten to string command.
Essentially, your application should be structured as a loop running the TCP/IP server, and another loop that actually communicates with the instrument. This might change if you need to get data back from the devices to your TCP client. A producer consumer model, if you will :)
To get you started off, open up the NI Example Finder (Help -> Find Examples) and browse to Networking->TCP and UDP-> Simple Data Server.vi
It depends who is going to be using the LabVIEW driver and for what. If you're handing over this hardware to someone else who is going to want to create their own application(s) for it, they would probably prefer to talk directly to the DLL rather than go through your GUI. If it's more about automating your existing software from LabVIEW to do testing or repetitive tasks on the hardware, for example, then driving your GUI from LabVIEW might be less work.