Sign in to follow this  
Followers 0
strantor

How can I communicate with a simulated PLC using FINS?

5 posts in this topic

I am writing a Python script that communicates with an Omron PLC using FINS commands. My script uses the SOCKETS function in Python and it works just fine over TCP. I currently have my script reading and writing to a CJ1M over TCP/FINS, but I want to put that PLC back on the shelf and move everything to the virtual world. I have been unsuccessful because my script communicates with a given IP address, not a given FINS [network].[node].[unit] address, which is seemingly all CX-Simulator supplies me: According the latest version of the CX-Simulator manual (revised in 2009), I need to have FinsGateway installed in order have my "Application Program" communicate with the simulated PLC (assuming I correctly understand what is meant by "Application Program").: I do not see this installed on my system: Some googling indicates that FinsGateway has been replaced by SYSMAC Gateway, which I also do not see installed. Googling for Sysmac Gateway yields most results having to do with CX-Compolet which I know for a fact I do not have. Is SYSMAC Gateway part of a regular CX-One distribution or is it an addon? The graphic above from the CX-simulator manual shows CX-Programmer utilizing the [FINS/SYSMAC]Gateway to access a simulated PLC. My CX-Programmer and CX-Designer can in fact access the simulated PLC, so does that mean that I already have SYSMAC Gateway installed? If so, how can I access the simulated PLC in the same way that CX-Programmer & CX-Designer does, using a 3-octet local FINS address instead of a 4-octet IP address? If not, then assuming I purchase the XXXXXXgateway (whatever it may be called by now), THEN how do I access it with a 3-octet address? Is Omron going to insist I use some Visual Studio OCX/ActiveX component? Because that is not an option. I am constrained to Python 3.4 and the native functions supported by Python 3.4, by the details of my project and I cannot implement Visual Studio. For reference, the Python Sockets command I'm using looks like this (snippet): self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)self.sock.connect((self.host, self.port)) ... where AF_INET specifies the address format. I have many options for address format, including (but not limited to): AF_BLUETOOTH, AF_PACKET, AF_CAN,AF_INET6,AF_UNIX AF_NETLINK, AF_LINK ,AF_RDS ,AF_UNSPEC, etc. Edited by strantor

Share this post


Link to post
Share on other sites
On a side-note, I halfway suspect that this 3-octet "fins address" and subsequent "fins communication" happening between all my various Omron softwares while in simulation is all just for show. I suspect that behind the scenes, what is really happening is data transfer through a shared memory range in my PC's RAM. If that's the case, and if there's a way I slip my python script into that shared memory area, that could be even more ideal, as I would have instant access to the data and not have to wait for simulated cycle time and simulated comms time. Anybody here know anything about this?

Share this post


Link to post
Share on other sites
I noticed that you are using SOCK_STREAM instead of SOCK_DGRAM which I have used in Java below to create Datagram packets. This will not solve your problem, but just a suggestion. On the other hand, while I haven't tried, you may use "localhost" or whatever the IP address of your PC running the simulator in the line of the RemoteIPAddress just like the line1 of the following code snippet in Java. String RemoteIPAddress= "192.168.0.10"; String SID, RSV, GCT, ICF; String SNA1= "00"; String SA11= "78"; String SA21= "00"; String DNA1= "00"; String DA11= "0A"; String DA21= "00"; int CmdLength, Cnt; byte[] ByteArray; byte[] receiveData = new byte[1024]; String Header, tmp1, CMND; InetAddress Remote_IP; DatagramSocket Ethernet_Socket; Cnt = 0; ICF = "80"; GCT = "02"; RSV = "00"; SID = "00"; Header = ICF + RSV + GCT + DNA1 + DA11 + DA21 + SNA1 + SA11 + SA21 + SID; CMND = Header + "010182019A000018"; CmdLength = CMND.length(); ByteArray = new byte[1 + (CmdLength - 2) / 2]; String strValues = ""; Ethernet_Socket = new DatagramSocket(9600); try { Remote_IP = InetAddress.getByName(RemoteIPAddress); DatagramPacket sendPacket = new DatagramPacket(ByteArray, ByteArray.length, Remote_IP, 9600); Ethernet_Socket.send(sendPacket); Ethernet_Socket.setSoTimeout(200); DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); Ethernet_Socket.receive(receivePacket); Ethernet_Socket.close();

Share this post


Link to post
Share on other sites
Thank you for your reply. I have used SOCK_DGRAM previously and it also works. With just the PLC connected straight to the PC, I get the same comms time whether using TCP or UDP. But when I throw the HMI into the mix, TCP comms time remains the same while UDP ( SOCK_DGRAM) gets much slower. Hence why I am using TCP instead of the typical FINS/UDP setup. I did not mention it, but the reason I am trying to move the PLC into the virtual world is because I need blazing fast data. This is for a 3D video game simulator of a Omron-controlled tool/machine, and the 3D rendering engine runs at 24FPS. Ideally I need to read and write to the PLC 24 times per second (comms time <24mS). With TCP I am getting close; around 65mS to read & write 249 words ( physical PLC, HMI, and PC in network) but in the same network configuration with UDP my comms times were inconsistent, between 200mS and 2000mS. This 65mS with TCP is passable but not ideal. I'm hopeful that by moving the PLC into CX-simulator I can get the data instantaneously with no comms time. BTW I just tried "localhost" as well as my PC's static IP and both returned this error: ConnectionRefusedError: [WinError 10061] No connection could be made because the target machine actively refused itApparently my PC takes offense to me trying to make it connect to itself Edited by strantor

Share this post


Link to post
Share on other sites
I swapped out the CJ1M for a CJ2M and changed the HMI<>PLC interface from "Ethernet(FINS)" to "Ethernet/IP" and that dropped my comms time down to 25-45mS (avg: 31mS). I'm going to call this acceptable for now. Having the physical PLC as part of the setup is handy anyway, since I will need to interface I/O soon (joysticks, pushbuttons, etc). Thanks for the help! (I will undoubtedly be back with more "things you don't hear every day") EDIT: made some changes to my FINS script and got comms time down to 15-20mS! Very nice! Edited by strantor

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0