Wincc Animation project with TP1900

Join Date
Aug 2018
Location
Sharjah
Posts
49
Dear Experts,

Need your suggestions. I am to take up an upgradation project (s7_314 IFM with PC to s7-1500 with TP1900) for our Concrete Block Manufacturing machine. Picture is attached for a transport system, where Wet produced blocks are carried to Curing chambers and after 2 days, removed and transported back to despatch conveyor. There are 21 chambers with 12 rows each (except first 3, which have 9 rows)..

I have s7-314 IFM with one positioning module and several DI,DO modules.

I want to replace Winxp PC with Siemens HMI TP1900. We don't have source file for PC program.

I have tia v15 with wincc advanced with me. I never did any animation project before.

I want to know how shall I proceed for animation programming as currently whole animation programming code is in pc, plc only works as Slave.

What is thr best expert approach for this Hmi animation coding?

Is hmi alone capable of doing so i.e Keeping track which chamber is full and which has empty spaces? Can HMI decide the Filling and Removing Chambers on it's own and direct PLC accordingly?

Guys! Don't hesitate to reply. I just need an Expert approach to accomplish this animation and storage task (without/few changes in PLC program).

Regards,

Mr. G M Ansari

IMG_20200727_081743~2.jpg
 
It is unlikely that all the code in the PC controls the process, You have not told us what the platform is for the PC for example is it a bespoke compiled application or is it some known Scada system like IFIX etc this would help.
If it is a bespoke system then I think you are going to have major problems, If the location data is held in the PC then I think WinCC is going to be a bit of a problem, however, if it is just control & animation then it should not be too difficult. Have you got the documented source code for the PLC?. What type of animation do you require, is it just location indication or movement animation etc, Is the PC application using some form of database like MYSql, SQL Server or some other.
 
You need to know the PLC addresses of the objects you wish to animate, and you need to know how they are animated (ex: colours, visibility, etc.).

In the past I have successfully decompiled HMIs that are just an .exe file to get SOME information out of it, but I had to have the client send me a copy of a backup image of the hard disk (using a software such as Acronis True Image). Sometimes the source code was on the hard disk, but not in an obvious place. Without seeing what's on the hard disk, I can't tell you anything about the "PC Program without source code". If somehow you can get me the hard disk image, maybe I can tell you what HMI software you have (ex: Google drive, Dropbox...)
 
Hi SigmaDelta,

Thanks for the help.
It has some Visual Basic kind of forms which is used for screen design. I hope they used Visual Basic for it. I uploaded PLC program, and analyzed it and put necessary comments in the networks, symbol table etc. by reverse engineering. I will try and send you harddisk image.

Regards,
Mr. G M Ansari
 
Last edited:
Hi Parky,

Thanks for the reply...
I have PLC program with comments that I added myself. I just want to show movement of both cars (Left-Right/In-Out, with MD68 and MD72 which read Position Module)... This I can do on HMI itself. My concern is below, how HMI calculates the Filling Chamber and Removal chamber, Fill in Position and Takeout Position.

Also, filling & removal chamber indication (e.g. in attachment Chamber 5 & 7). And as the car reaches the setpoint and offloads material in filling chamber, a 'colored' box(preselected with recipe) should appear at that position (with Date & Time of offloading) and when car goes to removal chamber and reaches the setpoint and upload the material, the colored box must disappear from there and should move with the car to the Despatch Conveyor where finally it is off-loaded again and now box indication moves from car to Loweraor/Despatch Conv.

Also, HMI should know which chamber has spaces to fill and which is FULL and accordingly should give SETPOINT to PLC for the movement.

Regards,
Mr. G M Ansari
 
Last edited:
In most systems I have come across the data is held in the PLC, the "Scada" just shows the animation, the reason for this is so tht the plc knows where the data is rather than the other way round, however, if the plc has limited memory then it is possible for it to be held in the Scada or HMI, these are often not designed for this as it will probably thrash the disk quite hard to store the information, as you must be aware a pc losing power without storing locations to disk will lose it all. PLC's have retentive memory so are more than capable of holding the information if power fails.
There have been a number of threads here regarding storing occupied locations & product tracking I suggest you search for them, As I said I find it less likely that the infor will be on the PC, bur in saying that there could be some form of database holding the info. Again animation of a moving object is mostly done in the plc in a number of forms, a shift register where moving product becomes a series of bits and these bits are shown on the graphics as visibility objects, or a register is used to give x/y co-ordinates of the object and the animation reads these co-ordinates an places the object symbol in the correct position.
 
In most systems I have come across the data is held in the PLC, the "Scada" just shows the animation, the reason for this is so tht the plc knows where the data is rather than the other way round, however, if the plc has limited memory then it is possible for it to be held in the Scada or HMI, these are often not designed for this as it will probably thrash the disk quite hard to store the information, as you must be aware a pc losing power without storing locations to disk will lose it all. PLC's have retentive memory so are more than capable of holding the information if power fails.
There have been a number of threads here regarding storing occupied locations & product tracking I suggest you search for them, As I said I find it less likely that the infor will be on the PC, bur in saying that there could be some form of database holding the info. Again animation of a moving object is mostly done in the plc in a number of forms, a shift register where moving product becomes a series of bits and these bits are shown on the graphics as visibility objects, or a register is used to give x/y co-ordinates of the object and the animation reads these co-ordinates an places the object symbol in the correct position.

Ok this means, I need to modify PLC program instead of taking SETPOINTS from HMI, it should generate SETPOINTS itself.
Just for a help.
1. Do I need to create Boxes for each position in Chamber and Make VISIBILITY On/off in PLC as the car touches SETPOINT?

2. Are should I carry box logically passing through all co-oridnates from Source Position to the Destination and then make it appear/transfer in the Chamber set position?

I hope 2nd option is more professional...
I think I should do it in SCL.....

Could you please give me reference to Example to Move/Animate object to desired HMI co-ordinate in SCL language?

Regards,
Mr. G M Ansari
 
I think we have a mis-understanding, what I meant was that it is unusual to have the tracking information in the PC, "IF" the tracking is in the PC then you would need to find out what it does (very difficult if a compiled application), As I mentioned, most systems I have come across the tracking on a system like this is usually done in the PLC, If this is the case then you need to look at the PLC code to see if you can find it. For you to re-create the tracking in the PLC is going to be a bit of a challenge, however, if the original PC application is something you cannot reverse engineer then you only have two choices, try and create the HMI application using some scripting for storing and handling the locations (not easy on an HMI as they are not generally designed for this). Or write the tracking information in the PLC if it does not already exist.
Looking at the picture you posted then the information should already be in the PLC (well at least some of it) Assuming the car position is tracked by an encoder then it must be assumed the encoder(s) are on the PLC so it would hold the car position already, without actually seeing the graphics working it is impossible to know if the car actually moves on the screen, and if it did it would probably be a little jerky, I noticed there are direction arrows, so it could be these are animated and not the car itself. The only thing I can guess is that the storage positions in the chambers are an array or arrays of bits that are either a 0 or 1 so there are 21 chambers each consisting of 12 locations, If it was me I would have 21 bit arrays (each 16 bits one word) then as a wet block is added to a chamber checks are made so for example, a wet block is moved from the loading station onto the travel car, this is moved to a chamber assume 4, the logic would need to determine if the chamber has a location spare (empty) to accept the product it moves to the chamber position, loads it into the chamber into the spare position.
I cannot explain it fully as I do not know the requirement for selecting a chamber but checking for locations is pretty simple.
Here is the bit map for the 21 chambers, you can see that where there is a one there is an occupied location it depends on how a location is selected for putting in a new wet block but assume it takes the nexr location that is empty then it would need to check the first chamber that had spare capacity and move to that chamber, off load it into the empty location and set the bit to 1 so in this instance chamber 2 is the first location that has spare capacity the logic would look at the first chamber and if no spare locations (0's) then check next chamber, the same goes for removing dry blocks, a chamber is selected, the car will move to that chamber, enter the chamber until it finds a "1" and remove it to the unload station, removing the "1" from the location in the bit array.
100000000000000000000
100000100000000000000
110000100000000000000
110000100000000000000
111000100000000000000
111000100000000000000
111000100000000000000
111000101000000000000
111000101000000000000
111000101000000000000
111010101000000000000
111010101000000000000
You really need the specification on how it works.
What determines the chamber, is it manually selected or take it as first empty location?
What determines when a location has a dried block product, is it based on time or manually entered?
What is the definition of the yellow blocks compared to the grey or "Empty" locations ? If my assumption is correct then the grey blocks depict dry blocks, the yellow wet blocks & no indication as empty locations. In this case each location may have a memory associated with it as a drying time.
In that case bits will not work it would have to be an array of words, 2 for each location, a total of 504 words.
An example is
Chamber 1 words 1 to 12 location of a block so 0 = empty, 1 = wet, 2 = Dry
Words 13 to 24 drying time in seconds/minutes.
There are many combinations of location/status that could be used and how you control them. I'm sure there will be other replies with novel ideas.
Perhaps if it is allowed, post the PLC code in zip form bearing in mind the limit on size of files allowed, it may give us some idea of how it is configured.
 
Hi Parky,
Thanks a lot for all your support.. You cleared many of my doubts... Yes, Car is shown moving on the screen, yes movement is jerky because it reads data from position module. You assumed many of the points correctly. Filling & Emptying positions can be set manually (Function keys F1...F4 sets manually which position the car should go now, Elevator is Wet block position, Lowerator is dried blocks/despatch conv. Position) but in auto mode it decides itself.
Actually we have fixed number of production pallets and it comes in a cycle, means if production cycle time is faster for 8" block, we would end up finishing all the pallets in 1.5 days. That means Blocks kept in chambers before 1.5 day, will have to come out; otherwise there will be no production. It is basically 1 in 1 out fashion. Car takes Wet block to chamber and comes with dried blocks. So there is no such fixed time for drying. Ideally it is 2 days.
Well, yellow block is the color assigned to 8"hollow block (one type of product); Different color can be set for say 10" hollow block, just to identify blocks in the chambers.
Grey means location is Empty.

I can try and manage modifying PLC, for identifying the Fill and Remove locations (as you guided), but my other concern is for display.
I was thinking to display boxes in chambers during Runtime only. So it will save memory and power tags. However I learnt from internet that in Wincc Flexible /Advanced, we cannot create sceen objects (even using script) in Runtime. I don't know about Wincc Professional,if it allows?
Otherwise, I will have to create 12x21 boxes and will control it's visibility....Each visibility bit if ON will display box with 'date & time'.
Isn't it going to put burden on Hmi? Is it fine to have these many boxes plus other screen objects, and TP1900 will not have problems with it?

Regards,
Mr. G M Ansari
 
The graphics should not be too much of a problem, I have had 99 blocks on a screen, each one either hidden, green or red, although this was a Scada system but in the 90's so not that much of a fast PC, most communication between the PC & PLC will only take place for animation either when a state changes and if the display is active, so event driven. this reduces the the number of reads. there are exceptions like logging alarms etc. it will depend on the communications driver. Also what makes a difference is try to group all animation information in contiguous blocks this also reduces communication time for example reading or writing a number of single bits or words that are fragmented usually means either large blocks or lots of small blocks, drivers tend to read bits in 16 or 32 bit chunks so it would be reading bits that are not used in the application. this also goes for words, fragmented words means at least one send/receive for each word whereas a contiguous block of 10 words will be one.
I'm not familiar with WinCC, but on many HMI's & Scada systems movement sometimes requires a little thought for example movement in one direction across the screen involves a variable, the object is parameterised with the co-ordinates from one position to another, this process can vary from HMI to HMI, On one system I did you had to give it position in pixels, so I had to take the encoder value & do some maths in effect scale it from many thousand to say 1000, the other you drew a line or the proposed path , gave it limits and it worked it out itself.
Some years ago I worked on a block drying system, this consisted of one cart almost the same as your picture, the trolley had a secondary trolley (fork lift) so a row was selected, the pallet of blocks was moved to the row, then the fork trolley left the main trolley down the row to store the blocks, however, this was a little more complicated as each row had 4 levels hence the fork lift, so the matrix was for example 10 rows, each 8 deep and 4 high
I cannot remember the actual but it was a lot of individual locations to be tracked, each location had a bit in matrix & a word for the drying time. it also used a rather complex algorithm for deciding location, however, I was not directly involved in that bit as there was 3 engineers working on it, this was a Siemens S5 system with a WF470 Graphics card, this was akin to one of the early ping pong games as the graphics were very chunky.
 
Hi Parky,

Thanks for sharing your experience.. Now I am little more confident that I would be able to execute this upgradation project.
My 2 main concerns before coming here were:
A) ProductTracking in HMI or PLC
B) Display boxes in Runtime only OR create offline all boxes for each target position and play with VISIBILITY.

And you cleared both.
I would now prefer Wincc Advanced only (as I am not going to display box in Runtime only) and with s7-1500 and TP1900, this job will be done.

Regards,

Mr. G M Ansari




The graphics should not be too much of a problem, I have had 99 blocks on a screen, each one either hidden, green or red, although this was a Scada system but in the 90's so not that much of a fast PC, most communication between the PC & PLC will only take place for animation either when a state changes and if the display is active, so event driven. this reduces the the number of reads. there are exceptions like logging alarms etc. it will depend on the communications driver. Also what makes a difference is try to group all animation information in contiguous blocks this also reduces communication time for example reading or writing a number of single bits or words that are fragmented usually means either large blocks or lots of small blocks, drivers tend to read bits in 16 or 32 bit chunks so it would be reading bits that are not used in the application. this also goes for words, fragmented words means at least one send/receive for each word whereas a contiguous block of 10 words will be one.
I'm not familiar with WinCC, but on many HMI's & Scada systems movement sometimes requires a little thought for example movement in one direction across the screen involves a variable, the object is parameterised with the co-ordinates from one position to another, this process can vary from HMI to HMI, On one system I did you had to give it position in pixels, so I had to take the encoder value & do some maths in effect scale it from many thousand to say 1000, the other you drew a line or the proposed path , gave it limits and it worked it out itself.
Some years ago I worked on a block drying system, this consisted of one cart almost the same as your picture, the trolley had a secondary trolley (fork lift) so a row was selected, the pallet of blocks was moved to the row, then the fork trolley left the main trolley down the row to store the blocks, however, this was a little more complicated as each row had 4 levels hence the fork lift, so the matrix was for example 10 rows, each 8 deep and 4 high
I cannot remember the actual but it was a lot of individual locations to be tracked, each location had a bit in matrix & a word for the drying time. it also used a rather complex algorithm for deciding location, however, I was not directly involved in that bit as there was 3 engineers working on it, this was a Siemens S5 system with a WF470 Graphics card, this was akin to one of the early ping pong games as the graphics were very chunky.
 

Similar Topics

Hi Guys, I need to animate the pipework on a few process mimics in a WinCC application. Not something I am a fan of due to the work involved but...
Replies
3
Views
2,679
Hello ! I need help to create a rotating fan , there are 2 frames of a fan in wincc flex , if anybody knows how to animate them .... or some...
Replies
16
Views
16,888
In our production plant we have multiple different networks (subnets). IT dept have setup routing between them so different subnets can...
Replies
0
Views
49
Is it possible to connect a PC with running WinCC Advanced or Unified to a siemens PLC such as S7-1200 across different subnets? The computers can...
Replies
0
Views
53
We are using wincc scada WinCC system software V7.5 SP2 , connected to few plc . Past 3 weeks we getting this alarm continously when we checked...
Replies
0
Views
64
Back
Top Bottom