There is a Simulink model composed of some subsystems, It is supposed to run each subsystem in a computer and all computers are connected to a LAN network.
There are interconnections between these subsystems and data shall be transferred between them so they should run synchronously and preferably real time.
But the computers have Windows operating system and so they do not have real time operating system.
I am searching to find a solution for this problem. what I have found up to now is that:
Simulink real time workshop can make executable code of simulink models but the code can be run real time just with real time processors and it doesn't seem that they can support connection between multiple computers.
XPC target is known but it just make connection between one host PC or hardware and one target PC and the target PC shall have real time OS. so it doesn't cover this problem.
There is a library for Matlab titled "Hardware Input / Output Library for Matlab / Simulink " by Werner.Zimmermann that have some good facilities such that it can make simulink to be run near real- time and it can make connection and send data via TCP/IP between two computers but it seems it can just make the connection between two computers running simulink.
It also have some constraints for OS and version of Matlab/Simulink and is not updated. So I'm not sure it would be enough.
After all of these, does anyone know a better way of handling this problem? I would appreciate any help on any of these topics to be useful or another ways to solve this problem.
Thanks in advance
see the following links (especially the first one):
http://www.mathworks.de/help/toolbox/instrument/brbv41k-1.html
http://www.mathworks.com/matlabcentral/fileexchange/4934
http://www.mathworks.com/matlabcentral/fileexchange/27290
Related
I want to give signal via PLC to Raspberry Pi and when the raspberry pi gets that signal, it should run the python script and when the python script execute properly and cycle is completed, it should wait for the other signal from PLC to again run the same script and same cycle should go on.
Please provide some suggestions.
Via Network:
Depending on your PLC, you could use UDP or TCP, where a Python program on Raspberry listens and sends commands. Depending on the command received, different scripts ou actions could be executed. There are many Python examples for using this on the internet.
For the PLC it can be a little more complicated to find and it will depend on the model and manufacturer, I recommend that you check your supplier's documentation.
Discrete Inputs:
I don't recommend it, but if it's impossible to use a network, you could use discrete digital inputs (like buttons do) to trigger the scripts on the Raspberry, but it must have an interface with relays or optocouplers between the PLC and the Raspberry due to differences in types of electrical signals. In this mode, scripty in pyton keeps checking the status of a digital input and triggers the action when the status of the input changes.
Note:
Note that in both cases the program remains running (in an infinite loop), waiting for the command.
Additional care must be taken when using the Raspberry in an industrial environment due to possible interference by EMC. If using digital inputs, consider applying filters to the signal and shilded cables.
Hallo this is my first post here.
I'm currently doing my internship at a company that uses twincat 3 programs for automation in conjunction with a yaskawa robot system. The assignment I received is to expand the simulation software they currently use to simulate the plc software to also be able to simulate the yaskawa interface so they can test if changes in eithers software causes issue's in the other without having to upload the program to a PLC. I've been looking online and found a couple options but I'm curious if I missed some other options or if the options I've found will not work.
The options I'm currently considering are.
using the ethernet port on the simulation pc to connect to the Yaskawa controller. I've found a driver(https://infosys.beckhoff.com/english.php?content=../content/1033/el7031-0030/1036996875.html&id=) that will allow the user to make an ethernet port on their pc function in real time so I theorized It might be possible to then directly connect the computer to the yaskawa controller so the user would not need to upload the software but have the PC act as a PLC instead.
Use ROS to simulate the robot. there are libraries for ROS industrial to program and simulate a yaskawa robot. It would require using 2 computers or using a virtual machine as ROS is used best on an linux system. Only problem is I can't figure out if the ROS simulation can use regular yaskawa jobs and functions or if it can only the adapted ones programmed in ROS.
Use motomans simulation software motosim to simulate the yaskawa robot. Seems like an obvious solution but can't figure out if it's possible to have it communicate with twincat3 however I might have missed something.
write a twincat 3 software that emulates a yaskawa interface. I consider this a last resort if all else fails. It would require the code be updated each time something about the yaskawa software changes which is not ideal for quick testing.
I'd really appreciate any suggestions or additional information more experienced programmers might have.
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.
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.
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.