You need to get PC Access, which is a Siemens program. Essentially this is an OPC server. It has to be loaded on the host computer. With it, you can read and write data from Excel VBA. I have never written from .Net, but if I can read and write with Excel VBA, I'm pretty sure you can get this done with .Net.
Sounds like more money. Based on the aforementioned libraries... I don't know if it will be necessary as .Net is... well not low level... but certainly lower than doing something in Excel. I mean if something need to go through to Excel you can program Excel from .Net... as long as the .Net bridge is intact.
.Net is a programming framwork. In order to communicate with the S7 PLC you will need to write a communications driver. Are you trying to talk with the PLC over Profibus-DP, Industrial Ethernet or MPI? S7 PLCs support all three, and all three are very different protocols and will require different drivers and different physical media adapters.
To arj... re: libnodave... I've dabbled with this quite a bit and gotten nowhere with it. If you could give me like 5-10steps to get the right files, the wrapper, and how to get it into a .Net project, and connect to a PLC... would be much appreciated.
To Fra... 1. It's free. 2. You have full control of the behavior, you are not limited to the attribute of the elements in an HMI package (such as WinCC... which are terrible IMO [I could give all kinds of examples],) 3. It's a proof-of-concept... I want to see if it can be done, and see if I can make it work.
No I am saying developing in .Net is essentially free, much more flexible, and allows more control. If you are not going to nail a post that is productive why bother posting? Come on.
I agree with Nick, .NET gives you complete control. You are not restricted by a crippled scripting language or limited tools. With tools like AdvancedHMI , you do not need to be a programmer to use Visual Basic .NET as an HMI software.
"If you are not going to nail a post that is productive why bother posting? Come on. "
I take exception to that. My point was quite obvious, you are kidding yourself if you think that .NET development costs nothing.
And it is not even just the cost, think of the person who will have to support this when you are gone.
"think of the person who will have to support this when you are gone."
Support is a very common argument against using .NET for an HMI platform, but that argument truly lacks merit. Yes, if an application is poorly written, it is a nightmare to support, but the same applies no matter what development package you use. Have you ever tried to support an HMI developed in an off-the-shelf package that has hundreds of lines of poorly written and poorly documented script?
A properly written .NET application takes advantage of object oriented programming and Visual Studio integration. That allows most changes to be made by simply dragging and dropping components and changing properties.
The other aspect of support is community support. If you perform an internet search for support forums for you favorite HMI software, then do the same for .NET, you will find at least 10 times more forums for .NET and Visual Studio than even the most popular HMI package.
The bottom line is that no matter what software you use, a well written application is the key to the next guy being able to easily support it.
Well that may be your view, but if you have ever worked on a project where they brought IT guys who know nothing of Control systems, PLC's and SCADA into the Automation team you might have a completely different point of view. (Been there!)
Programming Control Systems is not the same as programming for IT.
You can get great answers over on PLCTalk.net, which is an excellent community of PLC/SCADA programmers.
I had to add to the this... the other advantage of using .NET for a PC based HMI is that you are able to leverage all kinds of features standard on a PC... such as internet access, printing, etc... that you would otherwise, in most cases... would be optional for a PLC, proprietary, and in some case- require another several hundred dollar module to implement on a PLC based platform. So... I would argue that developing an HMI on a PC... regardless of language or platform... is much more cost effective in consideration of this... and furthermore... you don't have to pay for very costly vendor specific Industrial HMI units (sometimes conditions can warrant that... but there are ways to implement PCs to accommodate them.
Lets say this project will take 500 hours of your time with .NET.
And 300 with a standard SCADA. Difference 200 hrs. Your pay * 200? Cost of modules?
And even if the time it takes is the same, how do you assure ongoing core software fixes, proven internet security, etc etc.
I do have a question. Are you planning this for implementation on many similar systems so the cost is reduced per system?
"I do have a question. Are you planning this for implementation on many similar systems so the cost is reduced per system?" I am sorry, if I didn't make it clear somewhere in here earlier... this is a POC. Siemens allowing me and others in the fields to develop a simple POC at little to no cost... is in their best interests... as once the POC is fulfilled to a certain level of satisfaction... it will be a place where it will be a known... that can be implemented in the field... in consideration of all the other questions that you ask.
As I said in the other thread... I am not going to continue to debate on this. When someone responds with more thorough information, on getting me to a simple point via libnodave or some other API... then I'll get back at it.
FrancisL... with all due respect you must be either a vendor, oooor... a seasoned vet who fear progress with respect to the standardization of software practices, new technology, and the inherent removal of a highly propriety/costly model... that you have been working with for a long time... know well... know it takes a long time to master due to its cryptic and obfuscation-prone nature... and fear said new technology, as it will only take an intermediate programmer with reasonable knowledge of automation, to take your job.
If you are using MPI, which interface will you be using? You will need to start with device level drivers for which ever interface you will be using.
After you have the drive drivers in place, then you will need to develop the MPI protocol "stack" that goes between your GUI (HMI) and the device drivers.
I would really rather not get that low level... I am looking for an API (wrapper) that I can use in .Net at a higher level... I still have to look more and libnodave...
Device drivers are unique to the interface board. You can contact the manufacturer of the interface board you are using and see if they have an open API device driver.
