Ethercat compact RIO slave I/O ordering issue

[parsec43]

When creating names for I/O channels within the project, for some reason, channel names with numerical suffixes (e.g. 1.1.1) are treated differently and out of alphabetical order to the more conventional channel names. Then when performing a programattic block read of the card, the channels and data are again ordered differently (somewhat alphabetically, prioritising suffixed channel names). Images are attached in lieu of a tedious explanation of the mechanics of this bug/"feature".

This issue only affects ethercat slave variables, and does not seem to affect channel names for I/O in the master CRio, which makes the phenomenon so much more puzzling.

Does anyone know why this occurs or how to turn it off? Or do I just need to avoid these numerical suffixes?

It is very frustrating because not only does the project seem to apply aribtrary sorting to channel names, but arbitrary (inexplicit) sorting is also applied when doing a programmatic shared I/O variable read.

[Kelle]

It looks like when you use 1.1.1 instead of 1_1_1, the ordering prioritizes the portion after the last "." instead of going from left to right.  Thus, the order is ****...1.1.1, ****...1.2.1, ****...1.3.1, ****...1.4.1, ****...1.2.2 instead of ****...1.1.1, ****...1.2.2

It's probably best to avoid the dots in the name.  Seems like when reading in programmatically, it is treating the whole thing as a string and not the last number as an extension as what the project explorer seems to be doing, thus the difference.  It looks like the read is ordering it in alpha-numeric order.  You could try altering the XML file that defines the channels, as the project explorer probably just pulls the order from there.

[parsec43]

Yes, that's one issue. The other issue is that the order is inconsistent between what is displayed in the project pane and the programattic block read of the I/O container using the Scanned variable read VI. The inconsistency seems to defy logic, and is rather unpredictable.