Hey, bringing OpenSource to PLC is a great idea, but there is no reason to use Java to do it. There are lots of great OpenSource .NET software products out there.
I think it would make much more sense to start this whole project in Mono if .NET itself is for some reason on the blacklist, thus producing code that can actually be ported to Windows. Even C++ would be more useful than Java, at least a C++ library can run on almost any platform and easily be wrapped. I mean, the market research clearly tells us its all Windows and C#, so why create something that almost no one will ever use? There are companies out there that would probably release code to OpenSource, but the Java approach is just in the completely wrong direction. To get something out of it at least my company needs to engage the customer, and the customer runs mostly Windows Computers and wants native Apps that just work (and no experimental tinkering solution). So while the Java stuff is an interesting experiment, I can only start to contribute as soon as an industry relevant direction develops. But I hope it happens eventually. :) Ralf Am 24. Jan. 2018, 11:11, um 11:11, Christofer Dutz <[email protected]> schrieb: >Hi Gym, > >Yeah I share the assumption that, the Windows dominance of PLC software >being the main reason for .NET being the preferred platform ... at >least at the moment. >The thing is, that the reason for my involvement with this topic, is >that I want to bring open-source to the PLC world. > >If we would just plan on bringing yet another driver, I would agree >that we should do that in .NET immediately, but at least my intentions >are to bring the PLC world and the Open-Source world together. The >amount of solutions available for the Java ecosystem is far greater and >that's why I'll be focusing on Java for now but I will be glad to >assist any efforts to help porting that to other languages. > >Chris > > >Am 22.01.18, 20:07 schrieb "György Miru" <[email protected]>: > > I have no experience with the piPLCs, I was not even aware of them and >never seen them being used in industrial environment, but they might >just >be a new addition to the family. Regardless, they might be good >candidates > for development purposes. > >The company where I was working used Siemens, Beckhoff and Schnedier (I >have no experience with that) equipment, and I was also developing in >.Net. > The most obvious reason for this is that both the Siemens and Beckhoff >development environments and HMIs are windows based (WinCC, Step7, TIA, >TwinCAT...). As a result most of the commissioned control systems are >built >on windows. Also, the official S7 library (prodave), the free Beckhoff >ADS >library, the official OPC libraries and even most open source libraries > (Snap7) all have .Net wrappers or bindings. This makes .Net the most > convenient choice for many companies. > >This does not mean that there is no demand for alternatives. More and >more >companies start to realize that the support period of the Microsoft >OSes >are much shorter than the lifespan of their control systems and >security >patches are often not backported to previous versions. I have heard >about > multiple (fairly recent) projects that aim to implement SCADA and DCS > software on Linux. > > Cheers, > Gym > >On Wed, Jan 17, 2018 at 4:21 PM, Christofer Dutz ><[email protected]> > wrote: > > > Ok … so I am beginning to see a pattern here … > > >> This is now the third company using S7 and Beckhoff controllers. So, >I >> guess it does make sense to prioritize the ADS protocol >implementation. >> Let’s see what Beckhoff support answers to my request regarding using > > their spec to implement a driver. > > >> Unfortunately, again this was a company that seems to be fully in the >hand > > of Microsoft, so they too were asking for a .Net driver. > > >> Well let’s hope some folks interested in implementing a .Net version >of > > PLC4X will join our team soon. > > > > Chris > > > > > > >> Am 16.01.18, 18:21 schrieb "Christofer Dutz" ><[email protected]>: > > > > Hi all, > > > > today I had a complete day of talking to people from a company > > interested in PLC4X and what you can do with it. > > >> Downside is that they mainly use .Net and would be interested in >a >> .Net based implementation … I did find DotNetty – a port of Netty to >.Net … >> however integrating that into our build would probably be >“challenging”. > > >> But they did leave with a load of new Ideas what you could do >with >> PLC4X. I’ll treat that as success as they started out trying to >convince me >> that OPC-UA already does all what we want. I think I managed to >convince >> him that we do more and indeed there is a good reason for PLC4X’s >existence. > > >> I’ve now heard from the second customer I had a rather intense >chat >> with, that they use Beckhoff PLCs. These use a protocol calls ADS >(German >> people will probably grin with that acronym). I’ve had a quick look >and the >> protocol is a lot simpler than S7, so it should be easy to create a >driver >> for that. We should think about implementing such a driver. The >feature set >> is very slim. Would be a great coding exercise, if someone’s >interested. >> Also, it would be good if someone more familiar with reading legal >texts >> could have a look at the copyright notice at the bottom of this page >(also > > the root of the protocol spec): https://infosys.beckhoff.com/ > > english.php?content=../content/1033/tcadsamsspec/ > > html/tcadsamsspec_intro.htm > > >> Another interesting thing I found out is that Beckoff PLCs are >based >> on a software PLC called CODESYS from a company called S3. This >allows >> running a PLC on Windows, Linux & Mac … you can extend it with >Adapters so >> it could also speak in Modbus, Profinet, OPC-UA, … mabe it would be >good to >> setup such a thing in Docker to act as a Integration-Test slave … but >just > > an idea. Seams it would be possible to simulate PLCs with almost all > > protocols with just one System or VM. > > >> So far, the update from today … let’s see what tomorrow brings >:-) > > > > Chris > > > > > > >
