OkiePC

I needed an equivalent to the Panelbuilder32 screen list selector for up to 26 pages with scrolling too, so I built one.
I thought it would be a nice thing to have access to for those of us who have a lot of PB32 to G3 conversions in our future.
It is built for a G310 and there are comments in the program files with some instructions for how to customize it for different lengths. Right now, it is set up for 50 pages, with a visible length of 14, but that is easy enough to change. My goal with this conversion is to make it as easy as possible for veteran operators to adjust when we replace the Panelview 1000, so I made it look as much like the PB32 object as possible.
EDIT: I should explain, to get the the page with the page list selector, hit the button at the bottom, 2nd from the left labeled "Screen Menu".
This app also includes SLC communications with alarming, and SLC error codes with complete text, and language switching (English and Spanish, but the Mexican flag icon was not properly saved with it, so if you click the American flag, it will disappear and switch to Spanish (machine translated!) just touch that area again to switch back to English.
Paul

This program is used to construct a sequencer with both input and output sequencing. The excel file is used to design the sequencer and includes features to update the user selectable files in a PLC using DDE. The PLC program sequences the inputs meaning that the input pattern for each step determines when the sequencer advances. A mask file is used for the inputs so that those that are irrelevant for a particular step can be ignored. This program does not use the classic sequencer instructions but uses MEQ and MOV instructions with indirect addressing instead. This leaves the end user more flexibility for controlling the step number.
Update r002: Added CLR instruction to the diagnostic word so that it does not hold "old data" as the sequencer advances.
EDIT: Added a beefed up version* for a real world machine (OK International 220 Servo bag inserter.) This program is not fully polished, I think the version here was after a few hours of refinement, and then stripping it down for speed. Today, I hit a full 17.5 bags per minute replacing logic that was running at 14.5 bags per minute. I ended up removing another input conditon for the seal bar timer, finding that it doesn't need to inhibit the opener from opening. I need to put in a discharge timer to keep the belt running long enough to send the last box out when finished even when the downstream is blocked, but continue to hold back the input clamps. it would be handy to cycle stop and have the machine empty itself too.
My main next goal on this particular machine, is to find out why the Ultra drive is not ready and homing quickly enough. I think my reset times are worse than the old logic! It seems I have to wait 5.5 seconds after the drive is ready before I can send it a successful home trigger. Today, I tried keeping logic power applied, and it did well until someone had to physically move this linear device and caused regeneration which triggered a non-recoverable (must power cycle)... E41...So, I can't cheat with two black wires unless I add a shunt or an output contactor to dodge this hard fault. The extra effort will be an amazing improvement in recovery times when they have to open the doors. Now it take almost en seconds sometimes to reset and then reset. I must be sequencing the output logic to the Ultra drive incorrectly,.but I have altered it several times with little improvement. There will be more trial and error with the wiring and perhaps a DB to get this right.
*The 2nd file includes a rate calculation (boxes per minute in this case) as well as a programmable minimum and fault timeout for each step, multiple modes (auto, manual, single step, bag only).
Known limitations: I have realized the need to add a macro button to the xls sheet which would read back the PLC sequencer data and populate the bit fields in the sheets. I also still need to lock the references so you can move the raw data without hosing up the references on other sheets. For use as-is, just don't drag the raw bit data or insert data, copying and pasting is fine to move steps forward and backward.
I also need to add to the excel sheet some columns for minimum time in step, and fault times so they can be edited from the workbook too.

I got a little carried away with this exploration of rotation animation with Crimson 3.0
r005 2012-07-04:PEC:

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
r007 2012-07-04:PEC:
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
Bugs:
-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.

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 ;)
Have fun!
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...)
Paul
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...
Paul

This zipped cd3 file, built with Crimson 3.0 version 469.000, contains a tag (Status.SLC_ErrorLSW_Dec) which will display all of the error codes for a SLC.
The tag is set up with a multi-state format with 93 states to cover all of the error code texts as found in the RSLogix500 Online Help. For items that reference a slot number or a file number, that information is embedded in the text as well. You should be able to copy and paste the relevant tags into any application using a SLC, and then point the data source at your already configured device.
There are a few other tags including one designed to interpret the SLC keyswitch and mode.
There are a few other pages already set up for a Fault History, Active Faults list, and some Master Slides with dummy buttons on them that write to internal bits.
The device "SLC" is set up on the RS232 port with a DF1 driver set for 38.4k baud. If you need to use Ethernet or a different port, delete the device SLC first, then add your new device and name it SLC. This will take care of any tag reference errors. After all the tags are identified with your SLC on your comms channel, you can rename the device as you wish and Crimson will rename it throughout the application.
On the SLC Status page, the whole S:6 error code tag is set up as a data entry field (in hexadecimal). Writing a value to that S:6 address will not cause the SLC to fault, it will let you view the text for each value for testing and demonstration purposes. If you use these elements in a production situation, that field should be changed to display only.
Note the little flag icon on the upper right? That switches languages too. I did that with a couple mouse clicks in Crimson to do the whole database from which this file was extracted. Later, I went back and deleted the translations for the tag states because many of them became too wordy to fit neatly on the screen.
EDIT: r001: Added flashing indicators for each of the first ten slots that will light up when the respective slot generates a fault. If the slot is 31 (dec) all slot indicators light up and another text pops up to tell you that the exact slot cannot be determined. Improved one of the error descriptions based on online help at ab.com. Added indicator for EEPROM Loaded on boot. Touching that indicator will allow the user to clear the EEPROM Loaded bit.
If there are any corrections or further enhancements or suggestions to make this file better, please do let me know. I love constructive criticism.
Thanks,
Paul

EDIT: I think you may find that the flag icon doesn't include the bitmap for the Mexican flag when switching languages. After I shared this file, I learned a few more things about how images can be stored relative to (or within) the application. My next revision will embed that flag icon in the application, add numbers to the slots, and not turn the processor "flashing fuschia" unless the SLC is truly halted (just 'cause the last major error word contains data, doesn't mean it ain't runnin' again...)

This is the rough draft but I have many hours in it.
Run it on the Emulator only. I have not tested comms with a Click PLC yet. I put it here in the Automation Direct category, because I plan to run this 1000 step sequencer in the Click on my front porch, once I get all the bells and whistles ironed out.
Crimson 3.0 Build 469.
Run In Emulator
Includes:
*Scrolling Specialized Sequencer Display and Configuration Screens.
*40 screens with a navigation panel making use of hte menu (hard) button.
-this needs work. Right now, the only way to increment the menu is by using the menu button to cycle through 6 overlapped menu bars on the Master Slides.
-editing the nav menu is best done by dragging the groups (on the Black Master Slide) to the right until you have all of them in view. Then you can make changes to one member (wihtout ungrouping), then copy and paste special onto the other members of the group by holding shift + select)
The Navigation button text and page titles are tied to individual tags. I started with an array, but then couldn't individually control colors, so now they're individual tags.
The animation on the Sequencer Config Screen is pretty farging cool if I do say so myself.
I don't like my vertical text labels, so I am thinking of switching to individual character references to a custom font to give the appearance of angled text at bout 30 degrees. But I will need to be really bored to go that far.
I am also planning to alternate strips of background colors and make column selection and editing tools.
The rung editing buttons are stubbed, but I wanted to put this out there for critique before proceeding. Especially if someone has a real G315 to run it on. I need to know if my bit triggler is fat finger friendly.
Also, I have not tested the Click Modbus comms.
Run it on the Emulator, and go to the Sequence Config page, then touch the fire. Drill into my creation...
Paul