Having Fun with Yet Another Do-more Project

[Mike Nash]

I have a new project that is hurting my brain (conceptually.) In playing around with different ideas, or seeing what sticks to the wall, or tickles my brain, or whatever, I have come to a few conclusions.

First, it is so incredibly easy to do things with the Do-more. The biggest issue I have is looking for the instruction that surely must be there because everything else has been. (Unless I overlooked it, there is no instruction to SWAP two memory locations without switching bytes or words around.)

Second, bubble sorting 30,000 Signed Double Integers in a Do-more may take a few days if the values start as random numbers (nice function that RANDREAL()*10,000 or whatever for getting test values quickly. I had to "build" one once in a 260 and it wasn't fun.)

Third, I was surprised to find that MAPIO, INIT and MATH all ran faster than MOVE and much faster than MEMCOPY when doing the shuffle in a random 1000 cell bubble sort. No optimizations, all 1000*999 loops "swapping" Q-memory (just another D table) with a third temp holding cell. The first three take 2 min 32 secs, MOVE is 2 min 59 secs and MEMCOPY takes 3 Min 34 secs. Two runs for each with fresh random numbers. Sorting was done in a task with 100 uS time slice (more didn't seem to matter, nothing else is happening anyway.) Some optimizing has it to 1 Min 30 secs using MAPIO for full random values, quicker if partially sorted.

The MAPIO is the cleanest since I don't need to see the values as this is happening. That's the only thing I don't like about MAPIO for its intended purpose, the not having monitor values. But since I have 3 arrays to sort based on the contents of one array, I can do all of it with a single MAPIO, including an extra check value to stop sorting values that are already done. That's 10 discrete moves in one instruction, in order.

And no, I don't think I will pursue the 30K array option. It was just a test, it was only a test.

Nice job Host!

Now to stop tickling my brain by throwing it against the wall...

[Controls Guy]

Do you have to physically sort the arrays?   Would it be faster to generate an index array?

[ATU]

I wouldn't mind seeing a SORT function.

[franji1]

I wouldn't mind seeing a SORT function.

On the list.  We will add this when we implement Tables.

[Mike Nash]

Do you have to physically sort the arrays?   Would it be faster to generate an index array?

I haven't quite got the concept nailed down I'm but much closer. I don't think I'll have more than 200-500 values to calculate and sort and that happens pretty fast since I am sorting as the table is built. I also get to do all this before the machine starts up so no need for massive speed.

[Mike Nash]

Export Memory Data is a fantastic feature. Being able to select very specific ranges of memory to export and even choosing how many rows, and names and then one click into the spreadsheet has helped tremendously. (I have been looking for patterns in the data Do-more is producing from my code.)

I've looked in help and the forum but I can't find a means of saving the export ranges I've selected so I can easily pop out another batch to look over. Cut and paste didn't work and I right clicked all over with no helpful hints. It's not hard at all, but I have 14 ranges to type in each time.

Is there a way to do this?

I'll admit I have still got to dig into the memory manager as that still hasn't really clicked for me yet. That would make a nice tutorial video if it isn't already out there and I just missed it.

[BobO]

Memory manager just lets you pick which retentive ranges that you want to back up to the project file and restore to the PLC. You can view and edit the stored memory content. Nothing too complicated.

[Mike Nash]

I have another "How should I" type question on this current project.

Many years ago, in BASIC (never learned C), I would have an If Else type structure that could have multiple results for the If and multiple results for the Else, and their variants.

IF this=893
 do this, that and the other
ELSE
 do a few other things instead
ENDIF

I had some places today where this would have been handy but I only have the one result per MATH box so I wound up just setting a flag to handle the results in other instructions.

Is there a cleaner way to deal with this?

Second question - I suppose nesting If's in that MATH box is the only way to test for x=y AND z=7? The question being the multiple conditionals. They're great, just harder to follow. I could not easily do them as "contact" conditionals due to a lot of indirect addressing - some multilayered with offsets such as D[V[V10]]==TRD[200+V10] - which don't all work outside of the MATH box. (HA! I'm learning! I caught the single "=" before posting. That has tripped me up quite a few times.)

[BobO]

Until we implement some variant of a textual scripting language, constructs like that will always remain a little awkward. Traditional PLC languages are great at certain things, not so good at others. So short answer: no magic bullet.

[franji1]

I have another "How should I" type question on this current project.

IF this=893
 do this, that and the other
ELSE
 do a few other things instead
ENDIF

I construct IF/THEN/ELSE constructs via ladder logic using the NOT contact.  Basically, have all the input contacts driving a group of boxes for the IF portion, then put a NOT contact below the IF leg to drive a different set of boxes for the ELSE leg.

See the attached example.  Note that C0 input logic can be as complex as it needs to be to drive the MOVE box, the NOT contact is just the "not" of all that input logic.  Note also that the number of boxes being driven by each leg can be longer than 1 instruction for the IF part and the ELSE part.

[Controls Guy]

I construct IF/THEN/ELSE constructs via ladder logic using the NOT contact.

That's pretty slick, I like that!   

Also, if both the IF and the ELSE are computation of the same register using different rules, sometimes you can use the inline IF() in a MATH box.

[franji1]

That's pretty slick, I like that!

Yes!  And it is a very recognizable pattern when you see it...

Code: [Select]

{blob o'logic}--+----------+-[BOX1]
                |          |
                |          +-[BOX2]
                |          |
                |          +-[BOX3]
                |
                +-|>O------+-[BOX4]
                           |
                           +-[BOX5]
                           |
                           +-[BOX6]
                           |
                           +-[BOX7]


[Mike Nash]

I like that too and saw where plcnut on the ADC forum demonstrated that. My query was generated due to a MATH box construct required by the indirect referencing I needed for comparisons. And it also had nested IFs in place of the AND I needed.

[franji1]

I like that too and saw where plcnut on the ADC forum demonstrated that. My query was generated due to a MATH box construct required by the indirect referencing I needed for comparisons. And it also had nested IFs in place of the AND I needed.

You can do Boolean and, or, not:
 && ||  !

"(X0 && !X1) || X2"

[Mike Nash]

I like that too and saw where plcnut on the ADC forum demonstrated that. My query was generated due to a MATH box construct required by the indirect referencing I needed for comparisons. And it also had nested IFs in place of the AND I needed.

You can do Boolean and, or, not:
 && ||  !

"(X0 && !X1) || X2"

Yes, but I can do all that on the left side of the rung where I can see what state they are in!

Since I have involved conditionals that can't as yet be used directly in contacts, I was simply wondering whether I was missing some clean looking method of doing it in the MATH box. The MATH box is great, it is just not going to show the current state of conditionals, etc. as well. One of the boons of ladder over ST or whatever is that visual feedback.