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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
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.
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.
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?