The quick answer is no.
The long answer is.....
I'm afraid there is no way to modify the Comm Format of a module once it has been entered. This is because this choice affects which Module-Defined Tags are created.
So switching between Rack-Optimised and Standard connections is not possible, only deletion and re-creation is possible.
You can do this off-line, simply delete the modules and re-install them into the I/O configuration in the correct format.
Now - in theory - all should be well, BUT.....If any code is addressing the Rack-Optimised tags for the modules, you will have to convert them to the standard tags.
To Explain...
An I/O module Tag is made up as follows - location:slot:type
When in the same chassis as the owner controller - e.g. Local:3:I
In a remote chassis, the only thing that changes is location, and it changes to the name given to the remote chassis communications module in the I/O configuration "tree". - e.g. Filler_CN2:3:I.
However, when the remote comms module is added with Rack Optimisation chosen as the Comm Format, then additional tags are created - Filler_CN2:I and Filler_CN2:O
These tags contain the I/O data for all the digital I/O in the remote chassis - in effect the Comms Module is acting as a remote I/O Adapter.
In the above example, an Input Module in slot 3, the data from the module is in the Filler_CN2:I tag, in element 3 of an array called Slot. Input point 0 of that module is then Filler_CN2:I.Slot[3].Data.0
Programmers should use the standard for addressing I/O tags, no matter where they are in the system - location:slot:type.
However it don't always happen, I have seen programmers use the Slot[x] array in the optimised tag to get to their I/O points.
So how does the system allow programmers to carry on using the location:slot:type addressing ?
When you insert the module into the configuration, it creates the same tags Filler_CN2:3:I, Filler_CN2:3:O, and Filler_CN2:3:C as normal, but (assuming you request rack optimisation for the module), it then automatically aliases the I and O tags into the Rack-Optimised tags, to address where the data really is.
So, back to your dilemma, you want to change a Rack-Optimised module to a direct-connect module (you could try to explain why you are doing this?).
Step-by-step....
1. Before you start - verify the controller has no errors.
2. Delete the module you want to convert from Rack-Optimised to Direct.
If you did a verify controller now, you may get errors where the code is addressing I/O tags that don't exist anymore. If you do get these errors, then all is good, as it indicates the programmer has adhered to the location:slot:type addressing.
But, I've seen enough sloppy programming to know this can happen, someone may have addressed the I/O points directly via the Rack-Optimised tags. If you cross-reference the location:I, and location:O tags, you will quickly find if that has happened, and you will need to covert these references to the standard location:slot:type addressing.
If you don't convert them, then there is no justification in putting the module in as not Rack-Optimised, the I/O data will still be using the optimised connection, at the RPI rate specified for the comms module.
3. Put the module back into the configuration, choosing Input (or Output) Data.
4. Verify the controller again.
All the previous errors should disappear, and the project will be ready to run.
