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

Reading subarrays on Omron NJ #430

Open
exzombie opened this issue Jul 19, 2023 · 2 comments
Open

Reading subarrays on Omron NJ #430

exzombie opened this issue Jul 19, 2023 · 2 comments

Comments

@exzombie
Copy link

exzombie commented Jul 19, 2023

IIUC, libplctag relies on fragmented reads to fetch large tags, and that it not supported on Omron NJ. Skimming through the code, it seems to me that automatically splitting large tags into smaller chunks to be read with non-fragmented reads (service code 0x4C) does not fit the libplc architecture very well; I'd be happy to learn that I'm wrong about this, though. In any case, currently, this splitting into smaller "subtags" must be done by the client. I think that's perfectly fine, but then, libplctag should provide the means for the client to do so, which is not currently the case.

Specifically, large arrays need to be fetched in several chunks. Currently, libplctag offers two options: fetch the entire tag, or fetch single elements. The first option does not work when the array is larger than the max response size of 1996B, the latter option results in reads that are too small; even with packing enabled, the performance is not good.

A better solution is to fetch the array in several chunks, larger than a single element but smaller than the max payload size. Omron NJ supports that with service code 0x4C, based on their documentation. In libplctag, this is done by specifying the number of elements for the tag. For example, to read elements 16-24, the tag name would contain name=MyArray[16]&elem_count=9.

However, for some reason, libplctag explicitly disables such use. In ab_common.c, we have

    switch(tag->plc_type) {
    case AB_PLC_OMRON_NJNX:
        if (tag->elem_count != 1) {
            tag->elem_count = 1;
            pdebug(DEBUG_WARN,"Attribute elem_count should be 1!");
        }

I wonder why this is so. I see no reason for this limitation. I've looked at #171 which introduced this, but the description is unclear to me. I tried removing the line which forces the element count to 1, everything appears to work. When the starting element and the count are specified properly, the read works. If they are specified incorrectly, the PLC returns PLCTAG_ERR_BAD_PARAM.

So, I propose to remove this limitation. Unless there is something I missed?

@kyle-github
Copy link
Member

Hi, thanks for using the library. I don't have an Omron on which to test. If you have one, I would be very happy to experiment to find out what to do!

The original Omron code was donated by a user. From what we could determine, the entire array (at least that part that fits) was returned regardless of what was placed in the element count. At least on some of the tests that were done, an error was returned from the PLC when the element count was not one (1).

As to the size of the returned result, while the total result size appears to be negotiated to be about 2k, each individual return was limited to something much smaller.

Note that this was all a few years ago and perhaps Omron has updated the firmware to be more compliant with Allen-Bradley/Rockwell?

Can you try to get partial arrays using counts of 2 or some small number, but greater than one? If you use the PLC type of "micro800" you will be able to provide element counts, but the fragmented read will not be used.

If you can test this, please set the debugging level to 4 and capture the output.

What version of the library and what OS and compiler are you using?

@exzombie
Copy link
Author

Interesting. As I noted, this unit (NJ101-9000) has no issues with elem_count greater than 1; I have removed the override from the libplctag code, so I can test with the omron-njnx PLC type. I'm using the release branch of libplctag (currently equivalent to v2.5.5) on Linux.

I tested with an array of 1000 elements, 204 bytes each. Using the modified libplctag, I created 112 tags of 9 elements each (except for the last tag, of course) and checked that the data that arrived contains the correct values. It does. The log is attached.

If I understand you correctly, it used to be that reading from MyArray would have returned the first 9 elements. That is not what I see now:

  • Creating a tag for MyArray returns PLCTAG_ERR_TOO_LARGE.
  • Creating a tag for MyArray&elem_count=2 returns PLCTAG_ERR_BAD_PARAM.
  • Creating a tag for MyArray[1] works.
  • Creating a tag for MyArray[1]&elem_count=2 works.

test_subarray_read.log.gz

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

No branches or pull requests

2 participants