Store Data in Micrologix 1200

[jfls45]

I'm trying to figure out a way to store real numbers in Micrologix 1200. The LIFO & FIFO instructions won't allow me to use Floating values so I'm trying to figure out a way to use MOV instructions but I need them to store ascending (or descending). At the end of the day will send to a printer, etc...

My specific need is to record weights 250.5, 114.2, etc... that's why an integer won't work or I could use the FIFO instructions.

Can anyone share a tip how they would proceed with this?

Thanks

Jeff

 

[bernie_carlton]

If you are only storing weights with one decimal place accuracy then just multiply by 10 and store them as integers.

 

[OkiePC]

Okay, can we assume your ML1200 is a series C that supports the Float data type?

If so, then use COP to shuffle your numbers around. If you COPy from Fx:1 to Fx:0 with a length of (you didn't specify) then MOV the newest data to the end postiion, then you have effectively rolled your own FIFO . . . except the newest number will be at the end.

If the newest number must be at the lowest element and they must shift upward, then you will need to COPy the array of numbers to a buffer area first, since COPy Fx:0 to Fx:1 is essentially the same thing as FLL (Fill File) with Fx:0.

 

[jfls45]

I'm trying to wrap my head around what OkiePC said...

 

[Tharon]

Okay, can we assume your ML1200 is a series C that supports the Float data type?

If so, then use COP to shuffle your numbers around. If you COPy from Fx:1 to Fx:0 with a length of (you didn't specify) then MOV the newest data to the end postiion, then you have effectively rolled your own FIFO . . . except the newest number will be at the end.

If the newest number must be at the lowest element and they must shift upward, then you will need to COPy the array of numbers to a buffer area first, since COPy Fx:0 to Fx:1 is essentially the same thing as FLL (Fill File) with Fx:0.

Never thought of using the COP instruction to make a FIFO, interesting.

Basically he's saying you COPY F8:0 into F8:1, with a length of (for example) 10. So F8:9 goes into F8:10, F8:8 goes into F8:9, etc, etc. until you get to F8:0 moving into F8:1. Then you put your new number into F8:0.

F8:0 through F8:10 now contain the numbers stored from the last 11 times you triggered the event.

Bernie's solution is probably cleaner in the end if you only need one or two decimal points of resoltuion (x10 or x100).

 

[jfls45]

I'm not seeing how this would work. Are you saying I can do this one with just one COPY instruction or do I need multiple COPY instructions?

I am experimenting with the LFU Instruction only now but it won't stuff my data into the second position. Not sure if I'm understanding the use of LIFO instructions correctly.

Never thought of using the COP instruction to make a FIFO, interesting.

Basically he's saying you COPY F8:0 into F8:1, with a length of (for example) 10. So F8:9 goes into F8:10, F8:8 goes into F8:9, etc, etc. until you get to F8:0 moving into F8:1. Then you put your new number into F8:0.

F8:0 through F8:10 now contain the numbers stored from the last 11 times you triggered the event.

Bernie's solution is probably cleaner in the end if you only need one or two decimal points of resoltuion (x10 or x100).

 

[OkiePC]

Never thought of using the COP instruction to make a FIFO, interesting.

Basically he's saying you COPY F8:0 into F8:1, with a length of (for example) 10. So F8:9 goes into F8:10, F8:8 goes into F8:9, etc, etc. until you get to F8:0 moving into F8:1. Then you put your new number into F8:0.

F8:0 through F8:10 now contain the numbers stored from the last 11 times you triggered the event.

Bernie's solution is probably cleaner in the end if you only need one or two decimal points of resoltuion (x10 or x100).

Actually if you do that, it won't work. you must go downward from F8:1 to F8:0 for it to work correctly.

Attaching an example you can run in RSLogix Emulate 500 and toggle the trigger bit to see it in action.

 

[Tharon]

Oh, my mistake. Sorry.

I can see now if you did it the wrong way you'd end up copying all of a single value into the file?

I have done it using multiple MOV commands in a row, again backwards, last number to first number. It's an ugly ladder in the end. Number manipulation always ends up with ugly LAD files.

 

[OkiePC]

I can see now if you did it the wrong way you'd end up copying all of a single value into the file?

Yes, that's correct. Internally the processor performs the COPy instruction one element at a time from the first element counting through the length, so it turns your FIFO into a FLL if you go upward!

 

[jfls45]

Actually if you do that, it won't work. you must go downward from F8:1 to F8:0 for it to work correctly.

Attaching an example you can run in RSLogix Emulate 500 and toggle the trigger bit to see it in action.

OkiePC, I was able to emulate your example file on my laptop. My question is, how do I make it so one value is entered only once when I want it too. Lets say after a tank is filled, I want a single recording of that tank weight to be stored in a file? In your sample, it shows a running tally of the weights. I want to be able to store about 24 individual values in a list.
I'm not sure how to do this. Point me in the right direction if you would kind Sir.

Jeff

 

[OkiePC]

My question is, how do I make it so one value is entered only once when I want it too. Lets say after a tank is filled, I want a single recording of that tank weight to be stored in a file?

You need a bit that goes true for one scan when the tank is full. Use that to trigger logic similar to the example I posted.

In your sample, it shows a running tally of the weights. I want to be able to store about 24 individual values in a list.
I'm not sure how to do this. Point me in the right direction if you would kind Sir.

Jeff

In my example, if you toggle the bit on, the rung that shifts the data immediately turns it back off making it effectively a oneshot.

In your real application, it is likely your tank full condition stays true for multiple PLC scans, so look at the inline ONS instruction. I think it will serve your purpose:

  Tank                                 1Shot  FFL

  Full          B3:100/0                Trigger

--]  [----------[ons]---------------------(  )

Be sure to use a unique bit for the ONS storage bit and don't use it anywhere else in the program. It will cause the OTE instruction at the end of the rung to go true for one complete logic scan cycle. Use that 1Shot bit at the end of the rung to trigger the COP instruction to shift the data and the MOV instruction to put the new value at the end.

Alternatively, you could just put your Tank Full condition bit and the ONS instruction in series with the FIFO logic and skip the rung with the OTE and the extra bit altogether.

Just be aware that you will get a shift of the old data and a new entry each time the logic preceding the ONS makes a false to true transition.

 

[jfls45]

Ok great pointers OKIEPC, I was able to accomplish getting it to do exactly like I wanted. Now, I would like to do the same thing with a date and time if possible. Is there a way of pulling this info from the S2 file and timestamping these data logs? if not the time at least the date would be sufficient.

Jeff

 

[OkiePC]

Sure, you can grab the date and time (if your micro has the RTC option), but you have some choices to make. Before making suggestions about data types and format, it might be useful to know where all this information will eventually end up.

In general, you will have a parallel FIFO for the date and one for the time, the same logic as above triggered by the same condition, but unique memory locations.

Once I did something like this on a small PLC that was low on memory so I encoded the time in a list of floats where the month, day and hour was before the decimal point and the minutes and seconds were after the decimal point:

MMDDHH.MMSS

Since I was not sending this data anywhere except my own little HMI (technician access only) screen, it was worthwhile to write the code to formulate that, squeeze it into data tables of floats and display it "normally" on the HMI with some decoding expressions. I needed accuracy down to the second and wanted a list of up to 1000 items to be retained in the SLC so it spanned four data tables. I didn't want to tie up 20 data tables to keep each part of the date and time separated so I wrote a CPT block to take the month * 10,000 + (day * 100) + hour + (minute/100) + (second/10000).

If you have the space (likely with only 24 items recorded), you will have simpler logic if you store the elements of the date and time each in their own files, and just run logic for each element in parallel to your weight recordings and triggered from the same event. It might be a bit wasteful to use a whole INT to store a value that only ranges from 1-12 (month), or 0-59 (minute) but it may be easier to follow in the future and easier to make sense of wherever this data eventually "lands".

 

[jfls45]

Thanks for the info. I'm going to dig around the internet to see if I can figure this out, how and where do I grab the date from? To answer your question where is it going to end up, we need to be able to print it. So either it will be sent out to a printer or possible grabbed on a thumb drive, not sure if the small C300 or C400 Panelview supports that function, but it will go to a printer. For now, I just want to be able to store this data.

Sure, you can grab the date and time (if your micro has the RTC option), but you have some choices to make. Before making suggestions about data types and format, it might be useful to know where all this information will eventually end up.

In general, you will have a parallel FIFO for the date and one for the time, the same logic as above triggered by the same condition, but unique memory locations.

Once I did something like this on a small PLC that was low on memory so I encoded the time in a list of floats where the month, day and hour was before the decimal point and the minutes and seconds were after the decimal point:

MMDDHH.MMSS

Since I was not sending this data anywhere except my own little HMI (technician access only) screen, it was worthwhile to write the code to formulate that, squeeze it into data tables of floats and display it "normally" on the HMI with some decoding expressions. I needed accuracy down to the second and wanted a list of up to 1000 items to be retained in the SLC so it spanned four data tables. I didn't want to tie up 20 data tables to keep each part of the date and time separated so I wrote a CPT block to take the month * 10,000 + (day * 100) + hour + (minute/100) + (second/10000).

If you have the space (likely with only 24 items recorded), you will have simpler logic if you store the elements of the date and time each in their own files, and just run logic for each element in parallel to your weight recordings and triggered from the same event. It might be a bit wasteful to use a whole INT to store a value that only ranges from 1-12 (month), or 0-59 (minute) but it may be easier to follow in the future and easier to make sense of wherever this data eventually "lands".

 

[jfls45]

Micrologix 1200 store date

I'm going to assume now that I won't be getting a processor with the RTC module. So thinking I will need to enter in a date on my MMI screen, what type of instructions will I use? I believe it is the ASCII, correct? Anyone care to offer a tip or two as it's obvious this is a learning experience for me and I need to discover as much of this on my own as possible. Is ASCII the right way to approach this and are they any ASCII tutorials that will help me learn?

Jeff

Sure, you can grab the date and time (if your micro has the RTC option), but you have some choices to make. Before making suggestions about data types and format, it might be useful to know where all this information will eventually end up.

In general, you will have a parallel FIFO for the date and one for the time, the same logic as above triggered by the same condition, but unique memory locations.

Once I did something like this on a small PLC that was low on memory so I encoded the time in a list of floats where the month, day and hour was before the decimal point and the minutes and seconds were after the decimal point:

MMDDHH.MMSS

Since I was not sending this data anywhere except my own little HMI (technician access only) screen, it was worthwhile to write the code to formulate that, squeeze it into data tables of floats and display it "normally" on the HMI with some decoding expressions. I needed accuracy down to the second and wanted a list of up to 1000 items to be retained in the SLC so it spanned four data tables. I didn't want to tie up 20 data tables to keep each part of the date and time separated so I wrote a CPT block to take the month * 10,000 + (day * 100) + hour + (minute/100) + (second/10000).

If you have the space (likely with only 24 items recorded), you will have simpler logic if you store the elements of the date and time each in their own files, and just run logic for each element in parallel to your weight recordings and triggered from the same event. It might be a bit wasteful to use a whole INT to store a value that only ranges from 1-12 (month), or 0-59 (minute) but it may be easier to follow in the future and easier to make sense of wherever this data eventually "lands".