Week 27:

Starting out this week, I decided it was time to add some extra data into the blockchain. At station 5 - the pneumatic press station, the PLCs gather the amount of force the press produces in Newtons and also provides the pressure inside the muscles at this pressing force. Station 6 - the heating station, also sends data to the PLCs with current temperature, target temperature and total heating time.

On reflection, it was probably a bad idea to add extra to upload to the blockchain when the second island's stations were still not uploading to the blockchain properly.

The last two lines after 'Previous Hash' at each block read in the extra data from the PLCs, over the same TCP Server.

Problem:

CPU usage on the laptop for each node is at 25%. Clearly, when the time comes to migrate to the Raspberry Pi's, it's highly likely they won't run properly.

Solution:

After trolling through the code a realised the mainProg() function that reads in the raw data and inputs into the blockchain, was looping unnecessarily when there was no data to be uploaded which just equated to wasted performance. I decided to call the mainProg() function at the end of the TCP Server function so the mainProg() would only run when the server receives data. This cut the CPU usage from 25% to practically 0%.

Problem:

QR Code reading for the Raspberry Pi was not as simple in OpenCV when usage the Raspberry Pi Camera.

Solution:

At first I tried over complicating it but then discovered there was a library for the camera called pyCamera. From that library it was possible to set up a video stream variable that could then talk to OpenCV.

Mounting the camera far above, shown above, allowed the workers to still be able to reach the product to install the circuit board but was also incredibly reliable due to the high resolution of the camera.

The video below was of a QR Code scanning test, earlier in the week.

Problem:

Once the Raspberry Pi's had the blockchain code, the Pi's would keep missing data. The MES would then try to complete a product and get the carrier ready for the next order. Missing data would then stop the product from getting a 'Comp' receipt because the stationHistory array would not match up.

Solution:

I noticed when the scripts were initialising all the arrays, they were taking a considerably long time to start than the laptop was doing. The hunch a got was that when a station was trying to publish data, the script would move on before the message manged to send. This stopped the message sending as the message pending got over written. The solution I found was to just add 300ms timers after each attempted to publish data and that solved it because it forced the scripts to wait.

The final addition to the project is week is a customer user interface. One of the objectives of the project stated that there could be some was of including some sort of payment and order customisation for a customer. I created a bank of unique hashes that could potentially be given to customers after payment as an order token/voucher.

The customer can input the unique hash into the program which will then be sent to a licencing server on one of the Raspberry Pi's. This licencing server has the bank of hashes and if a hash is received that matches one in the bank then the server will send either 'success' or 'fail' in response. If the hash was successful, the customer will be prompted to enter the details of their order in the form 'product code, quantity, customer number'. They would receive their customer number on purchase of the hash token.

The order request gets sent to the MES Message server which processes the order and sends back a reply with the order number.