Skip to Content

Register Login

Industry Online Support

Technical Forum

Navigation

Moving UDT Parameters

Created by: Chemical CJS at: 11/15/2012 8:08 PM (7 Replies)

Rating (0)

Thanks 1

8 Entries

11/15/2012 8:08 PM	Rate (0)
Chemical CJS Posts: 28 Rating: (1)	Hi all, So our program design has hit a rough turn. Originally, we run nested motorFCs with a UDT sent in and stripped out as individual outputs. These outputs are used to update the UDT before the next scan. If we only call the nested FCs once (single pump), there is no problem. However, let's say we have two pumps that each required the same UDT and motor FCs. We have discovered that the data for the second pumpis overwritten by the first pump, and thenboth pumps run in unison regardless of differences in logic. (i.e. both pumps will begin an out of service timer when only the second one is out of service). The memory addresses are different so there is no direct memory overlap. We have found that there is still lingering UDT data from the first call that updates itself into the next call. Our solution is to send outputs from the nested FCs to a skeleton UDT with matching parameters, then move the parameters from this UDT to the actual target UDT. A large constraint is that we cannot have memory words or bits as well as any FBs. Problem is, you can't use MOVE or MOVE_BLK instructions for UDTs. So, without using additional FBs or DBs, is there a simple way to move this UDT? Keep in mind that we are looking at dozens of parameters, so individual MOVE instructions are frowned upon. Thanks in advance, CJ
Chemical CJS Posts: 28 Rating: (1)
Suggestion To thank Quote Answer

11/15/2012 8:37 PM	Rate (0)
0_Einstein Diamond Expert Joined: 7/7/2010 Last visit: 11/6/2024 Posts: 15385 Rating: (2443)	I use plc custom data types. I even have arrays of them. I create multi-instance FBs that reference these custom datatypes and prevent the behavior you describe. Without the multi-instance FBs, you will may have a more difficult time making it work like you want. The key is in the FB to reference an internal tag for everything. If you have a motor setpoint, your custom datatype might be like: myMotorDT : struct status : bool {on/off} command : bool {turn on/off} setpoint : Int scaled_setpoint : Int {scaled to drive units for internal use} ;//// In theinterface for your FB, you will then have a static tag named motor of datatype myMotorDT. Then each time you call the FB, you create a new DB. The trick I think is that within that FB, you might be passing the UDT to other FBs and that is tricky to get the syntax right.
	science guy
Suggestion To thank Quote Answer

11/15/2012 8:54 PM	Rate (0)
Chemical CJS Posts: 28 Rating: (1)	Hi huggy, Unfortunately we are under strict orders to limit the use of memory, so our design is trying to avoid FBs and instance DBs in general. Ideally we want to perform this operation within the same FC that assigns parameters to each call of our nested FCs. However, it looks like without FBs it would mean 48 MOVE commands, which would be...well you know. Additionally we would have multiple pumps so that number is definitely not final. Is there any reasonable alternative to moving UDT parameters without FB usage? I was certain that SCL had a way of equating same-size structures. If it helps, the skeleton UDT will be exactly the same in terms of number of variables as our target UDT.
Chemical CJS Posts: 28 Rating: (1)
Suggestion To thank Quote Answer

11/15/2012 9:19 PM	Rate (0)
0_Einstein Diamond Expert Joined: 7/7/2010 Last visit: 11/6/2024 Posts: 15385 Rating: (2443)	Chemical CJS Hi huggy, Unfortunately we are under strict orders to limit the use of memory, so our design is trying to avoid FBs and instance DBs in general. Ideally we want to perform this operation within the same FC that assigns parameters to each call of our nested FCs. However, it looks like without FBs it would mean 48 MOVE commands, which would be...well you know. Additionally we would have multiple pumps so that number is definitely not final. Is there any reasonable alternative to moving UDT parameters without FB usage? I was certain that SCL had a way of equating same-size structures. If it helps, the skeleton UDT will be exactly the same in terms of number of variables as our target UDT. Maybe I misunderstand, but to me, recycling the program logic and using multi-instance DBs is very much memory efficient. The PLCs have more storage space for DB data than program memory. In the case of the older S7-1200 PLC, they might have 50kB of program logic memory, and 2MB of memory where data can be stored, all without the need of an external flash memory card. Try it the other way and compare your resource usage. It is a simple screenshot to prove one method is more conservatively using the system resources. I ran into this problem 2 years ago where I filled up the memory. To save memory, I ended up using lots of global tags, global DBs, and lots of FCs and no FBs except where FCs would not work. It was not very reusable logic, but it was fast and resource usage was very optimal. I would solve the problem 2 or 3 ways (sometimes more), and compare resource usage of each method. Once I found out how much overhead I was losing by using too many that were single instance to begin with, I converted them to FCs and used global tags. There is the tradeoff. Time, cost, quality. Pick 2.
	science guy
Suggestion To thank Quote Answer

11/15/2012 10:51 PM	Rate (0)
Chemical CJS Posts: 28 Rating: (1)	Perhaps there is a work-around that wouldn't involve moving UDTs. I have stripped out my program to include only the relevant areas of the problem. I will try to explain. Basically, there is a block where I call MotorType01 twice. Each call I give it a different "pump" with the same UDT. Inside the MotorType01 block is a runtime counter. I test the counter for out-of-service time by triggering the bit in a watch table. If you only allow one and only one FC at a time to run, then your counter will go up appropriately. If both run, then the values add in unison and the time value is overwritten by the first UDT - this is our major problem. We are suspicious that this method doesn't work because the UDT isupdated withthe first function call before entering the second call. Our solution was to create a dummy UDT it writes to as an out UDT and simply move it to the original UDT upon completion in order to prevent cross-talking. Any ideas on what's causing this problem? Attachment C:\Users\csaharkh\Desktop\CJS_11152012.zip (475 Downloads)
Chemical CJS Posts: 28 Rating: (1)	Last edited by: Chemical CJS at: 11/15/2012 11:38 PM Last edited by: Chemical CJS at: 11/15/2012 10:54 PM
Suggestion To thank Quote Answer

11/15/2012 11:10 PM	Rate (0)
0_Einstein Diamond Expert Joined: 7/7/2010 Last visit: 11/6/2024 Posts: 15385 Rating: (2443)	If I read correctly, it sounds like you are creating a 2nd DB referencing the UDT custom datatype as a temporary DB, which sounds like what a multi-instance DB is ideally suited to do without any magic. I do also recall someone else having a similar problem and came up with an elegant solution. Perhaps they will post to this thread.
	science guy
Suggestion To thank Quote Answer

11/16/2012 7:09 PM	Rate (0)
Chemical CJS Posts: 28 Rating: (1)	Solved! I called Siemens support about the problem.In the endI never had to move UDTs. The reason we had cross-talking UDTs was that unwritten outputs in the nested FC were being overwritten from the L-stack. Turns out if we change these outputs to in/out parameters, then the UDTs won't cross-talk. At least, that's what solved our small sample program. Hopefully implementing it into a larger program will yield the same successful results Many thanks again for your suggestions, huggy.
Chemical CJS Posts: 28 Rating: (1)
Suggestion To thank Quote Answer
This contribution was helpful to 1 thankful Users O_Moderator

7/30/2013 8:39 AM	Rate (0)
John_326091 Member Joined: 2/19/2013 Last visit: 6/30/2024 Posts: 9 Rating: (0)	Hi, in My knowledge , i have seen that UDT usage in the DB strcuture ..in this case UDT have the same parameter for 1000 of motion which can be anything...just like you sending control word to Drive from PLC.. so that you can move the specified DB with update require UDT using move command like belolw DB##.DBx#.#,BYTE 2 // the above the dat will be writen in a bit upto 16 bit ( 2 BYTE ) Please help from expert that exat written parameter. is it wrong , Please correct me

Suggestion To thank Quote Answer

|

Share this page:

Share this page on...

Follow us on