Can onboard I/O be remapped on a BRX?

[stoic-one]

I'm using a 36ER3 for development purposes while waiting on a DM1E to arrive, and would like to either disable or move the I/O on the base unit.

I/O mapping error E094 - The software is telling me it can't be moved because the "on-board high speed outputs/inputs cannot be mapped, but I'm not using that function. Is there any way to get around this?

[RBPLC]

Currently how many I/O do you have? In general I think it's better practice to write your program using variables and use the MAPIO command at the top and bottom of the scan to read in inputs and write out outputs. If done this way there is a single table to update or you can completely disable physical I/O with one $off if desired.

[stoic-one]

It's not a question of mapping per se.
I'm asking because the intended target processor, which is back-ordered, is a non I/O unit. That means on my current base x0-23 and y0-15 seem to be fixed, even though they would be assigned to an actual card if I had the proper CPU. I have the cards but not the right CPU and I'd like to test it without remapping everything... This all stems from product availability/supply chain problems.

[RBPLC]

For example:
Use C0 (Nickname=Contactor) everywhere in your logic that you would need a contactor. This allows you to test all logic that needs the contactor. At the bottom of the scan use the MAPIO to map C0 to whatever physical output the contactor happens to be on. Say for example on the non-IO unit this would be Y0. On the current setup this would be Y16. When you get the new unit change Y16 to Y0 in one location an you're done. Using the replace command you can replace them all at once. Using replace, replace Y16 - however many outputs with Y0 and you're done.

[stoic-one]

You're missing my point here, I don't need the examples, but thanks...  I need to test code and equipment.

Just to clarify, I know what you're talking about re mapping I/O. My problem is that I have existing equipment with I/O assignments and labels that all match, but I can't get around the fixed I/O on the base using I/O that will be designated differently AFTER the proper CPU arrives.

I can map stuff from here to the moon and back, but X0 through 23 and Y0 through Y15 will still ALREADY be used by the base unit I currently have.

[RBPLC]

That means on my current base x0-23 and y0-15 seem to be fixed, even though they would be assigned to an actual card if I had the proper CPU. I have the cards but not the right CPU and I'd like to test it without remapping everything

You are saying that you want to put an additional input and output card on your 36 BRX which you currently have on hand. When you receive your non-IO BRX you will take the input and output cards off of the 36 BRX and put them on your non-IO BRX. Is this what you're saying?

[stoic-one]

That means on my current base x0-23 and y0-15 seem to be fixed, even though they would be assigned to an actual card if I had the proper CPU. I have the cards but not the right CPU and I'd like to test it without remapping everything

You are saying that you want to put an additional input and output card on your 36 BRX which you currently have on hand. When you receive your non-IO BRX you will take the input and output cards off of the 36 BRX and put them on your non-IO BRX. Is this what you're saying?

Yeah, see, that's what you were missing...  They're not additional cards, they were purchased to be used with a non I/O base, which is back-ordered 3+ weeks...

I'm trying to use a 36 point BRX to test while I wait for a non-I/O BRX, but the 36 point base allocates built-in I/O and it doesn't look like it can be moved or disabled. Which would mean to test this equipment, I'd have to rewire or re-code, which defeats the purpose...

[stoic-one]

It actually lets you change it in the I/O mapping section of the configuration, but it flags the error noted in the OP during error check, even though I'm not using the "on-board high speed" functionality, and It doesn't look like it can be disabled...

[RBPLC]

Your 36 BRX is already wired in. You want to test your equipment with the current configuration. Whether it's on the 36 BRX or the non I/O with a card, X0 will be the first input on either and Y0 will be the first output on either.

[stoic-one]

Yeah, no, the 36ER is NOT already wired in, it just has power connected and no I/O. The cards are connected to ziplinks, which are wired to field devices.... X0 is the first input on the 36ER, but the first input on the first card falls somewhere after x23, because it has to be above that input for the configuration to be valid. Same goes for Y0...

Meanwhile in my program, Y0 turns on an output connected to nothing, and the feedback from that device goes back to an input which is also connected to, you guessed it, nothing.

[RBPLC]

Just to clarify, I know what you're talking about re mapping I/O. My problem is that I have existing equipment with I/O assignments and labels that all match, but I can't get around the fixed I/O on the base using I/O that will be designated differently AFTER the proper CPU arrives.

I can map stuff from here to the moon and back, but X0 through 23 and Y0 through Y15 will still ALREADY be used by the base unit I currently have.

Not to be rude, but I don't think you're understanding the concept of properly using the MAPIO command in conjunction with intermediate logic in your program. If you just want to use the processor of the 36 BRX and have stuck additional I/O cards onto the right side of it which are currently wired into ziplinks, it's a trivial matter where the the I/O numbering starts with additional cards. In your MAPIO table Y0 would be reassigned to Y16 for testing and then be reassigned back to Y0 when you get the non-IO BRX.     

[stoic-one]

Just to clarify, I know what you're talking about re mapping I/O. My problem is that I have existing equipment with I/O assignments and labels that all match, but I can't get around the fixed I/O on the base using I/O that will be designated differently AFTER the proper CPU arrives.

I can map stuff from here to the moon and back, but X0 through 23 and Y0 through Y15 will still ALREADY be used by the base unit I currently have.

Not to be rude, but I don't think you're understanding the concept of properly using the MAPIO command in conjunction with intermediate logic in your program. If you just want to use the processor of the 36 BRX and have stuck additional I/O cards onto the right side of it which are currently wired into ziplinks, it's a trivial matter where the the I/O numbering starts with additional cards. In your MAPIO table Y0 would be reassigned to Y16 for testing and then be reassigned back to Y0 when you get the non-IO BRX.   

No, I get it, you're trying to help. Believe it or not I truly do understand the concept of mapping I/O. Thing is, if it was possible to remap or disable the onboard I/O in the configuration, I don't have to use the MAPIO instruction, because I just assign the proper addresses to the cards. Which is why I posted the question: "Can onboard I/O be remapped on a BRX?" No software changes are required other than the configuration change.

I don't mind remapping it, I just asked the question, because the software "acts" like it's ok to do that (including letting you save the mapping), right up until it flags that error during error checking prior to download. It's a reasonable question, and may be of use to others, if you don't know the actual answer, that's fine...

[franji1]

The onboard I/O cannot be mapped on BRX.  This restriction is due to the HSIO addressing to never be "remapped" because it is tightly coupled to the hardware I/O (in order for it to be high speed).

Could you go the other route.  Map your desired expansion I/O modules to start at X32 and Y32 on the -36 and eventually the -M.  Don't utilize X0-X31 nor Y0-Y31.  That means you can't use the onboard I/O, but you don't want to, since you actually need the expansion modules on the final unit.

[stoic-one]

The onboard I/O cannot be mapped on BRX.  This restriction is due to the HSIO addressing to never be "remapped" because it is tightly coupled to the hardware I/O (in order for it to be high speed).

Thanks, I gathered that from the error message it gave me, I guess the real gist of the question was if the HSIO function could be disabled so it would then be allowed, but ok.

Could you go the other route.  Map your desired expansion I/O modules to start at X32 and Y32 on the -36 and eventually the -M.  Don't utilize X0-X31 nor Y0-Y31.  That means you can't use the onboard I/O, but you don't want to, since you actually need the expansion modules on the final unit.

Normally I could do that, but the panels are already built, and all the documentation, labeling, and program would have to be changed to match.

Good information to know for future reference, thanks for your reply franji1.

[franji1]

EDIT: tweaked the -36 IDs from X32/Y32 to X24/Y16 - the actual auto-assigned IDs of the first expansion module on a -36

To expound on RBPLC's idea, create 2 bit blocks, _X and _Y (or something else close to X/Y), then use BYTE casts (or WORD or DWORD casts) to quickly copy the individual bits across (MAPIO is slow compared to BYTE sized memory copies).  MEMCOPY is fast - it's memory-based "copy" (vs. value based "copy").  Change all your logic to use _X and _Y, not X/Y.

So in your -36
in $tTopOfScan code block
MEMCOPY X24:UB _X0:UB 8  // I guessed 8 BYTEs, or 64 X's

in $tBottomOfScan code-block
MEMCOPY _Y0:UB Y16:UB 8  // again, guessed 8 BYTEs, or 64 Y's

When you get your -M, change those two instructions to
MEMCOPY X0:UB _X0:UB 8
and
MEMCOPY _Y0:UB Y0:UB 8

the logic just continues to utilize _X and _Y elements, not the actual X/Y elements.

Yeah, it's a hack - and can be confusing, especially on your test system where the X/Y IDs do NOT match.

The benefit is that the _X ID's and _Y ID's would match the engineering drawings in both the -M and -36 systems - and in the final -M system, the actual X/Y IDs would also match.