Having Fun with Yet Another Do-more Project

[franji1]

One of the boons of ladder over ST or whatever is that visual feedback.

Graphical language > textual language

A picture is worth 1000 words!

[BobO]

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

One of our wishlist items is to add a status bar at the top of the view that would expand status on expressions. Another wishlist item is to expand expressions to virtually any input parameter...which is why we added the status bar idea. It's bad enough that we can't get status of math box contents, but imagine how much worse that becomes when you have small expressions scattered all over the logic!

[Mike Nash]

Now that would be handy!

Rockwell's CPT (MATH) allows you to hover over a tagname and it will show the value in a small box, but only for the one you are hovering over. Good, but not great.

[Controls Guy]

One of the boons of ladder over ST or whatever is that visual feedback.

Siemens' TIA Portal does a reasonable job of showing ST status.  In status mode, there's a display off to the right of the ST code that shows IF() results, values of variables, etc.; it can even add additional lines to the display and space the ST lines when it needs to to have enough lines to show status.  It's not quite as obvious as in ladder, but serviceable.

Can't remember what AB does for ST status, if anything.  It's been about 4 years since I did any ST in AB. It's like a CPT box, IIRC.  You can hover and get one value at a time.  Pretty weak compared to the Siemens implementation if my recollection is correct.

[Mike Nash]

I thought I would update this thread. I got to playing around with this project in the simulator and our test Do-more over the weekend. The machine is running well, only had a few bugs and feature requests. But one thing has bothered me for awhile.

The relatively quick table building, sorting, shifting, re-sorting, etc. works, but the task takes about 67 seconds or so to complete which far exceeds what I was seeing early on. So I have been looking at other sorting methods.

Well, when I stripped off all of the other code to look into optimizing it, the simulator was handling the task so quickly I thought I had broken the code. I then loaded it into the test PLC and that was completing in 13 seconds. So what I found is ... (yes, I should have found this sooner)

1) Default Yield every 100 micro-seconds in Program/Task Code-Block Configuration dialog is way, way too short when scan time is averaging 2.45 milli-seconds without the task running.

2) Changing the yield time in the above location DOES NOT DO ANYTHING UNTIL PROGRAM TO RUN TRANSITION. I discovered this when I stumbled across Timeslice and could monitor/change it. And gee, it does indeed mention both of these in the dialog. 

3) Stripped down code doesn't take 2.45 mS scan time, it's only 0.356 mS.

4) I added a program I can set the Timeslice on that simply Goto's a label in the previous rung. This allowed me to set an average scan time for testing. After this I changed values and recorded results and determined that my convoluted task actually requires about 2.8 seconds to run all by itself, exclusive of overhead. So I was able to confirm that a 2.4mS scan time and a MySortTask.Timeslice of 100 uS does indeed take about 68 seconds to complete. But! With a MySortTask.Timeslice of 2000 uS, it completes in about 6.2 seconds. And since a 4.5 mS scan time while this is running once in every so many shifts (for 6 seconds!) is no issue. Whoo Hoo! Now I just need to go put it in the actual machine sometime.

At 30,000 uS timeslice for the task, it completes in 3.0 seconds.
At 50,000 uS timeslice for the task, it completes in 2.9 seconds.

I will probably stick with 2000.

[franji1]

Now you know the power of Do-more .TimeSlice-ing!

You have complete control over scan time vs. calendar time for your looping algorithms like sorting.  Just tweak the .TimeSlice member, just as you did.

The last thing I do is put a MOVE at the top of the task/program to set .TimeSlice in code. Then the rung comment documents what I tried and how I came up with THAT value in the Source of the MOVE.  The configuration value is just to initialize it on PGM to RUN.