Host Engineering Forum

General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Cactuar on December 14, 2020, 03:23:45 PM

Title: E094 (onboard IO mapping) after upgrade to 2.7
Post by: Cactuar on December 14, 2020, 03:23:45 PM
Hi,

Running some projects without issue in 2.6. At some point I moved from the DM1E-36* to the DM1E-18 and made some other IO changes, so rather than rework my code across hardware versions I remapped the IO. As part of this, I assigned onboard inputs to X112-X127. I had no errors when I originally did this in 2.6.

Now in 2.8.1, I'm attempting to load code to identical hardware (DM1E-18 series) with identical IO cards but I'm receiving "E094 On-board High Speed Inputs cannot be mapped; they must remain mapped starting at X0."

Notes:
* I am not using any of the high-speed functionality, only as standard inputs.
* It looks like this was added all the way back in 2.1.x according to the Updates PDF, so it's not new, but I never got it in 2.6

My question is, since I am not using any of the high speed features, can I safely ignore this? Inputs appear to work fine in the hardware I loaded with 2.6. Just concerned since I've never seen that error before.


(edit: I changed the title to reflect the info given below, that this change was made in 2.7 which I effectively skipped.)
Title: Re: E094 (onboard IO mapping) after upgrade to 2.8
Post by: BobO on December 14, 2020, 04:17:26 PM
Hi,

Running some projects without issue in 2.6. At some point I moved from the DM1E-36* to the DM1E-18 and made some other IO changes, so rather than rework my code across hardware versions I remapped the IO. As part of this, I assigned onboard inputs to X112-X127. I had no errors when I originally did this in 2.6.

Now in 2.8.1, I'm attempting to load code to identical hardware (DM1E-18 series) with identical IO cards but I'm receiving "E094 On-board High Speed Inputs cannot be mapped; they must remain mapped starting at X0."

Notes:
* I am not using any of the high-speed functionality, only as standard inputs.
* It looks like this was added all the way back in 2.1.x according to the Updates PDF, so it's not new, but I never got it in 2.6

My question is, since I am not using any of the high speed features, can I safely ignore this? Inputs appear to work fine in the hardware I loaded with 2.6. Just concerned since I've never seen that error before.

When we originally designed BRX, the intention was to allow remapping of the internal I/O and it was implemented accordingly. When we added the high speed capabilities, we intended to eliminate the remapping, but it slipped through the cracks. After we learned it was still a thing, we added the warning rather than remove the capability.
Title: Re: E094 (onboard IO mapping) after upgrade to 2.8
Post by: Cactuar on December 14, 2020, 06:04:43 PM
So I am to understand that remapping the onboard is acceptable as long as I do not make use of the high-speed IO capabilities. Sounds good to me! (I just want to keep IO consistency between 5-6 devices in a R&D setting without having to manage lots of code differences; I am not using the High Speed in this case.)

I was confused because this was showing up as an Error (not a Warning), but it seems like I can still ignore it. (Also confused as to why it was popping up now in 2.8, I didn't see mention of it in recent release notes. shrug)

Thank you for the prompt and helpful reply!
Title: Re: E094 (onboard IO mapping) after upgrade to 2.8
Post by: franji1 on December 14, 2020, 07:32:48 PM
It is an error, sorry.  You have to remap the I/O back to the base 0 value.  This was a change in 2.7 that should have been made back in 2.1.
Title: Re: E094 (onboard IO mapping) after upgrade to 2.8
Post by: Cactuar on December 14, 2020, 08:27:12 PM
Sure enough, I can't ignore the error.
The funny thing is the remapped IOs appear to work just fine (again I'm not using high speed so those features are disabled.)

Can't afford to go through and remap everything now, so guess I'm uninstalling and going back to 2.6.
Thankful that the newer versions don't nuke the previous installs, especially if they make potentially breaking changes like this!