S7 - identifying which PC is being used as HMI

RMA

Member
Join Date
Sep 2004
Location
North of Hamburg, Germany
Posts
2,052
For my 317 project I need to have two Operator Stations, one a desktop and one a Laptop, which is also used as a PG.

When somebody logs on from one PC, the other one has to be blocked, so that it cannot be used. In addition, the Laptop is only to have access to two of the 21 Modules.

In principle, it's not that difficult, but so far, I haven't been able to come up with any way of doing things which doesn't require two (slightly) different versions of either the PLC program, the ProTool program, or both.

Given the problems I've had with versions getting out of synch between sitting in the office and writing the program, then taking the archived file down to the test system half a mile away, making some changes and then either forgetting to save them and transfer them to the office PC or opening the old version the next morning instead of the new one, the last thing I need are two versions of the S/W floating around.

Has anybody any ideas how I can let the Software (I guess it probably needs to be ProTool, but maybe not) identify which PC it is running on?
 
In addition, the Laptop is only to have access to two of the 21 Modules.
This part of it is easy.
Simply setup the users on both PCs, so that there are only users with a relatively low password level available on the laptop.

The other part is not so easy, if you have an identical Protool application on both PCs.
Problem is that I think that you will have to use the PLC as a kind of go-between. Hmmmm....

I think I have it:

1. You have to have slightly different Protool applications anyway. They cannot share the MPI, Profibus, or IP address, whichever you are using.

2. You have to add two tags in each application "RemoteLogout" and "UserLoggedIn". For the two applications these tag must have a different address in the PLC.
When a user logs onto one PC, Protool must activate the "UserLoggedIn" bit, whereafter the PLC activates the "RemoteLogout" bit for the other PC. In Protool there must be a "Log out" function on the "RemoteLogout" tag.
 
When somebody logs on from one PC, the other one has to be blocked, so that it cannot be used
.
I see that my "solution" is not exactly the answer to what you asked for.

I dont think you can block someone from logging in.
And if you try to automatically log someone out after they log in by means of a memory in the PLC that someone is allready logged in, then you must be very certain that the memory that someone is logged in gets cleared. Otherwise this memory may "hang" and block both PCs forever.
 
Quote:
In addition, the Laptop is only to have access to two of the 21 Modules.
This part of it is easy.
Simply setup the users on both PCs, so that there are only users with a relatively low password level available on the laptop.
Unfortunately, it will often be some of the same people on both machines, but that in itself is not a problem, if I know that they've logged in from the laptop, then I can easily limit their access (that part is more or less completely written).

However, I think you've got the basis of the answer in your other suggestions, (which I haven't fully digested yet).

The Laptop will always be comunicating over Ethernet, whereas the desktop will always be on the MPI/DP port. If there is some way of identifying that, then that would solve the problem without requiring different S/W versions - oh no, you're right, I'm always going to have to have two different ProTool versions because of the communications.

I think I can live with that OK (well, Im going to have to aren't I!), because that's a trivial change that can be done at the last minute. I guess if I'm going that far, then it's not that much of a problem to change the login button on the opening screen to identify which PC is logging on. The HMI S/W is pretty stable anyway, and isn't changing much - other than acquiring about 20 - 50 new alarms per day!

Yes, I guess that's the answer, two versions of ProTool generated and modified at the last minute.

Thanks Jesper.
 
I think that the differences in the application can be minimsed to be only the online connection.
However, the "price" is a lot more programming effort.

Here goes:
Protool must send the name of the operator to the PLC as a string.
The PLC copies the name back to both PCs via another tag (but it is the same tag address for both PCs).
In a script in the Protool application the name of the current operator is compared with the name from the PLC. If these are different, then a logout command is issued.
Example:
"Roy" is logged onto PC1.
"Jesper" logs onto PC2. This sends the username to the PLC.
When PC1 detects that the username from the PLC doesnt match the current username, it logs out Roy.
PC2 detects that the current username matches the PLC, and therefore keeps Jesper logged in.

As this has a sort of oneshot functionality, there is no danger that the memory will "hang" and block both PCs.
 
Correction:
Protool must send the username to the SAME tag as the one that is used to compare the current username.

Otherwise the script will trigger a logout in the meantime that the username is sent and until it returns to the PC on the other tag.
 
Given that I haven't got to grips with scripting in ProTool, or for that matter, with Visual Basic either, I think changing the log-on button sounds like the easier answer for me!

Apart from that, the point hasn't been raised yet, but when they start working with the system, I'm pretty sure they will want to be able to login and get onto the second screen where they have the option to work with the recipes, even when somebody is using the system as a whole from the other PCs.

I'm blocking login completely at present, because it's easier, but I doubt if it will stay like that!

Edit: Login, Log-on - I don't seem to be able to make my mind up which term I want to use! :)
 
How about this: The versions have to be slightly different anyway, so how about making the Area Pointers point to different places (I think you should do that anyway)? So, the area pointers for HMI 1 could be DB100, and DB101 for HMI 2.

And then let's say that the HMI logon screen is Screen #5. If HMI#1 is on any screen other than #5, then you would know someone is logged in. Then, if HMI#2 switched to any screen other than #5, you would know someone logged in and then you could use a PLC job to bounce it back to Screen #5 and display a message that they have to log out on the other HMI. Again, by using different area pointers, you can tell what is happening on a particular HMI.
 
That sounds like an interesting suggestion S7Guy, it sounds like the potential solution to the Recipe maintenance problem. Thinking about it, your suggestion of using different are-pointers regardless sounds pretty sensible as well.

Is there anyway of changing the picture numbers in ProTool, or are they "set in stone" at the time of creation? If I could reorder the pictures, I could just do a compare less than, rather than having to check specific numbers. Still, it's not that much of a problem either way!
 
RMA, We have something similar in operation at our plant.

Two seperate protool projects with screen control of both controlled via the plc using job 51, when the "master" is active then the "slave" is sent a forced lock out screen. you simply define job no parameter(51 - force screen), screen number & element within the screen and sent to the panel via a pre build siemens Datablock.

Hopefully some help to you.

Steve
 
You don't need to use Job 51 anymore. You can set up a tag as screen_Number. Set the properties of the tag. Functions, select "select_Screen_Variable" and point to the tag as the screen number. Be sure to set "read continuously" under the options tab. By changing the value in the tag, the screens should follow.
 
Hi Steve,

I'm alread using job 51 to call up screens, so that's not a problem. Because I'm working regularly in two different places, I've had a lot of problems. With occasionally picking up the wrong version and carrying on working with it and then discovering sometime later, that something I had had working was suddenly not working again.

So I was interested to see if there was a possibility of avoiding having to have different versions of the program on the two PCs. When I posed the question I'd forgotten that I was going to be forced to have two versions of ProTool at the end of the day anyway, because of the comms setup.

The necessary changes are minor though, and can be made at the last moment, so it's not a problem.
 
Hi RMA,
thought i'd post just incase, seems like you have matters well in hand.

RRobbins,
Thanks for the alternative,its always good to learn something new - Just need a project to try it out now.

Regards
Steve
 

Similar Topics

Hello, I'm looking for a source for the white connectors in the picture below. This controller has 6.3mm spade connectors potted into it in rows...
Replies
4
Views
1,440
I have seen the canned transfer functions that are used to teach and transform a function from the (s) domain to the (t) time domain, but how can...
Replies
4
Views
2,805
Attached is a picture of a PLC from the mid to late 80's... It is currently running a machine that is struggling after a power disruption. Can...
Replies
22
Views
8,416
Hello everyone, I want to indentifying harware of a B&R Automation PC online to diagnose and set an encoder for the B&R ACOPOS servo drive but...
Replies
0
Views
1,507
I have a CompactLogix 1756-L72/B with only an EN2TR/C in a 4 slot chassis. Port 2 of the EN2TR is connected to two POINT I/O racks, while port 1...
Replies
8
Views
1,919
Back
Top Bottom