Help in designing Database or Tags

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.

Does it matter ? There would just be zero accumulated times in the array when the timer doesn't accumulate. And it's a good way of making sure that last months data gets cleaned out.

I would just let it run regardless....
 
Sure, if he leaves the robot controller "on" on Sunday, the robot would always wait in front of the conveyor, so your time would just keep increasing. Backendcode doesn't plan to keep check of the wait time for longer than 30 days, so at the end of 30 days, he can simply add all the times together to get total time wasted, instead of subtracting the times on Sundays when it doesn't count.
 
Sure, if he leaves the robot controller "on" on Sunday, the robot would always wait in front of the conveyor, so your time would just keep increasing. Backendcode doesn't plan to keep check of the wait time for longer than 30 days, so at the end of 30 days, he can simply add all the times together to get total time wasted, instead of subtracting the times on Sundays when it doesn't count.

I'm quite sure he can add another bit that says the robot is actually "waiting for something", the previous machine "active" for example ?
 
I'm quite sure he can add another bit that says the robot is actually "waiting for something", the previous machine "active" for example ?

I'm unsure what you describe, I just know if he includes day ≠ Sunday on the first rung with the timer "waitingTimer", then he won't have to account for removing the extra seconds the robot waited for all day on Sunday.

If he doesn't have a tag for Sunday, he can use 4 NEQ instructions, that check for day ≠ 4, 11, 18, 25, which coincidentally are the dates for the next 7 Sundays, which should be more than enough time for Backendcode to collect his 30 days worth of data.
 
Thank you so much Daba for writing a logic for but I finished the logic last night and this is how it looks.

Thank you rest of the guys as well for writing on my thread. I really appreciate your time.

Here is the logic.

https://ibb.co/naa9WH
https://ibb.co/jASTQc
https://ibb.co/g0VnJx

I am using a Retentive time on to calculate the wait time and this RTO gets reset at 7 am in the morning because I am calculating time from 7 am to 7 am (Next day)

Then I created UDT with 5 parameters which I am going to store and then I created an array of 32 elements with datatype "UDT I created" and each element represent a day, for example, array_name[7] will store information of 7th day of that month.

Then at 7 am, I will move all the stored wait time from RTO time to array element depend upon what day of month and then reset the RTO.

Please have a look at the pictures and Let me know what do you guys think of.


Thank you,
 
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.

Thank you for detailed information and I decided to get total wait time for 24 hours instead of each shift. Please have a look at my logic and what do you think?
Thank again
 
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.

The production runs 24 hours/ 7 days! so I am not worrying about sunday or any other day.

Thank you for the suggestion!
 
With minor modifications my code will record whatever is needed, whether it is a day, 2 shifts per day, 3 shifts per day, working 24/7 or not.

The principle is there, and can be moulded to suit the requirements.

The key element is getting the data structure correct, so the code has next to nothing to do....
 
With minor modifications my code will record whatever is needed, whether it is a day, 2 shifts per day, 3 shifts per day, working 24/7 or not.

The principle is there, and can be moulded to suit the requirements.

The key element is getting the data structure correct, so the code has next to nothing to do....

I definitely agree with you! and I really like the way you write logic which is simple and clean. I may try to implement if I get some extra time at work and I am pretty sure it will work. Thank you for teaching :)

Thank you,
 
One thing to watch is that your data for the day will be written to the element of the next day. The data will be intact but off by one.
 
One thing to watch is that your data for the day will be written to the element of the next day. The data will be intact but off by one.

Yes I agree with you and I realizes that issue as well. Right now I have robot wait time information from 7th feb ( 7am) to 8th feb (7am) which is 7th day data but this data is avaible in 8th element of my array. So What I am going to do is

Use Sub (Subtract instruction) and subtract 1 from date_time.day and put the result into a new tag and use that tag at subscript of the array rather than using date_time.day.

This will solve this problem.

What you think :)

Thank you again for the help
 
Not quite. On the 1st you will have trouble. Better off leaving it alone and knowing it is a problem.

Otherwise use a working day of month and update it with current day of the month after you have used it to store the data into the array.
 
Not quite. On the 1st you will have trouble. Better off leaving it alone and knowing it is a problem.

Otherwise use a working day of month and update it with current day of the month after you have used it to store the data into the array.

You are absolutely correct. I am going to leave it like that.

Thank you,
 
I think your solution(s) a little over-complicated.

Wouldn't this achieve what you want.... The only "issue" I can see is that it will need the rollover at 7 AM to set "Pointer" to the current day number.

You could leave it like that, and the accumulated time goes into array element 0, which is a redundant space anyway since there is no day 0. Or you could manually set it to the correct day, or do it with a S:FS bit.

Either way, once it is set, the DIV puts the data into the correct place, the Day number of the current month. And it does it continuously, so no data will be lost if the PLC goes off, and a new "day" starts while it is off.

Or, if you wanted to be really fancy, you could add the month to the array as another dimension, and record a years worth of waiting times. All you would need is a second MOV after the ONS to capture the Month number into the new array dimension name (Perhaps use "Month"). Same would apply as above, it would need one "initialisation" cycle, or manually set.

Then add code to detect a leap-year (evenly divisible by 4 or 100, but not 400), and clear the contents of array [2,29].

You could even go back easily to your 30-day cycle, which means you wouldn't have to account, in your totalisations and averaging, for the months that don't have 31 days, or even account for the fact that the number of days in February is variable !!


Anything is possible, just how far you want to take it....

2018-02-09_113300.jpg
 
Last edited:
The one thing that I don't like about your solution, Daba, is that some months you populate WaitingTimes[31] and some months you don't. Feb is even worse. So when you're looking at "the last 30 days of data", you have to know whether or not to include certain registers.

The COP ([1],[0],len) technique simplifies looking at 30 days worth of data. Making an array of UDTs allows the capturing of more data points than just the "Idle" times. There is a difference if the machine is idle for a total of 1 hour, but was idle 300 times in the shift (meaning that it was typically waiting 12 seconds between parts), versus being idle for an hour only 1 time in the shift (indicating a major downtime event).

A UDT can also, if it's important, include shift, day stamp, and whatever else is desired.

I'm all in favor of "keep it simple". But there's also such thing as too simple when there are unrealized needs.
 

Similar Topics

hello again, lets disregard that last thread I posted about the Panel Builder 1200. What I really need help with is some logic design. Here's...
Replies
4
Views
2,161
Hi!! I'm looking for Temperature rise calculation software from Rockwell, I just download "Product selection toolbox 2022" but this software is...
Replies
0
Views
71
Please see attached file. I need this program in Function Block form but I am totally lost on this. Any help would be appreciated. Thanks!
Replies
8
Views
252
Took a new job and the controls schemes are fairly old and I'm used to Allen Bradley and Siemens. I'm looking to replace a pair of Superior...
Replies
1
Views
84
Hello, I have a question about fuses and how to calculate their required size. I understand that determining the appropriate fuse size isn't...
Replies
0
Views
111
Back
Top Bottom