Lazarus
Announcements => Third party => Topic started by: avra on August 14, 2018, 10:28:59 am
-
Pasettimino
Pasettimino is a very lite native Pascal ethernet communication library for S7 Siemens Simatic PLC. S7 200/300/400/400H/1200/1500 and LOGO 0BA7 PLC families are supported. You can read PLC info and status, start/stop PLC, read/write from/to any PLC area (full access to I, Q, M, DB, C and T), get a list of existing PLC blocks (OB, DB, SDB, FC, SFC, FB, SFB), read CPU product number and firmware revision, read leds, read/write PLC time, and get PLC battery status. It is a greatly extended FreePascal port of Arduino Settimino library (http://settimino.sourceforge.net/) with Lazarus examples, and besides Synapse (http://wiki.freepascal.org/Synapse) for ethernet communication it does not have any other dependency (although example projects themselves need BitHelpers (https://bitbucket.org/avra/bithelpers/src/master/) package). Pasettimino is running 24/7 in industrial environment since 2016. If you need more heavy weight S7 ethernet/serial libraries, S7 PLC protocol simulator (https://bitbucket.org/avra/pasettimino/downloads/snap7-server-simulator.zip) or S7 rich graphical client (https://bitbucket.org/avra/pasettimino/downloads/snap7-rich-client.zip) then take a look at Snap7 (http://snap7.sourceforge.net/) and LibNoDave (http://libnodave.sourceforge.net/). They both have Pascal wrappers, but unlike Pasettimino their core is not native Pascal.
Info and Download
https://bitbucket.org/avra/pasettimino
License
Pasettimino is released under LGPLv3 (https://www.gnu.org/licenses/lgpl-3.0.en.html), the same as the original Settimino license (http://settimino.sourceforge.net/licensing.html), so commercial use is allowed (License explained in plain English (https://tldrlegal.com/license/gnu-lesser-general-public-license-v3-(lgpl-3)).
Author
Made by Avra (Zeljko Avramovic). Big thanks go to Davide Nardella, the author of the original Settimino and Snap7 libraries.
-
Thanks for this great news :-)
A native pascal system is always better to understand and to fix :-)
-
Thanks for this great news :-)
You are most welcome!
A native pascal system is always better to understand and to fix :-)
That was my main motivation. Original library had a bug where wrong running state was reported on redundant S7-400H PLCs. I have fixed it in Pasettimino and reported back to the author of the original Settimino library so he can fix it too. Understanding it more and more, I was also able to implement some quite unique features like getting status of all PLC leds (even on redundant CPU pairs) and getting status of power supply memory backup batteries.
-
@Avra, thank you very much!
-
Looks very nice and tidy! Good job.
One remark:why synapse and not fcl-net?
You know I myself prefer synapse in most cases :D, but from what I see in the code fcl-net is more than enough here and it is in the standard distribution.
So it removes a third-party dependency. Also: can the bit helpers be merged/patched into sysutils? The number of bit-tinkerers is fastly growing with so many people having at least one Raspberry Pi or the likes. And once they have that, half of them start using arduino's :D 8-) O:-)
-
@Avra, thank you very much!
You are most welcome!
-
Looks very nice and tidy! Good job.
You are very kind!
why synapse and not fcl-net?
I use Synapse in applications running 24/7, and that's what I am used to. Besides, although I do not care much for Delphi compatibility any more, if someone makes Pasettimino Delphi compatible I would be glad to include the patch. I do not have anything against fcl-net. I just do not have any experience with it.
can the bit helpers be merged/patched into sysutils?
My end goal is to try to make BitHelpers part of FPC, which could probably have been guessed from it's license. I was thinking about simple unit donation, although sysutils idea also seams tempting. I wonder what would FPC developers say about it? I see less includes and out of the box experience as benefits doing it that way. Are there other benefits that I am missing? SysUtils is platform specific, so maintenance would require more effort even if BitHelpers would be split into interface and implementation include files, and there is no way I could test for all the platforms. Maybe there are some other drawbacks as well. Anyway, I do not have time to deal with that now so it will have be filed for a while.
-
In s7pas the unit windows is used, so it is not compilable on linux (arm) :-(
Sometimes you use bool and sometimes boolean. In windows bool is defined as winbool and winbool is longbool. Is there any reason not to use a compatible Boolean like WordBool, ByteBool or LongBool and remove the depency of windows. Problems with the windows copymemory too. A soloution is to use Move(<source>,<Destination>,<size>) witch is IMHO plattformindependent.
Andreas
-
SysUtils is platform specific, so maintenance would require more effort even if BitHelpers
Well. No. sysutils is only partially platform specific. The type helpers are also implemented in a platform independent way.
(directory rtl/objpas would have told you it is not platform!). I think it could go in sysutils.
-
In s7pas the unit windows is used, so it is not compilable on linux (arm) :-(
Thank you for the code review! I will put both linux and booleans usage on my TODO list and see what can be done when time comes (not quite soon since I am very busy these days).
I think it could go in sysutils.
You are right. After another look there seams to be a way to make BitHelpers part of FPC without platform specific maintenance mess, so I will probably go that way. Thanks for pointing this out one more time!
-
UPDATE:
1.2.1 Added connection timeout. Removed Windows dependencies. Fixed compilation on Linux for FPC 3.0.4. Homogenization of boolean types. Fixed tabs code relic.
Thanks to Victor Campillo for the contribution! ;)