Splitting Integers into 2 bytes (decimal to Hex?)

I'm working up this temperature deviation stuff for a plant and fist I'll say what I've done, and then an idea that someone mentioned to me (which sounds really good, but I'm not certain how to implement it)...

What I've screwed up (errrrr done)
I've borrowed an idea from Microsofts Visual Basic 6.0 and have implemented it into the temperature deviation. In VB to add certain features to message boxes (for instance) a value is added to the initial value. This "secondary" value cannot be obtained no other way (in the vb case it is 2048 and also 4096).
To reflect the differening states of unit operation (startup/warmup/online/idle/shutdown) I've give each state a unique number that cannot be obtained by addition with any other state. For instance:
Startup = 100
Warmup =200
These states are cumulative. So that during a three hour block if both states occur (normally they would since startup isn't that long) the sum would be 300. The only way to achieve the value of 300 is to have these two states occur. Nothing else will achieve this value.
Online=400
Idle = 800
Again, these values are unique. If the unit were to startup/warmup and go online in a 3 hour block the value would be 100+200+400=700 (no other combination of states can achieve this value). It is unique to this combination of states only.
Shutdown= 1600
By using this combination 1 word can reflect all of the states that occur in a three hour block. There is no way these states can be confused and in the logic I will be using a 'Select Case' command to decipher all of the possible states that can occur in any three hour block. This came about due to memory limitations on the processor.
Nested within this command will be another loop which will pull out the alarms. (from the vba or vb script itself)

Alarms.
Since XXX's attorney is intent on finding the specific alarm (ie low gas pressure, flame-failure, combustion blower failure, etc...) there are just too many to realistically reflect each value and stay below the 32767 ceiling. (even the addition of using the 65K value wouldn't be able to hold the values). Starting with 1,2,4,8,16,32,64,128,256,512,1024,2048,4096,8192, 16384, 32768, 65256. As is evidenced, to save the values for 3 weeks it would only be possible to have 17 faults. Unfortunately there are more than 17 alarms. Plus with the unit states included the last value couldn't be included (with 32K or 65K ceiling) because it would cause an overflow error. If they could be generalized as 'Burner fault', 'Damper Fault', etc... it would be easy to do. But unfortunately that option doesn't seem to exist.
But.... to get around that what I'm doing is numbering all of the major faults incrementally from 1 (1,2,3,etc....).. I believe there are around 30-40 faults possible that will shut down the unit. So what I'm thinking about doing is taking the first significant fault and leaving that in the unit state (with a three week history). This will be reflected in the weekly temperature deviation report and will be stored for 3 weeks. Also up to 5 faults (just an initial value, which can be changed) can be reflected in any three hour block (which when the desktop computers are actively reading the data can be actively stored into the report. The only problem with this method is power loss or communication failure. (by hooking up the desktop to the ups I might be able to autosave the file in case of a power outage, though if that is the first fault to occur there is a possibility that it would be the only fault to be recorded). But again until the system proves reliable I wouldn't bet on retention. Since XXXX wants a three week history there just isn't enough memory to store all of the possible alarms (and give them unique identifiers).
How does this sound? Can anyone think of ways I might be able to store the unit states and 30-40 alarms uniquely in an integer? Or is there another "low memory" way of doing this?



THE IDEA!!! (a good one too I might add)
Split the word into 2 bytes and use hex to display each. that way I could record 2 alarms at one time with a single word 1A1A for example..
but the only thing is that I do not believe the unit state can be included in that number. Due to lack of memory the unit state must also be included in the same number... but....
The numbering system was chosen arbitrarily.. it could just as well be 1,2,4,8,16,32( ... etc ... ). But 8 bits only give me 256, unless negative values are also included, but that would pretty much eliminate the possibility of using unique numbers (unless I'm missing something).

COULD... Could I split a group of words into 6 bit groups? That way the memory needed to store the unit state space would be reduced to only 21 total words (from the current amount of 56 words). This 6 bit array would reflect the unit state.
Since faults don't normally occur I could make that remaining words reflect 3 weeks worth of data (by only recording faults when they occur, and splitting the words would allow for retention of twice the number of faults). Again.. faults are rare, but they do occur.
It would be great if it could work. Is it possible?

But then comes the issue of being able to transfer it through rslinx gateway to an excel spreadsheet.
but again... would it be possible to just use a standalone vb app and do the conversion? I'm certain I can export to excel from a stand-alone app.. but the conversion might be tricky...



Any idea's?



Thanks,
Russ

So...

I don't have a real good sense of what you are looking at...
How many "things" are you watching?
What about duplicate events in the same 3-Hour period?

Is this thing supposed to be something like a numerical histo-gram?

"So...

I don't have a real good sense of what you are looking at...
How many "things" are you watching? "

Total of 5 unit states. Upwards of 30-40 faults.


"What about duplicate events in the same 3-Hour period? "

Only the first instance is being recorded (it seems like they hit the start-up and idle mode buttons 2-3 times..hehehe)... button pushers are everywhere!!! Hehehe...

"Is this thing supposed to be something like a numerical histo-gram?"

Yeah... I guess it would be (though I'm not certain what a numerical histo-gram is).. but it does sound exactly like what I'm working up.
The states are cumulative, but I don't see any way on how to make the 30-40 faults work in the same way (in the same word). If enough space was available I could split up burner faults/damper faults/fan faults etc... but unfortunately that ideal situation doesn't exist.
So I'm scrambling for bits and bytes.. I would love to be able to keep up to 5 faults included with the state in a word for 3 weeks. but I'm not sure how that would work, it doesn't seem possible at this moment.

The processors are plc 5/20 and a slc 5/03. (I'm going to do the same thing on both).

I think that you might be best off keeping them 1 bit per fault. Perhaps you could only log when integer of fault bits changes. This would require 2,3 or 4 16 bit integers or 1 or 2 32-bit integers. Nice thing is that this is easy to work with and display a pen or whatever for each bit.

Or another way. Number up like what you are doing and have timer that displays each active fault one at a time for x number of seconds. Have each active fault take its turn. Many ways to program this in PLC. I have done this with 100+ possible faults with one display register as text description and it works well. If you are logging, you could have it change to next active fault as soon as the first one was logged. Otherwise they can scroll and take turns.

Altair:

It seems that your main goal is traceability of faults here. Can't say I really have a handle on how many of what you are trying to keep track of but beyond that It seems you want to have your alarms burned into a non-volitile memory as soon as possible.

Have you considered hooking up the serial port on the PLC (I know a SLC 5/03 has one .. not sure about the 5/20) to some sort of data logging PC that is powered at the machine. When a fault or state change occurs, write and event message out the serial port to the PC for storage on the hard disk. Then just poll the PC to get your data to your Excel spreadsheet?....

Just an idea...

If what you need is logging events (alarms), and your PLC has a serial interface (most do), you may use an HMI panel.
Each event is triggered by PLC bit. You add discriptive text to the event in the HMI software, and can log about 2K events. The log is maintained even with power loss. And you can upload the log to your PC.
I used one of EXOR's panels to fulfill customer's request, and the error log was an added benefit.
Using this (cost!!!) will save you "re-inventing the wheel".
I hope this aims to your intentions.

OK, I read your post again and think I know what you are doing.

Here's my understanding of it:

1. You are dealing with all data (states and alarms) in 3 Hour Windows
2. You only care IF a state or alarm happened within the 3 hr. window, Not how many times it happened
3. You want to keep a log of these 3 hr. window data for a period of 3 weeks
4. You have 5 states and 40 alarms you need to log each time period.
   [/list=1]
   
   What it sounds like you need is a FIFO buffer. There has been much discussion about this on this site but your situation is just a little different because all your data will not fit into 1 file (but it will easily fit into a 16k SLC 5/03).
   
   Here's how I would lay it out:
   
   Using 1 bit for each state and alarm adds up to 45 bits. Round up to the next word boundary and you have 3 words or 48 bits (It's always nice to have spares ). Then multiply this out by 8 periods in a day and 21 days (for 3 weeks) and you need 504 words. But , the SLC only allows 256 words per file. However, you can split your information nicely into 3 parallel files of 168 words each .
   
   Use, for instance B21, B22 and B23. The only tricky parts are that you have to fill the buffer at the highest address first (So, you will always be latching bits in the words at B21:168, B22:168 and B23:168) and on the SLC, you can only COPy a maximum of 128 words at a time so you need two COP instructions for each file at the end of each time period.
   
   Your data might be defined as:
   
   Alarm 01 -> B21:168/00
   Alarm 02 -> B21:168/01
   Alarm 03 -> B21:168/02
   .
   Alarm 16 -> B21:168/15
   Alarm 17 -> B22:166/00
   .
   Alarm 32 -> B22:168/15
   Alarm 33 -> B23:168/00
   .
   Alarm 40 -> B23:168/07
   State 01 -> B23:168/08
   State 02 -> B23:168/09
   State 03 -> B23:168/10
   State 04 -> B23:168/11
   State 05 -> B23:168/12
   SPARE 01 -> B23:168/13
   .
   SPARE 03 -> B23:168/15
   
   Then at the end of 3 Hours, copy all of the information UP in each of the three bit files such as:
   
   

   
   
   /* Self Reseting timer 10800 sec = 3 hr. */
   
       T4:0/DN
   
   ------]/[--------------------[TON T4:0 1.0 10800 0]--
   
   
   
       T4:0/DN
   
   ------] [------------------+---+-[COP]------------+--
   
                              |   | Source  #B21:1   |
   
                              |   | Dest    #B21:0   |
   
                              |   | Length     128   |
   
                              |   +------------------+
   
                              |
   
                              +---+-[COP]------------+--
   
                                  | Source  #B21:129 |
   
                                  | Dest    #B21:128 |
   
                                  | Length        40 |
   
                                  +------------------+
   
       T4:0/DN
   
   ------] [------------------+---+-[COP]------------+--
   
                              |   | Source  #B22:1   |
   
                              |   | Dest    #B22:0   |
   
                              |   | Length     128   |
   
                              |   +------------------+
   
                              |
   
                              +---+-[COP]------------+--
   
                                  | Source  #B22:129 |
   
                                  | Dest    #B22:128 |
   
                                  | Length        40 |
   
                                  +------------------+
   
       T4:0/DN
   
   ------] [------------------+---+-[COP]------------+--
   
                              |   | Source  #B23:1   |
   
                              |   | Dest    #B23:0   |
   
                              |   | Length     128   |
   
                              |   +------------------+
   
                              |
   
                              +---+-[COP]------------+--
   
                                  | Source  #B23:129 |
   
                                  | Dest    #B23:128 |
   
                                  | Length        40 |
   
                                  +------------------+
   
   
   
   /* Once all the data has been shifted in the FIFO */
   
   /* Clear the contents of our working data to      */
   
   /* Reset                                          */
   
   
   
       T4:0/DN
   
   ------] [------------------+--[CLR B21:168]-------
   
                              |
   
                              +--[CLR B22:168]-------
   
                              |
   
                              +--[CLR B23:168]-------
   
    
   
   .

   
   .
   
   Note: You can put all the COP instructions in one rung. It was just easier for me to cut and paste them on separate rungs above.
   
   Voila
   3 Weeks of 3 Hour Time Slots Each containing a history of 5 states and 40 alarms (and 3 spares).
   
   Hopefully, this is close to what you want

Thanks Norm!


"1. You are dealing with all data (states and alarms) in 3 Hour Windows
2. You only care IF a state or alarm happened within the 3 hr. window, Not how many times it happened
3. You want to keep a log of these 3 hr. window data for a period of 3 weeks
4. You have 5 states and 40 alarms you need to log each time period. "


Exactly! These go hand in hand with the average temperature for the 3 hour block. The current method in place will only allow me to record the initial fault during the block.
Though, I just checked and there are 67 Faults. (yuk!), plus 5 states yields 72 bits (5 words). That's 280 words/week, plus 840 words (for the 3 weeks history).
Is this still a workable solution?

Though maybe this might work (but I'm not sure the plant will go for it)...
These faults are rare occurrence. So set aside a total of 10 fault blocks. This would only require 50 words (plus the setup 5, and an additional 20 words for week/block data..though that could be reduced to 10 words if they're split half by using only 8 bits to display each part: 56 time-blocks, and 52 weeks). This could work, and would require far less space. The current unit state could be refined using 1 bit to represent each state (bits 0-4: 0=startup, 1=warmup, 2=online, 3=idle, 4=shutdown for instance). Splitting the currently used words in half would open up more space too. Though with the current savings it probably isn't necessary. But it would be fun to do anyway.
Currently the temperature averaging and end of week copy routines are in place. the processor takes 30 readings for every 3 hour block, averages them and stores them using indirect addressing).
I never should have mentioned putting a three week history for the temperature averaging routine. ... what a headache. Two weeks should be sufficient, assuming there is such a thing as vacation.



Thanks again!
Russ

Though, I just checked and there are 67 Faults. (yuk!), plus 5 states yields 72 bits (5 words). That's 280 words/week, plus 840 words (for the 3 weeks history). Is this still a workable solution?

Click to expand...

So long as your progarm is not to huge. I looked at some of my programs and it looks like I use up between 6 and 8 words per rung. If you have the program created, Just go into RSLOgix and start creating data files the size you need to hold all the info. Then do a Verify All, Go to the project tree and double click controller properties. It will tell you how much memory you have in instructions and data files.

Obviously you will also need some space to program the rungs to drive the FIFO ... But you will know if you are close to the limit or not.

Hope this helps