I've got an application that uses several large arrays. I am able to write variables to the application from a python script, but when I try to read a variable, I get an exception: "Value cannot be retrieved: Too many expressions."

Whether I get this exception or not seems to depend on the total size of my variable list. It does not seem to matter if I split my variables into different GVLs or POUs - once I hit some threshold, any read will result in the exception.

So, anybody seen this before? Any suggestions how to get around it?

Hi DavidWSteadman.

That exception is thrown if you want to read too many expressions or the result does not fit into the answer of the PLC.

If you read many different expressions with the same instance of the online application you get that exception because the online application keeps all previous expressions alive to speed up the next read of the same expression. As workaround for now you can use a new instance of the online application after the exception occured or you could limit the amount of expression used with each instance.

This should not happen so I add the bug report CDS-43982 to our system.

BR
Martin

Hello Martin,

I work with David and developed the automation framework for the codesys application validation. Though David has clearly written about the exception we're facing, I would like to elaborate a little on that.

The test automation framework is capable of pushing/fetching 100s of inputs/outputs to and from the application/block under test in the codesys environment. It works just fine in the simulation environment, but when we download the same on a real HFX controller, the exception occurs. In fact, it's not like the inputs are not getting pushed to the application/block, they do and the execution with those inputs happens, and the output arrays get populated too. BUT, during execution if we expand the output arrays in the GVL tab, we can see that those got populated, if we don't expand those it shows the Exception "Value cannot be retrieved:Too many expressions" under each item of the output array. Even after that the output values can't be read. The same is with the input arrays too. Please note that we're not reading any previous expressions using the same instance, rather as I mentioned, all the "previous" expressions are stored in the form of an array and we're just trying to read that array.

As you talked about in your reply, I've managed to rewrite the script yesterday with limited amount of IOs in each instance and running the same application in a loop to cater all the sets of IOs. Though this approach is a workaround but if we use it to test applications that take waveform inputs or processes inputs to calculate other stuff (like acceleration calculation using velocity as an input), the results won't be that accurate.

I'm trying to solve/identify how I can fetch the outputs even though they're getting populated in the output array and why still the exception comes.

Regards,
Vikash

Originally created by: M.Schaber

The difference between the simulation mode and the real hardware may be due to a different size of the communication buffer - most probably, the real PLC has a smaller communication buffer. limiting the amount of data which can be retreived or sent within a single packet.

Depending on the device description, your device may allow monitoring to split up the data into several packets, but this comes at a cost: the data you will receive may be from different PLC cycles.

Thanks Mr. Schaber for your reply.

But as I wrote earlier, the IOs are indeed getting populated but can't be fetched. If this would've been a communication buffer limitation then how come the inputs are all getting pushed in?

Do you think using HFX48m instead of HFX12 controller would help?

Regards,
Vikash

Hi vikashmondal.

What version of CODESYS do you use? Some improvements were introduced with CODESYS V3.5 SP4.

vikashmondal hat geschrieben:
But as I wrote earlier, the IOs are indeed getting populated but can't be fetched. If this would've been a communication buffer limitation then how come the inputs are all getting pushed in?

I talked to my colleague and there is no difference in the way the online mode of the editor fetches the values. You can add as many expression as you want but only the ones which fit into the buffer are fetched. The others return an exception if you request its value.

So even if you use the method read_values(<list of="" expressions="">) you can't fetch more than the limit of the buffer. The bug in the scripting prevents you from reading a single value until you use a new instance of the online application.</list>

vikashmondal hat geschrieben:
Do you think using HFX48m instead of HFX12 controller would help?

Sorry, I can't help you with that.

Have you thought about using IEC Unit Tests for that problem? Or a combination of both?

BR
Martin

Hello Martin Keller,
hello to anyone who could help me.

Although this discussion took place almost 3 year ago, I am facing the same or a similar problem. I am using CODESYS V3.5 SP10.

I want to call read_values() to fetch a big data amount. It would take too long using read_value() inside a loop. I need to read 20100 parameter values which parameter names I have gathered inside a list which I hand over by calling read_values(). As workaround, I slice the parameter list and call read_values() for these inside a loop.
I am getting two different errors:
(1) "Wert kann nicht ermittelt werden. Zu viele Ausdrücke." ('Value cannot be retrieved: Too many expressions.') - I am getting this if the list includes more than half of the total parameter list.
(2) "Der Wert des Ausdrucks kann nicht gelesen werden." ('Value of the expression can not be read.' or similar.) - I am getting this if the list includes less then the half of the total parameter list.
(I did not evaluate the exact border. It could be quite different to the half of the list size.)

If the list size or data amount were predictable, read_values() can handle faultlessly, I could live with it. Calling read_values() e. g. 20 times is quicker than calling read_value() 20100 times. But as you explained, it depends on the size of a dynamic buffer.

You wrote that you had generated a bug report. Are there any solutions or recommentations on this topic meanwhile?
E. g. is it possible to read the buffer size, so I could adjust the list slices during run time?

Thank you very much for your help in advance.

Best regards,
Ralf