Indirect, direct addressing, NT20m, NT20s

[Mechanicinchief 0]

Ok.

Still working on trying to migrate an NT20m to an NT20s.

I've been able to load software to it both as a 20s and in 20m tool mode but only if that software is tagged as direct addressing.

I've located a mention of the NT20s not supporting indirect addressing despite this being an available option in the support tool. If true that'd explain why it simply refuses to deal with it.

The 20s was the closest thing to a 20m I could identify as an upgrade. Now it looks like it may be useless for this application. Is there a way or a workaround to get an indirectly addressed program to run on this thing? Firmware update maybe? And if not, what would be the next least obsolete equivalent? The Omron people must have known a lot of applications would have been designed around or dependent on the indirect addressing feature in the 20m. Is there -anything- else out  there I can port NT20m code to that will support an indirectly addressed program and have it work? The defining feature of our application being indirect is that it needs to display a "welcome, hi I'm a 2020.017 machine" startup screen as a first screen without the Omron having had communication with a computer yet. (computer is still booting at that time) and in direct addressing mode, the Omron will not display -any- screen until a communication from the host tells it to. It just sits there "connecting to host"

This would seem to completely nullify the existence of the feature where you can define a first screen in the support tools, but maybe it at least has to have been acknowledged at the direct address before it will refer to that and display screen 1. Any way to fake or trick that at the Omron end, force a bit flip that says, "communication established" and cause the HMI to then load the screen marked screen 1?

 I'd settle for no screen until the computer comes up and starts talking to it and tells it what to display just so long as the rest of the program would actually run. I'm just not clear on whether it would run at all anyway. Our app doesn't seem to care much about constantly knowing which screen is being displayed, doesn't need to be actively monitoring a given piece of memory, so far as I know it just works by telling the Omron which of about 50 screens to show and listening for the info off a few touchswitches, but I'm not all that clear on how exactly the indirect addressing works, either.

Any suggestions on how to implement a workaround or another model entirely I could use?

-B

 

[Jay Anthony 118]

If you continue to insist on indirect addressing, then there is no solution.

Why are you against changing the PLC program?

[Mechanicinchief 0]

I'm not against it, I'm unable to do so. I have old industrial robots running off a computer and NT20m's. The executable for the bots will not run without interacting with the Omrons to log on. When powered up, the Omron displays a static start screen while the computer boots. When the robot executable completes booting it contacts the Omron and control is handed over to it for logging in on an onscreen keypad. The executable communicating with the Omron and using it as a frontend is just an .exe on a drive running under DOS. I do not have access to the source code of these things nor the ability to decompile them and change how they talk to the Omron. So I'm stuck trying to find something else that will plug in in place of the NT20m's because I am unable to rework the robot to talk to anything else.

[Mechanicinchief 0]

If I had a way to just get into the robot .exe and add something to the Omron interface code establishing a control and notify area for the NT20s to talk to and enabling direct addressing for this application I'd do it. But simply converting the screen programs to direct and loading them into the 20s isn't working because it wants a control and notify area assigned, and in the running app, so far as I know there ISN'T one, the app was coded for indirect addressing and so far as I know if there is a control and notify address present in the app to tell the Omron to talk to, I don't know what it is or how to find it. I can enter random values as control and notify areas in the support tool and it will happily load this into the Omron, but then the Omron's just looking at the address of whatever random stuff I entered. I don't know what the control and notify addresses should be, if there's even a program stub there to talk to.

[Jay Anthony 118]

Can you tell me about the bumber module in the back of the NT20M and the number of the PROM that plugs into it?  Also what dip switches are set?

[Mechanicinchief 0]

Bumber module...?

If that's what they call the host interface, this thing uses an NT600m-lk201 serial interface unit.

Dip switches in the NT600m serial interface are set at:

1:on 2:on 3:on 4:on 5:off 6:on 7:on 8:on 9:off 0:off

The NT20m itself is using SMR01-E as the PROM and a RAM22-15 chip.

The DIP switches in the back of the NT20m unit itself are set at

1:off 2:on 3:on 4:off 5:off 6:on 7:off 8:off

Does this tell you anything useful about how it is being communicated with by the computer?

[Jay Anthony 118]

Have to research it....