Protool and STEP7 "integration"

[JesperMP]

Hi,

are there anyone out there that is using the "integration" option in Protool ?
I can see that this option allows me to pick addresses in the PLC from its associated symbol list (when creating new tags in Protool).
But I am a bit disappointed that Protool "snubs" off most part of the symbol when creating the name for the tag.
"Motor1.status.running" becomes "Running".
"Motor2.status.running" becomes "Running1".
"Motor3.status.running" becomes "Running2".
etc.

I can manually retype the names to
"Motor1_status_running"
"Motor2_status_running"
"Motor3_status_running"
But thats exactly the hazzle that I thought that the integration would save me for.

Am I missing something here ?

 

[rdrast]

No, you aren't missing anything.

The 'Integration' isn't all that great in that sense.

Protool really has no clue about the logical structure of a DB at all, and really only references the physical structure. The 'Symbol' select is just a shortcut from having to fill in the Type/Size/Offset dialog box.

Like you, I wish they were more closely tied together, but Protool won't even allow tagnames over what, 20 characters or so?

 

[DesertDog]

I haven't encountered this problem because of habits I formed when dealing with slow data transfers. I create a function block with an asociated data block for all information that is going to be shared with the HMI. I use move or similar methods to transfer the values from the rest of the program in and out of the comunication function block. To pull data from several areas slows transfers so this puts all the data to transfer into one long string of data to access easier, this is worse with some other brand of PLC's. It also speeds things up if you move all the bit data into words or bytes and transfer them that way. This also gives you one point to troubleshoot data. If you use integers (more common with older PLC's) you can multiply / divide the values instead of move to handle decimals.

 

[S7Guy]

Jesper, you've found my biggest beef about the ProTool software. Apparently, the guys who developed ProTool never even imagined that S7 programmers would ever use arrays or structs, so the advantage of integrating and picking tags from a list becomes moot because the names are too long.

Because of this limitation, I gave up on Siemens panels about four years ago, because every time the absolute addresses changed in the PLC, I had to manually change the tags in the touch panel as well. So, I've found that it is much cheaper for my customers if I just quote a PC and VB HMI right from the beginning (assuming that the project is fairly large). That way, my names can be as long as I want them to be, and if the absolute addresses change, I can recompile and be back in business in ten minutes.

 

[JesperMP]

Well, I am both thrilled and disappointed at the same time with the new CE based panels. I like to use them because I get a lot of bang for my buck. But I am beginning to find the limitations.

There is a new version of Protool (Win CC Flexible) on the way, with supposedly better functionality.
Well, we shall see..

 

[RRobbins]

It appears, S7Guy hasn't used the "Integrated" function for awhile. The tag names can be 24 characters long now. I try use a DB to get my tags. It is a little bit of a pain to copy and paste the DB symbol ahead of the tag name but.... It works much better than having 2 or 3 tag data bases. The other feature I like is that when you insert an integer in the middle of a data area and you would expect the rest of the data tags to get thrown off by the offset of the inserted data, it will make the correction for you. There are a lot of features, built-in then there used to be. I use the DBname.Structname.tagname in my tag name. That way they will sort in the Protool tag list in order, also. Yes, I have to paste the DBname.Structname. before the tag name, but it is better than any thing else I've used. Browsing the PLC tags to create Operator Panel tags is a good thing.

 

[S7Guy]

I just tried it again, but I have the same problem as before.

First, 24 characters is less than many of my symbol names in my DBs, so they would have to be shortened manually. Second, it seems that when I point to a tag name in the symbol window, the symbol shows up properly in the bottom window but the tag name doesn't match, even if the name in the data block is less than 24 characters. Like I say, this might be ok on a small project, but it would be tedious if I had 2000 tags. With VB, I can export the DB and convert it to tags in 15 minutes, and the tag names match the names in my DB exactly, and I don't have any editing to do at all.

 

[Zxc-SLO]

I just tried it again, but I have the same problem as before.

First, 24 characters is less than many of my symbol names in my DBs, so they would have to be shortened manually. Second, it seems that when I point to a tag name in the symbol window, the symbol shows up properly in the bottom window but the tag name doesn't match, even if the name in the data block is less than 24 characters. Like I say, this might be ok on a small project, but it would be tedious if I had 2000 tags. With VB, I can export the DB and convert it to tags in 15 minutes, and the tag names match the names in my DB exactly, and I don't have any editing to do at all.

Sorry to jump in like this, but I want to ask S7Guy, what kind of communication (in Vb) you are using to communicate with S7 PLC (VB<->S7)?
You are talking about 2000 tags? What about speed?
I have made some VB HMI myself, but 2000 tags.... :-(

LP

 

[S7Guy]

Currently I am using the Simatic Net driver, but I will soon switch over to the KepWare OPC Server (initial tests have been very promising).

I used 2000 tags as an example off the top of my head, and in reality I have used up to 10000 or more tags on larger projects. Of course, you can't display every tag on one screen, but 10000 tags is no problem at all if you program your screens properly.

I'm not sure where the cut-off would be when I decided that ProTool would be too cumbersome; 300 tags, maybe? With PCs being so cheap, I'll probably stick with VB HMIs in the near future, unless it is for a small, stand-alone machine.