PLCS.net - Interactive Q & A

PLCS.net - Interactive Q & A (http://www.plctalk.net/qanda/index.php)
-   LIVE PLC Questions And Answers (http://www.plctalk.net/qanda/forumdisplay.php?f=2)
-   -   Help in designing Database or Tags (http://www.plctalk.net/qanda/showthread.php?t=114123)

backendcode February 6th, 2018 08:10 PM

Help in designing Database or Tags
 
I work with integrators and we build a production line but line cannot achieve the production goal. we have ABB robot and customer complaint us they can't make enough parts. I am babysitting this line and noticed sometimes robot just wait for the raw part because an operator is not on infeed conveyor to feed the raw parts. I am trying to calculate the robot wait time and need help in designing the database structure.

A line runs 24 hours/6 days a week so I would like to store the robot wait time for each shift separately for next 30 days.

That's what I am thinking about the tag structure.

1. Create one temporary tag.
2. A two-dimensional array of range 30 [0 to 29], Planning to record 30 days robot wait time.

Explanation:- A temporary tag which will store the robot wait time while a robot is ready to pick up raw part but raw conveyor is not ready to unload (This will give me robot wait time) and when the conveyor is ready to unload which means robot will move to pick up a part. Move the record time from temporary tag to 1st element of an array [0,0]. and when the same situation will happen again, add the record time from temporary tag to the first element of an array during the same shift. so At the end of the shift I will have a total time of that shift and then for the next shift of same move the data from temporary tag to array location [0,1] and so on then at the end of 24 hours I will have total wait time of robot for three different shift in single row on particular date for next 30 days.

Important question, How can I move the robot wait time in a different shift of array element? May be get the current day time with GSV and record that current time with robot wait time and set the limit if temporary tag record the "robot wait time" between 7 am to 3 pm then move to that particular location?

Please give me your feed back and Once I design with structure then I will start writing PLC code and if I would need help I hope you guys can advice me.

Note: I am looking for help to give me right direction and not looking for someone to do it for me and I appreciate everyone's time

Thank you

Aardwizz February 6th, 2018 09:39 PM

Rather than creating an array of Data[Day,Shift], it might be easier to create a UDT with elements .Shift1, Shift2, Shift3, then make a one-dimentional array of the UDT.

Between 7 AM and 3 PM, write to Data[30].Shift1, and so forth, and at 7 AM, do a one-shot COP of Data[1], Data[0], length 30, to shift your rolling FIFO.

backendcode February 6th, 2018 09:42 PM

Quote:

Originally Posted by Aardwizz (Post 767712)
Rather than creating an array of Data[Day,Shift], it might be easier to create a UDT with elements .Shift1, Shift2, Shift3, then make a one-dimentional array of the UDT.

Between 7 AM and 3 PM, write to Data[30].Shift1, and so forth, and at 7 AM, do a one-shot COP of Data[1], Data[0], length 30, to shift your rolling FIFO.

That's great advice! Thank you!

Is it possible to create UDT while production is running? I meant can I define/create UDT when online on PLC because I can't stop the PLC or line.

Thank you Again,

Geoff White February 6th, 2018 09:57 PM

Yes you can. You can add new types. You can't modify them.

Having done this sort of thing it usually easier just to use an array of 32 elements and write the data to the element using the day of month from the wallclock. That way you easily know which day the data is actually from. The FIFO thing is great if you have an arbitrary log length.

Don't try to be too clever for the shift stuff either. Just use three accumulators for each day and use limit instructions to decide which one to increment.

Initialise each days data when dayofmonth<>olddayofmonth

backendcode February 6th, 2018 10:27 PM

Quote:

Originally Posted by Geoff White (Post 767715)
Yes you can. You can add new types. You can't modify them.

Having done this sort of thing it usually easier just to use an array of 32 elements and write the data to the element using the day of month from the wallclock. That way you easily know which day the data is actually from. The FIFO thing is great if you have an arbitrary log length.

Don't try to be too clever for the shift stuff either. Just use three accumulators for each day and use limit instructions to decide which one to increment.

Initialise each days data when dayofmonth<>olddayofmonth

Thank you for your time!

I think you are right! I shouldn't be too clever about the shift stuff.

Now, I am thinking of creating UDT name "Robot_Wait" with two parameters (Types)
1. Date
2. Shift (robot wait time from 7am to 7am, 24 hours)

Then will create 32 elements of array called Robot_starving[32] (Datatype will be "Robot_wait" (UDT)

Now I will have 32 elements with each element will have two parameters 1.date and 2.shift

Now I am getting my robot wait time from the timer I will use to enable when robot will wait and move that .acc value to my temporary tag and keep adding the time whenever timer enable.

When world clock time will be 7 am, use equ instruction to check its 7am and then move whatever the value in that temporary tag to first element of my array name "robot_starving" and then move 0 to my temporary tag to start calculating for next day from 7am. How's that sound?
But next day How can I move the data to next element of my array? Any suggestion?

Thank you again for the time.

Thank you,

Aardwizz February 6th, 2018 10:48 PM

The COP([1],[[0]) command is an old trick for shifting data. The only problem is that the oldest stuff is in the lowest registers, while the loading register is higher up.

But one the data shift occurs, the loading register [30] in my earlier example, doesn't change. If you make the array a little bit bigger than it needs to be, and the COP length larger, the "loading register" will get automatically cleared when the COP moves (no) data from register loading+1.

With the UDT, consider having not just .WaitTime but also .WaitCount, maybe even .LongestWait. The more OOE data you collect, the clearer the picture becomes for where your bottlenecks are and how much they're costing you.

Geoff White February 6th, 2018 10:55 PM

The old shifts don't align with the calendar trick.
Stricly speaking you don't need to store the date as the index is the day on month.
If you only need one bucket for 24 hours

if ActualHour>6 then
if WorkingDOM <> ActualDOM
WorkingDOM:=ActualDOM;
Robot_wait[WorkingDOM].Shift :=0
end_if;
end_if;

if Idle then
run idle timer
if timer done
Robot_Wait[WorkingDOM].Shift := Robot_Wait[WorkingDOM].Shift + 1
reset timer
end_if
end_if

You can also put this in a 1 second periodic task then it will accumulate seconds without any timers.

backendcode February 7th, 2018 06:23 PM

Thank you for the help guys! I am sorry I forget to tell that I am using ladder logic.

Thank you!

Geoff White February 7th, 2018 09:45 PM

It can all be done in ladder.

Have you tried typing out ladder code?

backendcode February 7th, 2018 10:06 PM

Quote:

Originally Posted by Geoff White (Post 767908)
It can all be done in ladder.

Have you tried typing out ladder code?

I just started working now, Will give an update with screenshot of my logic once it finished.

Thank you,

Geoff White February 8th, 2018 12:29 AM

I was referring to the difficulty in trying to represent ladder logic in text on a forum :)

backendcode February 8th, 2018 12:33 AM

Hey I sent you PM.

Please check

Thank you

daba February 8th, 2018 07:33 AM

2 Attachment(s)
If all you want to do is record the waiting time for each day, then there's no need for any confusing shifts, or any other fancy code.

Just use the RTC .Day element (I used a UDT for the RTC data) to record the waiting time into an array big enough to hold a months worth of data. No need for limit checking either, the .Day can only be 1 to 31, so an array of 32 elements is needed.

You could do a bit more math than I have (recording time in seconds, hence the DIV), and do it as minutes or hours, in which case change the array data-type to REAL[32] instead of DINT[32].

EDIT : I'll work on the "working shifts", just re-read the post properly....

daba February 8th, 2018 07:55 AM

1 Attachment(s)
Done : I expanded the WaitingTimes array to 2-dimensional to accommodate different storage destinations for the 3 working shifts.

Shift will be 0 for 23:00 to 06:59
Shift will be 1 for 07:00 to 14:59
Shift will be 2 for 15:00 to 22:59

Timer is reset whenever the Shift number changes, not at midnight.

alive15 February 8th, 2018 10:48 AM

Assuming you aren't working on Sundays, you need to account for those dates, so your timer does not increment on those days. So on rung 0 of daba's code, you can check for day ≠11, 18, 25, and 4 if you plan on starting your data collection today.


All times are GMT -5. The time now is 04:49 PM.

.