-
-
Notifications
You must be signed in to change notification settings - Fork 246
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add python asyncio wrapper around as_ methods #164
Comments
Okay, it seems that we (python-snap7) are not responsible for that. If I understood the snap7 Code right the order is like this:
It looks like it is concurrent, but in another style as I thought. =/ From the Python side, I could imagine to turn these functions still into async and await the result of what ever happens inside there(because we are waiting and we want to be informed if something received). In such a scenario, we would maybe faster/more flexible. If I got any response in the snap7 sourceforege forum, I will let you all know. |
Could somebody may check async requests with other stations (I just have the 1200 one)? Maybe it is caused by the reduced support for this hardware.
This would may help circleing the root of this evil. :^) |
I actually don't own a PLC, so I can't help you, unfortunately. |
I don't think adding 'async' to snap7 library calls is useful.
A PLC is very simple does only one command each loop. And is many times
slower than a PC./ Python.
A PLC can only do one command at the moment. So if you do async you need to
queue up all the commands to the PLC. But then..
If you create a separate small non async service that talks to your PLC
receiving commands via a redis / db / message query / zero.mq. and
publishes the the response. Using one while loop.
Then Your main application / business logic send commands to your queue of
choice and subscribe to the PLC responses. You can do all the async you
want. And have multiple instances running or have something separate for
command logging / alarming etc etc.
If you have a lot of logic and a lot of plcs this is way more
understandable IMHO.
Cheer,
Stephan.
…On Wed, Jun 17, 2020, 12:18 Gijs Molenaar ***@***.***> wrote:
I actually don't own a PLC, so I can't help you, unfortunately.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#164 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAOSMORKTKEQIGUTRYVX3DRXCJ67ANCNFSM4N53PVBQ>
.
|
Ahoi @spreeker , I agree that you are right with the sync snap7 methods. You want to wait until an answer receives. My idea was to add async to the async snap7 methods like as_db_read. While the async request is pending, it would be good for the Python program to do something else, until an answer is received, because the PLC . This would be the philosophy of idle wait like mentioned in the snap7 docs Also because asyncio is a build in library, it would be nice to use, to reduce other extern libraries to implement this use (like twisted, tornado etc.). |
I am a bit confused about what is behind functions like: Line 514 in f82c051
Which async philosophy are they using? And what I want more to know, what is behind this self.library thing... |
the philosophy is described in the snap7 documentation. the library object is a ctypes wrapper around the lower level snap7 shared library. |
From the docs:
I am still not sure what is chosen or how I can select one of the upper three possebilities for the async methods (but Polling would be senseless, because then I can make it sync anyway). There seems to be something missing or is nor clear enough. |
After a while I am back here again. I guess that So either after sending an async request, we could check in a loop if
Another way could be dealing with Snap7Jobs as asyncio Future-Objects, because they seem to be similar in some points. But it would may ends in bigger effort to deal. This would lead to something like:
|
I made some lines but I'm still confused a little bit. So I created an async "waiting_loop" until the async request is done. The Code:
So while just adding an But if I use the waiting_loop, where I check if the job is done, I just get zeros as result. So if I understood this right, |
Because this is still an issue (no check if Job is pending and waiting) in |
at what point shall we close this issue? |
This issue should be closed, when all now existing as_methods are fixed about the return value (or shall be replaced with NotImplementedError) and the corresponding tests are implemented/fixed or set to NotImplementedError as well. |
I've been looking into this a bit, and to avoid the need for polling one should use the blocking (non async) methods available in the snap7 API and call them in a thread pool using the async scheduler. This would look something like this |
I got my station (S1200) last week and had some time to deal with some functions.
The sync functions work like expected, but the async functions receive garbage (mostly zeros).
While debugging I received sometimes the right values, so it seems to be an awaiting problem. I tried to just async these functions, but it seems to not change anything on it's behaviour.
I will have a deeper look under the hood of the plain snap7 or try some workarounds, so that the wrapper may deal with it asyncly.
The text was updated successfully, but these errors were encountered: