DO-MORE TABLES

[jbenek]

I'm trying to make a table in DO-MORE.

I have a bank of 6 Generator Engines. I'm reading run hours over MODBUS TCP/IP. I want to take the Data I'm collecting (Hours Engine #1, Hours Engine #2, Hours Engine #3, ect) and be able to pick out at any given time which engine has the highest hours, lowest hours, then the 2nd, 3rd and 4th from the bottom and top.

What i do is cycle the engines on and off through out the week in order to keep the run hours close to the same for maintenance reasons. I keep 4 on at all times. So when I shut one or 2 down I want to be sure the one or 2 with the highest hours shut down.... then when I start one or 2 I want to make sure the lowest hour units start.

Can anyone help? ADC wasnt much help.

[BobO]

I think this should be pretty straightforward.

You say engine time is coming back as hours. Is that a floating point number, or integer with some number of implied decimal places? The reason I ask is that it will make the sort very simple if you can store the time as a 23 bit integer. If so, I would shift the time into the upper 24 bits of a D location, and then stuff the generator number in the low byte. I would fire off a task to do a bubble sort on those 6 locations. But answer the first question and then we'll talk about what that looks like in practice.

[jbenek]

just straight hours in a single word integer.... no decimals, no minutes

1 = 1 hour

[jbenek]

Also the max hours a unit will have will be around 40,000. The engines are replaced right around that time.

[BobO]

This won't be hard.

Each entry in the table is a composite value containing the time in the upper 3 bytes of a DWORD variable, and the low byte is the engine number...0xTTTTTTNN. The math expression to create it is something like this:

Dn = (EngineHours << 8) | EngineNumber

Where EngineNumber is expected to be a value between 0 and 255, and EngineHours is a value from 0 to 8388607 (a 23 bit unsigned int). This guarantees that the data stays within the positive range of the 32 signed int.

After you have created your 6 entries in D0-D5, you would use a task to do a simple bubble sort. We'll try to throw a bubble sort example together to post to the examples section. But if you want to tackle it yourself, use a task with two nested FOR loops, and reference each entry using the array operator. You would be comparing each entry to all the other entries, and then swapping them based on the sort order, like this:
  
if D[V0] > D[V1] Then Temp = D[V1], D[V1] = D[V0], D[V0] = Temp

Once you have sorted the entries, D0 would contain the lowest time and D5 the highest. You can access the engine number from the entry using the byte extraction cast operator: EngineNumber = D0:B0 (returns the low byte)

Engine time would use a math expression: EngineTime = D0 >> 8

[BobO]

I would also suggest that you use a program block with stages to do the whole thing. One stage each to read the data from each engine, and then one stage that runs the sort task, and then additional stages as required to act on the data, at the last stage EXIT when complete. I assume this is something that you don't do very often, so you would just run the program whenever you needed the data.

[jbenek]

We kind of understand, testing it out right now.

If you dont mind and sample program would be extreamly helpfull.

[BobO]

I think we are going to put together an example that follows the basic flow of what your app would look like, using a Stage Program block to sequence through the building of data, sorting of data, then using the data...calling other tasks and/or programs to do some the work. The bubble sort will be just one part of it.

Until then, see the attached pic for a bit more detail. This is a simple bubble sort that will take values in D0-D5 and sort them in ascending order...I think...I didn't actually test it yet...

[jbenek]

It doesnt appear like that example works. It drops a few numbers and duplicates others when sorting.

Perhaps I'm doing something wrong.

It works when using the number 0-5, but not when you use other random numbers.

[BobO]

Worked perfectly for me.

Here's what I tested. Toggle C0 to randomize D0-D5. Toggle C1 to sort them.

[Greg]

jbenek,

Not being quite the programmer that BobO is, I thought of the problem a bit differently.

I made 2 tables:

V0-V5 = Engine1-5's hours
V10-V15 = Engine #s

So initially, let's say we read up the Engine hours and got:

V0 = 75
V1 = 101
V2 = 14
V3 = 52
V4 = 19
V5 = 73

And I would initialize the other table in the way I read the hourly values:

V10 = 1
V11 = 2
V12 = 3
V13 = 4
V14 = 5
V15 = 6

Thus the value in V0 corresponds to the Engine number in V10.

Then I ran a program like the one shown in the picture below. After running this program the result is:

V0 = 14
V1 = 19
V2 = 52
V3 = 73
V4 = 75
V5 = 101

...and...

V10 = 3
V11 = 5
V12 = 4
V13 = 6
V14 = 1
V15 = 2

So you can see that since V10 = 3 (Engine #3) its hourly value is in V0 = 14.

Thus after running the sort, V10 will always have the Engine number with the least hours and V15 will have the Engine number with the most.

Now, granted to make this better I would probably create 2 user-memory types in the Do-more called EngineHours and EngineNumber and use those instead of the V0-5 and V10-15 respectively.

[b_carlton]

So BobO's will always take the same number of steps (approx (n * (n-1))/2) while Greg's can take a variable number of passes from 1 (the list was already sorted) up to (n-1)^2 (the list was reverse sorted). Interesting.

[jbenek]

That works great. We had it working before but didnt have a way to trigger it like you do with c1

[BobO]

So BobO's will always take the same number of steps (approx (n * (n-1))/2) while Greg's can take a variable number of passes from 1 (the list was already sorted) up to (n-1)^2 (the list was reverse sorted). Interesting.

Yeah...I wasn't going for efficiency, I was going for what I knew I could make work in less than 5 minutes. 

[Controls Guy]

What i do is cycle the engines on and off through out the week in order to keep the run hours close to the same for maintenance reasons. I keep 4 on at all times. So when I shut one or 2 down I want to be sure the one or 2 with the highest hours shut down.... then when I start one or 2 I want to make sure the lowest hour units start.

Haven't given this a whole lot of thought, but just as an initial hip shot, I wouldn't bother sorting the values, in the sense of keeping them arranged in registers in order of runtime.  When you want to bring one online, crawl the (out-of-order) table to find out who's due and not online.  When you find it, turn it on and tag it as online.  When you want to turn one off, crawl the table to see who's online and has the most hours.

Also....as a practical matter, are you sure it's a good IDEA to precisely load level all the units?  Won't that make them much more likely to fail simultaneously?  If life == 40K hours, wouldn't it make more sense to keep 7K hours between units and THEN run them equally, so they DON'T all need replacing at the same time?  Also, your overall performance (efficiency, temperature, etc.) is likely to be more constant that way, as the average hours per compressor will go up from 16K to 23K, then back down to 16K when you replace one, rather than 0-40K then back down to 0 when you replace them ALL. Unless you have a scheduled outage every 40Khours (it is five years after all) so it's just easier to replace them all at once.