Convert RTO .ACC (milliseconds to HH:MM:SS)

Hi,

Anyone have a sample ladder logic code RSLogix5000 to convert a TON or RTO .ACC which is in milliseconds to HH:MM:SS.

Long story short. I have an RTO that will count in milliseconds when conditions are met. I want to display in HH:MM:SS in the HMI how long it ran while the conditions were present.

Thanks!

dfernand1985 said:

Hi,

Anyone have a sample ladder logic code RSLogix5000 to convert a TON or RTO .ACC which is in milliseconds to HH:MM:SS.

Long story short. I have an RTO that will count in milliseconds when conditions are met. I want to display in HH:MM:SS in the HMI how long it ran while the conditions were present.

Thanks!

Click to expand...

I find it easier to run a 1000ms task, and use my condition to increment a counter every 1000ms, far more accurate than a timer

Homework assignment probably does not allow for deviations from the expected correct answer. My bad pointing him to timed tasks

curlyandshemp said:

Homework assignment probably does not allow for deviations from the expected correct answer. My bad pointing him to timed tasks

Click to expand...

That's not a bad, that's a good idea. Still doesn't solve the leading zero problem though.



I'd rather have the frontal lobotomy

Here, find this with The Google:





It should be a start. Or how about this:

I just made an AOI and convert To string to show on the HMI using the Rockwell ms To HHMMSS AOI, saves have to display 3 dints with leading zeros on the HMI. Constant[0] is : and Constant[1] is 0

//Calculate Timer Remaining on Timer Inputs

CALC_DINT := Timer_PRE - Timer_ACC;

Milliseconds_to_H_M_S (Time_Remainer, CALC_DINT, Hours_DINT, Minutes_DINT , Seconds_DINT);

//Convert Hours to String // Add leading zero if less than 10
If Hours_DINT >=10 Then
DTOS (Hours_DINT,tString[0]);
ELSE DTOS (Hours_DINT,tempString[0]);
CONCAT (Constant[1],tempString[0],tString[0]);
END_IF;

//Convert Minutes to String // Add leading zero if less than 10
If Minutes_DINT >=10 Then
DTOS (Minutes_DINT,tString[1]);
ELSE DTOS (Minutes_DINT,tempString[1]);
CONCAT (Constant[1],tempString[1],tString[1]);
END_IF;

//Convert Seconds to String // Add leading zero if less than 10
If Seconds_DINT >=10 Then
DTOS (Seconds_DINT,tString[2]);
ELSE DTOS (Seconds_DINT,tempString[2]);
CONCAT (Constant[1],tempString[2],tString[2]);
END_IF;

//Concat all strings together
CONCAT (tString[0],Constant[0],tempString[3]);
CONCAT (tempString[3],tString[1],tempString[4]);
CONCAT (tempString[4],Constant[0],tempString[5]);
CONCAT (tempString[5],tString[2],tempString[6]);

//Write to InOut String
COP (tempString[6],String,1);

The simple answer is, how would you do this manually? Then apply that to your ladder logic. For example, if you had an .ACC value of 123,456,789 how would you break that down by hand.

To start, I would determine there are 3,600,000 milliseconds in an hour. Divide the .ACC by that number to get the number of hours. That would be 34.2935525. 34 hours with 1056789 milliseconds (3,600,000 x .2935525) remaining.

Then, you would take the remainder 1056789 and divide that by 60,000 to determine the minutes which would be 17.61315. 17 minutes with 36,789 milliseconds (60,000 x .61315) remaining.

Then take that remainder 36789 and divide by 1,000 to get 36.789 seconds. For your need, we are not after milliseconds so we ignore the remainder. We now know the hours, minutes, and seconds.

In the Logix 5000, there is an instruction (DIV) that will get the quotient result, but it will truncate the remainder if you use DINT tags, or it will round the result if you use REAL tags. For our purpose, we do not want it to round so we would use DINT tags for our sources.

There is also an instruction that will produce the remainder (MOD). Using these two instructions, we can do this all pretty easily. Below you can see one instruction to determine the hour and another to calculate the remainder. Then a similar setup for minutes and then seconds.

OG

welcome to the forum.
let's look at your problem this way
you have a timer that counts in milliseconds.
under the right conditions you want to display HH:mm:ss
so i would ask you the question how many milliseconds in a second?
how many seconds are in a minute?
how many minutes are in an hour?
how many hours in a day?
you may also want to include the format Days:hh:mm:ss

the next part is keeping up with this information when the milliseconds, seconds, minutes go beyond the answers above.

this should get you started. post your work and we will offer suggestions.
james

i posted this earlier for someone, this may help in the future.

For any given homework assignment or task at work, you must consider these instructions as the customers specifications.
1. read the specifications several times.
2. write down your understanding of what you read in a step by step fashion.
3. review what you wrote down and see if it makes since, modify if necessary.
4. Get with the mechanical designer and discuss the project openly and honestly. When your opinions differ in regards to an operation, discuss it, don't ignore it.
there must be a reason for a difference of opinion. modify your instructions and i/o to accomodate the mechanical design if necessary.
YOU BOTH MUST be in agreement on all points of operation before going to step 4.
5. step through your notes again this time, you are the one following the instructions. In other words, you are the plc. Write down on paper the events you are doing.
For example, turn on hydraulic motor 1, write down hydraulic motor 1 on. If a sensor is needed, write that down.
6. continue through the instructions. When you turn off the motor, mark a line thru it.
7. go through your instructions with all the sensors, motor aux. contacts, outputs documented. Modify if necessary.
8. repeat step 6 until no changes are made.
9. Try to group your data words into some organized fashion. The more programs you write, the more organized you become
10. write the plc program using your notes in a step by step manner.
10A Over half way through writing the program you WILL realize a different/better way of doing something you are almost done writing
(or a new spec will require it) and you will completely rewrite it
10B It WILL happen more than once.
Note: 10A and 10B added to list. thanks Aabeck, member plctalk.net forum

11. DOCUMENT EVERYTHING!!! You may remember things today, but in 5 years and hundreds of programs later, you won't
remember, especially at 2 am, so DOCUMENT EVERYTHING. use easy to understand tags and rung comments.
12. MAINTENANCE is your best friend and your worst enemy.
if you work with them and find out what they can do, write the program where they can trouble shoot the program. they will be able to fix the problem and everyone will be happy.
BUT
if you write the program to where you are the only one who understands what is going on, maintenance can't fix the issue, the machine is down, production is down,
management hears about it, your boss hears about it, then you hear about it - rewrite the program or else. you get calls all hours of the day and night.
this still holds true, a machine can cost a billion dollars, but it's not worth 10 cents if maintenance cannot trouble shoot the issue and fix the issue.
everyone has their own style of programming and you must develop your own way as well.

13. when the customer is in your shop and brings maintenance, discuss thngs with them, let them see your code, be open.
if they make suggestions, write them down, don't ignore them. their ideas may save you days of programming.

14. install the program and leave in program mode if possible so you can to debug your i/o
15. when writing your instruction manual(s), use your notes from step 9. Use easy to understand English language. specify the i/o, timers, counters, outputs when possible.
this will help maintenance even more to see what is going on.
16. Question for you, when is a machine and plc the most dangerous and why?
When it’s first powered on – when power is first applied to a machine, you don’t know how things are wired.
When you energize the plc outputs, you don’t know how they are wired.
When the plc is put into run mode the first time, it will do what you told it to do, NOT what you wanted it to do.
17. debug the program.
Remember, the program will always do what you told it to do, NOT what you wanted it to do.
18. IF you can ask a what if this happens type of question, YOU MUST have an answer, EVEN IF its a 1 in a million change.
that what if situation will happen in the first 30 minutes of production runoff in front of the customer.

this is the best advice I can give anyone.
if others has more / better suggestions, feel free to post
James

Why not create three tags, Hours, mins, secs, increment the secs on the time base 1 second bit, if it => 60 then reset the secs, increment the mins, if mins => 60 then reset the mins & increment the hours, display the three variables on the HMI like Hours : Mins : Secs. so simple, regardless of how you generate the time be it in minutes or 10ms etc at the required accuracy. this is so simple.

Just a somewhat "educated" guess here...

If legitimate, the user name "dfernand1985" would suggest to me, given the amount of online users that use their birth year in their handle, that the OP is circa 35 years old? If so, it is possible they are a late learner, but it is also quite possible they are already in employment some years and just facing an issue they've not had before? Still, either way, it is good to help others help themselves rather than always just doing it for them. Just something else for us to consider here, that's all.

There is a Rockwell AOI for exactly this but I won't "pull it out" unless the OP elaborates their position further. Although, any half decent RA sleuth should be able to find it easily enough?

Clever alternatives aside, which I love seeing, I do feel that the basic maths for this type of conversion is 101 for programmers, and so it is important to learn as is being outlined above.

Regards,
George

Geospark said:

...Clever alternatives aside, which I love seeing, I do feel that the basic maths for this type of conversion is 101 for programmers, and so it is important to learn as is being outlined above.

Click to expand...

Agreed. I thought I posted the same query that started @Operaghost's post i.e. more or less "how would you do this manually?" but apparently it got lost.

drbitboy said:

Agreed. I thought I posted the same query that started @Operaghost's post i.e. more or less "how would you do this manually?" but apparently it got lost.

Click to expand...

I saw it while I was writing my post, then it went away so I assumed you had removed it. Since it was good content, I included that concept as part of my post.

OG

Operaghost said:

I saw it while I was writing my post, then it went away so I assumed you had removed it. Since it was good content, I included that concept as part of my post.

OG

Click to expand...

Ah thanks. there must have been summat else about that post I didn't like and deleted it.

Geospark said:

I do feel that the basic maths for this type of conversion is 101 for programmers,

Click to expand...

Yes, unit conversion seems like 90% of any technical task. The other 10% is chasing down obscure values for one.


It is such a fundamental concept that, when I see a unit conversion thread topic, I often think "who put you in charge of this task, and do they realize how much you need to learn to do it?