After more experimentation with the CFG utility, I discovered a peculiar anomaly that may be part of the problem.
In the original NI .icd files, the termination character is \r. Using the Serial Setting dialog in the configuration utility I replaced these \r values with "/x03" in the serial dialog -- and please notice the direction of the slash character. Although this appears to have been a typo on my part, that detail appears to be significant.
When using a forward slash "/" character before the "x03" for the termination character, the serial transcation works, but a timeout error is generated. Regardless of how long or short the timeout period, an error message is always returned.
Now, after looking into the .icd files discovering my apparent typo, I reversed the slash direction, changing "/x03" to "\x03". Based on the Basler documentation, I would have assume this to be the correct format. Oddly, if this reverse slash is used, no error message is returned. However, the returned string is incomplete. Only half of the expected message is returned. For example, if I request the current settings for Timer 1, the camera returns everything up to, but not including, the 3 data bytes. Everything after the data bytes is also missing.
I don't know if this peculiar behavior is specific to the 1426. I will investigate this with the PXI-1428 framegrabber later today to see if both boards respond in the same way. Either way, it appears there may be some discrepancy between Basler's definition of the .icd file and NI's definition -- at least in terms of which direction the slash character should go. Or perhaps it could be something as simple as a programming typo (either in the camera firmware, or in the framegrabber serial spec). I can see that it would be quite easy for a programmer to make the same mistake I did -- typing "/" when they really meant to type this "\". Just a thought...
Anyway, thanks again for your help. I've constructed a LabVIEW VI that filters the timeout errors, and it works fine. If this is the best we can do, that's okay. Ideally, I would still like to find a solution that returns the full camera string WITHOUT the erroneous error message, but we can work with it this way, if necessary.
The next step is to check the 1428 and see how it behaves.
Anyway, thanks again Ryan.