Re: Scope of using PLC4x as simulated driver for PLC projects
Hello, The open plc project gives you the tools you need, a CPU core that runs as a service on Linux and Windows, plus it has a full IEC IDE for development. I think that is the way you should go. https://www.openplcproject.com/ If you are adventurous, in this project you will find a Modbus server, with which you can develop your application in java (like OSGi Bundles), incomplete but battle tested. https://github.com/glcj/Merlot And if you're not adventurous, I recommend using CodeSys where the IEC IDE is free, which includes the PLC simulator for Windows and Linux. The PLC only runs for two hours without licenses, but you can purchase one for a BlegleBon Black or Raspbery Pi, for about $100. https://de.codesys.com/ The big brands (Siemens, AB, IsaSoft, etc) also have their trial usage options, which you can try for about 15 days. my grain of sand, El lun, 9 may 2022 a las 14:09, Peter Saxton () escribió: > 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 > >> 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 >
Re: Scope of using PLC4x as simulated driver for PLC projects
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 >> 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
Re: Scope of using PLC4x as simulated driver for PLC projects
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 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.
RE: Scope of using PLC4x as simulated driver for PLC projects
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 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
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
RE: RE: Scope of using PLC4x as simulated driver for PLC projects
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 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-simulations/ 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 > 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 >
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-simulations/ 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 > 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 >
RE: Scope of using PLC4x as simulated driver for PLC projects
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 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
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
