Thanks for the thoughts. Would you recommend any one of the "soft PLC" projects that I should look at further. Certainly I think the idea of a PLC emulator is too ambitious. I think the minimum effort approach, though still lots of effort, is too run the PLC code using the standard propriety tools in a VM and the to drive the input output of this VM with software to simulate the connection to hardware.
On Wed, May 4, 2022, at 11:18 AM, Łukasz Dywicki wrote: > Hey Chris, > Sorry for mixing authorship. I didn't check simulator since a while, > hence was not certain if its up to date. > > My point is about reusing network layer which PLC4X provides in order to > simulate a device. This is how you normally interact with PLC so it is a > natural way to make an "integration test" at this level. It is not > beyond typical BDD which is more about defining scenarios. How they are > actually executed depend on a BDD toolkits and how they integrate with > test or build environment. > I get that scope of Peter work is to emulate a PLC runtime, that's why I > mentioned IEC grammars (so he can somehow parse or compile entire > program), which is the hardest part. > Once program can be interpreted and executed (ie. by turning ST into > LLVM and firing graalvm or c runtime or simply running it with one of > existing tools such as openplc), the remaining part will be possible > after proper adoption of code generated from MSpec. > Looking at amount of "soft plc" projects I have no doubts that its > possible. Its just matter of how much time and simplifications we can > accept. > I agree that we don't have a capacity nor will to dive into even more > specific parts of how PLCs work. If somebody else has such interest I > will definitely look for results and see if we could improve our part > afterwards. > > Best, > Łukasz > > On 4.05.2022 09:09, Christofer Dutz wrote: >> Hi Lukasz, >> >> I intentionally didn't mention the simulator, as I understood Peter, that >> he's looking for something to run his PLC programs on for testing. Yes, the >> simulator we have could be used to simulate being a PLC, but it can't >> actually simulate the PLC itself. That's not the scope of that thing. I >> think implementing the internal stuff needed to create a simulator where you >> can deploy a program from TIA Portal is totally unthinkable, considering how >> many different PLCs are out there. >> >> Perhaps we should name it differently in order to manage expectations. >> "plc-mock"? >> >> And our simulator was actually created by me and it's up-to-date and we just >> recently checked that it still works with the StreamPipes folks, as they >> were looking for something to use in their StreamPipes integration-tests. >> >> Chris >> >> -----Original Message----- >> From: Łukasz Dywicki <l...@code-house.org> >> Sent: Dienstag, 3. Mai 2022 22:47 >> To: dev@plc4x.apache.org >> Cc: pe...@petersaxton.uk >> Subject: Re: Scope of using PLC4x as simulated driver for PLC projects >> >> Hey Peter, welcome on mailing lists. First of all thank you for showing a >> interest in a project and bringing interesting topic! >> >> Just to oppose a little bit what Chris says, I would say there is no real >> blocker for trying to do a PLC simulator within PLC4X. We do (or >> did) have a S7 simulator in sandbox already. It was built a while ago by >> Julian based on netty tcp server and I think 0.6 structures, so it might be >> a little bit behind of what we currently have in a develop branch. >> >> Technically speaking what you need in most of the cases is launching a TCP >> server (in case of ADS/Modbus/S7) or a serial receiver (Modbus RTU/till some >> degree CANopen) and answering requests which come over such communication >> channel. If you get closer to basic fieldbus like a Modbus RTU or CANopen >> difference between sending a request and answering it is not that large. >> Few remarks - we currently do not have any support beside mentioned sandbox >> project. If you decide to do such thing, it will be a far away from a >> realtime, yet TCP/UDP stuff involving IP routing by definition is not! You >> will still have to invest a ton of time in order to mimic a complete PLC >> behavior. I suppose it might be problematic to keep it up with manufacturer >> tooling, simply cause they can share some libraries or specifications unseen >> by any of us. Also a device behavior can change with firmware upgrade, so >> you have to keep a close look on that. >> If you can sacrifice realtime requirement which is often crucial to >> certification, live with above simplifications and caveats, then >> infrastructure available in PLC4X will serve you better than any other open >> source components available out there. >> >> Before we go too optimistic, a fairly common problems is how devices react >> on read/write operations. Each brand does it in an unique way, some models >> have extended functionality, plus each device report errors differently. >> There is also handling of parallel/overlapping requests which we handle >> partially even in client side. >> ADS for example has an internal notion of an routing table which is somehow >> associated with communication peer, it has support for read single and read >> multiple addresses, it has also support for subscriptions which you have to >> coordinate. If you are not afraid of it, the communication structures will >> be provided by MSpec. :) >> >> I think that this is still a major advantage of MSpec approach and code >> generation framework provided by PLC4X which awaits more use cases. >> MSpec gives us a symmetric read/write operations which we prove through >> serialization unit tests. This is unseen in most of libraries as they >> usually focus on one of the sides - either a client/master or server/slave >> structures and handle only half which is needed by them. A prime example >> could be a S7 client which does a request serialization and reply >> deserialization or S7 server which does request serialization and response >> serialization. Code generated by PLC4X handles both ways. >> Even if we miss a support for making server side framework, its something >> you can definitely do on top of what PLC4X provide. >> An interesting benefit you could get from relying on PLC4X is possibility to >> make a test of different communications for assumed simulation logic. If you >> find a way for example to write a PLC program in some portable way, then by >> mapping such program inputs and outputs to PLC specific communication >> semantics you get a very nice training suite. >> If you search for ie. ANTRL IEC 61131-3 you will find a bunch of grammar >> files allowing to parse structured text programs. From there you "just" >> need to make interpreter working with one of languages supported by PLC4X >> code generators. >> Making a partial toolkit, even for a single brand/product line, is a lot of >> work and code to be made. This code is potentially hard to maintain due to >> various firmware versions, yet nothing really blocks you from trying. Do >> your thing and report your findings if you wish. I am eager to hear your >> feedback. I believe with your work we could improve our client side >> implementations too! >> >> Cheers, >> Łukasz >> >> On 3.05.2022 13:55, Christofer Dutz wrote: >>> Hi Peter, >>> >>> well simulating a real PLC generally would totally be out of scope of >>> PLC4X. I was more referring to the code to extract the program from a PLC >>> and to deploy it somewhere (like in a simulator or in case of Codesys you >>> could run the runtime on a test-server). But there are simulators out >>> there. Usually, the PLC vendors have them. Unfortunately, they usually are >>> not for free. But I know Siemens has various simulators to which you could >>> deploy your program and then interact with PLC4X. >>> >>> Well, I guess you would need to find out how to make a software like TIA >>> portal believe your application is a S7 PLC and then need to implement the >>> parts of the protocol, that we haven't implemented yet. As S7 doesn't have >>> a public spec, you'll have to reverse engineer most of it. And another >>> problem will be that newer S7 devices use S7comm ... to convince TIA that >>> you're a real device, you would probably need to implement the S7comm >>> protocol, which opens a whole new box of worms. >>> >>> All in all, I think the industry would need such a solution, but I also >>> think they haven't realized it yet and therefore are not willing to pay the >>> money for it. >>> >>> Perhaps I'll try this concept out as part of my job, but that will probably >>> only have an effect on the types of PLCs that we use, and I have no idea, >>> if I'll get the time needed to do it. >>> >>> Chris >>> >>> >>> >>> >>> -----Original Message----- >>> From: Peter Saxton <pe...@petersaxton.uk> >>> Sent: Dienstag, 3. Mai 2022 13:30 >>> To: dev@plc4x.apache.org >>> Subject: RE: RE: Scope of using PLC4x as simulated driver for PLC >>> projects >>> >>> Hi Chris, >>> >>> Thanks for the clarification. So potentially PLC4X could drive the tests >>> but would leave the problem of simulating a PLC as outstanding. >>> One other approach I have head about is putting the PLC in a >>> completely virtual environment and then manipulating it by setting >>> values on the Virtual Machine. I don't have much information on this >>> approach just this blog post >>> https://www.plcnext-community.net/makersblog/painful-memories-of-plc-s >>> imulations/ >>> >>> You mentioned that you had though about working on something like this. >>> What would be the rough shape of your solution? Apart from industry >>> resistance what would be the hardest thing to get through in this project. >>> In my area there is a desire to embrace testing and CI probably not CD that >>> seems bold. At least the right noises are being made. We can see how it >>> plays out. >>> >>> Peter >>> >>> >>> On 2022/05/03 08:17:49 Christofer Dutz wrote: >>>> Hi Peter, >>>> >>>> Well, if you want to use PLC4X to communicate with the real or the >>>> simulated PLC in order to execute various test-scenarios: then probably >>>> PLC4X is what you're looking for. >>>> >>>> If you want to extract the PLC program from one PLC and write that to a >>>> simulator, then unfortunately PLC4X doesn't have that focus and therefore >>>> doesn't support this. >>>> >>>> The programming part of automation engineering is what every PLC vendor >>>> implements separately. Sometimes even one vendor has multiple ways of >>>> doing that for their different products. >>>> >>>> However, PLC4X does have the parts that you probably need to implement >>>> such a feature, however it will certainly require reverse engineering for >>>> almost every type of PLC. >>>> >>>> I had been thinking about starting to work on something like what you >>>> describe. However, my idea would have been to simulate just enough of a >>>> PLC for the engineering tool to accept it and to have the Engineering tool >>>> deploy the new program to that instead of a real PLC. This component would >>>> then pass the program to a CI/CD pipeline, just as you describe it. >>>> However, I knew this would be a lot of work and considering how well the >>>> industry accepted my offers in the past, I decided that I won't do this, >>>> as it's not worth it. They haven't even started thinking of concepts like >>>> continuous-integration or continuous-delivery or even testing. >>>> >>>> Chris >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Peter Saxton <pe...@petersaxton.uk> >>>> Sent: Dienstag, 3. Mai 2022 09:35 >>>> To: dev@plc4x.apache.org >>>> Subject: Scope of using PLC4x as simulated driver for PLC projects >>>> >>>> Hi everyone. >>>> >>>> First post here so apologies if my terminology is a bit off, I'm from a >>>> web software background. >>>> >>>> If I want to write behavior tests for a PLC project that already exists, >>>> is PLC4x the right tool for that job or would there be something better? >>>> >>>> Ideally I would be able to export a whole PLC project from a machine. >>>> Start that exported project in a soft/simulated PLC environment and run a >>>> suite of tests against the PLC logic. Ideally at no point would I be >>>> reliant on having the correct hardware. >>>> >>>> Reading through the PLC4x pages I found the section on "Testing (or using >>>> PLC4X without a PLC)". As I understand this this is for testing software >>>> outside the PLC but simulating a PLC. I would like to go the other way >>>> round and test a PLC project by simulating the outside world. I also >>>> looked at the section on the simulated protocol, but again I think this is >>>> for simulating values for a plc4x client. >>>> >>>> Essentially we'd like to write a test saying "when input 1 & 2 are on the >>>> output A is live", and check that the PLC code was going to do this. >>>> >>>> I'm interested in testing against Siemens PLC projects, however for >>>> getting started I would happily run a proof of concept on something like >>>> OpenPLC if that was easier without hardware. >>>> >>>> Cheers, Peter >>>>
