1. If I use N10:121/0, N10:121/1, N10:121/2 etc is it not still arrays?
In the screenshot you posted, you have a PV tag (it's a bit fuzzy, so there may be a typo): "chaut_961a" which is a bit array, length of 2, starting at N10:42/6. That is, this tag reads only N10:42/6 and N10:42/7, and calculates an integer value (0-3) based on the state of those two bits.
Thus this "bit array" is actually an "integer", but not a 16-bit integer, merely a 2-bit one.
Unfortunately, FT ME doesn't know how to handle "demi-bytes", is reads whole addresses -- Bits or Words. So you need to do in the PLC what PB32 could do natively, and create an entire 16-bit word where only the first two bits have any meaningful information and the rest are zeros.
I also see that you had another tag, ¿¿ comp1_pic961a ??, that was also in N10:42, but using bits 2 & 3. Those two bits would be the first 2 bits of a wholly different word from the chaut_961a.
It wouldn't surprise me if there were several bit-pairs N10:42, all dedicated to the status of 961a (whatever that is). You might want to keep them near each other when you reorganize. Or not. It's really up to you.
De gustibus non est disputandum, as they used to say.
2. Is the above rung branched or two different rungs as I guess? (just to be sure)
My intent was to put them on the same rung, as parallel branches, just to "keep them together" programmatically, as a hint for some future programmer.
They were also my third (and least preferred) method to redo the code. My first is to do a search/replace, so that there is only one bit with the same meaning. The second is to create a series of BTD commands, which look weird, and again provide a hint to a future programmer that you are deliberately trying to keep these two bits together in a single word.
3. The Original Programmer used Comparisons (e.g. GRT) on same rung as conditions to most of the OTE's with bit array Tags on the plc code. Does it have any effect as per the statement; ''Check to see if he does any comparisons or math at the word level''.
Not necessarily, and probably not. If I'm guessing right (with the requisite kilo of salt), N10:42 has a lot of status info on 961a. It could be that the "Heathly" status is for all those bits to be off. ***IF*** so, then he could have a "NEQ N10:42 0" instruction in his code, where he looks to see if 961a is unhealthy, and if it is, do something.
If you scatter those status bits into N10:121, N10:122, etc., then the NEQ won't work, which means either don't do search/replace, or rewrite that NEQ statement with a FSC or somesuch.
4. Those bit arrays with bit 0 e.g. N10:40/0 can I just leave them the way they are?
Yes. Data types that are Bits, not Bit Arrays can stay just as they are. It depends on how your OCD is; If I'm moving things around anyway, I'd probably bite the bullet and move everything, just to keep the addresses together. But that's me; I can make Adrian Monk seem like a sedate fellow at times.
5. Finally, what about this error; ''Bit and LSBit triggered alarms that used a Trigger Tag with a Bit data type will only be able to trigger a single alarm after import'' what should I do to correct it please?
This one requires a different solution. Let's say that your original programmer had all his alarms in B13, and had a bit array of 128 (8 full words) in a tag called "ALARM". There was a way (and I don't remember what it was now) to reference the individual bits of the bit array tag; perhaps ALARM.22, in the trigger field of the alarm configuration.
What you'll need to do now is to create 128 new tags, one for each unique alarm, and link it to the corresponding bit in B13. When you go to the alarm configuration on the Trigger tab, you will reference each of the new tags instead of the bit array tag.
There might be other, cleaner methods to do the conversion, but without having both systems to play with -- PB32, FTV ME & the PLC -- I'm not going to guess.
The PV alarm configuration is .CSV exportable & importable. Excel is your friend. It'll make the conversion relatively painless.