Re: Similarities between PLC and Arduino programming experiences
Hi Peter, I think you will find multiple answers to these concerns in the forums dedicated to Automation. The openplc open source project answers your first question. I sent you the link in a previous email. I have had to see some projects implemented with OpenPlc applying advanced control techniques for the Oil industry, running on PC Embedded. Although OpenPlc has basic libraries, you can take it to quite complex applications, and you do not pay development software licenses. When it comes to these developments, generally the clients, who are the ones who pay, must be answered "what, when and how" their specific problem will be solved. Therefore, the training, level of experience and expertise in the area of knowledge to be developed are of weight for the assignment of the work. Regarding your second question, I dare to think that the models are very similar, clearly depending on the specific process that you are going to control. In the end, you must always ensure that your control box (plc or embedded) responds in the time required by the process, if not, you will have a serious problem (ask the programmers of the Boeing 737 MAX). My grain of sand, El lun, 9 may 2022 a las 14:48, Peter Saxton () escribió: > I was surprised to see that PLC4x supports the Firmata protocol. This is > something that is often used for talking to arduino scale embedded devices. > I have been part of several discussions around where it would be possible > to use alternative solutions to the traditional and expensive PLC. Has the > development of a common API interface, that of PLC4x, over different > hardware controllers given any insight on the following questions: > > 1. Why is there no established ecosystem for hobbiest level PLC > programming? If you can't afford a PLC and all the associated licenses what > do you fall back on to, is it embedded systems? Does that require moving > from the standard PLC languages/environments for C/C++ > 2. PLC programming and embedded programming models appear very different. > For example PLC programming model relies on a cycle or read all inputs at > once, execute scan cycle, write all outputs at once, in arduino embedded > reading a pin is executed at call time. Are these two models incompatible > or more similar than they first appear? > -- *CEOS Automatización, C.A.* *GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,* *PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,* *FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI* *Ing. César García* *Cel: +58 414-760.98.95* *Hotline Técnica SIEMENS: 0800 1005080* *Email: support.aan.automat...@siemens.com *
Similarities between PLC and Arduino programming experiences
I was surprised to see that PLC4x supports the Firmata protocol. This is something that is often used for talking to arduino scale embedded devices. I have been part of several discussions around where it would be possible to use alternative solutions to the traditional and expensive PLC. Has the development of a common API interface, that of PLC4x, over different hardware controllers given any insight on the following questions: 1. Why is there no established ecosystem for hobbiest level PLC programming? If you can't afford a PLC and all the associated licenses what do you fall back on to, is it embedded systems? Does that require moving from the standard PLC languages/environments for C/C++ 2. PLC programming and embedded programming models appear very different. For example PLC programming model relies on a cycle or read all inputs at once, execute scan cycle, write all outputs at once, in arduino embedded reading a pin is executed at call time. Are these two models incompatible or more similar than they first appear?
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: Need help for canopen in kafka
Hey Naveen (hope its fine), I can't provide you much of the input in regard to kafka, but I can guide you, at least briefly, on details. 1. Kafka component in PLC4X is just an PLC4X api caller, so you need to configure it. It works independently of the driver. Please check examples, I think it might be a "kafka connect" thingy. https://plc4x.apache.org/users/integrations/apache-kafka.html Connection properties mentioned in webpage can be found here: https://github.com/apache/plc4x/blob/v0.9.1/plc4j/integrations/apache-kafka/config/plc4x-source.properties 2. CANopen driver is a CANbus "client" which is capable of sending requests and listening to bus communication. For more detailed docs on query syntax please visit: https://plc4x.apache.org/users/protocols/canopen.html Please be aware that this driver is not a full blown CANopen master so you need to set them in automatic boot mode. PLC4X does not verify and assure that state of nodes is fine for SDO/PDO transfer. Additional note - plc4x source processor does not support subscription API which is most effective for CANopen. You might need to try first with SDO (request-response) and see if everything assembles into a working pipeline. Please keep in mind that CAN support so far is limited only to linux platforms. Best, Łukasz On 9.05.2022 13:35, Reddy Naveenkumar wrote: Hi Team, I am doing some feasibility study, can you please provide some documents related to canopen in kafka. Best Regards, Naveen Kumar.R.
Need help for canopen in kafka
Hi Team, I am doing some feasibility study, can you please provide some documents related to canopen in kafka. Best Regards, Naveen Kumar.R.
