Corrugated Box Industry SHARC Success Story Pt2
In part one of this story, I discussed our initial installation of the Banner Wireless Sure Cross system and replacing it with our SHARCs. I don't think I explained the "why" of replacing it with SHARCs.
The largest contributor to removing the Banner wireless was the complexity of setup and troubleshooting.
Here is a simple representation of the Banner Wireless infrastructure. Six legacy machines with a single 24V DC sensor to capture the part count.
Here is a simple representation of the same infrastructure, but with Banner Wireless replaced with SHARCs and an MQTT Broker.
Sensor to "Adapter"
Troubleshooting from the sensor to the DX80 wouldn't seem too different based on the diagrams except that in the SHARC diagram we can visualize the signal from the sensor very easily through an MQTT client like MQTT Explorer or our Sharc Studio iPhone app. I'm not sure if you can visualize this portion of the Banner Wireless process at all without using a client program AFTER the DXM like Node-RED and programming the visualization. Even if you use their software that connects to the remote node for configuring I still believe that it just shows configuration options.
Installation requires opening up the DX80 and wiring to the terminal blocks. Not to mention the effort that goes into reading the 64-page manual to understand how to set up and troubleshoot the node.
Installing a SHARC into the same sensor requires plugging in the M12 5 PIN cable from the sensor into the SHARC. Then you connect to the SHARC over Bluetooth from your browser using sharc.tech or using our iPhone app Sharc Studio and configure the sensor type, edge detection, and MQTT broker the signal information should be published.
Adapter to "Hub"
From the "adapter" to the "hub" we find major differences in application, installation, and troubleshooting. First question; who reading this knows how to troubleshoot a 900MHz RF signal? Raise your hand... OK, that's what I thought. Now, who knows how to ping an IP address? If you don't I'll teach you...
ping 192.168.111.1
Pinging 192.168.111.1 with 32 bytes of data:
Reply from 192.168.111.1: bytes=32 time=22ms TTL=64
Reply from 192.168.111.1: bytes=32 time=30ms TTL=64
Reply from 192.168.111.1: bytes=32 time=3ms TTL=64
Reply from 192.168.111.1: bytes=32 time=3ms TTL=64
Ping statistics for 192.168.111.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 3ms, Maximum = 30ms, Average = 14ms
We got a reply and the time it took was anywhere from 3 milliseconds to 30 milliseconds. Good job.
Second question: how do you read all of the signals from the DXM? How do you read all of the signals from an MQTT Broker? To read the signals from the DXM you must read the 64-page rocket science manual to understand how to set the the Modbus registers so you can write an application that will read them so you can display them or use something like Node-RED and their Modbus nodes which can still take a while.
To read all of the signals from an MQTT Broker you can use an MQTT client like MQTT Explorer or Sharc.tech which can run in the cloud or on-premise and can display each topic or SHARC respectively.
领英推荐
Hub to Node-RED
From the "Hub" to Node-RED the largest difference is with Banner Wireless you have to read the Modbus registers that you calculated earlier (Register?number?=?I/O#?+?(Node#?×?16)) and with the SHARC you simply subscribe to the MQTT topic (sharc/{{sharc_id}}/evt/io/{{sensor_name}}).
Here's a spreadsheet of the Modbus mapping for one of the IO points in the DXM. Makes sense right....?
Subscribing to the SHARCs MQTT published topic in Node-RED.
The Point
In the words of the great Dr. Stone (link to one of my favorite Japanese Anime) installing, configuring, and troubleshooting the SHARC is ten billion percent easier than the Banner Wireless infrastructure. With the SHARC it will be easier to find someone to install and troubleshoot than it will be for the Banner wireless. The skill set to install, configure, and troubleshoot the SHARC is much easier to find in today's workforce.
Devil's Advocate
In all fairness let me say that the DX80 and DXM hardware infrastructure has a place out there in the industry. I have of course simplified and shortened this article for brevity's sake. When we implemented the Banner Wireless infrastructure at this client there weren't many, if any, simpler options at the time (which is why we created the SHARC). Now there are quite a few. I still believe that the SHARC is one of the better options out there. Someday in 2024, it will be the best option....who wants more than one data point from the SHARC!?
Interested in purchasing?
You can contact us directly through our Contact Us page if you're looking for bulk discounts or need to order through a purchase order. Or order straight from our secure store.
More Information
YouTube: Sharc Introduction
We build Smart Factories.
1 年Bro, you only had to read one manual. I had to read four.
We build Smart Factories.
1 年You didn’t talk about the process of resetting the part count when a job changed. I think it went something like this: - job change event - confirm node status register is healthy, somewhere a value of 128 - write 5392 to the status register - confirm 5392 was written to the status register - write 0 to the status register - confirm part count dropped to 0
We build Smart Factories.
1 年I do have to say that I did make a new friend through the Modbus mapping exercises. He kept track of -1/+1 on register vs address for me. Took a few tries to keep it straight.