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.
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.
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
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.
I'm using a DSP to control a sensorless brushless DC motor, The DSP is on a board which has a parallel port and a jtag connection (it's an eZdspTMS320F2812). What would be the best way to communicate between a PC application and the DSP as it was running? Ideally I'd like to have a GUI program with buttons like start, stop, accelerate, decelerate... but I've never done anything like that before. Which ports and method would be easiest to use?
Thanks
You can also use simple RS232 communications. I use always because it`s cheap and easy to implement.
The RS232 transceivers are very cheap (like MAX232 from Maxim-IC), and easy to use. Also they come in many packages like DIP or SOIC for example and can be found almost every electronic shop.
You can use any USART from your microcontroller to link with MAX232. Then, using a PC serial-usb converter (or if your PC does have a serial port it`s easier), you can use serial port programming from any programming language to develop your desktop application.
After that, all you have to do is create a protocol to exchange data between your PC programm and your DSP (some simple commands to start, stop and change motor direction for example).
Good luck in your project.
The parallel port is probably the easiest route. Depending on what OS and programming language you are using you should be able to find example code or libraries to support bi-directional communication via the parallel port. Since you have a small set of commands that you might want to send to the DSP board then you can probably just send a single character to the board for each command, e.g. 'R' = start, 'S' = stop, etc.