*** INVALID 16#40 - what this means ??

2020-02-27T20:51:13.637000Z

Hi, @pnn .
201709251730 UTC+8
I change the CoDeSys v2.3--Project--Options--Build--Number of data segments to default value, and the problem is gone.

210709251400 UTC+8
I encountered a similar problem, indicating ' INVALID: 16#08 '. Have you solved your problem, and what is your solution?

*** INVALID 16#40 - what this means ??

2020-02-27T20:51:12.248000Z

yes, sC34M and sC34F are BOOL's, these are the names of two physical inputs - declared directly in the PLC configuration.

Thanks for reminding me about SEL, just forgot about it. It's indeed the better choice in this case and I'll use it.
But still the question remains why this INVALID 16#40 appears, as the use of MUX is technically valid. And especially why it disappears if I use a copy of a variable instead of the variable itself.
BTW the problem is not in the conversion - I tested to attach a BYTE variable (not obtained via conversion) to the first MUX input, and the output was still invalid.

*** INVALID 16#40 - what this means ??

2020-02-27T20:51:10.858000Z

Is sC34M a BOOL?
is sC34F a bool?

instead of MUX use SELECT (it needs a BOOL input, this way no conversion needed)
please have yur names to the convention (x foor BOOL etc.

*** INVALID 16#40 - what this means ??

2020-02-27T20:51:06.944000Z

Hi,

I have a really weird problem with a CFC program, please check attached image.

There is a MUX box which switches between two BOOLS(physical inputs), and sends the output to a BOOL input of a FB.
When online, Codesys 2.3 displays the MUX output (here sensorFWD FB input) as invalid - there is text *** INVALID 16#40 next to it, highlighted in red. Modifying MUX inputs has no effect at all.

The problem is not in the FB but in the MUX - if I attach MUX output to a locally declared BOOL, this BOOL is displayed as INVALID as well.

What is even more strange is that if I first copy one of the physical inputs (sC34M in the picture) to a local BOOL(copy_of_sC34M), and then then connect this BOOL copy to the MUX input (instead of the physical input, as displayed in the picture) - the problem disappears ??? MUX works as expected, no INVALID etc. How could that be ?

I did project check for overlapping memory areas and concurrent access - no results. As far as I can tell, the problem is not in the physical inputs either - they are read correctly, the PLC doesn't display any problem. Project has only one freewheeling task, PLC is Festo CPX-CEC-C1.

What could be the explanation for this?
I have found some sort of a workaround, but don't want to leave it like that.

Another question is, how do I detect issues like this? I found this *** INVALID 16#40 by chance, there wasn't any indication for a problem from the PLC/Codesys.

Thanks

Recent posts to *** INVALID 16#40 - what this means ??

*** INVALID 16#40 - what this means ??

*** INVALID 16#40 - what this means ??

*** INVALID 16#40 - what this means ??

*** INVALID 16#40 - what this means ??