About This File
With the truck shootout graphics as a basis, I made a work related effort by modelling one of our packing areas.
This file runs in the Crimson 3.0 emulator and will display little pink fill animated boxes to represent cartons of product being manually filled.
Once each of the 21 pack stations get a box full, it is popped onto the conveyor belt and moves along through the process.
Each object takes up space along the whole path which is defined with lots of hard code. I built tools to teach those positions intially, without thinking about making the project portable...those retentive tags didn't seem to make it to my thumb drive...so I taught the path easy peasy with the emulator running, then painstakingly added hard code to poke those position values into array points.
Each belt has an adjustable "rate" which is not tied to reality (yet). I found that the speed with which the emulator updates a page varies dramatically from one PC to the next. At home, I switch the display page properties to overdrive and get about 15 updates per second when there are 20 or more boxes flying around. At work, I get 40-60 updates per second so I slow it down to enhanced mode.
The unlabeled data in the lower left is my quick and dirty method for "frames per second" or updates per second.
EDIT r001: After my little doh! (why don't i just count frames in my existing once per second subroutine?), I discovered the undocumented system variable already doing just that.
EDIT r001a: Oops, set the background task back to by caller, went ahead with my dispcount to real time compensation with the goal of having decent accuracy once I later apply real world measurements to my scale factors.
Someone may have advice for my calculation of DIspFactor, but the goal is to be able to update the positions of the now 25 animated weight stamped cartons along the path at a control reliably but smooth and pretty rate.
I am most certain my code can be tightened, I am unsure what impact the postiion (within branches of logic) affect the overall performance of the final code, or if access to a Crimson tag is faster...
All comments and criticisms are welcomed on the discussion link.
At some point, I will improve that bit of math and find a way to get realistic behavior from my animation with varying update rates, probably by using that frame rate calculation.
At the present state, this file is suitable for sharing and others may find it useful for ideas. For actual usefulness at work, I intend to get the animation timing/speeds realistic first, then add controls which allow a user to select our various production arrangements (which affect pack station fill rates) and then allow adjustment of line speeds to model the results...
How much time do we really have at each scale to make weight and close the liners, etc?
This model should help us find out in a very graphical and intuitive way.
There are some other neat things I played with, like dynamically switching the background color (click on the updates per second value) and using Dec2Text to move the case weight onto the moving animated rectangles so they travel carrying the numbers along with them. I used 4 pointed star (missile from the video game) for my rectangles this time instead of overlaid images. The 4 pointed star already has a rotation property and can be adjusted to look remarkably like a carton of beef patties!
It isn't bug free. Earlier today, I watched it knock a box off the conveyor near one of the kickers. It looked too realistic then. Must be a problem with some of that digital cardboard I used or that virtual air pressure going to the kicker ;)
I should add some operating instructions:
Only one of the "trough percent fill" values is animated, the others are what truly determines whether there is a chuck worth packing onto the pink fill animated pack table.
You can disable each of the pack tables by clicking them, the border will flash when disabled, but the trough is actually what you are disabling (whether you can see the trough or not, one exists in tag form for each trough).
The button marked OFF is the diverter mode selector, "all", "alternate "or "off", click to step through the 3 modes of operation of the kicker to the offset line (one of the Win. tag objects elements acts like a conveyor section mathematically...)
Well, it's obvious I would need some sort of mathematical miracle to be able to derive any accurate measure of time less than one second, so I will go the feed forward route and alter my DispFactor to correct for time by multiplying another scaling factor derived from number of visible Objects which drops my update rate to about 1/3...I am not even yet counting how many packets are visible...
The latest version has company related process capability info and details, so I won't post it. If i conquer the time thingy, (and I will, even if it means another layer or three of self learning or calculated scheduled gains) or Mike Granby coughs up a 0.1 second or better timebase, I will strip it back down of proprietary info, and post it in the future...If not, it shall remain a toy...until I drop it in a real an app and connect the O.position tags to PLC tags...and emulate that way...I was hoping to build a highly accurate and fast updating offline emulator to give to the production gods to run on their own... Who knows what the DispFactor will be in a real G315? I probably will have to switch to a G310 to find out...