Todd Shedeck

Web breaks are a major factor in performance leading to savings for our business. Through another project below, web detectors were installed to capture the tensions at each tower and reelstand. This was a great addition to help during running for tension control but this did not help to explain failures, since the web break information was not stored.
I decided to build a capture and storage process that could be used for both live operation and historical purposes. The tension data would be pulled directly from Printa system during operation and placed into a database. Once in the database, the services and application built could then use this detail. Not only would it help the tension gpahing process but it could also benefit the ERP system by supplying a faster update time. The Honeywell database, at times, could take up to 1-2 minutes at times to refresh where this new process would update in seconds. With the data now stored, advanced run reporting could also be built for later analysis.
For the capture process I decided to repurpose a logging application that was provided by Honeywell for mining data from the Printa system to an output file. These files were then pulled into Power BI and mapped out, which provided a quick and intuitive way to visualize the data. The problem using Power BI was the lack of quick access and control this provided to the operators and managers to help provide immediate results without a lot of filtering and analysis.
Using the Power BI reports as a template for the visual layout, I created a Node script to pull the data from the file and place it into a MySQL database. Next a webpage was created that first pulled from the Printa SQL database to get the original job build, and then use that information to pull data from the MySQL database to get the corresponding data in JSON format.
The run, waste, and all the related tower and reelstand tension data was then parsed and graphed out, set to run from a job selection list. It is relatively new but seems to be successful, click the job in question and all the relevant run and tension data is displayed immediately for analysis.

Technology: Apache, HTML, CSS, PHP, jQuery, MySQL, JSON, NodeJS, NSSM, CanvasJS, Power BI

A long time ago I had originally installed temperature & humidity devices (THUMB) throughout the facility for monitoring critical areas. With advances in IOT devices, and the overhead involved requiring a PC for the THUMB device to connect and operate through the software, I decided to look into something more efficient and autonomous.
The IT department was installing GEIST sensors in the server rooms and closets that connect directly to the network, with similar monitoring capabilities, so I decided to try and consolidate and switch to these units as well. The devices worked well but did not easily allow the visual interface and immediate display that the THUMB devices offered through the PC, especially for the maintenance department or digital displays.
To get around this limitation, and provide the technicians a similar interface, I decided to build our own web interface. An API was built using PHP to pull the information from the devices using SMNP and serve the results in JSON, then a NodeJS app was built to pull this information and place it into a MySQL database. A website was then built to display the data in a table for each device connected. An action was then created to pull and display information over time for whatever cell of data was selected. A display was created for the digital display screens as well, in the maintenance department, that would change color so there would be an immediate indication of a possible issue to anyone passing.

Technology: Apache, HTML, CSS, PHP, jQuery, SQL, MySQL, JSON, NodeJS, NSSM, SNMP, CanvasJS

Due to the yearly service contract and discrepancies between counts of multiple systems, I decided to develop a web interface that could take advantage of our current systems and eliminate the duplication and discrepancies that constantly caused confusion.
The previous QTMS system was used to collect shop floor running data and place it into the ERP system for running metrics, using proprietary hardware that was installed during implementation as an add-on to the ERP system. The replacement web application built resembles this QTMS extension, to maintain operational familiarity, except for the separate hardware and displayed details. It pulls and consolidates jobs from the ERP system, press run data from the Honeywell system, preink pages from our FPAR system, and Inserter run data from the Muller Martini system. This information feeds the web display that the operator also interfaces with, to add other important details during operation. While running, all of this is placed in an separate MySQL database for temporary storage, backup, and planned extended reporting that was unavailable with the current systems. When finished, the operator verifies the details, which then send the final information back into the ERP system so that an operations report can be sent to the customer. The extended usage of the temp database was then used to provide information on current operation and efficiency for digital displays and a separate website portal for managers.

Technology: Apache, HTML, CSS, PHP, jQuery, SQL, MySQL, JSON

Because of constant changing technology, OS upgrades, security patches, and web expansions we were operating on an older webserver with processes and security vulnerabilities. Instead of updating and upgrading current server applications and processes, rebuilding was the decision. Not only was it better to start with a clean system instead of upgrading, you can also take advantage of this time to re-evaluate current processes, looking for potential upgrades or improvements.
The latest of all software was used in the core install including Windows, Apache, PHP, MySQL. Apache was configured using vhosts to take advantage of our internal DNS and multiple sites. Set up schemas and users, then restored database tables and data from backups of the current system. Transferred all websites to the new server and modified logons and configured the new drivers used in the updated version of PHP, moving away from deprecated logic and modifying for newer standards.
Removed old VB scripts that were used to capture streamed data from Serial-to-IP devices and modified webpages to pull data from the new capture devices on a separate SQL server. Moved away from Java and Pentaho jobs, rewriting scripts using Python. These new scripts pull data from files and write it into the local MySQL database, which are tasks set to run daily.
Auto-backups were then created and set to run daily. Sendmail was setup and configured to use our internal SMTP server, used in scripting from the local task scheduler since the windows mail was being deprecated.

Technology: Apache, HTML, CSS, PHP, jQuery, SQL, MySQL, MySQL Workbench, JSON

In an effort to clean up and help to create a fresher look with more dynamic control, I started looking into digital displays. This was something discussed in the past but technology was not as easy and available at that time so the cost could not justify what it could offer.
Now with readily available components and larger flat screen TVs at a lower cost, building a process internally, and more affordable, was a possibility. After deciding the cost and requirements, a project plan was written up, proposed, and presented. After it was approved, the hardware was installed, software and webpages were built, schedules and displays were configured, and then training was provided for the HR staff.
This became a very successful implementation that has since grown to additional monitors across the facility in separate departments. Being able to build and display metrics and data related only to those areas, with dynamic displays and metrics, this has opened up a lot more opportunities and communication options.

Technology: Risevision, HTML, CSS, PHP, jQuery, SQL, MySQL, JSON, Raspberry PI

Within our industrial environment there was a lot of coordination required to manage workflows and processes involved in estimating, planning, scheduling, distribution, invoicing, and shop floor data entry. This ultimately created a very chaotic and inefficient situation by using various 3rd party systems in workflows to display, process and evaluate the information for each area independently, then using manual consolidation through Excel. To improve this overall process, we decided to invest in an ERP system.
After evaluating many systems as a larger group, and finally deciding on a system, three employees were ultimately responsible for its implementation, myself, our financial manager, and our scheduling manager. There were a lot of shared duties but specific responsibilities, as related to my part, include application display customization, data entry requirements, shop floor data collection interfaces, scripting, 3rd party application interfaces, and report writing.
Application customization involved making specific changes to the visual style sheets for operator entry, tailoring each style sheet for each department and position. Data entry requirement design included understanding what reports are required first, then developing the fields for entry and storage in the database to satisfy the future reports filtering, grouping, and calculations. The shop floor interfaces consist of connecting into or using details from existing equipment to eliminate duplication entry from operators. The Honeywell Printa system required modification to the logic to provide the necessary outputs where the Muller inserters only required mapping current outputs. The new system and devices were installed and both interfaces were then physically wired into the new system.
The application had an internal scripting system allowing for a sort of macro response to actions performed. A lot of these were set up to automate many processes such as launching reports, clearing fields, closing jobs, exporting data, and printing job packets with single operator actions. The internal reporting was an expansive system that offered a lot more than standard reporting, it also allowed for programming integrations and scripting. It was first developed for invoicing by pulling external excel-based price scales that were too complex for the internal grid pricing required for our needs. This was then expanded to reading from an excel file to calculate paper usage, import distribution quantities, insert imports and exports of invoiced items in structured xml format that another system would then import. In-depth reports were built more interactively with button-based scripts to perform actions or run more detailed, filtered results. This is a continuous process of customization and report writing to fit any need or new requirement.

Technology: Prism, SQL, IIS, Alcont Printa DCS, Pentaho, Python

One project involved an engineered modification from an original design because of the cost savings and extended visibility it offered. There are large static annunciator displays attached to packaging equipment to display important zoning information to the operators. The problem was that the display faced only one direction, toward the machine, which limited the visibility for the other processes downstream.
The original idea was to purchase two more of these annunciators to face the back of the machine. There would still be limitations due to the immobile nature of these units and less ability for future expansion. What we decided to do was re-engineer it with more global visibility. With this in mind, instead of purchasing two more annunciators, we purchased a Nintendo Wii, a Serial-to-IP converter, and large flat screen TVs. Since this was prior to the explosion of IOT devices, a lot of discussions, and justifications, for our purchases were required. With these items, we intercepted the signal going to the annunciators, redirected it through a Serial-to-IP converter, captured the stream with a VB script to a file, and then read this file into a webpage. Not only did this offer greater flexibility and visibility but the costs were significantly less than purchasing two more annunciators.
This had since been modified using newer, cheaper IOT hardware to offer even more options for newer TVs and monitors while expanding visibility to more locations. The VB scripts were also replaced with software to capture the stream and place it in a SQL database, which were mined and placed on the new displays and into the other webpages as status updates.

Technology: Serial-To-IP, Advanced Datalogger, HTML, CSS, PHP, jQuery, SQL

An extremely meaningful and impacting project involved installing tension meters on the press. The issue was that the operators had no clear, reliable feedback on the status of the web tensions. This lack of visibility made overall tension control difficult to maintain, leading to a higher amount of web breaks, waste, and overall downtime.
Building visibility into tension control was a project discussed many times throughout the years but the cost and unknown ROI was not enough to justify and move forward. With in-house efforts to offset a large portion of the costs, and updated data analysis, we were able to push forward with the project.
We took on all the hardware installation and software programming, leaving only the costs of required hardware and our time and effort. Rollers with the tension transducers were installed in critical locations, replacing the existing idle rollers. The transducer signaling was sent into converters which then transferred the signal into Honeywell analog input cards (MAI) that were installed and configured into the Printa press control system. The logic of the Printa program was modified to integrate the MAI inputs, warnings were programmed for minimum and maximum ranges, and new screens were built to display the information. New monitors were purchased and setup as extensions to the production PCs and integrated to display tension reading on one display and the standard operating controls on the other. With this new visibility the operators could now see and manage tensions, drastically decreasing web breaks and increasing overall production efficiency.

Technology: Alcont Printa

One of the first projects I was involved in was very shortly after being hired into a new company. Being a new building and installation, there were a lot of minor quirks and trial and error operations.
One of the first larger issues involved an instance of breaking glass during the initial loading process. With the larger sheets of glass, automated sections of suction cups were used to pull the pieces off an A-frame to the load conveyor. If there was a problem with the separating agent during the initial packaging, a vacuum was generated between the currently loaded piece and the adjacent one, causing the second piece to fall and break.
The repair, since we could not affect the initial packaging, was to try and mitigate the vacuum on the adjacent piece. This was done by adjusting the PLC logic to introduce a stagger and delay to each section of suction cups. The cups would grab the piece of glass, pull back one section at a time to create a peeling effect, delay to allow any movement from the adjacent piece to settle, then finally lower it to the conveyor.

Technology: GE Fanuc PLC Programming

One of the first more meaningful projects was an improvement to increase the overall process output. The problem was with the medium sized glass and lack of conveyor coverage. Because of the specialized manual load process, requiring two people and driven roller assist from the conveyor, this limited the current method and amount to one piece per load process. From a time and material standpoint, there was a lot of waste in preparation and process material while grossing less overall product.
The idea was to design a way to fill the conveyor while allowing the overall load process to remain the same. The solution involved splitting the chain mid-conveyor, adding a sensor and a clutch, and modifying the PLC logic. The resulting process was that the first piece was loaded and run up to the transfer position. The clutch would then disengage, allowing the front half of the conveyor to continue to run, and the second piece to be loaded. This second piece would then move up to the sensor, filling the load conveyor and re-engaging the clutch, moving both pieces to the next section. This doubled the efficiency for the medium sized pieces and decreased the amount of material wasted, and cleanup time, caused by sputtering to empty rollers.

Technology: Allen Bradley PLC Programming