Manufacturing has always had its unique set of challenges. Skilled labor shortage is at the top of the list. We’ll cover that hurdle in upcoming posts!
In the meantime, another challenge at the top of the list is technology -- the Industrial Internet of Things (IIoT), getting intelligence, aka data, from machines.
Today, we’re covering a couple of Industrial IoT challenges an elliTek customer was facing and the real-world, actionable solutions our team of problem-solvers created.
To set the stage, elliTek’s team met with the database administrator and their contractor in charge of setting up elliTek's Data Commander™ MES Gateway Appliance and their andon system.
Challenge 1: Simplify the process of checking multiple strings coming from a PLC
The problem this customer was facing was from the database side.
A barcode read from a part is sent up to the database. A response is sent back to the Data Commander (an IIoTA, elliTek’s Industrial Internet of Things Appliance can be used in lieu of a Data Commander) according to which process it was. The response could be a multitude of things.
In our customer’s situation, they wanted to be able to pick out a specific response from all the numerous options returned. All that they wanted to know was if the part was OK to go or No Good, but to arrive at that conclusion was the issue - there were multitudes of possibilities that could be returned, along with the 'Ok to go' or 'No Good', in a multitude of strings.
For instance, if there were 15 strings returned resulting from each code, the customer thought they’d have to create 15 checks for every trigger.
IF it’s this value, then do this. IF it isn’t this value, then move on to the next and so on.
So, if there were 15, 25, or even 50 codes, they thought they’d have to have that many IF statements. Utilizing an IF statement for each check quickly became daunting, so the customer asked elliTek if our problem-solvers could come up with a better industrial IoT automation solution.
Our team, the database admin, and the contractor discussed the application in deeper detail, and elliTek's team rose to the occasion. The final solution was simply using our string builder function in which they would create a single string that could be delimited or not, but basically would append or concatenate all 15, 25, 50, or however many strings into one string.
In this case, once concatenated into a single string, the user can now search the string using our string compare function to see if the “No Good” exists or if the “OK to go” exists, or not.
By simply looking at a single string, it allowed our customer to decide an action.
To do that, they would use our string builder and that would create the string to begin with - That's one command.
Then the second command would be our string compare function in which they would compare the string to see if they found anything in there that resembles or contains.
By setting the string compare to a "contains" string test, each string can be found despite all of the neighboring responses, assuming it exists. Of course, if either string is not found, that can act on that as well.
In summary, by using our string builder function in combination with our string compare function, they can more easily decide the outcome as opposed to checking all 15, 25, or 50 strings 15, 25, or 50 times.
From up to 50 commands down to two commands – a pretty good simplification.
Our customer’s response -- “It’s working perfectly!”
Challenge 2: MySQL for ID changes - the Listener
Occasionally, this customer can have what they call message ID’s. It doesn’t really matter to the Data Commander™ MES Gateway Appliance or the IIoTA™ as to what the message is, just that it’s data. The customer is using MySQL. If any of the data message ID’s are modified (modified in a data table on the enterprise level) the Data Commander / IIoTA needs to be notified of that change so it can update its local database.
The objective is to keep MySQL and the database on the Data Commander or IIoTA in sync. If the main server goes offline, the customer must be able to continue to run parts on their assembly line. Having a mirrored database local to the Data Commander / IIoTA ensures this functionality.
The manufacturer thought they were going to have to constantly poll the data table, read it back, and perform some type of compare function in the Data Commander. Compare each one of the message ID’s (data fields) to see if any of the fields may have been changed. If the fields were different, then it would be overwritten in the local DB.
The customer had a justifiable concern about inefficient bandwidth utilization, because they would be polling the entire time, and the reality was that the MySQL data table on the server was rarely updated. Constantly polling for the same data was far from ideal.
elliTek’s IIoT solution – On the enterprise side (the database side), if any change happens to the MySQL database, a trigger can be setup such that, upon realizing a change, MySQL and connect to a device (in this case a Data Commander or IIoTA), and then send a message.
The Data Commander or IIoTA can be easily setup to "receive" that message from the MySQL database server – we call it a Listener. So, we set up a Listener that would listen for any messages that may be sent by the MySQL database server. The Data Commander / IIoTA is setup to listen for a message to come from a specific IP address, and to a specific port - any other message from unidentified IP addresses or to unidentified ports are simply ignored. In this case, since there is no polling, a message may arrive today, or may not arrive for a month, but it isn’t taking any bandwidth in the time in-between.
In this mode, the Data Commander / IIoTA is silent on the network - it's just listening.
As soon as something comes in from that predetermined IP address and that port, and it matches what we’re expecting from the server, then we spring into action!
Whether it's parsing the message ID’s being sent down in one fell swoop, or more simply reacting with a Select of the MySQL data, the information can be gathered and the local DB Updated all at once...and then...silence. We return to just listening.
Now that's efficient bandwidth management!
elliTek eliminated the need to constantly poll - saving bandwidth. In addition, production doesn’t stop if the main server goes offline.
elliTek’s customer can continue to run parts on their assembly line without worry of Production Downtime should the server go offline, by utilizing the internal databases residing within both the Data Commander and certainly the IIoTA.
This solution represents a tremendous improvement over polling. The message ID modifications don’t occur very often. The Listener can act as the event trigger to the project trigger, and the customer can either parse where it’s sent, or they can enact the transaction to do a Select of the information and Update the local database.
It’s simple and effective.
Watch this video to learn how to create a LISTENER.
If you'd like to learn how to Create a Listener Map and how to Create a Listener Trigger, the Data Commander website has those video tutorials plus more.
The IIoTA, Industrial Internet of Things Appliance, will be released next month. Not only does the IIoTA do everything that the Data Commander can do, but it contains a fully functioning, integrated database server, pre-built data server apps (e.g. Traceability), and pre-built dashboards. Click here to learn more about elliTek’s IIoTA.
Tell us what your biggest IIoT challenge is.
Is it lack of skilled labor, technology, or something else?
Comments