NX MCD and Beckhoff PLC connection - opc-ua

Hei everyone!
I am working on a project in TwinCAT3 and want to simulate how it would behave in real world. I am trying to control my SolidWorks model using HMI in a project. I found that it is possible to make a connection between NX MCD and Beckhoff PLC. But there is a little information about it.
I saw that there is possibility with EDAG solution, but it is outdated and I haven't really found out how to make it. I know there is also a solution using OPC UA in Beckhoff and somehow connect it to NX MCD.
Note : I have a Student version of NX

Related

How do I control a Beckhoff EtherCAT Coupler with powershell?

We have a Beckhoff EtherCAT Coupler which is currently being controlled by some c# code, we call that c# code from a powershell script. We want to move the entire process of toggling slots on the coupler to the powershell script but I'm not sure how to do that. If you could provide me even with information on how to send/receive Modbus commands in powershell that would be hugely helpful.
Thank you!
EDIT:
Here is the code used in C# to toggle one slot of the IO coupler:
using System.Net.Sockets;
using Modbus.Device;
TcpClient tcp_connection = new TcpClient(ip, MODBUS_TCP_PORT);
ModbusIpMaster coupler = ModbusIpMaster.CreateIp(tcp_connection);
coupler.WriteSingleRegister(0x1120, 0);
coupler.WriteSingleCoil(slot, state);
Acontis offers an EtherCAT Master for Windows library and a C# example application you could leverage to include into your own application: https://acontis.com/en/ecsta.html
Working with machine automation controllers is highly manufacturer specific. I've got working knowledge only about Omron PLC & MACs, so I cannot provide exact details.
Anyway, one way would be to create a C# DLL and call it from Powershell. As how to program the coupler, start by finding out which model, exactly, you are working with and searching Beckhoff's documentation. Maybe there are suitable samples available.
Consider also contacting manufacturer's support. They might be able to provide advice with very reasonable pricing, unless the task grows into a consulting gig.
Programming PLCs and MACs is often done via manufacturer specific solutions. Those are much simpler to use than general-purpose language such as C#.

Is it required to use an OPC Server to Communicate with Controllogix?

I'm wondering if for simply communicating with a PLC, like reading and writing tags, do I need all of the other heavy lifting that comes with an OPC-UA server?
I've tried writing a simple server in Python that talks to the PLC, but I get denied when requesting information from the PLC.
The Controllogix PLC I'm attempting to communicate with uses Ethernet/IP to communicate, so why doesn't a simple server/client script work? What is required exactly to communicate with an Allen Bradley PLC or PLC's in general?
There is quite a bit required to communicate with a PLC.
Each vendor has a driver, there are firmware compatibility considerations. Different protocols to think about.
OPC-UA makes it a bit more generic, but OPC-UA still has a set of things to work around when setting up communications.
Most of the OPC products I've worked with, needs to have their security adjusted to allow anonymous communication. It's generally bad practice to do this. (A network intrusion would be able to read/write to your automation layer) There is certificate signing and some encryption business that needs to be turned off if you're looking for simple communication. (Again, not a good practice but ok for learning)
After all that you have to have a notion of how your PLC is set up on your OPC server, there are channels, devices, namespaces etc. You'll point the OPC client to some opc.tcp://:
If you got this far you're almost done, I'm assuming your OPC server is running and has tags configured at this point. You can use your OPC-UA API to do a read. It can return just the value, or you can get an object back with tag health, timestamp, and a bunch of other data. Depends on the implementation. After that you can do subscriptions, writes...whatever else you need.
TLDR: OPC server not required, but may be the easiest method. Turn off security. (But turn it back on before exposing your control layer to the net)
I am also a little late to this conversation. If you are interested in coding your own solutions and don't want to use any of the commercially available standards, AdvancedHMI is a "mostly" open source solution written in VB.NET which is 100% free and provides communications to many different PLCs including the ControlLogix platform. Since I see you are programming in Python you may also be interested to know that the project does work under Mono on the Linux OS. I have used it to write gateways between EthernetIP and ModbusTCP and to pull data serially from OEM devices and push this data to a CLX PLC.
The forum is full of many helpful hints and is very active and supported.
Just trying to give you another option. DDE, NetDDE, FastDDE, OPC, DCOM, Suitelink.... These are all good, but mostly a pay to play adventure. As a programmer, it seems ridiculous to have to pay such an excessive amount of money just to talk to my hardware, IMHO. Sorry for the rant. Have Fun!
Update - Just wanted to also suggest the following open source project written in python:
https://github.com/dmroeder/pylogix
I have used this to write small programs for communicating with CompactLogix and ControlLogix. (Even to/from a RaspberryPi!)
Depends on several factors, if you want something simple to program you can opt for Modbus/TCP I think some AB PLC supports it without extra hardware.
However if you want something with more security for example for industrial use then OPC UA would be better choice but the programming has a complexity far higher than Modbus, even using the libraries of OPC Foundation or others. There is the option of using a commercial or free (if any) OPC UA server to save work, then you will need to program the client side only.
With Ethernet/IP it should also be possible, but the problem is that there is no clear specification and even different AB models talk different Ethernet/IP dialect ! , it is also far more complex to program than Modbus.
I am a little late to this discussion, but there are a couple commercial tools that make this a bit easier. The one that comes to mind for me when you say you are using python is Cogent's data hub. It is certainly not the cheapest tool out there, but they have already done all of the heavy lifting for PLC/PC communications & security.
If trying to read CLX data using Python, there are several open source implementations that will save you a lot of work. Such as this:
https://github.com/dmroeder/pylogix
If you use .NET and Visual Studio, you can use AdvancedHMI
to be able to read and write OPC Tags to ControlLogix platform is done via its communication Driver RSLinx. RSLinx acts as an OPC Server, it will need to be configured to communicate with the PLC and run on a networked PC on the same LAN. Several flavours of RSLinx are available (for WAN/VLAN also) but essentially this is the communications driver you need to talk to AB PLC's

Building a free .net OPC Client (UA or DA) without frustration

I have an application whereby I need to read data from a PLC into a database and whereby I need to develop my own application to do this. I just need to read 5 values from the PLC and log it to a DB. I have a demo OPC server running and can access it via UA or DA.
After looking at many different approaches I settled on using an OPC server to connect to the PLC and then to write an OPC client to interface to the OPC server and then write the data to the DB from my app. My language of choice is C# with .Net and the only licence fee I am able to pay for is for the OPC server from my PLC vendor.
What I am however finding extremely frustrating is getting the right info on OPC to get started. I dont want to buy any stacks but would prefer an open source stack. The information seems very fragmented and all over the place. Most of the info about OPC seems to be hype about how easy it is to use etc.
The best post on Stackoverflow that I could find is: Noob guide to OPC: how to write a C# Hello World client? and some of the links are not active any more.
My question is therefore are there any good tutorials showing how to build and OPC client from scratch in .net and what is the best open source SDK to use without having to buy a vendor's stack?
Is DA also worth learning or should one stick with UA?
The big question is why is OPC so frustrating when its marketed as being so easy?
It would also be nice to have a nice high level guide on the theory that one needs to know to build a client. I do realize that with time its possible to eventually figure this from the resources available but with limited time to make sense of all the scattered resources a quicker guide would be helpful.
Stick with OPC UA.
Luckily for you, the OPC Foundation's C# reference implementation has the capabilities of both stack and SDK, whereas other language reference implementations are typically just stack functionality.
The code is available on GitHub: http://opcfoundation.github.io/UA-.NET/
If you're not a member of the foundation the code is available under GPL2.
As for your concerns about the ease of use and marketing... I assume it's because OPC UA is marketed towards end users, who will just be hooking up various OPC UA compliant applications, which is easy. As a developer I think its fair to say there's a little more assumed about your ability to figure things out... from code examples, the specifications, books that are available, etc...

Understanding the nodemcu-firmware repository

Just getting started with the nodemcu-firmware repository on GitHub. My goal is to implement a networking suite into the esp8266, so I will not have to do the socket programming myself. I am wondering if someone would be able to elaborate to me, what exactly is the node MCU-firmware repository used for, and if my goal would be a good fit for the repository. I am new to C programming and working with microcontrollers, so any help would be very much appreciated.
Link to nodemcu-firmware: https://github.com/jfollas/nodemcu-firmware
Jason's repository is a fork of https://github.com/nodemcu/nodemcu-firmware. Read the intro page there, it says it all.
NodeMCU is an eLua based firmware for the ESP8266 WiFi SOC from
Espressif. The firmware is based on the Espressif NON-OS SDK 1.5.4.1
and uses a file system based on spiffs. The code repository consists
of 98.1% C-code that glues the thin Lua veneer to the SDK.
The NodeMCU firmware already has a network module that abstracts socket programming.

Real time communication PC with PLC (protocol?)

Basically, I would like to creat my own piece of software something a la communication protocl between PC and PLC.
I would like to read real time values from PLC and display them in a table for example Data Base, OPC table, Excel and write to PLC from PC in real time mode as well.
The whole point is I would like to access this data via ethernet port. How I can do it ? I do not want to use 3rd party software. I want to create something my own.
Choose any programming languages like C#,VB.NET and use opcdaauto.dll ,it is free dll for OPC Foundation members
You can easily get the live data from the OPC
or use dll provided by the OPC Server which you are using
As already mentioned, OPC-UA is probably more preferable, otherwise, there are commercial libraries such as InGear and open projects on GitHub.
If you actually want to implement your own low level drivers, they will depend on the PLC manufacturer. For example:
If you are working with Allen-Bradley, you will have to implement Common Industrial Protocol (CIP).
If you are working with Siemens, you will have to implement S7 Communication (S7comm or S7 for short).
If you search GitHub for various search terms related to Allen Bradley CIP and Siemens S7, you will find many starting points for communicating directly with these controllers.