S7 - Strange behaviour of two OSs running ProTool

On my 317-2 DP system I have two OSs, one on a desktop in the control room connected to the MPI input and a second one on a laptop connected to the system via a CP343-1 IT Ethernet module. The program on the laptop is essentially the same program as on the desktop (actually, it's a modified copy) with different DBs for the job mailbox, screen and data boxes. When an operator logs in one PC the ProTool on the other PC is supposed to be locked out.

What actually happens though is that if somebody logs in on the laptop, the lockout seems to more or less work (up to a point anyway), however, if you log in on the desktop and work through the different screens, on the laptop the screens follow the desktop's screens!

Anybody got any ideas what might be going on here?

I remember there was an old thread where someone (you maybe ?) wanted to lockout the operator on one HMI when the other was logged in.
There was also something about forcing the screens.
If that really was your project, I would look into how the screen selections are made.

Note: In later panels and on the PC RT remote screen selection doesnt have to be done with PLC jobs. Changing screens can be done with a function assigned to any tag.

There's an add-on for WinCC Flexible called Sm@rt Access. All you'd need to do is create the project once and the 2nd PC is a Smart client. Any changes are automatically reflected on the client and only 1 HMI can have control at any given time.

@Jesper,

yes that was my Thread and having tested a bit more, when working from the Laptop everything works as planned. I can either lock out the desktop or I can arrange things so that I can still access the recipe screens to prepare recipes (effectively offline) without affecting the PLC ot the ProTool program on the Laptop.

However, when I work from the desktop, instead of locking out the Laptop, the Laptop screens follow the desktop as though it was being driven by PC-Anywhere (although it only follows the screens - the buttons are not affected). It's almost as though the Laptop program is somehow "remembering" the original DB-address of the Screen number DB instead of using the new one I've created.

Incidentally, I've tried changing most of the screen calls from Job 51 to using the Screen number DB, however, that seems to make things worse, I must be doing something wrong somewhere!

@RGB,

that's not quite what I want, I want to be able to work independantly with ProTool on both PCs at the same time, although only one PC would have control of the PLC at a time. Failing that, it would be enough if I could completely block logging in (to the ProTool program) on the second PC, however, at present that only works in the one direction.

I can't say I'm very surprised that nobody's seen this one before!

I suspect that the problem is that the "copy" program on the laptop has somehow "remembered" the original address of the Screen number DB, at least, that seems like the most likely source of the problem. Having played around for a while I have been able to see that in fact, initially the Laptop screen reacts as it should (the "Logon" button is disabled and a message window enabled by the OS1 "Busy" bit being set in the DB), then a fraction of a second later, the screen jumps to the same one as on the desktop.

Unfortunately all the activity is either taking place under Windows (in ProTool) or in the PLC Operating System. As far as I can see, the breakpoints only work in programs (OBs, FBs or FCs), there doesn't appear to be any way to set a Breakpoint to halt the PLC on accessing a data-bit in a DB - or if there is, I haven't found out how to do it yet!

Has anybody any other ideas as to how I could go about trying to track down the source of this problem?

Bright idea at last!

It finally occurred to me that I could pretty well shut out programming faults by putting a "BEU" at at the start of OB1 and OB32 so that none of my program was running - sure enough, cycle time 0 ms, no faults in the diagnostic buffer and still the laptop screen follows the desktop.

I then thought I might as well try switching the CPU from RUN to STOP - sure enough the problem persisted. Getting a bit paranoid now, I finally tried switching the PLC power off - thankfully, that at least killed the problem!

Some time after this the Siemens Hotline finally called back after listening to the above, there was pregnant pause followed by the suggestion "Send us the Zip file of the project and we'll have a look - but if it isn't immediately obvious what's wrong, it's going to cost money to investigate the problem"!

I guess the next step will be to reinstall Step7 and ProTool next week (I don't have the CDs on site).

Problem solved

There was an e-mail from the Siemens hot-line waiting for me when I got back into the office on Friday and the answer turned out to be pretty simple.

On the Laptop version of the program (not on the original desktop version, though) there was a variable called "screen update" or to be more accurate the equivalent in German, with the address set to Word 2 of the Screen Nr. DB. According to the X-ref it wasn't used anywhere, but it was set to update continuously.

How or when it got created is a bit of a mystery, I'm pretty sure I didn't create it (intentionally) myself and I certainly didn't set it to be scanned continuously! Anyway, deleting it solved the problem.

Moral of the story, if strange things are happening in ProTool, which look like they might somehow be being caused by something to do with the area pointers, sort the variable list by Address. That way you can find all accesses to the area pointers at a glance.