Skip to content
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

Notification when all of the tags have been read with "auto_sync_read_ms"...? #439

Open
ArjanVer opened this issue Nov 14, 2023 · 5 comments
Labels

Comments

@ArjanVer
Copy link

Hi,

thanks for developing this very nice library!
I am currently developing an application based on libplctag which is able to connect to various PLC types. The user here can select a reading cycle which will be then passed to the "auto_sync_read_ms" parameter.

I am looking for ways to detect when all of the configured tags have completed reading for in one cycle.
For example PCCC PLC models like SLC and MicroLogix only support around 100 tags for 1 second, but theoretically a user could configure reading 1000 tags for 1 second.
This will stretch the reading time, since the PLC will be under load and won't be able to read all of the 1000 tags in the given 1 second. Now I would like to detect this and give a feedback to the user, by tracking the time it takes for all of the 1000 tags to be read for example. The library handles each tag individually, so that it is difficult to get a notification when all of the 1000 tags have been read.

Is there any way I could achieve this with the current implementation?
I thought of tracking the time for the first time without "auto_sync_read_ms" and then setting "auto_sync_read_ms", however this is not very good since the fetching time could change in future...

@timyhac
Copy link

timyhac commented Nov 14, 2023

One thing to keep in mind is that not all tags will complete in the same amount of time, so you might need to have different cycle times for different tags (i.e. individual DINT tags could take 50ms per read, but a huge array of 1000 DINTs could take several seconds).

If it is important that each tag is read only once per cycle, then you should instead use the asynchronous read (i.e. where timeout=0). You can use your own periodic timer to start the tag reads once per cycle, and perform timeout checks either on a per-tag basis or for the entire set of tags.

Many other things can go wrong besides the read taking longer than expected, so you may consider performing additional logic to check for other failure modes.

@kyle-github
Copy link
Member

The idea of a cycle is not really something that the library understands. Each tag is treated independently. Internally there are some shared things (like the connection to the PLC).

As @timyhac says, if you want to have your own concept of a cycle, you need to impose it by using async mode.

@kyle-github
Copy link
Member

Was any of this any help?

Unfortunately, PLCs like Micro8xx, PLC/5, SLC 500 and MicroLogix do not support multiple requests per packet to the PLC. Only Control/CompactLogix (and to an extent Omron) support this.

The automatic tag reads are only "best effort" and not a guarantee.

@ArjanVer
Copy link
Author

Thanks for your inputs @timyhac and @kyle-github . I will see how to implement the required function.

@kyle-github Yes, unfortunately the PCCC PLCs do not support multiple requests per packet. However, there is something called "block reading", which allows consequent tags to be read at once (or in a more performant way). For example you could read tags like N7:1 to N7:9 in a more performant way (block reading) and not one by one.
Is this functionality available for libplctag? I did some testing but it doesn't seem so, any ideas if this could be implemented easily?

@kyle-github
Copy link
Member

I am not sure what you mean by block reading. You can read more than one INT at a time from an INT data file (for instance). Just set the number of elements higher than one.

If that is not what you are talking about, do you have a pointer to any documentation about block reads?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants