By Steve BaileyThis is a simulation of a tank fill/drain system. The simulation runs on your PC while connected to a PLC. When the PLC program turns on the pump the simulation shows the tank level increasing. The simulation also sets and clears discrete inputs represe
By yomeMini Scada Pro is like sounds its name a mini Supervisory Control And Data Acquisition. It has been designed in order to help in debugging automated systems.
New version 1.1
By TimWilbornePeakHMI is a full featured robust Human Machine Interface (HMI) SCADA program designed with the engineering, operations and management needs and wants at the forefront of development and product roadmap.
By OkiePCI got a little carried away with this exploration of rotation animation with Crimson 3.0
Improved shields, now available at 100% to start the game, shows up as unfilled ellipse around the truck. Can be used to put out your own truck when on fire. Improved truck steering...still not where I want it added 2 pages running at enhanced and overdrive update modes respectively Made end of game appearance transparent, with action continuing in the background. Improved tag names fixed problem with restart not working improved collision detection beginnings of comments
Added fire button (single shot, level 2 and up) Increased number of animated enemies to 28 Changed Game Over font (missing on old XP machine) Altered circular movement of targets
r007a: Fixed problem with collision loop (spontaneous explosions!)
--Performed conversion to G310, fixed a few over sized fonts and added that version to the zip (soon to test with real hardware!)
r008: Made numerous polishing touches:
Hero truck is now colored magenta. Some of the images have a transparent background. Added extra lives with indicators Changed missile and enemy travel limit logic Adjusted shield rates to make the game more playable Remodeled control panel
-Missile occasionally gets taken over by Auto program. Sort of a good bug for a video game, so I decided not to fix it yet. I may add a flag later to make this bug selectable.
-Images need black pixels replaced with transparent ones to allow alternative play-field colors/patterns.
-Observed failure to complete a level when hero is sole survivor.
-Still need to tone down speed especially after level ten when using the overdrive update rate (Page3).
Wow, at least in the emulator, Crimson is more than fast enough to reproduce the old school arcade action.
I am still having fun with this thing, tinkering with pattern animation now, but the little blurb of a graphics speed test turned video-game had no spine.
I have successfully inverted the code and wrappered it storybook 2-d shooter style, and will be posting some variation of the Galaga shooter type of level, some mountain jumping. It may be a while before I finish chugging through the new structure, so I can do space invasions and galaga and whatever else. I can't wait to try this on real hardware. Picture a portrait view with the Menu button being a fire button, so you could touch one action and still shoot at the same time, right?
This is cool as he<L...
Wow, I remember being amazed by the Crimson 3.0 script language on first sight, but now with the graphical editor being a work of functional genius...I am in love.
What a powerhouse!
Then, I need to turn the pattern matching game result toward a work related packaging department to convince the powers that they don't need more checkweighers, I can upgrade three they have...they started to understand, but I can prove it with real time sensor (photoeye + PLC position tracking logic)...substitute my exploding truck for cases of patties, and show them how they would flow with my process changes...I think I did spend a couple of hours on the clock with this, polishing and uploading it, so my employer should get something back from that effort.
So, I need cartons flowing around curves, 180 degrees, 45's, two diverters, case check weigh stations, manual stations, carton sealers, then toward the robot area where theres another diverter. This game engine can already position 40 objects and update their data with such quickness...I will be leery about using the Overdrive mode in a production control setting after reading what Red Lion wrote in the help file...
I need some one who understands widgets, to help me make an "Action Figure" widget out of my O tag folder and related graphics elements too.
G3 Truck Shoot 'em Up r001
This one is almost playable...minor tweaking could make it more challenging. It allows multiple missiles to be fired with no minimum delay between. This makes it unfair. The other changes are numerous. I turned the program inside out as far as logic flow, and this would enable further expansion and addition.
By OkiePCWith 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...